DEV Community: iamsopotatoe

TinyLoad v7 — VEH page-fault decryption and a fully encrypted overlay, what's new in TinyLoad v7.0, my open-source PE packer for Windows

iamsopotatoe — Sun, 31 May 2026 06:44:05 +0000

TinyLoad v7 is out. if you haven't seen it before — it's a PE
packer for Windows. one .cpp file, no dependencies, MIT.
repo here.
v6 killed the switch statement and split the opcode table. v7 goes
after the two things that were still exploitable — a readable
overlay and a dumpable memory image. both are gone now.

VEH page-fault decryption
this is the headline feature. instead of decrypting the payload
into a normal RWX allocation and jumping to it, v7 maps every
section as PAGE_NOACCESS after loading:
cpp// after mapping sections, mark them inaccessible
for each section:
VirtualProtect(page, 0x1000, PAGE_NOACCESS, &old);
vehPageXor(page, 0x1000, g_vehKey, (uintptr_t)page);
a vectored exception handler catches every ACCESS_VIOLATION,
checks if the fault address is inside the payload range, decrypts
the faulting page, and marks it PAGE_EXECUTE_READWRITE:
cppLONG CALLBACK vehHandler(EXCEPTION_POINTERS* ex) {
uintptr_t fault = ex->ExceptionRecord->ExceptionInformation[1];
uintptr_t pg = fault & ~(uintptr_t)0xFFF;
VirtualProtect((LPVOID)pg, 0x1000, PAGE_READWRITE, &old);
vehPageXor((BYTE*)pg, 0x1000, g_vehKey, pg);
VirtualProtect((LPVOID)pg, 0x1000, PAGE_EXECUTE_READWRITE, &old);
// add to LRU cache...
return EXCEPTION_CONTINUE_EXECUTION;
}
a background watchdog thread scans the LRU cache every 50ms and
re-encrypts any page that hasn't been touched in 200ms, setting it
back to PAGE_NOACCESS. the cache holds 256 slots with
thread-safe eviction.
the result is that at any point in time only the currently
executing page (and recently accessed pages) are ever in plaintext
in memory. a full memory dump gives you at most a few hot pages.
the rest is encrypted noise.
each page uses a unique key: g_vehKey ^ (addr >> 12) — so even
if you recover one page's key you can't decrypt the others.

fully encrypted overlay
in v6 the overlay was still partially readable — the signature,
metadata fields, and VM bytecode were sitting in the clear. v7
encrypts everything with per-file stub-derived keys:
[stub binary]
[encrypted Tail struct] — sig, origSz, packSz, flags, dispKey all XOR'ed
[encrypted VM bytecode] — full bytecode blob XOR'ed with stubKey stream
[chunk 0][junk][chunk 1][junk][chunk 2][junk][chunk 3] — payload split into 4
[encrypted tail offset] — 4-byte EOF pointer XOR'ed
the stubKey is derived from a hash of the stub binary itself —
so it's different for every build and can't be precomputed without
the stub. even the 4-byte tail offset at the very end of the file
is encrypted, so the overlay start address isn't readable from a
hex dump.
zero-filler interleaving pads the overlay at a 3:1 ratio giving
roughly 6.73 bits/byte entropy, making it blend visually with
normal PE sections rather than standing out as high-entropy packed
data.

canary integrity chain
8 canary values are embedded in the VM bytecode. each one is
checked in sequence — if any check fails, a corruption mask
escalates from 1 bit to 8 bits and gets XORed into the decrypted
plaintext. tampering with the overlay produces garbage output
rather than a clean crash, which makes it harder to know if your
modification worked.

payload chunk splitting
the payload is split into 4 chunks with random junk gaps of
128–640 bytes between them. automated overlay scanners that look
for a contiguous payload region won't find one.

usage
v7 adds a new --veh flag:
TinyLoad.exe --i myapp.exe --vm --c --veh
build from source:
g++ -o TinyLoad.exe TinyLoad.cpp -static -O2 -s
grab the binary from
releases.

what's left
the main thing still missing is payload stub dependency — making
the payload actively call back into the stub at runtime so a
reconstructed dump is broken without the stub mapped. that's v8.
if you find files it breaks on, open an issue. star helps a lot ❤️
repo: github.com/iamsopotatoe-coder/TinyLoad
blog: iamsopotatoe-coder.github.io/TinyLoad/#blog

TinyLoad v6 — split opcode tables, encrypted dispatch, and control flow flattening

iamsopotatoe — Tue, 26 May 2026 11:40:13 +0000

TinyLoad v6 is out. if you haven't seen it before — it's a PE packer for Windows. one .cpp file, no dependencies, MIT. repo here.

