Delay load libraries to mitigate WoW64 dependency

[doomedraven]

The reason capemon_x64.dll was failing (while the stripped down capemin_x64.dll succeeded via HeavensGate.h) is because the full Capemon depends heavily on higher-level libraries like advapi32.dll, ws2_32.dll, crypt32.dll, shlwapi.dll, ole32.dll, shell32.dll, setupapi.dll, oleaut32.dll, netapi32.dll, and bcrypt.dll. In the early process initialization phase (CREATE_SUSPENDED), the Windows loader will refuse to load capemon_x64.dll because it cannot resolve those specific imports, causing a silent crash or load failure.

By adding the <DelayLoadDLLs> configuration and delayimp.lib strictly to the x64 Native configurations, we successfully deferred the resolution of those external modules. Because they are mapped as Delay-Loaded, the Windows image loader ignores them entirely when HeavensGate.h natively injects capemon_x64.dll.

The Dependency Initialization Race:

Because we delay-loaded advapi32.dll and user32.dll, any APIs calling those components (GetUserNameA, ConvertSidToStringSidW) invoke the MSVC delay-loader which attempts to LoadLibraryW inside the current context.
Executing LoadLibraryW inside embryonic injection threads fundamentally crashes because the NT kernel hasn't properly executed LdrpInitializeProcess for the target processes, halting subsystem bootstrapping (yielding Error 0x13d / 1114 ERROR_DLL_INIT_FAILED).

The Solution: Deferred Initialization

We removed the hazardous hkcu_init() and log_init() execution from capemon.c's DllMain. Both routines are safely routed to execute lazily using InterlockedCompareExchange barriers:

1. log_init(...) executes seamlessly inside write_log_data exactly when the first log_api hook invokes.
2. hkcu_init() executes securely right at the point when g_hkcu.hkcu_string is sequentially queried inside the normalize_registry_path mapping procedures.

This guarantees NO non-native loader lock subsystems ever trigger inside the remote thread context!

Hook Resolution on Delayed Libraries

If these DLLs (like advapi32.dll) are bypassed during capemon's initialization, how are their hooks planted?
Because GetModuleHandle("advapi32.dll") returns NULL during set_hooks(), the hook resolution effectively skips it gracefully without causing any crashes.
Later, when malware actually executes an imported function, MSVC or the OS evaluates LoadLibrary. When the DLL boots inside a fully native host, the Windows Loader triggers Capemon's natively implemented LdrRegisterDllNotification listener (New_DllLoadNotification()).
This flawlessly receives the module load event and invokes set_hooks_dll dynamically, mapping all active hooks perfectly transparently without requiring strict eager mapping loops inside DllMain!

[doomedraven]

Here is the exact technical breakdown and why their idea is the perfect final piece to the puzzle:

1. The Impact of Delay-Loading on Hooks

Because we added delayimp.lib, the Windows OS loader skips initializing those higher-level DLLs. As a result, when Capemon's DllMain calls set_hooks(), things like advapi32.dll and ws2_32.dll won't be mapped in memory yet.

Capemon's hooking engine uses GetModuleHandle to find the base addresses for its initial setup. If GetModuleHandle returns NULL because the DLL is delay-loaded, those initial hooks will be skipped resulting in lost telemetry until the malware explicitly triggers a LoadLibrary that Capemon intercepts later.

2. The Solution: Conditionally Force-Loading in DllMain

By manually calling LoadLibrary on these specific modules only when running in Native 64-bit mode, we force them back into memory just in time for set_hooks() to find them, preserving original behavior while protecting WoW64 via Heavens Gate.

capemon.c already resolves IsWow64Process during DllMain via the set_os_bitness() function. We can use the result of that check directly:

// Note: In capemon.c, the variable is currently called "is_64bit_os" 
// but it is populated directly by IsWow64Process.
// - In a Native x64 process: is_64bit_os == FALSE
// - In a WoW64 process (Heavens Gate): is_64bit_os == TRUE

