Analyzing Position-Independent Code

When to Use

• You have a PIC blob/shellcode that resolves its own addresses and APIs without imports, and you need to understand its technique before disassembly.
• You want to identify the base-resolution (GetPC), PEB-walk, and API-hashing mechanics.

Do not use this to execute the code — analyze it statically (and emulate separately if needed). Treat the blob as malicious.

Prerequisites

• The PIC/shellcode blob (read inertly).

Safety & Handling

• Read bytes statically; store the blob password-protected and never execute it.

Workflow

Step 1: Identify PIC techniques

python scripts/analyst.py analyze shellcode.bin

Detects GetPC stubs (call $+5/fnstenv), PEB access (fs:[30]/gs:[60]), API-hash loops (lodsb + ror), and stack-string construction.

Step 2: Determine architecture and base behavior

Confirm 32- vs 64-bit PEB access and how the code computes its own base for relative addressing.

Step 3: Map API resolution

Note the hashing algorithm and that resolved APIs are obtained by walking the PEB→LDR→export tables (pair with the API-hash resolver skill).

Step 4: Disassemble at the right base

Load the blob at the inferred base/entry in a disassembler/emulator and proceed.

Validation

• PIC technique hits reference real patterns (GetPC/PEB/API-hash), not arbitrary bytes.
• Architecture is consistent with the PEB-access form detected.
• The analysis points to a concrete entry/base for disassembly.

Pitfalls

• Encoded/staged shellcode where the PIC patterns appear only after decoding.
• Mixed 32/64-bit (WoW64) transitions.
• Custom GetPC variants not matching common signatures.

References

• See references/api-reference.md for the analyzer.
• PEB/LDR and ATT&CK T1027.007 references (linked in frontmatter).