v5 hardened the stub itself with encrypted strings, IAT wiping, and opmap obfuscation. v6 goes after the two biggest remaining fingerprints: the switch statement in the VM interpreter, and the single contiguous opcode table. both are gone.

the problem with a switch statement

every version of TinyLoad up to v5 had a vmRun function with a giant switch(op) dispatching 28 opcode handlers. this is the most fingerprint-able thing in any custom VM — disassemblers recognise the pattern immediately, and once you have the handler layout you can reconstruct what each opcode does without ever running the code.

v6 replaces it entirely with a computed-goto dispatch table using GCC's &&label extension:

static void* s_tbl[32] = {};  // file scope, filled at runtime

// pack time: read live label addresses, encrypt with random key
uint64_t dispKey = rng3();
for (int i = 0; i < 32; i++) {
    uintptr_t addr = (uintptr_t)s_tbl[i];
    s_tbl[i] = (void*)(addr ^ dispKey);
}
// store dispKey in tail

// runtime: decrypt and jump
dispatch:
    uint8_t raw = vmCode[ip++];
    uint8_t sub = raw >> 3, slot = raw & 7;
    uint8_t op = decodeOp(sub, slot);
    void* handler = (void*)((uintptr_t)s_tbl[op] ^ dispKey);
    goto *handler;

the label addresses are never plaintext in the packed binary. the packer reads them from its own running process, XORs them with a random key, and stores the result in the tail struct. the packed stub decrypts and recomputes the table at runtime. there's no static jump table to dump, no switch to fingerprint.

split opcode decoder

v5 had a single 32-entry opmap, encrypted with one FNV-derived key. one key crack = full opcode table.

v6 splits 28 opcodes across four independent 8-entry subtables, each with its own key derived from different slices of the payload and VM bytecode:

// 4 subtables, each XOR-encrypted with independent key
BYTE sub0[8], sub1[8], sub2[8], sub3[8];

// key for each subtable derived from different data slices
uint32_t k0 = fnv(origSz, packSz, vmCode[0..7]);
uint32_t k1 = fnv(packSz, vmCodeSz, payload[0..7]);
uint32_t k2 = fnv(vmCodeSz, origSz, vmCode[8..15]);
uint32_t k3 = fnv(origSz ^ packSz, vmCodeSz, payload[8..15]);

for (int i = 0; i < 8; i++) {
    sub0[i] ^= (uint8_t)(k0 >> (i % 4 * 8));
    sub1[i] ^= (uint8_t)(k1 >> (i % 4 * 8));
    // ...
}

cracking one subtable key reveals at most 8 of 28 opcodes. the other 20 are behind three different keys derived from different data. opcodes are encoded as (subtable_index << 3) | slot — every packed file gets a completely different encoding across all four tables.

staged entry point and control flow noise

tryRun and runInMem are both broken into stages dispatched through function pointer tables — no linear flow to trace:

tryRun: s_chk → s_ld → s_prs → s_vm → s_dc → s_ex
runInMem: sp_hdr → sp_map → sp_reloc → sp_import → sp_go

on top of that, noiseDecrypt() fires at every stage transition and every 64 VM iterations — calling sdec2 on throwaway buffers with random keys. in a dynamic trace the real string decryption calls (the IAT hook lookups) are buried in identical-looking noise. you can't tell which call matters without executing every path.

other stuff in v6

full resource cloning — switched from hardcoded RT_ICON/RT_VERSION/RT_MANIFEST to EnumResourceTypesA, so all resource types survive packing now
LZ compressor fix — found a hash-chain self-loop bug that was silently degrading match quality, compression improved ~2% across tested files
PE loader hardening — SizeOfBlock underflow guard, reloc bounds validation, negative e_lfanew rejection, import thunk iteration cap, better error propagation throughout

current usage

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

build from source:

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

grab the binary from releases.

what's left for v7

the one criticism from the RE community that's still open — making a dump worthless. right now once the payload is decrypted in RAM it's self-contained. making it call back into the stub at runtime so a dump without the stub is broken is the hard problem v7 needs to solve.

also thinking about more opaque predicate variety and bytecode encryption on top of the split subtables.

if you find files it breaks on, open an issue. star helps a lot ❤️

repo: github.com/iamsopotatoe-coder/TinyLoad
blog: iamsopotatoe-coder.github.io/TinyLoad/#blog

don't use this to pack malware — legitimate use only.

TinyLoad v5 — encrypted strings, opmap obfuscation, and IAT wiping

iamsopotatoe — Tue, 19 May 2026 12:02:12 +0000

TinyLoad v5 is out. if you haven't seen the project before — it's a PE packer for Windows. you give it an .exe, it compresses and VM-encrypts it into a self-extracting stub that runs the original entirely in RAM. one .cpp file, no dependencies, MIT. repo here.

