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]

Der Runtime-Nonce-Trick ist der entscheidende Anti-Memory-Scan-Schachzug: Die Handler-Tabelle liegt im Speicher, XOR-verknüpft mit einem Wert, der aus `rdtsc XOR cipher_init` abgeleitet wird, sodass zwei Prozesse, die dasselbe Blob laden, byteweise unterschiedliche Handler-Tabellen enthalten. Der Dispatcher demaskiert sie bei der Lookup-Zeit mit einem zusätzlichen XOR.

## Packer-Modus: `--pack`

Der umgekehrte Kompromiss. Der Lifter wird nicht ausgeführt. Der ursprüngliche Shellcode wird verschlüsselt in die Dateninsel gelegt, und die IR ist ein einziges synthetisches `JMP_NATIVE imm=0`. Der Prolog überspringt bewusst die Entschlüsselung der Dateninsel, die der Standardmodus sofort ausführt. Stattdessen entschlüsselt der einzige JMP_NATIVE-Handler beim ersten Auslösen die Dateninsel an Ort und Stelle, setzt ein Markierungsbyte und übergibt dann die Kontrolle an Byte 0 des nun im Klartext vorliegenden Shellcodes. Der Shellcode wird von dort nativ ausgeführt.

Funktioniert mit jedem Shellcode, unabhängig von der Lifter-Abdeckung. Nützlich für stageless Cobalt, exotische syscall-lastige Payloads und alles, was zu groß oder zu ungewöhnlich zum Virtualisieren ist. Verliert die Pro-Instruktion-Virtualisierungsverteidigung, behält aber die vollständige VM-Polymorphie pro Seed auf dem Wrapper.

### Build-Pipeline

Wie `--pack` den ursprünglichen Shellcode als verschlüsselte Dateninsel hinter einem synthetischen IR-Programm mit einer einzigen Instruktion verpackt.```mermaid
flowchart TB
    A[shellcode.bin] --> SKIP[skip CFG build, skip lift]
    SEED[seed u64] --> VMC[VMConfig polymorphism axes as in default mode]
    SKIP --> SYN[synthesize 1-insn IRProgram: one block with JMP_NATIVE Imm 0 Width Q]
    SYN --> SETF[VMConfig::set_pack_mode true, set_data_island_size shellcode.size]
    SETF --> ENC[BytecodeBuilder encodes the 1 insn into ~35 bytes]
    ENC --> CDATA[data island = entire shellcode bytes verbatim]
    CDATA --> ECIPH[encrypt shellcode bytes with cipher_init as the data island]
    ENC --> ECIPH2[encrypt bytecode + block table + handler table]
    VMC --> STUB[VMCodeGen::emit_full]
    STUB --> FLAG[data_island_init_flag byte starts at 0 because pack_mode true]
    STUB --> ASM[finalize layout]
    ECIPH --> ASM
    ECIPH2 --> ASM
    FLAG --> ASM
    ASM --> OUT[out.bin]

Die verzögerte Data-Island-Entschlüsselung ist nur im Pack-Modus verfügbar. Im Standard- und Hybridmodus führt der geliftete Code VM LOAD/STORE auf Data-Island-Bytes mitten in der Ausführung aus und benötigt diese von Anfang an im Klartext, daher behandelt der Prolog dies eager. Im Pack-Modus gibt es genau einen Konsumenten der Data-Island, den nativen Escape nach dem synthetischen JMP_NATIVE, sodass die Entschlüsselung bis dahin warten kann.

## Hybridmodus: `--ranges A:B,C:D`

Gezielte Virtualisierung. Wählen Sie Byte-Bereiche in der Eingabe aus, die geliftet werden sollen. Alles andere bleibt als die ursprünglichen nativen Bytes in der Ausgabe erhalten. An jedem Bereichsstart patcht der Lifter einen 5-Byte-`jmp rel32` zu einem `vm_entry_K`-Stub, der nach dem nativen Shellcode-Bereich angehängt wird. Externer nativer Code kann einen gelifteten Bereich nur über das gepatchte Startbyte wieder betreten. Mid-Range-Bytes werden mit int3 gefüllt, sodass jeder native Zweig, der auf ein Mid-Range-Byte zielt, beim Scan abgelehnt wird. Gelifteter Code, der einen Bereich zu Bytes außerhalb davon verlässt, wird zu `JMP_NATIVE` oder `CALL_NATIVE`.

Verwenden Sie zuerst `--scan`, um geeignete Kandidaten zu finden. Der Scan klassifiziert Bereiche mit Lücken, ohne `ret`-terminierten Block, mit einem Körper kürzer als 5 Bytes oder mit externen nativen Verzweigungen in Mid-Range-Bytes als Near-Miss statt als geeignet.

### Build-Pipeline

Wie `--ranges` nur die ausgewählten Byte-Bereiche liftet und den nativen Shellcode an Ort und Stelle patcht, sodass die Steuerung in die angehängten VM-Eintritts-Stubs umgeleitet wird.```mermaid
flowchart TB
    A[shellcode.bin] --> RP[parse_ranges from --ranges flag]
    RP --> CFG[CFGBuilder with set_lifted_ranges restriction]
    CFG --> LIFT[lift_program: only blocks whose start_va is inside any range]
    LIFT --> XCG[branches/calls leaving the range become JMP_NATIVE/CALL_NATIVE]
    XCG --> OBF[IR obfuscation passes same as default]
    OBF --> ENC[encode bytecode]
    ENC --> BTAB[block table for RET_VM lookup]
    SEED[seed u64] --> VMC[VMConfig]
    VMC --> STUB[VMCodeGen::emit_range_mode: one vm_entry_K per range + dispatcher + handlers]
    STUB --> NSEC[start with verbatim copy of the native shellcode bytes]
    NSEC --> PATCH[at each range start, write 5-byte jmp rel32 to vm_entry_K]
    PATCH --> INT3[fill remaining bytes of the displaced run with int3]
    INT3 --> APPEND[append: VM stub + sbox_inv + bytecode + data island + block table]
    APPEND --> OUT[out.bin]

