TinyLoad v6 Enhances PE Packer with Obfuscation and Split Opcodes

TinyLoad, the lightweight PE packer for Windows, has reached version 6 with major upgrades designed to thwart reverse engineering. Built as a single .cpp file with no dependencies and released under the MIT license, this tool now includes advanced obfuscation techniques to obscure critical components of packed executables.

Eliminating the Signature Switch Statement

Previous versions of TinyLoad relied on a large switch statement within the VM interpreter to dispatch 28 opcode handlers. While functional, this structure is highly recognizable by disassemblers, which often flag such patterns as indicators of custom virtual machines. The developers addressed this vulnerability in v6 by replacing the switch mechanism entirely.

The new approach leverages GCC’s &&label extension to create a computed-goto dispatch table. This method stores handler addresses as encrypted values, decrypted only at runtime using a randomly generated key. The encrypted table is reconstructed dynamically, ensuring no static jump table remains in the binary. The implementation uses XOR encryption to mask label addresses, which are derived from the packer’s own process memory and further obfuscated with a key stored in the binary’s tail section.

static void* s_tbl[32] = {}; // Runtime-filled label addresses
uint64_t dispKey = rng3();

// Encrypt label addresses at pack time
for (int i = 0; i < 32; i++) {
  uintptr_t addr = (uintptr_t)s_tbl[i];
  s_tbl[i] = (void*)(addr ^ dispKey);
}

// Runtime decryption and jump execution
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;

Splitting Opcode Tables for Greater Resilience

Version 5 encrypted a single 32-entry opcode table with a unified key, creating a single point of failure. If the key was compromised, the entire opcode mapping could be reconstructed. TinyLoad v6 divides the 28 opcodes into four independent 8-entry subtables, each protected by a unique encryption key derived from distinct slices of payload data and virtual machine bytecode.

Each subtable uses a different XOR key generated via a modified FNV hash function, incorporating variables such as original and packed file sizes, virtual machine code segments, and payload data. This fragmentation means that even if one subtable is decrypted, only a subset of opcodes becomes visible, while the remaining three subtables remain secured by separate keys. Opcodes are encoded as (subtable_index << 3) | slot, further randomizing the opcode layout per packed file.

BYTE sub0[8], sub1[8], sub2[8], sub3[8];

// Independent keys derived from diverse data sources
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]);

// Apply per-byte XOR encryption to each subtable
for (int i = 0; i < 8; i++) {
  sub0[i] ^= (uint8_t)(k0 >> (i % 4 * 8));
  sub1[i] ^= (uint8_t)(k1 >> (i % 4 * 8));
  // ... apply to sub2 and sub3
}

Introducing Control Flow Noise and Staged Entry Points

TinyLoad v6 also disrupts static analysis by breaking execution flows into multiple stages, each dispatched through function pointer tables. The tryRun function now follows a sequence: s_chk → s_ld → s_prs → s_vm → s_dc → s_ex, while runInMem proceeds through a different staged path. This segmented structure eliminates linear execution traces, complicating attempts to follow the control flow graph.

Additionally, the packer injects noise into the analysis process. A function called noiseDecrypt() executes at every stage transition and approximately every 64 virtual machine iterations. It performs unnecessary decryption operations on throwaway buffers using random keys, making it difficult to distinguish genuine decryption calls from decoy operations. In dynamic analysis, identifying which function calls are legitimate becomes a challenge without full execution coverage.

Additional Security and Compatibility Improvements

Beyond obfuscation, TinyLoad v6 includes several under-the-hood fixes and enhancements:

• Resource Cloning: The packer now dynamically enumerates and clones all resource types using EnumResourceTypesA, replacing hardcoded handling for icons, versions, and manifests. This ensures compatibility with applications using custom resources.

• LZ Compression Fix: A previously undiscovered hash-chain self-loop bug in the LZ compressor was corrected. Testing shows an average 2% improvement in compression efficiency across a range of files.

• PE Loader Hardening: New safeguards address potential vulnerabilities such as SizeOfBlock underflow, relocation bounds violations, negative e_lfanew values, and capped import thunk iterations. Error propagation has also been improved for better diagnostics.

Building and Using TinyLoad v6

To pack an executable with TinyLoad v6, users can run:

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

The tool can be compiled from source using:

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

Precompiled binaries are available in the project’s release section on GitHub.

Looking Ahead to TinyLoad v7

The development team has identified one critical area for improvement in the next version: making memory dumps useless. Currently, once a payload is decrypted in memory, it operates independently. The goal for v7 is to design a mechanism where the unpacked code continues to interact with the stub, rendering dumps incomplete or non-functional without the original stub present.

Future enhancements may also include introducing more opaque predicate logic and adding an additional layer of bytecode encryption on top of the split subtables. For developers encountering compatibility issues, the team encourages opening issues on the repository. Community support through stars and feedback is welcomed to guide further development.

TinyLoad remains focused on legitimate use cases, and the developers emphasize that it should not be used for malicious purposes.