d7ead/mkpivmGere máquinas virtuais polimórficas e independentes de posição (PIVMs) a partir de shellcode x86/x64 arbitrário.
Leia o artigo de pesquisa (escrito para a versão 1.0.0).
mkPIVM é um virtualizador de shellcode polimórfico independente de posição para Windows x86 e x64 (Linux em breve).
Alimente-o com shellcode bruto. Ele emite outro blob bruto: uma pequena máquina virtual que interpreta uma versão elevada e criptografada em repouso das suas instruções originais. A saída é, por si só, código independente de posição e é executada em qualquer lugar onde o shellcode original seria, desde um carregador de thread remota até um desvio de code cave. Cada botão por semente varia independentemente: família de cifras, layout de slots de registradores, permutação de opcode para handler, topologia do dispatcher, padrão de junk gadgets, pontos de inserção de obfuscação de IR. Duas compilações da mesma entrada compartilham menos de uma centena de bytes coincidentes em dezenas de kilobytes.
Por quê: shellcode nativo é trivial para assinaturas. Envolvê-lo em uma VM por instância com uma cifra por instância não deixa nada útil em repouso, e elevar as instruções para bytecode coloca outra barreira entre os bytes do disco e qualquer desmontador que conheça a aparência do x86. Pelo que posso dizer a partir de uma varredura na literatura, nenhuma ferramenta pública possui exatamente esse pipeline: PIC bruto de entrada, PIC de VM polimórfica bruto de saída. Então, mencionei isso no artigo de pesquisa que ele exigiu. Para ser honesto, se eu estiver certo sobre ninguém ter feito isso (publicamente) antes, e estou bastante confiante, estou surpreso. No entanto, aproveite.
mkpivm.exe shellcode.bin --arch x64 -o out.bin
Seu PIVM está quente e pronto. Esse é o caminho mais simples. Vários outros modos variam o quão agressivamente as instruções originais são virtualizadas, se a saída é um blob independente ou um PE patched, e se o lift é executado ou não.
# Demonstração
Tenho as provas. Você pode ver um vídeo do mkPIVM em ação abaixo, virtualizando completamente um stager do Meterpreter (vanilla, por sinal), injetando no explorer.exe, e nós capturando um callback. Claro que isso é apenas um exemplo, e o mkPIVM pode ser aplicado a muito mais, assumindo que as instruções no shellcode são suportadas. Se não forem, abra um Issue, me envie o shellcode, eu resolvo.
Veja [aqui](https://github.com/D7EAD/mkPIVM/raw/refs/heads/main/media/mkpivm-showcase.mp4). Hospedado em ./media, infelizmente não pode ser incorporado.
Aqui está o relatório do VirusTotal para exatamente aquela amostra virtualizada (em 06/04/2026).
<img src="https://assets.kitploit.com/production/public/readmes/7466/3f4a6dbe2777c02fb32f71749a5b1fa2aa324cb0dac2f77d5681bbe3a4e17a81.png">
...e a versão empacotada, nem mesmo virtualizada, entropia notavelmente maior.
<img src="https://assets.kitploit.com/production/public/readmes/7466/47f68372e31a2c24fa49eb71648adbdf8944977db90d645df337125c1bdfa8e3.png">
Aqui estão os resultados de um beacon normal do Cobalt Strike para comparação.
<img src="https://assets.kitploit.com/production/public/readmes/7466/76e2107589cd2b1b65c846a671aed173aa5e6d89630f5e9d283d99c546a2d566.png">
Foi dada atenção cuidadosa à telemetria de entropia da saída desta ferramenta, o que resulta em shellcode com entropia menor do que DLLs típicas do Windows WinAPI (fora do modo de empacotamento), como ntdll.dll ou kernel32.dll. A comparação de entropia é aproximadamente...
| Arquivo | Bytes | Entropia |
|------|-------|---------|
| `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 relance
| Modo | Flags | O que muda |
|------|-------|--------------|
| Default | none | Levanta toda a entrada. Tudo virtualizado. |
| Packer | `--pack` | Não levanta. Embrulha a entrada como dados criptografados, descriptografa em tempo de execução, salta para dentro. |
| Hybrid | `--ranges A:B,...` | Levanta apenas os intervalos de bytes escolhidos. O resto permanece nativo. |
| Stacked | `--pack --ranges A:B` | Constrói o blob híbrido, então o empacota. |
| Detour | `--embed-into PE --at RVA` | Pega um blob pré-construído, incorpora em um PE, aplica um patch jmp no RVA escolhido. |
| Scan | `--scan` | Imprime candidatos `--ranges` elegíveis do CFG da entrada, então sai. |
| RX | `--rx` | Blob PAGE_EXECUTE_READ. A ilha de dados permanece criptografada em repouso; o PEB walker dentro do blob resolve VirtualProtect, descriptografa in-place no state_init. |
| RX w/ Loader | `--rx --rx-loader-vp` | Como `--rx` mas seu loader passa VirtualProtect como o primeiro argumento do blob. Sem PEB walker. |
Cada modo respeita `--seed`, `--arch`, `--input-format` e `--format`. Veja as seções por modo abaixo para o pipeline de construção e o fluxo de execução.
## Virtualização padrão
O lifter percorre todo o CFG e baixa cada instrução para um IR personalizado. O IR passa por duas passagens de ofuscação, depois por codecs que codificam cada insn na forma de bytecode por semente. A tabela de blocos, a tabela de handlers e a ilha de dados são criptografadas com o mesmo cifrador de fluxo por byte que o bytecode. Em tempo de execução, o prólogo descriptografa essas três regiões in-place e o loop do dispatcher busca bytes do bytecode um de cada vez, descriptografando e despachando para um handler que faz o trabalho.
### Pipeline de construção
Etapas que o build executa para transformar shellcode bruto no blob virtualizado emitido, de ponta a ponta. _Todos os gráficos abaixo se aplicam à versão 1.0.0, eles mudaram desde então, mas a ideia é a mesma._```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]