How does an application identify a DLL file

Question

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.

Answer 1

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.

Answer 2

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

Answer 3

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