How do I rename a DLL but still allow the EXE to find it?

Question

We have a DLL which is produced in house, and for which we have the associated static LIB of stubs.

We also have an EXE which uses this DLL using the simple method of statically linking to the DLL's LIB file (ie, not manually using LoadLibrary).

When we deploy the EXE we'd like the DLL file name to be changed for obfuscation reasons (at customer's request).

How can we do this so that our EXE still finds the DLL automagically?

I have tried renaming the DLL and LIB files (after they were built to their normal name), then changing the EXE project settings to link with the renamed LIB. This fails at runtime, as I guess the name of the DLL is baked into the LIB file, and not simply guessed at by the linker replacing ".lib" with ".dll".

In general, we do not want to apply this obfuscation to all uses of the DLL, so we'd like to keep the current DLL project output files are they are.

I'm hoping that there will be a method whereby we can edit the DLL's LIB file, and replace the hardcoded name of the DLL file with something else. In which case this could be done entirely within the EXE project (perhaps as a pre-build step).

---

Update: I find that Delay Loading does not work, as my DLL contains exported C++ classes. See this article.

Are there any alternatives?

Answer 1

Using the LIB tool (included with visual studio) you can generate a lib file from a def file. Asuming your dll source does not include a def file, you have to create one first. You can use dumpbin to assist you. For example: dumpbin /exports ws2_32.dll

In the output you see the names of the functions exported. Now create a def file like this:

LIBRARY WS2_32 EXPORTS     accept      @1     bind        @2     closesocket @3     connect     @4 

The @number is the ordinal in the dumpbin output

Use LIB /MACHINE:x86 /def:ws2_32.def to generete the lib file.

Now you can easily modify the def file, and generate a new libfile each time you rename your dll.

you can verify the libfile using dumpbin: dumpbin /exports ws2_32.lib. You should get the same output as the original lib file.

Answer 2

Here is a nice alternative approach: delay loading.

When building your application, link it all as you would with the original DLL name (but set the origional dll to be delay loaded).

You then deploy the DLL renamed as per your customers request.

Your EXE will attempt to locate the DLL using the original name and not the renamed version so will fail, however with delay loading you can intercept this fail and load the renamed version yourself and then have the native windows loader resolve everything as if nothing changed.

Read the article Linker Support for Delay-Loaded DLLs and see the Delay Hook example.

Your delay hook might be something like below:

FARPROC WINAPI delayHook( unsigned dliNotify, PDelayLoadInfo pdli ) {     switch( dliNotify )     {         case dliNotePreLoadLibrary:             if( strcmp( pdli->szDll, "origional.dll" ) == 0 )                 return (FARPROC)LoadLibrary( "renamed.dll" );             break;         default:             return NULL;     }      return NULL; }