DEV Community: iamsopotatoe

How I load an exe directly into memory without touching disk — manual PE mapping

iamsopotatoe — Wed, 06 May 2026 12:15:13 +0000

most people think running an exe means writing it to disk first. it doesn't.

as part of building TinyLoad, a Windows PE packer, I had to write a PE loader that maps an executable directly into memory and runs it without ever creating a file. here's how it works.

what is a PE file

PE (Portable Executable) is the format Windows uses for .exe and .dll files. it's basically a structured blob with a header describing how to load it, followed by sections containing code, data, resources etc.

to run a PE file manually you have to do what the Windows loader does — but yourself, in memory.

step 1: parse the headers

every PE starts with a DOS header, then an NT header. the NT header tells you everything you need:

SizeOfImage — how much memory to allocate
ImageBase — where the linker expected the binary to live
AddressOfEntryPoint — where to jump to start execution
SizeOfHeaders — how much of the front to copy as-is

IMAGE_DOS_HEADER* dos = (IMAGE_DOS_HEADER*)data.data();
IMAGE_NT_HEADERS64* nt = (IMAGE_NT_HEADERS64*)(data.data() + dos->e_lfanew);

step 2: allocate memory and copy sections

allocate a block of memory the size of the image, then copy the headers in. after that, iterate the section table and copy each section to its virtual address:

void* base = VirtualAlloc(NULL, nt->OptionalHeader.SizeOfImage,
    MEM_COMMIT | MEM_RESERVE, PAGE_EXECUTE_READWRITE);

memcpy(base, data.data(), nt->OptionalHeader.SizeOfHeaders);

IMAGE_SECTION_HEADER* sect = IMAGE_FIRST_SECTION(nt);
for (int i = 0; i < nt->FileHeader.NumberOfSections; i++) {
    if (sect[i].SizeOfRawData > 0)
        memcpy((BYTE*)base + sect[i].VirtualAddress,
               data.data() + sect[i].PointerToRawData,
               sect[i].SizeOfRawData);
}

step 3: fix relocations

the linker assumed the binary would load at ImageBase. if it lands somewhere else (which it usually does since ASLR), every absolute address in the binary is wrong by delta = actual_base - preferred_base.

the relocation table tells you exactly which addresses need fixing:

size_t delta = (size_t)base - nt->OptionalHeader.ImageBase;
if (delta != 0) {
    auto* rel = (IMAGE_BASE_RELOCATION*)((BYTE*)base + relDir->VirtualAddress);
    while (rel->VirtualAddress > 0) {
        WORD* list = (WORD*)(rel + 1);
        DWORD count = (rel->SizeOfBlock - sizeof(IMAGE_BASE_RELOCATION)) / sizeof(WORD);
        for (DWORD i = 0; i < count; i++) {
            if ((list[i] >> 12) == IMAGE_REL_BASED_DIR64) {
                size_t* p = (size_t*)((BYTE*)base + rel->VirtualAddress + (list[i] & 0xFFF));
                *p += delta;
            }
        }
        rel = (IMAGE_BASE_RELOCATION*)((BYTE*)rel + rel->SizeOfBlock);
    }
}

step 4: resolve imports

the import directory tells you which DLLs the binary needs and which functions to load from each. iterate the import descriptors, load each DLL, resolve each function by name or ordinal, and write the function addresses into the import address table:

auto* imp = (IMAGE_IMPORT_DESCRIPTOR*)((BYTE*)base + impDir->VirtualAddress);
while (imp->Name) {
    HMODULE mod = LoadLibraryA((char*)((BYTE*)base + imp->Name));
    auto* thunk = (IMAGE_THUNK_DATA64*)((BYTE*)base + imp->FirstThunk);
    auto* orig  = (IMAGE_THUNK_DATA64*)((BYTE*)base + imp->OriginalFirstThunk);
    while (orig->u1.AddressOfData) {
        if (IMAGE_SNAP_BY_ORDINAL64(orig->u1.Ordinal)) {
            thunk->u1.Function = (size_t)GetProcAddress(mod,
                (char*)(orig->u1.Ordinal & 0xFFFF));
        } else {
            auto* name = (IMAGE_IMPORT_BY_NAME*)((BYTE*)base + orig->u1.AddressOfData);
            thunk->u1.Function = (size_t)GetProcAddress(mod, name->Name);
        }
        thunk++; orig++;
    }
    imp++;
}

step 5: jump to entry point

