maxDcb-DreamWalkers/docs/memorymodule-loader-build-notes.md

MemoryModule Loader Build Notes

Summary

memoryModuleLoader is not used as a normal executable in the production path. CMake links it as a PE file so exe2h can extract its .text section into bin/memorymodule_exe_<arch>.h. That extracted byte array is the shellcode loader consumed by DreamWalkers.py.

Because only the code section is extracted, the loader must behave like standalone shellcode:

• execution starts at the Loader routine,
• required Windows APIs are resolved at runtime from the target process,
• the loader must not depend on CRT startup or external runtime libraries,
• architecture-specific call/unwind assumptions must be validated with the generated shellcode, not only by launching the linked PE.

Linker Constraints

/ENTRY:Loader makes Loader the PE entrypoint instead of the default C runtime startup. memoryModule/order.txt also keeps Loader first in .text, which keeps the extracted section aligned with the shellcode entrypoint expectation.

/NODEFAULTLIB prevents implicit CRT and default library dependencies. The shellcode path cannot rely on imported runtime startup code because exe2h only preserves .text.

/ORDER:@memoryModule/order.txt keeps the entry routine first in the generated code layout. The order file currently contains only Loader; that is intentional.

/FIXED and /DYNAMICBASE:NO are used for x86 and x64 so the linked image does not rely on normal PE loader ASLR or relocation behavior for the shellcode extraction path. The extracted loader still needs to be position-independent through its own code and runtime API resolution. ARM64 currently omits these flags, so changes here should be treated as architecture-sensitive.

/SAFESEH:NO is used on x86 because the loader uses a custom entrypoint and shellcode-oriented layout instead of a normal CRT-linked image. x64 and ARM64 do not use SAFESEH.

Compile Constraints

The loader compile options favor a compact, shellcode-friendly C image:

• /Zp8 keeps the expected structure packing.
• /Gy, /Os, and /O1 favor small function-level code generation.
• /GR- disables RTTI.
• /Oi allows intrinsic expansion.
• /GS- avoids stack cookie helpers that would add runtime dependencies.
• /EHa keeps SEH-compatible exception handling behavior for the test/debug path.

Validation Rule

After changing these options, regenerate the headers and run the loader tests for each affected architecture. A normal executable launch is not enough validation because the real path executes the extracted .text bytes.