Loading Windows PE Files, Off the Books

This research started as a personal two-week project inspired by Process DoppelGanging. It was not sponsored, assigned, or done for a customer. The work started with two practical Windows systems-security questions:

1. Can useful loader code be written in normal C with stock compilers, without turning the whole project into handwritten assembly?
2. What loader state must be reconstructed before a memory-only PE behaves like an ordinary Windows-loaded image?

What This Research Does

This work separates three things that are often mixed together in discussions of memory-only PE execution:

1. Where the PE bytes come from.
2. What kind of Windows memory view gets created.
3. Which loader-created process state must exist before a real program runs correctly.

The first result is a stock-compiler loader artifact. The project builds a self-contained position-independent loader blob from normal C and MSVC section ordering. The blob carries the loader stub, runtime configuration, API lookup material, and the PE payload.

_{Figure 1. MSVC section ordering keeps the loader body in a bounded stub range that can be dumped as position-independent code.}

_{Figure 2. The final blob carries the stub, API hash material, runtime configuration, and PE payload.}

The second result is a loader-state model. Copying headers and sections is not enough for many Windows programs. A memory-only loader also has to reconstruct the user-mode state normally prepared by the Windows loader: process identity, LDR metadata, dependency state, activation context, appcompat state, CFG/XFG state, unwind state, and cross-process image-base assumptions used by Chromium-style targets.

_{Figure 3. The loader-state model separates byte mapping from process identity, LDR metadata, dependencies, SxS, appcompat, CFG/XFG, unwind state, and cross-process image-base assumptions.}

The third result is an image-source experiment with two profiles. The VirtualAlloc profile creates a MEM_PRIVATE image and is used as the baseline for loader-state reconstruction. The SMB-over-QUIC profile opens a loopback MUP path backed by a loader-owned SMB server and asks Windows to map it through the ordinary SEC_IMAGE path, producing a payload-backed MEM_IMAGE view.

_{Figure 5. The SMB-over-QUIC experiment serves payload bytes from the loader stub while Windows creates the image view through MUP and the Memory Manager.}

SMB-over-QUIC is not presented here as a new Memory Manager primitive. It does not change MmCreateSection, Code Integrity, ETW, or kernel image-load callback semantics. The point is narrower: a loopback SMB redirector file object can supply the bytes for a normal image section without a payload file on the target NTFS volume in the measured setup.

If you prefer a whitepaper-style write-up, read final-paper.pdf.

Disclaimers

This repository is published for education, defensive research, and personal lab work. It studies Windows loader behavior, which is useful for defensive analysis but must be handled carefully.

Use it only in an isolated lab on systems you own or have permission to test. The code and notes are research material, not an offensive service, product, or operational toolkit.

Research Topics

The project grew into four research topics.

#	Topic	Core question
1	Classic C Shellcoding	Can we build useful Windows shellcode from normal C with stock compilers?
2	By the Book - Manual Mapping Modern Microsoft Binaries	What loader state must a manual mapper recreate for modern signed Microsoft binaries?
3	SMB-over-QUIC - The Missing Localhost SMB Server	Can localhost SMB-over-QUIC give us a diskless SEC_IMAGE backing store?
4	Chromium ASLR - Cross-Process Image-Base Contract	Why does Chromium fail when the parent image base differs from the child image base?

Repository Layout

Path	Purpose
src/	Loader, SMB-over-QUIC components, test targets, and Visual Studio projects.
research/	Technical notes organized by topic.

Build

Build from a Visual Studio Developer PowerShell at the repository root:

msbuild .\src\Loader_v145.vcxproj /p:Configuration=Release /p:Platform=x64 /m /v:minimal
msbuild .\src\Loader_v145.vcxproj /p:Configuration=Debug /p:Platform=x64 /m /v:minimal

The supported public target is x64. Generated binaries are written under build/v145/<Configuration>/x64/.

Optional test harnesses can be built the same way from their Visual Studio project files under src/.