Hakimi Eiqbal (@hakimieiqbal) on X

What it claims

Hakimi Eiqbal's thread argues that a reverse-engineering setup should be chosen per target type, and that agent output counts only when backed by evidence ("evidence > plausible explanations"). It names concrete tools for each target. It also gives a setup command for REA, two adoption caveats, and a step-by-step workflow that ends in an independent reconstruction compared against the original.

How to use it

REA lives at github.com/morluto/rea. It connects coding agents to tools for native binaries, JavaScript/Electron apps, .NET assemblies, websites and runtime behavior. Setup:

npx rea-agents@latest setup

The setup proposes changes to the agent configuration. The user reviews and approves them, then restarts the agent.

The thread recommends starting with REA's worked examples, each scoped to one feature:

• Notes export: trace a button through the preload bridge and IPC handler to the CSV writer, then predict and test an edge case.
• Notion clipboard: follow clipboard behavior across Electron process boundaries.
• DX-Ball: trace a native sound calculation from the original instructions into a reconstruction that can be verified.
• Aegis: an APK investigation focused on TOTP behavior.

The MCP bridges it lists for Claude Code, Codex and similar agents are IDA Pro MCP (mrexodia), GhidrAssistMCP (symgraph), GhidraMCP (LaurieWired) and radare2 MCP (radareorg).

Per-target starting tools, beyond the categories the summary names:

• Native: Ghidra, radare2, Rizin, Cutter, plus GDB, LLDB, pwntools, ROPgadget, Detect It Easy, capa and YARA.
• .NET: ILSpy, dnSpyEx, dnlib and de4dot.
• iOS: Frida, OWASP MASTG, DVIA-v2 and libimobiledevice.
• Electron: the asar tool, Source Map Explorer, AST Explorer and Babel Parser.
• Web: Chrome DevTools Protocol, Puppeteer and Playwright.
• Firmware: Binwalk, EMBA, FACT Core and FirmAE.
• WebAssembly: WABT, Binaryen and wasm-tools.
• Protocols: Wireshark, Scapy, Zeek and Boofuzz.

For Electron, the suggested first trace is renderer, then preload bridge, then main process, then the actual side effect.

The thread's workflow has eight steps:

1. Pick software you own or are authorized to examine.
2. Identify one behavior.
3. Collect evidence.
4. Trace the relevant implementation.
5. Write a behavior specification.
6. Build an independent reconstruction.
7. Compare outputs.
8. Record mismatches and unknowns.

The suggested progression is Notes export, then Electron clipboard, a practice CTF binary, an APK feature, a native calculation, and finally firmware or protocols. For practice it names OpenSecurityTraining2 (its x86-64 material), pwn.college with Reversing Hell, and Malware Unicorn RE101, plus crackmes.one, Microcorruption, Flare-On and picoCTF.

The recommended first prompt, verbatim:

Investigate this one feature. Show the relevant files, functions, calls or instructions. Separate verified facts from hypotheses. Predict an edge case, test it where authorized, and report what remains unknown.

Limits

REA is open source, but the tools it drives still need their own licences; the thread names IDA Pro and Hopper. Analysis runs locally, but tool results are sent to the AI agent, so the model provider's data policy applies to whatever is being analyzed. The thread treats the agent as an assistant to the investigator, not the final authority on what a binary does. It reports no measurements of REA's or the MCP bridges' accuracy. Most repository links on the page are truncated, so full paths for the MCP bridges and several tools have to be looked up.