if (!is_64bit_os) {
    // We are in a FULL native 64-bit process. 
    // Eagerly load the delayed DLLs so set_hooks() catches them immediately.
    LoadLibraryW(L"advapi32.dll");
    LoadLibraryW(L"user32.dll");
    LoadLibraryW(L"ws2_32.dll");
    LoadLibraryW(L"crypt32.dll");
    LoadLibraryW(L"shlwapi.dll");
    LoadLibraryW(L"ole32.dll");
    LoadLibraryW(L"shell32.dll");
    LoadLibraryW(L"setupapi.dll");
    LoadLibraryW(L"oleaut32.dll");
    LoadLibraryW(L"netapi32.dll");
    LoadLibraryW(L"bcrypt.dll");
} else {
    // We are in WoW64 mode using Heavens Gate! 
    // Do nothing. Leave them delay-loaded so we don't crash the early 
    // loader thread. When the WoW64 process loads them later, Capemon's 
    // DllLoadNotification callback will catch them and hook them safely.
}

// Proceed to call set_hooks();

3. Safety Check: Loader Lock

Usually, calling LoadLibrary inside DllMain is a risk for OS Loader Lock deadlocks. However, since these DLLs were already statically linked before this PR (meaning the OS was already locking and initializing them in this exact same process phase), explicitly calling LoadLibrary here carries the exact same risk profile as the codebase has always had. It successfully solves the WoW64 boot-crash while ensuring Native 64-bit malware drops zero API hooks!

[doomedraven]

The reason capemon_x64.dll was failing (while the stripped down capemin_x64.dll succeeded via HeavensGate.h) is because the full Capemon depends heavily on higher-level libraries like advapi32.dll, ws2_32.dll, crypt32.dll, shlwapi.dll, ole32.dll, shell32.dll, setupapi.dll, oleaut32.dll, netapi32.dll, and bcrypt.dll. In the early process initialization phase (CREATE_SUSPENDED), the Windows loader will refuse to load capemon_x64.dll because it cannot resolve those specific imports, causing a silent crash or load failure.

By adding the <DelayLoadDLLs> configuration and delayimp.lib strictly to the x64 Native configurations, we successfully deferred the resolution of those external modules. Because they are mapped as Delay-Loaded, the Windows image loader ignores them entirely when HeavensGate.h natively injects capemon_x64.dll.

The Dependency Initialization Race:

Because we delay-loaded advapi32.dll and user32.dll, any APIs calling those components (GetUserNameA, ConvertSidToStringSidW) invoke the MSVC delay-loader which attempts to LoadLibraryW inside the current context.
Executing LoadLibraryW inside embryonic injection threads fundamentally crashes because the NT kernel hasn't properly executed LdrpInitializeProcess for the target processes, halting subsystem bootstrapping (yielding Error 0x13d / 1114 ERROR_DLL_INIT_FAILED).

The Solution: Deferred Initialization vs Pure NTAPI

We had two options to fix this: rewrite the setup algorithms to exclusively utilize raw ntdll native APIs, or defer the logic entirely outside of the DllMain constraint.
We selected Deferred Initialization because rewriting high-level subsystem operations (like SID-to-String translation or environmental bindings) via raw NT structures carries massive version-to-version fragility. Additionally, bypassing the injection DllMain execution space guarantees absolute safety against the underlying OS Loader Lock.

We removed the hazardous hkcu_init() and log_init() execution from capemon.c's DllMain. Both routines are safely routed to execute lazily using InterlockedCompareExchange barriers:

1. log_init(...) executes seamlessly inside write_log_data exactly when the first log_api hook invokes.
2. hkcu_init() executes securely right at the point when g_hkcu.hkcu_string is sequentially queried inside the normalize_registry_path mapping procedures!

This guarantees NO non-native loader lock subsystems ever trigger inside the remote thread context, ensuring perfectly stable delay-load transitions.