Tu PIVM está lista y funcionando. Ese es el camino más sencillo. Varios otros modos varían la agresividad con la que se virtualizan las instrucciones originales, si la salida es un blob independiente o un PE parcheado, y si el lift se ejecuta o no.

# Showcase

Tengo los recibos. Puedes ver un vídeo de mkPIVM en acción a continuación, virtualizando por completo un stager de Meterpreter (vanilla, por cierto), inyectándose en explorer.exe, y nosotros capturando un callback. Por supuesto, esto es solo un ejemplo, y mkPIVM se puede aplicar a mucho más, siempre que las instrucciones del shellcode sean compatibles. Si no lo son, abre un Issue, envíame el shellcode, yo te cubro.

Míralo [aquí](https://github.com/D7EAD/mkPIVM/raw/refs/heads/main/media/mkpivm-showcase.mp4). Alojado en ./media, lamentablemente no se puede incrustar.

Este es el informe de VirusTotal para esa muestra virtualizada exacta (a fecha de 06/04/2026).

<img src="https://assets.kitploit.com/production/public/readmes/7466/3f4a6dbe2777c02fb32f71749a5b1fa2aa324cb0dac2f77d5681bbe3a4e17a81.png">

...y la versión empaquetada, ni siquiera virtualizada, con una entropía notablemente mayor.

<img src="https://assets.kitploit.com/production/public/readmes/7466/47f68372e31a2c24fa49eb71648adbdf8944977db90d645df337125c1bdfa8e3.png">

Aquí están los resultados de un beacon normal de Cobalt Strike para comparar.

<img src="https://assets.kitploit.com/production/public/readmes/7466/76e2107589cd2b1b65c846a671aed173aa5e6d89630f5e9d283d99c546a2d566.png">

Se prestó especial atención a la telemetría de entropía de la salida de esta herramienta, lo que da como resultado un shellcode con una entropía menor que la de las DLL WinAPI típicas de Windows (fuera del modo de empaquetado), como ntdll.dll o kernel32.dll. La comparación de entropía es aproximadamente...

| Archivo | Bytes | Entropía |
|------|-------|---------|
| `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** |

## Modos de un vistazo

| Modo | Flags | Qué cambia |
|------|-------|--------------|
| Default | ninguno | Levanta toda la entrada. Todo virtualizado. |
| Packer | `--pack` | No levantar. Envuelve la entrada como datos cifrados, los descifra en tiempo de ejecución y salta dentro. |
| Hybrid | `--ranges A:B,...` | Levanta solo los rangos de bytes elegidos. El resto permanece nativo. |
| Stacked | `--pack --ranges A:B` | Construye el blob híbrido y luego lo envuelve con pack. |
| Detour | `--embed-into PE --at RVA` | Toma un blob preconstruido, lo incrusta en un PE y parchea un jmp en la RVA elegida. |
| Scan | `--scan` | Imprime los candidatos elegibles de `--ranges` desde el CFG de la entrada y luego sale. |
| RX | `--rx` | Blob PAGE_EXECUTE_READ. La isla de datos permanece cifrada en reposo; el walker de PEB dentro del blob resuelve VirtualProtect y descifra en el lugar en state_init. |
| RX w/ Loader | `--rx --rx-loader-vp` | Como `--rx`, pero tu loader pasa VirtualProtect como primer argumento del blob. Sin walker de PEB. |

Cada modo respeta `--seed`, `--arch`, `--input-format` y `--format`. Consulta las secciones por modo a continuación para ver el pipeline de construcción y el flujo en tiempo de ejecución.

## Virtualización por defecto

El lifter recorre todo el CFG y reduce cada instrucción a un IR personalizado. El IR pasa por dos pasadas de ofuscación y luego por codecs que codifican cada insn en la forma de bytecode específica de la semilla. La tabla de bloques, la tabla de handlers y la isla de datos se cifran con el mismo cifrado de flujo por byte que el bytecode. En tiempo de ejecución, el prólogo descifra esas tres regiones en el lugar y el bucle del dispatcher obtiene los bytes del bytecode de uno en uno, descifrándolos y despachándolos a un handler que hace el trabajo.

### Pipeline de construcción

Pasos que realiza la construcción para convertir el shellcode sin procesar en el blob virtualizado emitido, de principio a fin. _Todos los gráficos a continuación se aplican a la versión 1.0.0; estos han cambiado desde entonces, pero la idea es la misma._```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]

