d7ead/mkpivmGeneriere polymorphe, positionsunabhängige virtuelle Maschinen (PIVMs) aus beliebigem x86/x64-Shellcode.
Lesen Sie das Forschungspapier (geschrieben für 1.0.0).
mkPIVM ist ein polymorpher, positionsunabhängiger Shellcode-Virtualisierer für Windows x86 und x64 (Linux bald).
Gib ihm rohen Shellcode. Er gibt einen weiteren rohen Blob aus: eine kleine virtuelle Maschine, die eine angehobene, im Ruhezustand verschlüsselte Version deiner ursprünglichen Befehle interpretiert. Die Ausgabe ist selbst positionsunabhängiger Code und läuft überall, wo der ursprüngliche Shellcode laufen würde, von einem Remote-Thread-Loader bis zu einem Code-Cave-Umweg. Jeder pro-Seed-Regler variiert unabhängig: Chiffrefamilie, Register-Slot-Layout, Opcode-zu-Handler-Permutation, Dispatcher-Topologie, Junk-Gadget-Muster, Einfügepunkte für IR-Obfuskation. Zwei Builds aus derselben Eingabe teilen weniger als hundert zufällig übereinstimmende Bytes aus zig Kilobyte.
Warum: Nativer Shellcode ist signatur-trivial. Ihn in eine pro Instanz einzigartige VM mit einer pro Instanz einzigartigen Chiffre zu hüllen, hinterlässt im Ruhezustand nichts Nützliches, und das Anheben der Befehle zu Bytecode stellt eine weitere Wand zwischen die Bytes auf der Platte und jeden Disassembler, der weiß, wie x86 aussieht. Soweit ich aus einer Literaturdurchsicht sagen kann, liefert kein öffentliches Tool exakt diese Pipeline: roher PIC rein, roher polymorpher VM-PIC raus. Also erwähnte ich das in dem Forschungspapier, das es verlangte. Um ehrlich zu sein, wenn ich richtig liege, dass das vorher niemand (öffentlich) getan hat, und ich bin ziemlich zuversichtlich, dann bin ich überrascht. Nichtsdestotrotz, viel Spaß.
mkpivm.exe shellcode.bin --arch x64 -o out.bin
Deine PIVM ist heiß und bereit. Das ist der einfachste Weg. Mehrere andere Modi variieren, wie aggressiv die ursprünglichen Instruktionen virtualisiert werden, ob die Ausgabe ein eigenständiger Blob oder eine gepatchte PE ist und ob der Lift überhaupt läuft.
# Showcase
Ich habe die Belege. Du kannst unten ein Video von mkPIVM in Aktion sehen: Es virtualisiert einen Meterpreter-Stager (übrigens Vanilla) vollständig, injiziert in explorer.exe, und wir fangen einen Callback ab. Natürlich ist das nur ein Beispiel, und mkPIVM kann auf viel mehr angewendet werden, vorausgesetzt, die Instruktionen im Shellcode werden unterstützt. Falls nicht, erstelle ein Issue, schick mir den Shellcode, ich helfe dir.
Siehe [hier](https://github.com/D7EAD/mkPIVM/raw/refs/heads/main/media/mkpivm-showcase.mp4). Liegt in ./media, kann leider nicht eingebettet werden.
Hier ist der VirusTotal-Bericht für genau dieses virtualisierte Sample (Stand 06/04/2026).
<img src="https://assets.kitploit.com/production/public/readmes/7466/3f4a6dbe2777c02fb32f71749a5b1fa2aa324cb0dac2f77d5681bbe3a4e17a81.png">
...und die gepackte Version, nicht einmal virtualisiert, mit deutlich höherer Entropie.
<img src="https://assets.kitploit.com/production/public/readmes/7466/47f68372e31a2c24fa49eb71648adbdf8944977db90d645df337125c1bdfa8e3.png">
Hier sind die Ergebnisse eines normalen Cobalt-Strike-Beacons zum Vergleich.
<img src="https://assets.kitploit.com/production/public/readmes/7466/76e2107589cd2b1b65c846a671aed173aa5e6d89630f5e9d283d99c546a2d566.png">
Es wurde sorgfältig auf die Entropie-Telemetrie der Ausgabe dieses Tools geachtet, was zu Shellcode führt, dessen Entropie geringer ist als die typischer Windows-WinAPI-DLLs (außerhalb des Packing-Modus), wie z. B. ntdll.dll oder kernel32.dll. Der Entropievergleich sieht ungefähr so aus...
| Datei | Bytes | Entropie |
|------|-------|---------|
| `p_m64.bin` | 3,969 | **7.1181** |
| `msvcrt.dll` | 699,888 | 6.5319 |
| `wininet.dll` | 2,724,528 | 6.4934 |
| `shell32.dll` | 7,839,992 | 6.3639 |
| `kernel32.dll` | 836,232 | 6.3597 |
| `crypt32.dll` | 1,538,632 | 6.3010 |
| `rpcrt4.dll` | 1,162,672 | 6.2405 |
| `ntdll.dll` | 2,522,104 | 6.1934 |
| `v.bin` | 29,229 | **6.0442** |
## Modi auf einen Blick
| Modus | Flags | Was sich ändert |
|------|-------|--------------|
| Standard | none | Lifte die gesamte Eingabe. Alles wird virtualisiert. |
| Packer | `--pack` | Nicht liften. Eingabe als verschlüsselte Daten verpacken, zur Laufzeit entschlüsseln, hineinspringen. |
| Hybrid | `--ranges A:B,...` | Nur die gewählten Bytebereiche liften. Der Rest bleibt nativ. |
| Stacked | `--pack --ranges A:B` | Den Hybrid-Blob erstellen und dann pack-verpacken. |
| Detour | `--embed-into PE --at RVA` | Einen vorgefertigten Blob nehmen, in eine PE einbetten, einen jmp an der gewählten RVA patchen. |
| Scan | `--scan` | Geeignete `--ranges`-Kandidaten aus dem CFG der Eingabe ausgeben und dann beenden. |
| RX | `--rx` | PAGE_EXECUTE_READ-Blob. Data Island bleibt im Ruhezustand verschlüsselt; PEB-Walker im Blob löst VirtualProtect auf und entschlüsselt an Ort und Stelle bei state_init. |
| RX mit Loader | `--rx --rx-loader-vp` | Wie `--rx`, aber dein Loader übergibt VirtualProtect als erstes Argument des Blobs. Kein PEB-Walker. |
Jeder Modus beachtet `--seed`, `--arch`, `--input-format` und `--format`. Siehe die Abschnitte zu den einzelnen Modi unten für die Build-Pipeline und den Laufzeitablauf.
## Standard-Virtualisierung
Der Lifter durchläuft das gesamte CFG und senkt jede Instruktion auf ein benutzerdefiniertes IR herab. Das IR durchläuft zwei Obfuscation-Durchgänge und dann Codecs, die jede insn in die pro Seed definierte Bytecode-Form kodieren. Die Blocktabelle, Handler-Tabelle und das Data Island sind mit derselben Byte-für-Byte-Stromchiffre verschlüsselt wie der Bytecode. Zur Laufzeit entschlüsselt der Prolog diese drei Bereiche an Ort und Stelle, und die Dispatcher-Schleife holt Bytecode-Bytes einzeln, entschlüsselt sie und leitet sie an einen Handler weiter, der die Arbeit erledigt.
### Build-Pipeline
Schritte, die der Build ausführt, um rohen Shellcode in den erzeugten virtualisierten Blob zu verwandeln, von Anfang bis Ende. _Alle Grafiken unten beziehen sich auf das 1.0.0-Release; sie haben sich seitdem geändert, aber die Idee ist dieselbe._```mermaid
flowchart TB
A[shellcode.bin] --> CFG[CFGBuilder: identify blocks via Zydis disasm + recursive descent]
SEED[seed u64] --> VMC[VMConfig: pick cipher kind, reg perm, opcode map, dispatcher topology]
CFG --> LIFT[LifterRegistry: lower each block to IR]
LIFT --> RBT[resolve_branch_targets: link BR_CC/BR/CALL_VM/LOOP_DEC to target_block_id; synthesize JMP_NATIVE block for any out-of-range jcc]
RBT --> OBF1[obfuscate_ir_dead_inject: 20% per insn-gap, IMM Tmp2/Tmp3 random]
OBF1 --> OBF2[obfuscate_ir_opaque_predicates: 25% per block, split block with IMM Tmp3=0 + TEST + BR_CC NZ random_block, never taken]
OBF2 --> ENC[BytecodeBuilder: each codec emits its variant for this seed]
ENC --> CDATA[compact data island: bytes not covered by any CFG block]
CDATA --> PROMO[promote LEA-fixup target VAs back into data island if CFG put them in code]
ENC --> BTAB[build block table: va_off to bytecode_off pairs]
PROMO --> ECIPH[encrypt data island with cipher_init]
BTAB --> ECIPH2[encrypt block table with cipher_init]
ENC --> ECIPH3[encrypt bytecode per-block with cipher_init reset at each block start]
VMC --> STUB[VMCodeGen::emit_full: prologue, state init, dispatcher tail, handlers, sbox_inv, exit handler]
STUB --> HTAB[handler table: 256 entries, each a 32-bit offset from handler_base; encrypted at rest]
ECIPH --> ASM[finalize: stub + trampolines + sbox_inv + bytecode + data island + block table]
ECIPH2 --> ASM
ECIPH3 --> ASM
HTAB --> ASM
ASM --> OUT[out.bin]