Da Li’L World of DLL Exports and Entry Points, Part 1

August 8, 2013 in Malware Analysis

This series is an attempt to bring together in one place various info scattered all over the place about numerous types of DLL Entry Points and DLL Exports. Knowing what functions are exported by specific DLL types helps in both identification of a file and its reverse engineering. Everything below is from a reverse engineer’s perspective i.e. what you see when you open a DLL in a RCE tool e.g. IDA Pro. Information provided here is based on a lot of sources yet it is quite condensed; if you want a nice starter about DLLs instead, please check this Microsoft support article What is a DLL? first.

Since this is by no means an exhaustive list, and as I was researching it I was finding more and more stuff I started getting really insane while trying to make it all correct and nicely hyperlinked so please consider this to be a draft quality a.k.a. a WORK IN PROGRESS. If you spot any mistake please let me know. Thanks and see in you in a Part 2 soon!

Generic Exports

  • .tls
    • Not really an exported function per se, but since it may be present inside PE file I am mentioning it for completeness. Code potentially present inside .tls section (.tls callbacks) is executed on many ‘funny’ occasions. Do read Ange’s article to understand its quirks; it’s seriously @#$%^.
  • DllEntryPoint
    • A pseudo-export (unless really exported and I have actually seen it exported) so you will see it mainly inside programs for analysis e.g. IDA Pro. This is actually an entry point of the Portable Executable (note that on the source code level in high-level languages or RAD tools it is a place holder and it can be customized by a programmer so it can have some ‘funny’ stuff inside); This is where you start analysis, unless an RCE program finds DllMain for you (beware that DllMain can be empty yet DLL can be executing some code via modified DllEntryPoint, or .tls, or obviously – via other exports expected for certain types of DLLs).
  • DllMain
    • A main function for a non-.NET user-mode DLL (32- and 64-bit); does NOT need to be exported, but sometimes is. It is called by DllEntryPoint. If the DLL is written in an assembly language, often has the same address as DllEntryPoint.
  • _CorDllMain
    • NET entry point; it initializes the Common Language Run-Time (CLR) and starts the .NET DLL. It is called internally by DllEntryPoint on OSs not supporting .NET. Sometimes exports named like this are fake.
  • LibMain / LibEntry
    • DLL initialization entry point (16-bit). Newer DLLs use DllMain.
  • DllInstall
    • Can be quite common, handles installation and setup for a DLL. To be executed by regsvr32.exe, a command line argument “/i” needs to be used – as per Microsoft:

To use DllInstall with regsvr32, add a “/i” flag followed by a colon (:) and a string. The string will be passed to DllInstall as the pszCmdLine parameter. If you omit the colon and string, pszCmdLine will be set to NULL.

  • ___DllMainCRTStartup (DLLMainCRTStartup)
    • ¬† Run-time library Startup code. Calls DllMain internally.
  • WEP (_WEP)
    • Exported by old DLLs (16-bit) and is called before the driver DLL is removed from memory (WEP=Windows Exit Program).
  • LangDataCall
    • An export that can be found inside NLS*.dll on Windows 7; the function is called internally by NaturalLanguage6.dll.
  • ___CPPdebugHook
    • A debug export often found in the projects created using Borland C++ Builder (BCB)/ Delphi. It provides a way for a program to communicate with the Borland debugger (note: it’s not a function, but a variable; debugger finds it and writes “2″ changing the internal state of the RTL component which will result in debugger being notified about the events via RaiseException API with a magic value).
  • __GetExceptDLLinfo
    • Another Borland-specific export used by a debugger. This one is actually a function which is called anytime the DLL is attached or a new thread is created.

If it is a lot and it’s confusing think of it this way:

  • DllEntryPoint is like Start
  • DllMain is like WinMain

for .exe files, and a code execution flow for a DLL is as follows:

If kernel mode DLL:

  • DllInitialize
  • then DLL is doing stuff asynchronously
  • then DllUnload when DLL is unloaded

If user mode DLL, .NET:

  • _CorDllMain (if ran on OS supporting .NET)

If user mode either not a .NET DLL, or .NET DLL used on a OS not supporting .NET:

  • .tls callbacks (if exist)
  • then DllEntryPoint
  • then _CorDllMain (if .NET)

CorDllMain

  • then¬† DLLMainCRTStartup (if exists)

___DllMainCRTStartup

  • then either DllEntryPoint or ___DllMainCRTStartup calls DllMain
  • and asynchronously:
    • specifically named exports for specific protocols – see list below for examples
    • .tls callbacks depending on circumstances (loading/unloading, creating/exiting threads)

Comments are closed.