20 Repositories That Chain Reverse Engineering Into One Pipeline

Someone has listed the tools needed for reverse engineering as 20 GitHub repositories. The source is a tweet by rob. The main subject is a list by morluto, the REA author. The tweet includes a workstation video, and the interface brings together Opus 5.5, REA workflows, Clean-room loop, ANALYZE, SPEC.md, and REBUILD. After watching it, it is easier to understand what this setup is trying to solve: have an agent connect to decompilation, debugging, traffic, and validation tools to form a repeatable reverse engineering process.

The list is organized into five groups.

01 Analysis Core

REA: An MCP entry point that connects to the whole toolset.
Ghidra: A free decompiler. The link in the original tweet was truncated.
GhidraMCP: Lets agents operate Ghidra. The link in the original tweet was truncated.
ida-pro-mcp: Connects agents to IDA Pro. People with a license will look at this first. The link in the original tweet was truncated.

02 Mobile and Apps

jadx: Converts Android APKs back to Java.
Apktool: Unpacks an APK and packs it back together.
Frida: Hooks into an app at runtime.
ILSpy: Decompiles .NET. The link in the original tweet was truncated.

03 Binaries and Low Level

radare2: An RE framework that lives in the terminal.
x64dbg: A Windows debugger.
ImHex: A hex editor with a pattern language.
angr: A symbolic execution engine.

04 Network and Execution

mitmproxy: Sits in the middle and reads traffic. The link in the original tweet was truncated.
dnSpy: Debug and edit .NET applications.
rizin: A fork of radare2.
raddebugger: Epic Games' debugger. The link in the original tweet was truncated.

05 Reconstruction and Validation

awesome-ai-reverse-engineering: 122 repositories, all rated. The link in the original tweet was truncated.
awesome-reverse-engineering: Curated by the creator of REA. The link in the original tweet was truncated.
REA workflows: Ready-made reverse engineering research prompts, provided with REA.
clean-room loop: Repeatedly compares using SPEC.md, oracles, and checks until it matches.

The workflow is written very briefly: binario -> REA -> SPEC.md -> rebuild -> oracle -> retry. In the comments, someone latched onto this closed loop, saying that going from binario to SPEC.md to reconstruir is a beautiful idea. Others asked how well REA runs locally, whether it must go through an API, and how it performs on obfuscated binaries. These questions matter more than the number of tools.

Most of these tools are not new. Ghidra, jadx, Frida, and radare2 have been around in their respective circles for years. What has changed is orchestration: the agent handles invoking, logging, and checking against SPEC.md, while the oracle determines whether the reconstruction is equivalent. The fantasy of one-click cracking is easy to go off track. The real value is turning reading binaries, writing specs, rebuilding, and validating into a retryable closed loop. The more tools there are, the more you need clear boundaries. Reverse engineering has legal and authorization limits; being able to read a binary does not mean you can casually touch someone else's software.

Before bookmarking a list, figure out your goal first. Auditing your own application, learning about binaries, and handling malicious samples follow different paths. The tweet gives you a toolbox, not a license.