El truco del nonce en tiempo de ejecución es la clave de la jugada anti-escaneo de memoria: la tabla de manejadores reside en memoria sometida a XOR con un valor derivado de `rdtsc XOR cipher_init`, por lo que dos procesos que cargan el mismo blob tienen tablas de manejadores con bytes distintos. El despachador la desenmascara en el momento de la búsqueda con un XOR adicional.

## Modo empaquetado: `--pack`

La compensación inversa. El lifter no se ejecuta. El shellcode original se guarda en la isla de datos cifrado, y el IR es un único `JMP_NATIVE imm=0` sintético. El prólogo omite intencionadamente el descifrado de la isla de datos que el modo predeterminado ejecuta de forma anticipada. En su lugar, la primera vez que se dispara el único manejador de JMP_NATIVE, descifra la isla de datos en su lugar, establece un byte marcador y luego transfiere el control al byte 0 del shellcode ya en texto plano. El shellcode se ejecuta de forma nativa a partir de ahí.

Funciona con cualquier shellcode, independientemente de la cobertura del lifter. Útil para Cobalt stageless, payloads exóticos con muchas syscalls, cualquier cosa demasiado grande o extraña para virtualizar. Pierde la defensa de virtualización por instrucción, pero conserva el polimorfismo completo de VM por semilla en el envoltorio.

### Pipeline de compilación

Cómo `--pack` envuelve el shellcode original como una isla de datos cifrada detrás de un programa IR sintético de una sola instrucción.```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]

El descifrado diferido de la isla de datos solo está disponible en modo pack. En el modo predeterminado y en el modo híbrido, el código elevado ejecuta VM LOAD/STORE sobre los bytes de la isla de datos a mitad de ejecución y los necesita en texto plano desde el inicio, por lo que el prólogo lo maneja de forma inmediata. En modo pack hay exactamente un consumidor de la isla de datos, la salida nativa después del `JMP_NATIVE` sintético, por lo que el descifrado puede esperar hasta ese momento.

## Modo híbrido: `--ranges A:B,C:D`

Virtualización dirigida. Selecciona rangos de bytes en la entrada que deben elevarse. Todo lo demás permanece como los bytes nativos originales en la salida. Al inicio de cada rango, el elevador parchea un `jmp rel32` de 5 bytes hacia un stub `vm_entry_K` añadido después de la región nativa del shellcode. El código nativo externo solo puede volver a entrar en un rango elevado a través del byte inicial parcheado. Los bytes intermedios del rango se rellenan con int3, por lo que cualquier rama nativa que tenga como destino un byte intermedio del rango se rechaza en el momento del escaneo. El código elevado que sale de un rango hacia bytes fuera de él se convierte en `JMP_NATIVE` o `CALL_NATIVE`.

Usa `--scan` primero para encontrar candidatos elegibles. El escaneo clasifica como casi coincidencia, en lugar de elegible, los rangos con huecos, sin bloque terminado en `ret`, con cuerpo más corto de 5 bytes, o con ramas nativas externas hacia bytes intermedios del rango.

### Canalización de construcción

Cómo `--ranges` eleva solo los rangos de bytes elegidos y parchea el shellcode nativo en su lugar para que el control se redirija hacia los stubs de entrada de VM añadidos.```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]

Los rangos de estilo corrutina, los que no tienen `ret` y salen mediante un tail-jmp, se documentan mediante `--coroutines` para la salida de `--scan`. El indicador no cambia la generación de código en la actualidad. El modo de rangos es el más adecuado para funciones hoja autocontenidas. Las funciones auxiliares que dependen de un estado de registros específico proporcionado por el llamador no pueden extraerse de forma independiente; la API acaba llamándose con argumentos basura.

## Modo apilado: `--pack --ranges A:B:C,D`

Ejecuta la compilación híbrida y luego envuelve el resultado con pack. La VM externa descifra el blob híbrido interno en su sitio y salta al byte 0 del mismo. A partir de ahí, la ejecución continúa exactamente igual que en el modo híbrido autónomo, excepto que todo el blob, incluido el bytecode del rango elegido, está cifrado en reposo. Las dos capas se combinan limpiamente porque el blob interno es una región PIC autocontenida.

### Canalización de compilación