v4 added opaque predicates, anti-debug, and section scrambling. v5 is about hardening the stub itself — the code that actually runs when the packed exe launches. three main additions: encrypted API strings, content-derived opmap obfuscation, and IAT wiping post-load.

quick recap

when you run a TinyLoad packed exe, the stub spins up a custom 32-opcode VM interpreter, executes a decryption bytecode program against the payload, then manually maps the original PE into memory and runs it. every packed file gets a randomly shuffled opcode table so the bytecode looks different every time.

v5 makes the stub itself harder to analyse statically.

1. encrypted API strings

in v4 the DLL and function names the stub needs — kernel32.dll, GetModuleHandleA, VirtualAlloc etc — were sitting as plaintext strings in the binary. any static analysis tool would immediately see what APIs the stub calls just from strings view.

v5 XOR-encrypts all of them:

static const BYTE _ed_k32[]  = {0x3A,0x37,0x21,0x3A,0x30,0x3A,0x64,0x6A,0x77,0x3E,0x37,0x30};
static const BYTE _ed_gmha[] = {0x70,0x5D,0x4D,0x77,0x54,0x58,0x48,0x52,0x5A,0x08,0x20,0x2C,0x27,0x28,0x20,0x07};
static const BYTE _ed_gpa[]  = {0x06,0x27,0x37,0x14,0x37,0x29,0x24,0x09,0x2D,0x2E,0x39,0x29,0x3E,0x3D};

each one decrypts at runtime with a rolling XOR:

static char* sdec2(char* buf, const BYTE* enc, size_t n, uint8_t k) {
    for (size_t i = 0; i < n; i++) buf[i] = enc[i] ^ (uint8_t)(k + i);
    buf[n] = 0; return buf;
}

no readable strings in the binary anymore. strings view on the packed output is clean.

2. opmap obfuscation via FNV hash

this one directly addresses feedback from the r/ReverseEngineering community who pointed out that the opmap decode table was sitting plaintext right behind the stub — effectively a silver platter for static analysis.

v5 derives a per-file XOR mask for the opmap using FNV-1a hash, seeded from the file's own content:

static void xorOpmap(BYTE* opmap, const Tail& t, const BYTE* vmCode, const BYTE* pay) {
    uint32_t h = 0x811C9DC5u;
    auto feed = [&](uint8_t b) { h ^= b; h *= 0x01000193u; };
    for (int i = 0; i < 4; i++) {
        feed((uint8_t)(t.origSz >> (i * 8)));
        feed((uint8_t)(t.packSz >> (i * 8)));
        feed((uint8_t)(t.vmCodeSz >> (i * 8)));
    }
    DWORD vmLim = t.vmCodeSz < 32 ? t.vmCodeSz : 32;
    if (vmCode) for (DWORD i = 0; i < vmLim; i++) feed(vmCode[i]);
    DWORD payLim = t.packSz < 32 ? t.packSz : 32;
    if (pay) for (DWORD i = 0; i < payLim; i++) feed(pay[i]);
    for (int i = 0; i < NUM_OPS; i++) {
        feed((uint8_t)i);
        opmap[i] ^= (uint8_t)((h >> 24) ^ (h >> 16) ^ (h >> 8) ^ h);
    }
}

the hash feeds on origSz, packSz, vmCodeSz, and the first 32 bytes of both the VM bytecode and the payload. the resulting mask is different for every single packed file — you can't extract the opmap from one sample and apply it to another. the stub runs xorOpmap at unpack time to recover the real table before passing it to the VM.

3. IAT wiping post-load

after the stub manually maps the packed PE into memory and resolves all its imports, v5 zeroes out the import structures:

// kill recovery
imp->OriginalFirstThunk = 0;
imp->Name = 0;
imp++;

// ...
nt->OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_IMPORT].VirtualAddress = 0;
nt->OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_IMPORT].Size = 0;

once imports are resolved the IAT entries aren't needed anymore. zeroing them means if someone dumps the process from memory after load, the import directory is gone — no DLL names, no function names, no reconstruction path from the dump alone.

4. dead code and junk VM instructions

v5 also adds dead code functions in the stub (__attribute__((used)) to force the compiler to keep them despite -O2) and junk NOP and self-mov instructions scattered through the VM bytecode to inflate and confuse disassembly:

eOp(bc,enc,NOP_I);              // junk
eOp(bc,enc,MOV_I); eR(bc,6); eR(bc,6); // junk — mov r6, r6

minor individually but they add noise on top of everything else.

current usage

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

build from source:

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

or grab the binary from releases.

if you run into files it doesn't pack correctly, open an issue. and if you find it useful, a star helps a lot ❤️

repo: github.com/iamsopotatoe-coder/TinyLoad
blog + changelogs: iamsopotatoe-coder.github.io/TinyLoad/#blog

