How do I rename a DLL but still allow the EXE to f

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

Is your customer drunk? Of all the crazy requirements in all the world ...

Back in my glory days as a syphilitic madman midnight C++ programmer I used to add my DLLs to my .exe file as resources. Then at startup I'd unpack them and write them to the exe's directory. Your program can decide on the DLL filename at this point. Really go for the obfuscation thing - start with a random number, concatenate some Edward Lear poetry and xor it with your favourite German double-barrelled noun; should do for starters anyway. Then load the DLL using LoadLibrary().

enum ukOverwrite {dontOverwriteAnything = 0, overwriteWhateverPresent = 1};
void unpackResource (ukOverwrite param1, int resourceID, const char* basePath,  
const char* endFilename)
{
  char* lpName = 0;
  lpName += resourceID;
  HRSRC MrResource = FindResource (0, lpName, "file");

  if (MrResource)
  {
    HGLOBAL loadedResource = LoadResource (0, MrResource);
    if (loadedResource)
    {
      void* lockedResource = LockResource (loadedResource);
      if (lockedResource)
      {
        DWORD size = SizeofResource (0, MrResource);
        if (size)
        {
          unsigned long creationDisposition = CREATE_NEW;
          if (param1 == overwriteWhateverPresent)
            creationDisposition = CREATE_ALWAYS;

          char filepath [MAX_PATH];
          strcpy (filepath, basePath);
          strcat (filepath, endFilename);
          HANDLE rabbit = CreateFile (filepath, GENERIC_WRITE, 0, 0,  
creationDisposition, 0, 0);
          if (rabbit != INVALID_HANDLE_VALUE)
          {
            DWORD numBytesWritten = 0;
            int wf = WriteFile (rabbit, lockedResource, size, &numBytesWritten,  
0);
            CloseHandle (rabbit);
          }
        }
      }
      FreeResource (loadedResource);
    }
  }
}

Answer 3

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;
}

Answer 4

you'll have to use Assembly.Load and have the obfuscated assembly name saved in the app.config.

either that or use the same approach that plug-ins use. have a class in your assembly implement an interface that you search for from your app in every assembly in a certain directory. if found loat it. you'll of course have to not obfuscate the Interface name.

Answer 5

1. Use LoadLibrary (Read new name from registry) is one option.
2. You can rename your visual studio project to have a generalised name (which your customer has no objection).
3. The DLL itself needs to be renamed. But the lib still carries the old name? Did you cross verify using DUMPBIN /ALL *.lib > file. grep for the old DLL name. Is it still there? Check *.def file in the project. Did you rename the LIBRARY "OLDNAME"

Otherwise, there is no reason for the LIB to carry old DLL name.

Answer 6

I created a little python script to rename native dlls properly. It generates a new lib file for you to use in project linking in MSVC.

https://github.com/cmberryau/rename_dll/blob/master/rename_dll.py.

You'll need to use the developer command prompt for it to work of course.