Skip to content

Lab 07 — Disassembly Basics

Hands-on lab · ← Back to the module concept

Setup

git clone https://github.com/plaintext-security/plaintext-labs
cd plaintext-labs/malware/07-disassembly-basics
make up
make fetch-sample      # pulls a real GuLoader sample from MalwareBazaar into the isolated container
make demo

⚠ This lab disassembles a live malware sample. Handle it accordingly. - Static only. Nothing in this lab executes the sample — analysis is objdump, radare2, and (optionally) Ghidra disassembly. Do not run it. - Isolation. All work stays inside the isolated container; never copy the sample to your host. - Hygiene. The sample is fetched at lab time (password-protected zip, password infected) and is never committed — .gitignore covers samples/. make fetch-sample needs a free abuse.ch Auth-Key (set MB_AUTH_KEY). - Offline fallback. No key / MalwareBazaar unreachable? Skip make fetch-sample; make demo falls back to the bundled synthetic crackme — the same XOR-decode mechanism, deliberately legible.

Scenario

A triage queue drops a sample flagged as GuLoader (a.k.a. CloudEyE) — the shellcode-based downloader dissected by CrowdStrike and Unit 42 (MITRE S0561). GuLoader stores its strings — and most of its own shellcode — encrypted, unpacked at runtime by a small decode stub: a handful of executable bytes at the front that XOR-decode the encrypted tail before control jumps into it. strings finds nothing useful; the readable form only exists after the stub runs. Your job is to recover it the analyst's way — disassemble the stub, identify the XOR loop, extract the key, and reconstruct the plaintext without ever executing the binary.

The same mechanism, made legible, lives in the bundled crackme (compiled from data/crackme.c, which you read only after the analysis): one XOR-decode loop over a static encrypted buffer. The synthetic binary is the offline fallback — start there to learn the loop shape, then point the same workflow (objdump/radare2/Ghidra) at the real GuLoader PE in /lab/samples/. Treat the disassembly as your only source of truth.

Do

  1. [ ] Generate a flat disassembly with objdump. 

    objdump -d -M intel /lab/crackme > /tmp/crackme.asm
    Open /tmp/crackme.asm and find the decode function. (Hint: search for <decode> in the objdump output.)

  2. [ ] Identify the loop structure. In the decode function, locate the instruction sequence that forms the loop: the counter increment, the cmp or test instruction, and the conditional jump. Write down the loop bounds — how many iterations does it run?

  3. [ ] Extract the XOR key. Find the xor instruction inside the loop. What register or immediate value is the key? Is it a single byte (constant) or is it derived from the loop counter?

  4. [ ] Read the encrypted buffer from the disassembly. The encrypted bytes are stored as a static array in the binary. Locate the .rodata section in objdump output or the data segment reference in the decode function. Read the raw bytes.

  5. [ ] Recover the plaintext string manually. Apply the XOR key to each byte. Write the result. If your recovered string is readable ASCII, you found the key. If it is not, re-examine the key width and any endianness considerations. (Hint: python3 -c "print(bytes(b ^ KEY for b in ENCRYPTED_BYTES))")

  6. [ ] Confirm with radare2. Run: 

    radare2 -q -c 'aaa; pdf @ sym.decode' /lab/crackme
    Compare radare2's disassembly of decode to objdump's. Note any differences in how each tool presents the same instructions.

  7. [ ] Make demo runs all of the above automatically and shows the recovered string. Verify your manual recovery matches the demo output.

  8. [ ] Turn the same workflow on the real GuLoader sample (opt-in — needs make fetch-sample). The synthetic crackme taught you the loop shape; now find it in the wild. Disassemble the real PE in /lab/samples/ (objdump -D -M intel, or radare2 -q -c 'aa; pd 80 @ entry0', or Ghidra headless for a graph view) and locate the decode stub the CrowdStrike/Unit 42 writeups describe: a short run of executable bytes that XOR-decodes the encrypted region before jumping into it. You will not get a clean named decode symbol — that is the point. Identify the XOR instruction, note the key, and write down where the encrypted region begins. (You do not need to fully unpack it — recognising the stub and its key is the deliverable. Static only; never execute.)

  9. [ ] Author a YARA hex-pattern rule on the recovered stub and prove it (the build half). Recovering the string is only half the job — the byte sequence of the decode loop is a signature. Capture the exact opcode bytes of the XOR loop from your objdump output (the movzx / xor / mov / inc / cmp / jne sequence — mask register-encoding or address bytes that vary with ?? wildcards so the pattern is stable). Write disasm-xor.yar with that hex string { ... } in the condition; optionally also include the encrypted blob bytes from .rodata. Then prove the two-sided result: yara disasm-xor.yar /lab/crackme must match, and yara disasm-xor.yar /bin/ls (a benign control with its own, different code) must not match. If the rule fires on /bin/ls, your pattern is too generic — it caught a common compiler idiom, not this stub; widen the captured run or add the blob bytes until only crackme matches. Recovering the plaintext and authoring the byte-pattern detection that proves you isolated the right bytes are equal halves. (Hint: get the bytes from objdump -d — each instruction's machine code is in the second column; use ?? for the operand bytes you expect to differ across builds, keep the opcodes fixed.)

Success criteria — you're done when

  • [ ] The XOR key is correctly identified (exact byte value).
  • [ ] The plaintext string is recovered manually and matches the demo output.
  • [ ] The loop structure (bounds, increment, condition) is documented in your notes.
  • [ ] Both objdump and radare2 disassembly outputs are reviewed.
  • [ ] disasm-xor.yar matches /lab/crackme and does not match /bin/ls — the build half, proven two-sided.

Deliverables

disassembly-notes.md — your annotated analysis: the loop structure (in pseudocode), the XOR key, the encrypted bytes, and the recovered string. annotate_asm.py (see Automate & own it), disasm-xor.yar (with the match/no-match proof recorded in the notes). Commit all three.

Automate & own it

Required. Write annotate_asm.py: a Python script that reads the objdump output file and identifies all xor instructions, printing each one with the surrounding 3 lines of context and a label: [LOOP-XOR] if the xor uses a register operand (variable key), [CONST-XOR] if the xor uses an immediate (constant key). AI can draft the regex parsing; you write the operand classification logic by hand (this is the learning — classifying xor rax, rax as a zero-idiom, not a key, requires understanding the instruction).

AI acceleration

Paste the decode function disassembly into an AI and ask "what does this function do and what is the XOR key?" Then verify the key independently by tracing through the instructions manually. Check whether the AI's key is a byte or a wider value — this is the most common error.

Connects forward

The XOR decryption skill you practice here is the foundation for manual unpacking (reversing a packer's decryption stub) and for writing YARA rules that match on byte patterns in encrypted or obfuscated data. In Track 05 (Cloud Security) and Track 06 (Active Directory), you will see similar obfuscation patterns in PowerShell payloads.

Marketable proof

"I disassemble compiled binaries, identify XOR obfuscation loops, extract keys manually, and recover hidden strings without executing the sample."

Stretch

  • Find any function in the binary that uses a call instruction. Trace the arguments: which registers are set before the call, and what does the System V ABI say each register holds? Verify against the C source after the exercise.
  • Modify crackme.c to use a two-byte XOR key (XOR each byte with key[i % 2]). Recompile and re-run your analysis — how does the assembly change?

Comments

Sign in with GitHub to comment. Choose the type: Feedback (errors or suggestions on this page) · Hints (help for fellow learners — no spoilers) · General (anything else).