i added opaque predicates, anti-debug, and section obfuscation to my PE packer published

iamsopotatoe — Fri, 15 May 2026 08:21:29 +0000

TinyLoad v4 is out — here's what i added and why it actually matters:

so TinyLoad v4 just dropped. if you don't know TinyLoad — it's my open-source PE packer for Windows. you throw an exe at it, it compresses and encrypts it with a custom VM, and spits out a self-extracting stub that runs the original entirely in RAM. no temp files, no installer, nothing written to disk. one .cpp file, no dependencies. here's the repo.

v3 was already a decent jump because that's when the custom VM came in — randomised opcode shuffling so every packed file speaks a different instruction set. v4 is more focused. three specific additions that each solve a different analysis problem:

VM opaque predicates
anti-debug checks
PE section name obfuscation

let me actually explain each one instead of just listing them.

opaque predicates — confusing static analysis

when someone's trying to reverse a packed binary statically, they're usually building a control flow graph — figuring out which code actually runs and in what order. an opaque predicate is a branch where the outcome is predetermined (always taken, or never taken) but looks like it could go either way without executing anything.

in v4 the VM bytecode that gets generated for decryption starts with this:

// load two constants into registers
eOp(bc,enc,LDI_I);  eR(bc,6); e64(bc,0x1337);
eOp(bc,enc,LDI_I);  eR(bc,7); e64(bc,0x1338);

// compare them — r8 will always be 1 since 0x1337 < 0x1338
eOp(bc,enc,CMP_I);  eR(bc,8); eR(bc,6); eR(bc,7);

// jump if nonzero — always jumps
eOp(bc,enc,JNZ_I);  eR(bc,8);
int opqPatch = (int)bc.size(); e32(bc, 0);

// this HLT is dead code — never reached
eOp(bc,enc,HLT_I);

// real decryption loop starts here

the halt never actually executes. but a static analyser that doesn't evaluate the constants just sees a branch with two possible destinations — one being an immediate halt before any decryption happens. it has to either run the code to know the truth, or assume both paths are possible.

what makes this play nicely with the rest of TinyLoad is that opcodes are randomly shuffled at pack time. so 0x1337 and 0x1338 appear as completely different byte values in every packed file. no two samples look the same, which makes pattern matching across samples a lot harder too.

anti-debug — making dynamic analysis awkward

static analysis not working? fine, let's just run it in a debugger. v4 adds two checks before the loader does anything:

bool isDebugged() {
    if (IsDebuggerPresent()) return true;

    BOOL remote = FALSE;
    CheckRemoteDebuggerPresent(GetCurrentProcess(), &remote);
    if (remote) return true;

    return false;
}

IsDebuggerPresent catches the obvious stuff — x64dbg, WinDbg attached locally. CheckRemoteDebuggerPresent goes a level deeper and catches kernel debuggers and remote sessions that the first check doesn't see.

if either one fires, the loader just returns false silently. no error, no crash, no messagebox. the packed exe runs and does absolutely nothing. that kind of silent failure is more disorienting than a visible error because it's not immediately obvious why nothing happened.

section obfuscation — breaking heuristic scanners

PE packers often get detected not from what the code does but from what the file looks like — and section names are one of the things scanners latch onto. if a packer consistently leaves behind a section called .tinyld or whatever the compiler decided to name things, that's a trivial signature.

after writing the packed output, v4 goes back into the PE headers and renames every section:

void scrambleSections(Bytes& data) {
    IMAGE_NT_HEADERS64* nt = (IMAGE_NT_HEADERS64*)(data.data() + dos->e_lfanew);
    IMAGE_SECTION_HEADER* sect = IMAGE_FIRST_SECTION(nt);

    const char* names[] = {".text", ".data", ".rdata", ".bss", ".idata"};
    for (int i = 0; i < nt->FileHeader.NumberOfSections; i++) {
        memset(sect[i].Name, 0, 8);
        strncpy((char*)sect[i].Name, names[i % 5], 8);
    }
}

the payload itself lives in an overlay after the sections, not inside any of them, so renaming changes nothing about how the exe actually runs. but from the outside the file looks like any other plain Windows binary — .text, .data, .rdata. nothing to fingerprint.

putting it all together

grab the binary from releases or build it:

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

usage hasn't changed much from v3:

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

--vm is the custom VM encryption (now with the opaque predicates and anti-debug baked in). --c is LZ77 compression. compression runs first, then VM encryption goes on top — so the compressed stream's patterns get hidden too. you need at least one of the two flags.

if you find files it breaks on, open an issue. and if you use it, a star really does help ❤️

repo: github.com/iamsopotatoe-coder/TinyLoad
blog + changelogs: iamsopotatoe-coder.github.io/TinyLoad/#blog

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!