Anti Reversing Techniques

# Advanced Anti-Reversing Techniques

This reference covers advanced and niche techniques extracted from the core skill to keep SKILL.md focused on common patterns. Refer here for deep-dive analysis of virtualization-based protections, packer internals, and anti-disassembly tricks.

---

## Packing and Encryption

### Common Packers

```
UPX          - Open source, easy to unpack (upx -d)
Themida      - Commercial, VM-based protection with anti-debug
VMProtect    - Commercial, code virtualization with multiple VM architectures
ASPack       - Compression packer, LZSS-based
PECompact    - Compression packer with CRC integrity checks
Enigma       - Commercial protector with key-based licensing
MPRESS       - LZMA-based packer, often used by malware
Obsidium     - Commercial, anti-debug + anti-VM + encryption
```

### Unpacking Methodology

```
1. Identify packer (DIE, Exeinfo PE, PEiD, detect-it-easy)

2. Static unpacking (if known packer):
   - UPX: upx -d packed.exe
   - Use existing unpacker tools from UnpacMe, MalwareBazaar

3. Dynamic unpacking:
   a. Find Original Entry Point (OEP)
   b. Set breakpoint on OEP
   c. Dump memory when OEP reached
   d. Fix import table (Scylla, ImpREC)

4. OEP finding techniques:
   - Hardware breakpoint on stack (ESP trick)
   - Break on common API calls (GetCommandLineA, GetModuleHandle)
   - Trace and look for typical entry prologue (push ebp / mov ebp, esp)
   - Check for tail jump pattern: jmp <far address>
```

### Manual Unpacking (ESP Trick — x64dbg)

```
1. Load packed binary in x64dbg
2. Note entry point (packer stub address)
3. Use ESP trick:
   a. Run to entry point (F9 then F8 until PUSHAD)
   b. Right-click ESP value → "Follow in Dump"
   c. Set hardware breakpoint on access (HW BP on [ESP])
   d. Run (F9) — execution breaks after POPAD (stack restored)
4. Look for JMP to OEP (often a far jump to .text section)
5. At OEP, use Scylla plugin:
   - IAT Autosearch → Get Imports
   - Dump process
   - Fix dump with imports
```

### UPX Variant Unpacking

```bash
# Standard UPX — direct decompress
upx -d packed.exe -o unpacked.exe

# Modified UPX header (signature patched to evade upx -d):
# 1. Find UPX0/UPX1 section names (may be renamed)
# 2. Restore original UPX magic bytes: 0x55 0x50 0x58
# 3. Then run upx -d

# Python: restore UPX magic for patched header
python3 -c "
import sys
data = open(sys.argv[1], 'rb').read()
# UPX magic at various offsets — search for stub pattern
idx = data.find(b'\x60\xBE')  # PUSHAD; MOV ESI stub
print(f'Stub at: {hex(idx)}')
"
```

---

## Virtualization-Based Protection

### Code Virtualization Architecture

```
Original x86 code is converted to custom bytecode interpreted by an
embedded virtual machine at runtime.

Original:          VM Protected:
  mov eax, 1    →    push vm_context_ptr
  add eax, 2         call vm_entry
  ret                ; VM dispatcher loop decodes bytecode
                     ; and invokes handler table entries
                     ; equivalent semantics, unrecognizable form
```

### VM Component Identification

```
1. VM Entry Point:
   - Usually a CALL or JMP to a large function with a loop
   - Look for: load bytecode ptr, load handler table, dispatch loop

2. Handler Table:
   - Array of function pointers (one per virtual opcode)
   - Indexed by decoded opcode byte/word
   - Each handler emulates one instruction

3. Virtual Registers:
   - Stored in a context structure (vm_context)
   - Usually on the stack or in a dedicated heap allocation
   - Map to native registers by handler logic

4. Bytecode Location:
   - Separate section (.vmp0, .vmp1 in VMProtect)
   - Or inline with code (Themida)
   - Encrypted or compressed in some implementations
```

### Devirtualization Analysis Workflow

```
1. Identify VM entry: look for large functions with indirect dispatch (jmp [reg+offset])

2. Trace execution with logging:
   - Use x64dbg trace log: log handler address and context on each iteration
   - Example trace command in x64d