Coroutine-artige Bereiche, diejenigen ohne `ret`, die über einen tail-jmp enden, werden über `--coroutines` für die `--scan`-Ausgabe dokumentiert. Das Flag ändert derzeit nichts am Codegen. Der Range-Modus ist am besten für eigenständige Blattfunktionen geeignet. Helper-Funktionen, die von einem bestimmten, vom Aufrufer bereitgestellten Registerzustand abhängen, können nicht eigenständig geliftet werden; die API wird dann mit Müll-Argumenten aufgerufen.

## Stacked-Modus: `--pack --ranges A:B,C:D`

Führe den Hybrid-Build aus und umhülle das Ergebnis anschließend mit Pack-Wrap. Die äußere VM entschlüsselt das innere Hybrid-Blob direkt an Ort und Stelle und springt zu dessen Byte 0. Von dort aus läuft die Ausführung genau wie im eigenständigen Hybrid-Modus ab, nur dass das gesamte Blob einschließlich des Bytecode des gewählten Bereichs im Ruhezustand verschlüsselt ist. Die beiden Ebenen fügen sich sauber zusammen, da das innere Blob eine eigenständige PIC-Region ist.

### Build-Pipeline

Wie der Stacked-Modus den Packager rekursiv aufruft: Zuerst ein innerer Build mit `--ranges`, dann ein äußerer `--pack`-Wrap dieses Builds.```mermaid
flowchart TB
    A[shellcode.bin] --> INNER[invoke package_shellcode recursively in range-only mode]
    INNER --> RBLOB[range-mode bytes in memory]
    RBLOB --> WRAP[invoke package_shellcode again in pack-only mode with RBLOB as input]
    WRAP --> OUT[out.bin: outer pack VM wrapping the inner range-mode blob]

Die innere VM und die äußere VM teilen keinen Zustand. Es sind zwei unabhängige VMs, die zufällig im selben Blob existieren. Die einzige Aufgabe der äußeren besteht darin, die innere hinter einer Entschlüsselungsschicht abzuschirmen.

## Detour-Modus: `--embed-into target.exe --at RVA`

Anders geformt als die anderen. Die Eingabe ist roher Shellcode, üblicherweise ein VM-Blob, der bereits von mkPIVM in einem anderen Modus erzeugt wurde, obwohl beliebige PIC-Bytes funktionieren. Die Ausgabe ist eine gepatchte PE.

Das Tool parst `target.exe`, lokalisiert die gewählte RVA in einem ausführbaren Abschnitt, disassembliert dort genügend Anweisungen, um 5 Bytes abzudecken, und lehnt ab, wenn die verschobene Sequenz RIP-relative Adressierung oder relativen Kontrollfluss enthält, der eine Verschiebung nicht übersteht, und fügt dann einen neuen RWX-Abschnitt hinzu, der einen Wrapper plus den VM-Blob enthält. Der Wrapper sichert den Aufruferzustand, übergibt die Kontrolle an den VM-Blob, stellt den Zustand wieder her, führt die verschobenen ursprünglichen Bytes aus und springt zurück zu dem Byte nach dem Patch. Ein 5-Byte-`jmp rel32` an der gewählten RVA zeigt auf den Wrapper.

Zwei Untermodi dafür, wie der Wrapper an die VM übergibt:

### Threaded-Untermodus, der Standard

Es folgen zwei Diagramme. Das erste ist die PE-Patching-Pipeline zur Buildzeit, die den Wrapper-Abschnitt injiziert, Referenzen korrigiert und den 5-Byte-Jmp an der gewählten RVA schreibt. Das zweite ist der Kontrollfluss zur Laufzeit, wenn der Hostprozess schließlich diese RVA erreicht.```mermaid
flowchart TB
    BLOB[vm_blob.bin pre-built from any other mode] --> READ[read target.exe bytes]
    TGT[target.exe] --> READ
    READ --> PEHDR[parse DOS header, NT headers, sections, OptionalHeader, BASERELOC dir]
    PEHDR --> ARCHCHK[arch from PE32/PE32+ magic must match blob arch]
    ARCHCHK --> LOC[locate RVA inside an executable section]
    LOC --> DA[Zydis disassemble at RVA, accumulate insns until total length >= 5]
    DA --> VALID{any displaced insn has RIP-relative mem operand or is a rel32 branch?}
    VALID -- yes --> FAIL[error, pick a different RVA]
    VALID -- no --> IATSCAN[scan IMAGE_DIRECTORY_ENTRY_IMPORT for kernel32!CreateThread]
    IATSCAN --> IATFOUND{found?}
    IATFOUND -- no --> FAIL2[error, suggest --detour-inline or different target]
    IATFOUND -- yes --> EMITW[emit threaded wrapper bytes]
    EMITW --> APPEND[concatenate wrapper + vm_blob into new section content]
    APPEND --> ARCHBR{arch?}
    ARCHBR -- x64 --> X64FIX[fix wrapper rel32s: lea r8 to vm_blob; call qword ptr rip+iat_disp32]
    ARCHBR -- x86 --> X86FIX[fix wrapper abs32s: push vm_blob_va; call dword ptr iat_va; then append combined IMAGE_BASE_RELOCATION table with new HIGHLOW entries for those abs32s]
    X64FIX --> RJMP[compute jmp_rel32 from wrapper-tail back to RVA + displaced_len]
    X86FIX --> RJMP
    RJMP --> SEC[allocate next aligned VA + raw offset, write IMAGE_SECTION_HEADER with RWX + CNT_CODE]
    SEC --> BUMP[bump NumberOfSections, SizeOfImage, zero CheckSum]
    BUMP --> X86RELOC{x86?}
    X86RELOC -- yes --> RDIR[update DataDirectory BASERELOC to new combined table]
    X86RELOC -- no --> WJ[write 5-byte jmp rel32 at RVA, NOP-fill remaining displaced bytes]
    RDIR --> WJ
    WJ --> WRITE[serialize patched bytes to output path]
    WRITE --> OUT[patched.exe]

