What is DLL

1. A DLL is a dynamic link library
   • contains code and data
   • can be loaded dynamically at runtime
   • can be shared or reused by multiple programs
2. Most DLL has .dll extension but can use .txt extension as well

   Usage of DLL

3. Multiple programs can share code and data without each program having its own copy
   • Can reduce disk space usage
   • Can reduce memory usage
4. Can defer decision of whether to load functionality until runtime
   • May not always need some functionality
   • To support open-extended extensibility like plugins
5. Maintainability benefits
   • Componentization via DLLs
   • Improvied serviceability (bug fixes, security patching, etc.)
   • Improved maintability

Difference between Static Libraries and DLL

A static library (.lib) is linked into the executable at compile time, which means all the required code is embedded directly into the final binary. This will result a larger executable size but ensures the program is self-contained, with no external dependencies. Since the functions are resolved during compilation, there is no runtime overhead for function lookups, making execution slightly faster. However, any updates to the library require recompilation of the entire program.

On the other hand, a dynamic-link library (.dll) is loaded at runtime, allowing multiple programs to share the same code. This significantly reduces the executable size and enables modular updates without recompiling dependent programs. The downside is that DLLs introduce runtime dependecies, meaning the correct DLL version must be available on the system. Additionally, function calls from a DLL involve indirect addressing through an import table, introducing a small performance overhead. DLLs can either implicity linked (via an import library) or explicitly loaded using function like LoadLibrary() and GetProcAddress(), offering greater flexibility in managing dependecies.

Table of comparison between Static Library and DLL

How to create DLL

Create a hello word version of a DLL using

• __declspec(dllexport): Marks the function sayHello as exported.
• DllMain(): The entry point of the DLL, called when it’s loaded/unloaded.

#include <windows.h>
//Exported Function
__declspec(dllexport) void sayHello() { MessageBox(0, "Hello from DLL!", "DLL Message", MB_OK); } 
// Entry Point 
BOOL APIENTRY DllMain(HMODULE hModule, DWORD ul_reason_for_call, LPVOID lpReserved) { 
	switch (ul_reason_for_call) { 
		case DLL_PROCESS_ATTACH: 
			break; 
		case DLL_PROCESS_DETACH: 
			break; 
		} 
	return TRUE; 
}

// COMPILE: cl /LD hello.c user32.lib

And hello.exe that implements DLL

#include <windows.h>
#include <stdio.h>

typedef void (*HelloFunc)();

int main() {
    HMODULE hDll = LoadLibrary("hello.dll");
    if (!hDll) {
        printf("Failed to load DLL\n");
        return 1;
    }

    HelloFunc sayHello = (HelloFunc)GetProcAddress(hDll, "sayHello");
    if (!sayHello) {
        printf("Function not found\n");
        return 1;
    }

    sayHello(); // Call DLL function

    FreeLibrary(hDll);
    return 0;
}

// COMPILE: cl main.c

Types of Linking DLL (Explicit and Implicit)

When creating DLL, there are two ways to link with the client application or runner, implicit and explicit. Here is the difference;

The inside of DLL

1. DLL File Structure
   • DOS Stub
   • PE Signature
   • COFF File Header
   • “Optional” Header
   • Section Header
   • Sections 0..N
2. Use dumpbin /headers Hello.dll -> prints out contents of COFF headers
3. Optional Header -> contains magic numbers, entry point, base address, alignment information, RVA
4. Section Header -> contains code (.text), virtual address
5. Use dumpbin /rawdata /section:.text Hello.dll -> view hex bytes of .text section
6. Use dumpbin /disasm /section: .text Hello.dll -> view assembly instruction
7. Use dumpbin /rawdata /section: .rdata Hello.dll -> view read only data section
8. Use dumpbin /exports Hello.dll: -> view export directory and available functions
9. Use dumpbin /dependents PrintGreeting.exe -> view dependecies
10. Use dumpbin /imports PrintGreeting.exe -> view imports

Addressing Within A DLL

The process of DLLs loaded into memory along with an executable based on this memory layout diagram:

1. Loading process:
   • When executable that uses DLL is lauched, the Windows loader first loads the EXE at a random base address in the user space
   • Then it examines the EXE’s import table to find relevant DLLs that is needed
   • The DLls are loaded into memory at their own randomly chosen base addresses (ASLR - Address Space Layout Randomization)
2. Dynamic-Base DLLs:
   • From the image showing “Dynamic-base DLLs” section specifically because modern DLLs are built to be position-independent
   • It can loaded at any available addresss in memory
   • It allows multiple programs to share the same DLL code in memory while having different base addressess
3. Memory references:
   • When your executable calls a DLL function, it doesn’t use absolute address
   • Instead, it uses: Import Address Table (IAT) for function lookups, Relative Addressing for internal DLL references
   • The loader fixes up these addresses during load time