using EntryPoint = void(WINAPI*)();
EntryPoint entry = (EntryPoint)((BYTE*)base + nt->OptionalHeader.AddressOfEntryPoint);
entry();

that's it. the exe runs directly from the allocated memory block, no file on disk, no Windows loader involved.

where this is used in TinyLoad

TinyLoad packs your exe with LZ77 compression and VM encryption. when the packed stub runs, it decrypts and decompresses the original exe in memory, then calls this loader directly. the original exe never exists as a file — it goes straight from encrypted bytes to running process.

full source (single .cpp file, no deps): https://github.com/iamsopotatoe-coder/TinyLoad

I built a PE packer with a custom VM that randomizes its own instruction set every build — single .cpp file, no deps

iamsopotatoe — Tue, 05 May 2026 13:26:48 +0000

PE packers are one of those things that sound complex until you actually build one. then they sound complex again but for different reasons.

I built TinyLoad — a Windows PE packer in a single C++ file with no external dependencies. v3 just shipped and the main change is replacing rolling XOR with a custom virtual machine for decryption.

what it does

you give it an exe. it spits out a new exe that:

stores your original exe compressed and VM-encrypted inside itself
at runtime, spins up a tiny VM interpreter, runs the decryption bytecode, and loads the result directly into RAM via manual PE mapping

the packed exe never writes anything to disk. the original binary just materializes in memory and runs.

why a VM instead of XOR

rolling XOR is trivially broken. an analyst sets a breakpoint on VirtualAlloc, runs the stub, and dumps the decrypted payload from memory. takes about 30 seconds. the decryption loop is native x86 and immediately recognizable to any disassembler.

the VM changes the problem completely. instead of decrypting with native x86 instructions, the stub runs a custom bytecode interpreter. the decryption logic is stored as VM bytecode — not x86. there's no native decryption loop to find.

more importantly: the opcode table is randomly shuffled at pack time and baked into the binary. every packed file has a completely different instruction set. an analyst can't reuse their work across builds. they have to reverse the interpreter first, then figure out what the bytecode is doing.

how the VM works

20 opcodes: loads, moves, arithmetic, bitwise ops, memory read/write, jumps, halt. nothing exotic.

at pack time:

generate a random permutation of the 20 opcode IDs
emit the decryption program using the shuffled opcode table
encrypt the payload with the matching key
store: opmap + bytecode + encrypted payload

at runtime:

read the opmap from the binary
run the interpreter against the bytecode
the bytecode decrypts the payload byte by byte
load and execute

the cipher is a 128-bit stream cipher using rotl/rotr key mixing. the keys are embedded as immediates directly inside the VM program — there are no separate key fields in the file format.

the compression

custom LZ77 with hash-chain matching, 64KB sliding window, and lazy evaluation. runs on the raw PE first, then VM encryption goes on top. on a 3MB test exe it compressed down to ~878KB before encryption, so the final packed output was ~1.9MB including the ~1MB stub.

PE files compress well because of their structure — repeated import patterns, padding sections, predictable headers.

single file, no dependencies

the whole thing compiles with:

g++ -o TinyLoad.exe TinyLoad.cpp -static -O2 -s

no cmake, no vcpkg, no submodules. the LZ77, VM interpreter, bytecode emitter, PE loader, and resource cloner are all in one ~400 line .cpp file.

usage

TinyLoad.exe --i myapp.exe --vm --c

--vm for VM encryption, --c for LZ77 compression. you need at least one.

what's next

v4 is going to be PE-aware compression — preprocessing the binary structure before LZ77 to get better ratios on code sections specifically. probably also a more complex key schedule inside the VM program.

source: https://github.com/iamsopotatoe-coder/TinyLoad

Why I Built My Own Windows Installer in C#

iamsopotatoe — Wed, 12 Nov 2025 18:39:24 +0000

Ive been working on C# projects lately, and I kept running into the same problem: making a simple installer was way too complicated. NSIS, Inno Setup, WiX etc.. were way to complicated.

So I decided to build my own: Flex Installer.

What it does:

Downloads your app from Dropbox (GitHub support coming soon)

Installs it on Windows

Adds an uninstaller entry in Windows Settings

Fully customizable via a config file

Its simple: customize the config file to your liking and add your dropbox link and done!

Its open source on GitHub: https://github.com/iamsopotatoe-coder/Flex-Installer

Still in early development but it works.

Id love to hear feedback, suggestions, or ideas for features from anyone!