Your first analysis with REA
Before you start
You need REA set up in your agent (see the install guide) and a target you are allowed to examine: your own app, an open-source project, a CTF binary or a practice target made for learning. Commands below come from the REA project's public README, CLI guide and agent prompts; check them there if something has changed.
Start with a JavaScript or Electron app
Static JavaScript analysis needs no native analysis engine, so it is the shortest path to a first result. Point REA at an extracted app directory or an ASAR file:
npx -y rea-agents@latest analyze-javascript-application /absolute/path/to/app --json
The result lists modules, imports, Electron boundaries and the evidence for each. Use an absolute path; on Windows that looks like "D:/apps/example". Static inspection reads the files without running the app.
Ask your agent
Inside your agent, describe the target, the feature and what you want back. The README's example:
Understand how search works in the Notes app, show me the evidence, and build a
similar feature for my project.
Your agent calls REA through MCP, traces the relevant code and gets findings with their evidence. A good first question is narrow: one feature, one target, a request for evidence. Ask the agent to keep what it observed, what it inferred and what is still unknown apart.
Guided investigations
REA also exposes six investigation workflows through MCP prompts. Clients that show MCP prompts list them by name:
| Prompt | What it is for |
|---|---|
investigate_feature | Trace a feature from discovery into the relevant functions |
compare_application_versions | Compare two shipped builds |
verify_reconstruction | Check a reconstruction against the retained evidence |
trace_crash | Link a crash symptom to code paths |
audit_residual_unknowns | Review what is still unknown |
prepare_bounded_process_capture | Plan a controlled runtime experiment before running anything |
Native binaries
Native analysis uses Hopper, Ghidra or IDA. Check that one is ready, list the providers REA can see, and pick one when several support the target:
rea doctor --provider ghidra --json
rea providers --json
rea analyze /absolute/path/to/program --provider hopper
rea doctor only reads your setup; it changes nothing. You can also set REA_ANALYSIS_PROVIDER as a standing preference. Native results include pseudocode, assembly, strings, symbols, calls and references.
Read the result like a reviewer
The project's disclaimer is direct: decompilation, reconstruction and AI-assisted analysis may be incomplete or incorrect. Check the evidence behind each conclusion before you rely on it, and remember that an analysis report or source-like output grants no rights to the original program. Runtime workflows run or interact with the target using your permissions, so try untrusted targets in a suitable environment. See safe and legal use.
Share what you found
Did something interesting with REA? Submit your case to this directory with a link to the original source. The REA project also welcomes cases in its issues.