2

Sorry if this is a basic question, as I'm very new at this.

I'm trying to get an .exe to load a dummy .dll. I've created an example .dll project in VC++ 2019, added the functions listed in the .exe's import table, made sure to declare extern "C" __declspec(dllexport), using a hex editor changed the ordinals in the import table to match the new .dll and made sure the filename matches. Still, when I run the .exe with this .dll in its folder, I get this kind of error message:

The procedure entry point MyFunction2 could not be located in the dynamic link library MyDll.dll

I've rechecked that I haven't missed any of the function names in the import table, and that none of the function names in the .dll got mangled. Are the offsets for functions entry points in the .dll file hardcoded in the PE format? What am I missing that could cause the application to reject the .dll?

Edit: The program doesn't import LoadLibrary, CreateProcess, ShellExecute nor any other functions I know which handle processes and libraries.

  • Why are you changing ordinals ? It seems the import is being done by name and not ordinal. – Igor Skochinsky May 2 at 21:42
  • @IgorSkochinsky yeah I think so too, but I tried to get everything to match in case that would make it work. – Liz May 3 at 19:42
2

It is possible that the program is employing mittigations against DLL sideloading and won't load the DLL from current directory. Check Secure loading of libraries to prevent DLL preloading attacks.

You can check what paths the program is actually trying to use with Process Monitor (see Using Process Monitor to dynamically detect nonsecure loads in the linked article).

P.S. to force program.exe to check for DLLs in the current directory, create an empty file named program.exe.local. However, this may not be enough if it's calling LoadLibrary explicitly.

| improve this answer | |
  • I've ran ProcessMonitor, it seems the program is loading it immediately (or almost immediately) directly from the current directory, which I expected (not a Windows DLL). It seems all the DLLs (including the dummy DLL) are opened and loaded into memory and then as the program is about to start, it dies with this message. The program doesn't import LoadLibrary, CreateProcess etc. – Liz May 3 at 19:42
  • @Liz: can you add the (trimmed) output of dumpbin /exports MyDll.dll and dumpbin /imports program.exe to the question? – Igor Skochinsky May 3 at 22:29
1

there is a way more easy solutuion:

use Microsoft Detours: https://github.com/microsoft/Detours

very well developed, works out of the box, easy compileable on VStudio shell with nmake (just follow the build instructions), many small examples

can detours some (or all) of the Dll-Functions to your own code without replacing the original Dll or patching the executable, even possible to intercept any function/method you know the adress of

the setdll and withdll are very helpfull

| improve this answer | |
0

I know this is not a direct answer, but I cant comment with my amount of rep here.

Maybe the loading application is checking the DLL name, that is stored inside of the loaded DLL. There is a field somewhere in the header, that contains the name of the dll at compile time iirc.

It could be possible, that the dll is lazy loaded and the error message is just misleading, as the error was thrown during dll loading and not during retrieving of the named function.

Its the first field on the section table header

Section Table header PE File

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.