4. Address Space Layout:
   • The executable gets it own space at the top
   • DLLs are loaded in their own section below the executable
   • Process heap and thread stacks get their own regions
   • Everything above the dotted line is user space, accessible to the program
   • Below the line is kernel space, protected from user programs

Lets say in the exe contains a code snippet of this:

int result = displayNumber(); //displayNumber is a function from DLL

The actual process is:

• Loader sees displayNumber() in import table
• Finds the DLL and loads it at an available address
• Updates the IAT with the actual memory address of displayNumber()
• When code runs, it looks up the real address from IAT
• Jumps to that address to execute the DLL function

This is the reason why DLLs need to be position-independent as the code must work regardless of where the DLL is loaded in the memory space. This works because DLL addressing use RVA (Relative Virtual Addressing), which is an offset from the base address where the DLL is loaded.

Here is the address resolution process:

Address in memory = DLL Base Address + RVA

Take this an example:

• If DLL base address is 0x10000000
• Function RVA is 0x1234
• Actual address will be 0x10001234 (0x10000000 + 0x1234)

The process of how loader (exe) uses RVA:

• DLL file contains Export Directory Table
• Table lists function names and their RVAs
• When loading:
  1. Loader places DLL at some base address
  2. Adds this base to each RVA
  3. Creates Import Address Table (IAT) with actual address

Example of Export Table Structure:

Export Directory:
Function: displayNumber
RVA: 0x1234
Name RVA: 0x5678
Ordinal: 1

So, when the loader (exe) wants to call displayNumber(), it will looks up RVA in export table and then adds the current DLL base address. Next, updates IAT with the final address then it able to use it for function calls.

This is the beauty of RVA which makes DLL position-independent while maintaining all internals references correctly, regardless of where the DLL is actually loaded in memory.

Known DLL

reg query "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs"

Relocations in DLLs

When a DLL is compiled, it has a preferred base address. However due to ASLR (Address Space Layout Randomization) or address conflicts, it may needed to loaded elsewhere. This is where relocations come in – they allow a DLL to adjust its absolute address dynamically when loaded at a different base address.

How Relocations Works:

1. Relocation Section (.reloc)
   • The .reloc section contains Base Relocation Table entries.
   • These entries specify which memory addresses need adjustments if the DLL is loaded at a different base.
   • The OS loader uses this table to fix absolute addresses at runtime.
2. When Are Relocations Needed?
   • If a DLL is loaded at its preferred base address, no relocations are needed.
   • If it is loaded at a different address, the OS must adjust memory references.
   • Without the .reloc section, the DLL will fail to load if ASLR forces it to a new base.
3. How Relocations Are Applied:
   • The loader calculates the new base address where the DLL is mapped.
   • It finds all absolute addresses listed in the relocation table.
   • It applies the formula: ``New Address = Original Address + (New Base - Preferred Base)`
   • It modifies the necessary memory locations accordingly.
4. Types of Relocations:
   • IMAGE_REL_BASED_HIGHLOW (common for x86/x64) → Modifies a 32-bit address.
   • IMAGE_REL_BASED_DIR64 (used in 64-bit binaries) → Modifies a 64-bit address.
   • IMAGE_REL_BASED_ABSOLUTE → Placeholder; no actual relocation needed.
5. Disabling Relocations (/FIXED Flag):
   • If a DLL is compiled with /FIXED, it won’t have a .reloc section.
   • This means it must be loaded at its preferred base address.
   • If another module occupies that address, the DLL cannot be loaded and will cause an error.

Entry Point of DLL (AKA DllMain)

DllMain is a special entry point function for DLLs, is the same as C Main function but for DLLs. Here is how:

BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved)

The hinstDLL is a handle to the DLL, is the same one that will be returned from LoadLibrary.

DllMain is called by the system in these situations (fdwReason):

• DLL_PROCESS_ATTACH (1):
  • Called when DLL is loaded into process
  • Good for one-time initialization
  • If returns FALSE, DLL load fails
• DLL_PROCESS_DETACH (0):
  • Called when DLL is unloaded
  • Use for cleanup operations
  • lpvReserved is NULL for FreeLibrary, non-NULL for process termination
• DLL_THREAD_ATTACH(2):
  • Called when process creates a new thread
  • Skipped if DisableThreadLibraryCalls() was called
• DLL_THREAD_DETACH(3):
  • Called when thread exits normally
  • Use for thread-specific cleanup

For lpvReserved parameter, it gives a little extra information:

• For process attach: It is null if DLL loaded via LoadLibrary; non-null if loaded as implicit dependency
• For process detach: It is null if DLL unloaded via FreeLibrary; non-null if the process is terminating

Returns TRUE on success; FALSE on failure

Static Analysis of DLLs

==TODO==

Dynamic Analysis DLLs

==TODO==

Analysis of A Simple DLL Injection

==TODO==