Virtually Mad

Technical Walkthrough

Writeup

Challenge

• Name: Virtually-Mad
• Category: Reversing
• Difficulty: Medium
• Mode: file

Summary

virtually.mad is a stripped Linux ELF that implements a small custom virtual

machine. The binary asks for a hex-encoded program, executes five VM opcodes,

then checks the final register and flag state before printing the HTB-format

answer.

The solve path was to reverse the opcode format, construct the shortest

program that satisfies the final checks, validate it against a local simulator

and the real ELF, then capture the generated answer through the harness.

Artifact Inventory

• files/a12c7370-0371-4e10-9634-462e3ff95d45.zip: original challenge archive.
• files/extracted/rev-virtuallymad/virtually.mad: stripped 64-bit PIE Linux

ELF containing the custom VM.

• analysis/source-audit.md: reconstructed VM layout, instruction format,

dispatch table, and final checks.

• analysis/binary-validation-redacted.txt: Docker run against the real ELF

showing the generated program reaches the redacted success output.

Analysis

The disassembly shows that each input instruction is an eight-character hex

chunk parsed as a 32-bit opcode. The high byte selects the VM operation:

mov, add, sub, cmp, or exit.

For the useful arithmetic and comparison operations, the instruction format is:

bits 31..24: opcode
bits 23..20: subtype, required to be 1
bits 19..16: destination register index
bits 15..12: operand mode, 0 for immediate and 1 for register
bits 11..0 : immediate value, or source register index shifted left by 8

The VM has four 32-bit registers, a, b, c, and d, plus a flags field.

The main routine requires exactly five instructions and applies per-position

shape checks. The final accepted state is:

a == 0x200
b == -1
c == -1
d == 0
flags == 0x10000000
opcode_count == 5

That state can be reached with this conceptual VM program:

add a, 0x100
add a, 0x100
sub b, 1
mov c, b
cmp d, 0

The RAG query did not return actionable challenge-specific memory, so it was

recorded as missing and rejected. The evidence used for the final path is the

current ELF disassembly, the local VM simulator, and Docker validation against

the binary.

Solve

solve/solve.py implements the VM encoder and simulator. It first self-tests

the constructed five-opcode program against the expected final VM state. It can

then write the resulting HTB-format answer to a file for harness capture.

Validation performed:

python3 -m py_compile Reversing/Virtually-Mad/solve/solve.py
python3 Reversing/Virtually-Mad/solve/solve.py --self-test \
  --transcript Reversing/Virtually-Mad/analysis/self-test-transcript.txt

The generated code was also sent to the real Linux ELF inside Docker. The

redacted transcript in analysis/binary-validation-redacted.txt confirms the

binary reached the success path with:

a: 0x200
b: 0xffffffff
c: 0xffffffff
d: 0x0
flags: 0x10000000

Final capture was done through the challenge harness:

python3 scripts/challenge_exec.py Reversing/Virtually-Mad -- \
  python3 Reversing/Virtually-Mad/solve/solve.py \
  --output Reversing/Virtually-Mad/analysis/flag-candidate.txt \
  --transcript Reversing/Virtually-Mad/analysis/solve-transcript.txt

python3 scripts/challenge_harness.py capture-flag Reversing/Virtually-Mad \
  --from analysis/flag-candidate.txt

Flag

Raw flag is stored in loot/flag.txt and intentionally not reproduced here.

Lessons

• A compact custom VM is often faster to solve by reconstructing the instruction

fields and writing a small simulator than by manually trying inputs.

• Per-index validation in main can be as important as the VM dispatch logic.
• For file-only reversing challenges, a redacted binary validation transcript is

enough to preserve proof without leaking the raw flag outside loot/.

Source-Backed Dossier

The sections below are merged from companion Markdown notes for the same case. They are rendered after sanitization so the article stays precise without publishing raw flags, credentials, or target-specific secrets.

Notes

Scope

• Challenge: Virtually-Mad
• Category: Reversing
• Difficulty: Medium
• Mode: file
• Remote instance: none
• Start time: 2026-06-12T15:45:07Z
• Operator: harness
• State file: challenge-state.json

Harness Status

• Current phase: see challenge-state.json
• Next allowed actions: see next-action.json
• Raw flags and sensitive material stay in loot/ only. Do not paste them here.

Artifact Inventory

Evidence Ledger

Key Findings

-

RAG / Advisory Memory

RAG output is advisory only. Record evaluated retrievals with:

scripts/challenge_harness.py rag-record <workspace> --query "..." --tag MATCHED|PARTIAL|MISSING|<secret redacted>|GENERIC --validation "..."

Secrets/Flags

Raw flags and sensitive material stay in loot/ only. Use scripts/challenge_harness.py capture-flag to validate and record flag capture without printing the value.

Memory Summary

Metadata

• Platform: HackTheBox Challenges
• Category: Reversing
• Challenge: Virtually-Mad
• Difficulty: Medium
• Source workspace: <local workspace>

Validated Solve Chain

Concepts only. Do not include raw flags, reusable credentials, tokens, cookies, private keys, or live secrets.

1.

Reusable Lessons

-

Dead Ends

-

Tool Quirks

-

Evidence Paths

-

Ingestion Decision

• Proposed for LightRAG: yes/no
• Requires user approval before ingestion: yes

Hypothesis Board

Keep no more than 3 active hypotheses on Easy/Medium and 5 on Hard unless the user explicitly asks for breadth.

Closed Branches