Add/bof dll stomp - BOF concurrency compatibility

[Loki-rt]

Summary

The DLL Stomping implementation for BOFs was converted from a design based on a global singleton with CRITICAL_SECTION to a design based on dynamic per-instance contexts (BOF_STOMP_CTX*), additionally introducing a pool of reusable contexts for asynchronous BOFs.

1. Core architectural change: global → dynamic per-instance context.

Upstream (add/bof-dll-stomp)

bof_stomp.h declares a single global variable:

extern BOF_STOMP_CTX g_BofStomp;
BOOL InitBofStomp(const char* sacrificialDll, int method);

Now

The global variable and the embedded CRITICAL_SECTION are removed. The struct is annotated and the BOOL pooled field is added:

BOF_STOMP_CTX* BofStompCreate(const char* sacrificialDll, int method);
void           BofStompDestroy(BOF_STOMP_CTX* ctx);

BofStompCreate returns a BOF_STOMP_CTX* allocated with MemAllocLocal. BofStompDestroy restores .text/.pdata, frees the saved sections, unmaps the DLL, and releases the struct.

Reason: the singleton prevented concurrent execution of asynchronous BOFs across multiple threads. With independent contexts, each BOF carries its own stomping state without contention.

---

2. Context pool for asynchronous BOFs (Boffer)

Upstream

Boffer::Init() called InitBofStomp(...) once, creating the singleton. Asynchronous BOFs competed for the same g_BofStomp.lock.

Now

Boffer.h adds:

#define BOF_STOMP_POOL_MAX 32

struct StompSlot {
    BOF_STOMP_CTX* ctx;
    BOOL           inUse;
};

and in Boffer:

StompSlot        stompPool[BOF_STOMP_POOL_MAX];
int              stompPoolSize;
CRITICAL_SECTION stompPoolLock;

BOF_STOMP_CTX* AcquireStompSlot();
void           ReleaseStompSlot(BOF_STOMP_CTX* ctx);

Boffer::Init() now calls the new getBofStompDllsAsync() function to retrieve the list of DLLs and creates one BOF_STOMP_CTX per DLL, marking them as pooled = TRUE.

AsyncBofContext receives the BOF_STOMP_CTX* stompCtx field. When executing an async BOF, RunBof acquires a slot from the pool using AcquireStompSlot(); if no free slots are available, it falls back to VirtualAlloc. Once execution finishes, ReleaseStompSlot returns the slot back to the pool without destroying it.

Boffer::~Boffer() properly destroys all pool slots.

---

3. Signatures propagated throughout the entire execution stack.

The following functions change their signatures to carry stompCtx instead of accessing the global:

function	Upstream	now
AllocateSections	(coffFile, pHeader, mapSections, outMapFunctions)	+ BOF_STOMP_CTX* stompCtx
CleanupSections	(mapSections, maxSections, mapFunctions)	+ BOF_STOMP_CTX* stompCtx
ExecuteProc	(entryFuncName, args, argsSize, pSymbolTable, pHeader, mapSections)	+ BOF_STOMP_CTX* stompCtx

---

4. New configuration function: getBofStompDllsAsync

config.h :

int getBofStompDllsAsync(const char*** outArray);

config.tpl :

Implementation that parses the BOF_STOMP_DLL_NAME_ASYNC macro at runtime (format: "dll1.dll|dll2.dll|dll3.dll") using a static buffer and idempotent lazy initialization. Falls back to {"xpsservices.dll", "Hydrogen.dll", "actxprxy.dll"} if the macro is not defined.

---

5. Secondary refactorings

AllocateSections — single contiguous VirtualAlloc

In the upstream implementation, each COFF section was allocated with a separate VirtualAlloc call (+ an additional call for mapFunctions). Now, the total size of all sections is calculated using 16-byte alignment (ALIGN_UP) and a single VirtualAlloc call is performed. mapFunctions is placed at the end of the block. CleanupSections only frees mapSections[0] (the base of the block) and no longer iterates through the remaining sections.

FindTextSection — extracted helper

The code used to locate the .text section inside a loaded PE was duplicated across the LoadLibraryEx and NtCreateSection paths. The logic has now been extracted into FindTextSection(PVOID base, PVOID* outTextBase, SIZE_T* outTextSize), and both paths invoke it.

Fix for IMAGE_REL_AMD64_ADDR32NB relocation

The upstream implementation calculated the relative offset using index arithmetic that could become incorrect for non-contiguous sections. It now implements the proper calculation (pc-relative offset = target_addr - (reloc_site + 4)) with 32-bit range validation.

Asynchronous BOF output

The upstream implementation set ctx->state = ASYNC_BOF_STATE_FINISHED and packaged the completion packet inside the BOF thread itself (under lock). A new state, ASYNC_BOF_STATE_DONE (0x4), has now been introduced: the BOF thread transitions to DONE, and the monitor loop is responsible for packaging and sending the completion packet during its iteration, simplifying synchronization.

BofOutputToTask was also refactored to use tls_CurrentBofContext directly instead of relying on the indirect IsAsyncBofThread() + AsyncBofOutput() flow.

---

UI

Quick demonstration: concurrent asynchronous + synchronous BOF execution.

• keylog start: asynchronous BOF
• kerbeus monitor /interval:1: asynchronous BOF
• clipboard: synchronous BOF

In Memory

• Main thread: 5928
• keylog start: thread 5676
• kerbeus monitor: thread 2504

thread 5676

DLL STOMPING: xpsservices.dll

thread 2504

DLL STOMPING: actxprxy.dll

---

To verify that DLL STOMP also works in synchronous mode, we execute SharpHound.exe using execute-assembly so we have enough time to observe what happens in the Beacon’s main thread.

DLL STOMPING: wmp.dll

---

Now we execute SharpHound.exe again with execute-assembly, but this time in asynchronous mode.

DLL STOMPING: mfc42.dll

---

If the asynchronous BOFs finish execution, the DLLs are returned to the pool and become available again for future asynchronous BOF executions. Keep in mind that up to 32 DLLs can be added to the pool.