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.

Ability to load a DLL of your choice anytime someone is connecting to the internet is something that definitely deserves some attention. This is why I will describe here yet another obscure mechanism that can be abused for malicious purposes. Courtesy of Winsock 2 library (ws2_32.dll).

When Winsock library connects to the internet it ‘talks’ to various service providers and probes them for connectivity services. It’s actually pretty complex and I won’t pretend that I fully understand what’s going on there yet there is one thing which this library does that I do understand 🙂

At some stage it attempts to load a DLL as specified by the following Registry key:

HKLM\SYSTEM\CurrentControlSet\Services\WinSock2\Parameters\AutodialDLL

This key is quite obscure and Microsoft only describes it in a context of a very old vulnerability MS06-041.

Turns out that the AutodialDLL entry points to a DLL that WinSock will load anytime it connects to the internet.

The DLL needs to export 3 functions:

• WSAttemptAutodialAddr
• WSAttemptAutodialName
• WSNoteSuccessfulHostentLookup

The result of loading the following registry key:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WinSock2\Parameters] "AutodialDLL"="c:\\temp\\foo.dll"

and dropping the file

c:\temp\foo.dll

(the DLL exports the aforementioned APIs) can be seen below:

The screenshot was taken from a Windows XP system – I simply opened and closed Internet Explorer.

Of course, it works on Windows 10 too – just access to HKLM is slightly more difficult 🙂