Die Thread-Submodus ist die richtige Form für Stager und Beacons. Der Hauptthread des Hosts blockiert nie. Der Worker-Thread erbt den Lebenszyklus, den der Payload benötigt. Wenn der Payload `ExitProcess` aufruft, stirbt der gesamte Prozess, aber für einen nicht-terminierenden Payload wie jeden C2-Beacon läuft der Host für immer parallel dazu weiter.

### Inline-Submodus: `--detour-inline`

Gleiche Wrapper-Struktur, aber der Wrapper führt einen direkten `call vm_blob` anstelle von `CreateThread` aus. Der Hauptthread des Hosts blockiert, bis die VM zurückkehrt. Nützlich, wenn dem Ziel `CreateThread` in seiner IAT fehlt, oder als Fallback, wenn der Thread-Base-Reloc-Pfad auf ein bestimmtes Ziel nicht angewendet werden kann.```mermaid
flowchart TB
    HOST[host main reaches patched RVA] --> RJMP[jmp rel32 to wrapper]
    RJMP --> SAVE[save flags + volatile regs + align]
    SAVE --> CALL[call rel32 vm_blob synchronously]
    CALL --> BLOCK[host main thread blocks here for the duration]
    BLOCK --> RET{vm_blob returns?}
    RET -- via ret --> REST[restore rsp, pop volatiles, popfq]
    RET -- via ExitProcess in payload --> DEAD[process terminates, no further code runs]
    REST --> DISP[execute displaced original bytes]
    DISP --> RJMP2[jmp rel32 back to RVA + N_displaced]
    RJMP2 --> HOST_CONT[host continues]

## Polymorphie-Achsen pro Seed

Grob in der Reihenfolge aufgelistet, wie stark sie die statische Signatur beeinflussen.

* Chiffre-Familie. Eine von ARX, LcgSub, SBoxAdd, FeistelByte. Wählt sowohl die beim Erstellen verwendete Bytecode-Verschlüsselung als auch die Inline-Entschlüsselung, die im Dispatcher-Fetch-Pfad emittiert wird. Verschlüsselung und Entschlüsselung stimmen konstruktionsbedingt überein.
* Register-Slot-Layout. Der VMState enthält `reg_count` Slots – je nach Seed zwischen 24 und 32. Die 16 architektonischen GPRs plus 4 Tmp-Regs erhalten pro Seed eine neue Permutation der Slot-Indizes.
* Opcode-zu-Handler-Zuordnung. Jeder Codec-Familie wird pro Seed ein zufälliges Opcode-Byte zugewiesen. Die Handler-Tabelle mit 256 Einträgen wird über den Opcode indiziert; der kodierte Bytecode referenziert die abgebildeten Opcodes.
* Dispatcher-Topologie. Threaded oder zentral, pro Seed gewählt.
* Prologue-Selbstlokalisierungsstrategie. `call $+5; pop`, `lea reg, [rip+0]` oder ein jmp/call-Shuffle.
* Handler-Register-Temporärvariablen. Der BR_CC-Handler permutiert seine 6 temporären Rollen über den Pool flüchtiger Register. Der Store-Handler macht dasselbe.
* Junk-Gadget-Dichte. 0 bis 3, steuert die Ausgabe von Junk-Code zwischen den Handlern.
* Entscheidungen des IR-Obfuskationspasses. Dead-IR-Injektion und opake Prädikate verwenden jeweils ihr eigenes Sub-RNG, sodass ihre Entscheidungen pro Seed deterministisch sind, ohne andere Achsen zu beeinflussen.
* Anfangszustand der Bytecode-Verschlüsselung. Zufällige 64 Bit pro Seed.

## Getestete Payloads

Dieses Tool wurde gegen mehrere Cobalt Strike-, MSF-, Sliver- und zahlreiche weitere Shellcode-Beispiele validiert.

## Erstellen

Erfordert Visual Studio 2022, CMake 3.21 oder neuer und vcpkg. Das CMake-Projekt bezieht Zydis und fmt über den Manifest-Modus von vcpkg.```
cmake -S . -B build
cmake --build build --config Release --target mkpivm