Así es como el modo apilado invoca recursivamente al empaquetador: primero una compilación interna con `--ranges` y luego una envoltura externa con `--pack` de esa compilación.```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]

La VM interna y la VM externa no comparten estado. Son dos VMs independientes que casualmente viven en el mismo blob. El único trabajo de la externa es poner la interna detrás de una capa de descifrado.

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

Forma distinta de las demás. La entrada es shellcode crudo, normalmente un blob de VM ya generado por mkPIVM en otro modo, aunque cualquier byte PIC funcionará. La salida es un PE parcheado.

La herramienta analiza `target.exe`, localiza el RVA elegido en una sección ejecutable, desensambla allí las instrucciones suficientes para cubrir 5 bytes, rechaza si el tramo desplazado contiene direccionamiento relativo a RIP o flujo de control relativo que no pueda sobrevivir al ser movido, y luego añade una nueva sección RWX que contiene un wrapper además del blob de VM. El wrapper preserva el estado del llamador, transfiere el control al blob de VM, restaura el estado, ejecuta los bytes originales desplazados y salta de vuelta al byte posterior al parche. Un `jmp rel32` de 5 bytes en el RVA elegido apunta al wrapper.

Dos submodos para la manera en que el wrapper transfiere el control al VM:

### Submodo enhebrado, el predeterminado

A continuación se presentan dos diagramas. El primero es la canalización de parcheo del PE en tiempo de compilación que inyecta la sección del wrapper, corrige las referencias y escribe el jmp de 5 bytes en el RVA elegido. El segundo es el flujo de control en tiempo de ejecución cuando el proceso anfitrión alcanza finalmente ese RVA.```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]

El submodo con hilos es la forma adecuada para stagers y beacons. El hilo principal del host nunca se bloquea. El hilo de trabajo hereda el ciclo de vida que el payload necesite. Si el payload llama a `ExitProcess`, todo el proceso muere, pero para un payload que no termina, como cualquier beacon de C2, el host se ejecuta para siempre en paralelo con él.

### Submodo en línea: `--detour-inline`

La misma estructura de wrapper, pero el wrapper hace una llamada directa a `call vm_blob` en lugar de `CreateThread`. El hilo principal del host se bloquea hasta que la VM retorna. Útil cuando el objetivo carece de `CreateThread` en su IAT, o como respaldo cuando la ruta de reubicación base con hilos no puede aplicarse contra un objetivo concreto.```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]

## Ejes de polimorfismo por semilla

Enumerados aproximadamente en orden de cuánto afectan a la firma estática.

* Familia de cifrado. Una de ARX, LcgSub, SBoxAdd, FeistelByte. Elige tanto el cifrado del bytecode usado en tiempo de compilación como el descifrado en línea emitido en la ruta de obtención del dispatcher. El cifrado y el descifrado coinciden por construcción.
* Distribución de ranuras de registros. El VMState contiene ranuras `reg_count`, con un tamaño de 24 a 32 por semilla. Los 16 GPR arquitectónicos más los 4 registros Tmp obtienen una nueva permutación de índices de ranura en cada semilla.
* Mapeo de opcode a manejador. A cada familia de codec se le asigna un byte de opcode aleatorio por semilla. La tabla de manejadores de 256 entradas se indexa por opcode; el bytecode codificado hace referencia a los opcodes mapeados.
* Topología del dispatcher. Enhebrado o central, elegida por semilla.
* Estrategia de autoubicación del prólogo. `call $+5; pop`, `lea reg, [rip+0]` o una mezcla de jmp/call.
* Temporales de registro del manejador. El manejador BR_CC permuta sus 6 roles temporales entre el grupo de registros volátiles. El manejador Store hace lo mismo.
* Densidad de gadgets basura. De 0 a 3, controla la emisión de basura entre manejadores.
* Decisiones del paso de ofuscación de IR. La inyección de IR muerto y los predicados opacos utilizan cada uno su propio sub-RNG, de modo que sus decisiones son deterministas por semilla sin perturbar otros ejes.
* Estado inicial del cifrado del bytecode. 64 bits aleatorios por semilla.

## Payloads probados

Esta herramienta fue validada contra varias muestras de shellcode de Cobalt Strike, MSF, Sliver y numerosas otras.

## Compilación

Requiere Visual Studio 2022, CMake 3.21 o superior y vcpkg. El proyecto CMake obtiene Zydis y fmt a través del modo manifiesto de vcpkg.```
cmake -S . -B build
cmake --build build --config Release --target mkpivm