Beyond good ol’ Run key, Part 25

January 28, 2015 in Anti-Forensics, Autostart (Persistence), Compromise Detection, Forensic Analysis, Malware Analysis

I have already covered persistence mechanisms that rely on localization features implemented by popular programming platforms (MFC and Visual Basic). These features support localization efforts by automatically loading language-specific DLLs anytime a program written in any of these platforms starts.

You may (or not) be wondering if there is more to it.

What may immediately come to mind here is a simple question: what about Delphi (or more broadly: what about Borlandish apps)?

When the Borlandish application is executed it queries very characteristic registry keys that you may see in the Process Monitor anytime you start f.ex. a Delphi application:

  • HKCU\Software\Borland\Locales
  • HKLM\Software\Borland\Locales
  • HKCU\Software\Borland\Delphi\Locales

Other (newer) Borlandish applications may include not only Delphi reference, but also Code Gear and Embarcadero:

  • HKCU\Software\CodeGear\Locales
  • HKCU\Software\Embarcadero\Locales

and query them as well. These keys are queried for an entry which is a full path of the executed application e.g. for c:\foo.exe it could be:

  • HKCU\Software\Borland\Locales
    • c:\foo.exe = abc

If such entry exists, it should contain a value maximum 5 bytes long and identify a file extension of the requested localization library. In our example it is ‘abc’. The file extension will then be appended to the file name of the application (after removing the original file extension, typically ‘.exe’). Notably, if the entry is not there, or more than 5 bytes long the application will try to use the value of a Deafult key under

  • HKCU\Software\Borland\Locales
    • {Default} = def

If none of the 2 values exist, the file extension for the localization DLL will be based on the current locale for the calling thread e.g. for English it could be .ENU, .EN.

Once the file extensions are sorted the program will call LoadLibraryEx API and attempt  to load the localization DLL as follows:

  • <appname>.<file extension> if Locale registry entries exist
  • <appname>.ENU – if the above fails
  • <appname>.EN – if the above fails

Also, as a side effect of the way LoadLibraryEx works, the API will query for the following DLL names and will load them if .ENU/.EN files don’t exist (respectively):

  • <appname>.ENU.DLL
  • <appname>.EN.DLL

The good news is that all these libraries are loaded using LoadLibraryEx functions with the LOAD_LIBRARY_AS_DATAFILE flag. So, while Borlandish apps do support external localization DLLs they load them properly i.e. not as a code, but as data. As far as I can tell this was implemented correctly from the very first version of Delphi that supported localized DLLs.

That pretty much kills the idea of using such DLLs as a persistence mechanism.

Well sort of, you could always use a pattern matching to find a DLL loading routine in the existing Borlandish binary and patch it. Patch requires a flip of a single bit to disable LOAD_LIBRARY_AS_DATAFILE (0x2) – this would enable loading of localization DLLs as a code.  Quite honestly, this is lame and while it could be a good idea a decade ago or so, now any modification to an existing .exe will most likely trigger an AV alert (since it looks like a possible viral infection).

So, while it’s not really a persistence mechanism it was still worth exploring even if just for the sake of ruling it out and understanding what these Locales keys are.

If you are a bit disappointed I can only say that the topic of this post leads us directly to the part 26. It will be about yet another Frankenstein’s Monster 🙂

Stay tuned.

Comments are closed.