JoasASantos/REA-Prompts

REA Investigation Prompts (REAP) — Reverse Engineering with your Coding Agent

A curated collection of prompts for REA (Reverse Engineer Anything) — the toolset that lets your AI coding agent inspect how software works, from native binaries, firmware and kernels to games, Electron apps, APKs and websites.

Prompts are ready to paste into your agent. Replace everything in `` and keep each request focused on one feature — narrow questions get evidence-backed answers.

Star History

Install as agent skills (recommended)

setup.sh (macOS/Linux) or setup.bat (Windows) copies every prompt section into your coding agent's skills folder (~/.hermes/skills, ~/.claude/skills or ~/.codex/skills):

./setup.sh          # auto-detect installed agents
./setup.sh hermes   # or: claude-code | codex | all

setup.bat           :: Windows

What you get:

• Skills/ — 26 skill packs, one folder per section (reap-00-install-and-verify … reap-22-go-and-rust-binary-source-recovery, plus reap-prompts index, reap-wildcard and reap-prompt-writing-tips), each a SKILL.md with YAML frontmatter the agent auto-loads when relevant.
• system_prompt.md — the whole library as a single document you can paste into any agent's system prompt / custom instructions instead of installing skills.
• tools/build_skills.py and tools/build_system_prompt.py — regenerate Skills/ and system_prompt.md from readme.md (the setup scripts run them automatically; readme.md stays the source of truth).

Sources & credits

• REA tools & guides: https://rea.tools/
• Official prompt gallery: https://madewithrea.com/prompts
• Intro thread ("REA is the most dangerous thing on the internet right now") by codila — https://x.com/0xCodila/status/2109623431763292649

(quoting Matthew Berman — https://x.com/MatthewBerman/status/2108245653843509415)

• REAP Name by https://x.com/zazencodes?s=11

Table of contents

| # | Section | |---|---------| | 0 | Install & verify | | 1 | Getting started | | 2 | Feature tracing (any program) | | 3 | Native binary exploration | | 4 | Software & feature cloning | | 5 | Games | | 6 | Game portability to WASM | | 7 | Firmware & embedded | | 8 | Android | | 9 | Kernel analysis | | 10 | Vulnerability research | | 11 | Electron & JavaScript | | 12 | Anti-cheat & protection research | | 13 | DMA & hardware-assisted cheat research (defensive) | | 14 | Software cracking research | | 15 | Version comparison & crash work | | 16 | Long-running investigations | | 17 | Malware analysis | | 18 | Advanced binary exploration & deobfuscation | | 19 | Kernel & driver exploitation research | | 20 | Advanced software cloning & feature reconstruction | | 21 | Protector & obfuscator research | | 22 | Go & Rust binary source recovery | | — | Wildcard prompt · Prompt-writing tips · Next steps |

⚠️ Use responsibly. Only analyze software you own or are explicitly authorized to test. Anti-cheat, DMA, DRM, kernel and vulnerability prompts below are for security research, interoperability, CTFs, bug bounties and testing the protection of your own software. Bypassing protection of software you don't own, cheating in online games, or weaponizing a found vulnerability may violate law and terms of service. Every prompt asks the agent to separate confirmed facts from hypotheses and to cite evidence — treat that as non-negotiable.

---

0. Install & verify

Install REA and connect it to this agent using: npx rea-agents@latest setup
First, show me the installation plan and the configuration changes for my
approval. After the install, verify the connection and list the available
tools and workflows.

---

1. Getting started

First exercise — trace a CSV export

Download https://rea.tools/examples/notes-example.zip into a new folder and
extract the contents.
Use REA to investigate what happens when I click "Export notes". Trace the
flow from the button to the file write.
Show where notes.csv is created, which fields it contains, and the files and
functions that prove each step.

First look at an unfamiliar app

Use REA to give me a map of : its main parts, entry points and the
three features worth investigating first. Keep it short and point to evidence
for each claim.

---

2. Feature tracing (any program)

Explain one feature

Use REA to investigate how  works in .
Identify the entry point, the functions involved, the data flow, the
dependencies and the observable effects.
For every conclusion, present evidence: file, function, address or relevant
snippet. Separate confirmed facts, inferences and points that remain unknown.
Do not execute the application in this step.

Trace a button to its effect

Use REA on . Start at the  button and trace what happens
until the result is written, sent or shown. Name every module or function on
the path and what each one does.

Recover a rule and rebuild it

Use REA to find the rule that controls  in . Write the
rule in plain words, then build a minimal standalone version I can run, and
give me one input that proves it matches the original.

---

3. Native binary exploration

Understand an executable

Analyze  with REA.
Identify format, architecture, runtime, libraries, relevant strings and
possible entry points.
Map the main components and explain their responsibilities with evidence.
State which analysis engine is available and its limitations.
Start with static analysis.

Function deep-dive

Use REA on . Pick the function that handles  and produce:
decompiled pseudocode, its callers and callees, the data structures it reads
or writes, and every string/global it touches. Annotate each finding with the
address range that proves it.

Imports, strings and triage map

Use REA on . Produce a triage map: file format and architecture,
section layout, linked libraries and imports grouped by capability (network,
filesystem, crypto, process/thread, registry/IPC), interesting strings with
their addresses, and the top candidate entry points for . Flag any
signs of packing, obfuscation or control-flow flattening.

File-format reverse engineering

Use REA on  to work out how it reads and writes .
Describe the structure field by field, show where each field is parsed, and
write a small reader that prints a sample file.

Protocol / serialization extraction

Use REA on  to recover the wire format used for 's network or
IPC traffic. Show the marshal/unmarshal functions with addresses, list every
field (size, endianness, encoding), and produce a Python struct/proto
definition plus one example message built from the code's constants.

---

4. Software & feature cloning

Clean-room methodology: extract behavior, not code. Never copy

proprietary source, assets, branding or licensing mechanisms.

Full application clone (behavioral)

Use REA to study  as a black box for a clean-room clone.
Produce CLONE_SPEC.md covering: every user-visible feature, screen and state
machine; inputs, outputs and edge cases; file formats and network protocols it
uses; settings and persistence layout; error behaviors.
For each requirement, cite the evidence (function, address, string, captured
request). Mark anything unconfirmed as UNKNOWN. Do not copy code or assets —
I will implement from the spec only.

Clone one feature into my own app

Use REA to recover the exact behavior of  in : trigger,
inputs, processing steps, outputs, side effects and failure modes.
Then implement  from scratch in  matching that
behavior, with tests derived from the recovered rules. List every observable
difference that remains between my version and the original.

Validate a clone against the original

Compare  with the observed behavior of .
Use verify_reconstruction, if available. Check results, errors, limits and
state transitions.
Present passing cases, divergences and behaviors not yet tested. Do not
consider equivalence demonstrated just because a few examples passed.

UI/UX behavior cloning without assets

Use REA on  to document its interaction model: layout logic,
keyboard shortcuts, command dispatch, undo/redo semantics and clipboard
formats. Recreate the behavior in  using only my own visual
assets, matching the documented semantics. Show which original function
proves each documented rule.

---

5. Games

Gameplay logic recovery

Use REA to reconstruct  from its executable. Recover the gameplay logic
in C and test it against the original.
For each mechanic (movement, physics, scoring, spawning), show the function,
the constants and the update loop that prove the rule.

Speed / difficulty rule (dino-style)

Use REA to inspect . Why does  change over time? Show
the exact rule and the constants behind it, then build a small standalone
version with an adjustable parameter.

Engine & asset pipeline map

Use REA on . Identify the engine or framework,
the render loop, the update/tick order, how levels and assets are loaded and
serialized, and where gameplay data lives (tables, scripts, archives). Map
each component to functions/addresses and describe the load pipeline step by
step.

Single-player mod support (offline only)

Use REA on  to locate the code that controls
. Show the data tables or functions with
addresses. I only want to understand where the values live so I can build my
own offline trainer for personal experimentation — no multiplayer, no
persistence tricks.

---

6. Game portability to WASM

Port a native game to the browser

Use REA to analyze  as a portability target for WASM.
Map: the main loop and frame pacing, the rendering backend (OpenGL/DirectX/
SDL/Vulkan calls), filesystem and save paths, threading model, audio output,
input handling, and any platform-specific APIs or inline assembly.
For each, classify as: portable as-is / needs shim / must be rewritten. Cite
the functions and call sites that prove each classification.

Build the port plan

Based on the REA findings for , produce a WASM port plan:
toolchain choice (Emscripten or manual recompile) and required shims
  (GL→WebGL, SDL→SDL2-compat, pthreads→SharedArrayBuffer/threads);
the minimal set of source modules to compile;
how saves move to IndexedDB and assets to fetch/streaming;
performance risks found in the native code (allocation per frame, busy
  loops, 64-bit assumptions) with function evidence;
a milestone list ending in a playable index.html.

Port the logic core first (headless)

Use REA to isolate 's pure simulation logic (physics, AI, rules) from
rendering and OS calls. Extract the exact rules with evidence, then implement
that logic core in C/Rust compiled to WASM with a test harness that replays
recorded inputs and compares state hashes against the original behavior.

---

7. Firmware & embedded

Firmware image triage

Use REA to analyze .
Identify the container format, extract partitions/filesystems (JFFS2, SquashFS,
UBI, cramfs...), map each region to architecture and load address, locate the
kernel and rootfs, and list boot entries, init scripts and services.
Show offsets, entropy observations and the evidence for every claim. Start
with static analysis; do not flash or run anything.

MCU / IoT binary analysis

Use REA on  for a  target.
Find the vector table and reset handler, reconstruct the memory map from
literal pools and peripheral base addresses, identify the RTOS (FreeRTOS,
Zephyr...) from symbol/string fingerprints, and map the main task loop and
peripheral drivers (UART, SPI, I2C, radio stack) with function addresses.

Embedded protocol & update mechanism

Use REA on  to recover: the network stack usage (hardcoded IPs,
DNS, MQTT/HTTP endpoints, ports), the OTA update path (download URL, signature
check, flash write), and credential material (keys, default passwords, debug
tokens). For each finding give the function/address and say whether the
behavior is confirmed statically or still a hypothesis.

---

8. Android

Audit an APK

Use REA to analyze .
List declared permissions, exported components, analytics/tracking SDKs,
domains found and local storage mechanisms.
For each finding, show the corresponding class, method or file.
Distinguish references present in the code from behaviors actually observed.
Do not conclude that a domain is accessed just because it appears in a string.

Trace a feature through Java/Kotlin and native code

Use REA on  to trace  end to end: UI entry point (Activity/
Fragment/Composable), the Java/Kotlin call chain, any JNI boundaries
(RegisterNatives / native library loads), the .so functions involved, and the
final effect (network call, file write, database row). Show class, method and
offset evidence at every hop.

Storage, crypto and secrets review

Use REA on . Determine how the app stores : SharedPreferences,
SQLite, files, keystore. Recover any embedded crypto (hardcoded keys/IVs,
obfuscation routines) with the class/method that uses them. State whether
data is encrypted at rest and in transit, with evidence, and list concrete
risks.

Obfuscated / packed app triage

Use REA on  that appears obfuscated or packed. Identify the packer or
protector (string/class fingerprints, loader stub in the native libs), map
what is statically visible vs. deferred to runtime, and propose the minimal
safe steps to reach the real dex/native code for analysis.

---

9. Kernel analysis

Driver inspection (Windows / Linux)

Use REA on .
Identify the format and target OS version, the entry/init routine, the device
object and driver dispatch table, every IOCTL code with its input/output
buffer validation, the callbacks/notifications it registers, and the memory it
reads or writes outside its own allocations.
Map each finding to function/address evidence. Static analysis only — do not
load the driver.

IOCTL attack-surface enumeration

Use REA on . Enumerate all control codes handled, and for each:
the handler function, how it validates input/output buffers (probe methods,
size checks, IRQL assumptions), and any copy_to_user/copy_from_user or
memcpy with attacker-controlled length. Rank the handlers by risk with
evidence for the ranking.

Kernel subsystem / syscall behavior

Use REA on  to explain how 
processes . Trace from the syscall/dispatch entry to the parsing
functions, show bounds checks (or their absence), the data structures
populated, and error paths. Cite addresses for each step.

---

10. Vulnerability research

Trust-boundary audit

Use REA to review the security of .
Prioritize trust boundaries, untrusted input, privileged operations,
credential storage, IPC, file handling and command execution.
For each possible vulnerability, present:
the input origin and the sensitive operation;
the code path and existing checks;
preconditions and impact;
evidence and uncertainties;
a proposal for controlled validation.

Do not classify a hypothesis as a confirmed vulnerability without sufficient
evidence.

Sink hunt from untrusted input

Use REA on . List every place untrusted data enters (network sockets,
files, IPC, command-line, clipboard, URL handlers) and follow each source to
dangerous sinks: memcpy/strcpy with unchecked length, system/exec, dynamic
loading, deserialization, path concatenation. For each source→sink path give
the function chain with addresses and state which validation exists in
between.

Patch diffing (1-day to incomplete-fix hunting)

Use REA to compare  and  of .
Diff the security-relevant functions: what check was added, where else in the
binary the same pattern exists without the fix, and whether the fix covers
every caller of the vulnerable routine. Report candidate incomplete-fix
locations with function/address evidence, clearly labeled as hypotheses until
validated in a controlled environment.

Crash triage to root cause

Use REA to investigate this crash in .
Available evidence:
Relate the error to the functions involved, formulate hypotheses and indicate
which evidence supports each one.
Propose the smallest experiment needed to distinguish the hypotheses and
validate the cause.

How is my data handled?

I am allowed to analyse . Use REA to find where it stores or sends
. Show the code paths, say whether the data is encrypted at rest
and in transit, and list concrete risks with evidence.

---

11. Electron & JavaScript

Electron app anatomy

Use REA to analyze .
Locate the JavaScript files and any app.asar archives. Map the main and
renderer processes, the preload scripts and the IPC channels.
Then trace  from the UI to its implementation, including network
calls and filesystem operations. Show the evidence.

IPC & contextIsolation security review

Use REA on . Enumerate every ipcMain handler and the channels
exposed via contextBridge/preload. For each channel: what arguments it
accepts, whether it reaches shell.openExternal, child_process, fs, or webview
navigation, and what validation exists. Flag any handler where renderer-
controlled input reaches a privileged sink without checks — with file and
function evidence.

Minified / bundled JS feature tracing

Use REA on  to trace  through minified code.
Identify the module boundaries, recover the relevant functions with readable
names, follow the data flow from the UI event to the network/filesystem
effect, and produce a call graph. Cite offsets in the bundle for each hop.

Web feature mapping

Use REA to observe  while I use . List the requests, scripts
and state changes involved, then summarise how the feature works and which
parts run on the client versus the server.

Website clone (structure + behavior)

Use REA to inspect https:///. Recover the page structure, the client
routes, the API calls each view makes and the state management pattern.
Rebuild a functional equivalent with my own assets and styling, matching the
observed behavior. List requests and scripts as evidence per view.

Web app API-surface mapping

Use REA on  (authorized testing of an app I own or am permitted
to assess). Enumerate the client's full API surface: every endpoint the
bundled JavaScript calls, HTTP method, request/response shape, auth header or
token source, and where in the bundle each call is made (file + offset).
Group endpoints by feature and flag any that are called from the client but
validated only client-side. Separate endpoints proven in code from ones only
seen in traffic.

Source-map & bundle recovery

Use REA on . Check for exposed source maps (.map references in the
bundles or 404-then-200 probing of known paths). If maps exist, reconstruct
the original module tree, name the components/functions and map the recovered
sources to the shipped bundles. If they don't, de-minify the hot modules for
 by hand: rename locals, split the bundle into logical modules and
produce a readable equivalent. State clearly which names are recovered from
maps versus inferred.

Auth & token flow analysis (web)

Use REA on  to document its authentication flow end to end: where
the login form posts, how tokens are stored (cookie flags HttpOnly/Secure/
SameSite, localStorage, IndexedDB), refresh/renewal logic in the client code,
and which requests attach the token and how. Give the bundle offset proving
each step. Flag client-side-only authorization checks (UI gating without
server validation) as hypotheses to confirm with controlled requests.

WASM module inside a web app

Use REA on . Identify the toolchain that produced the
WASM (Emscripten, Rust/wasm-bindgen, Go/WASM), map the exported functions and
their JS callers, recover the linear-memory layout and any embedded strings or
data tables. For , trace the JS→WASM boundary: arguments crossing,
return values and side effects. Cite export indices and JS call-site offsets.

Browser extension (MV3) audit

Use REA on  I own or am authorized to review.
Enumerate manifest permissions, service worker and content-script entry
points, every host the extension can reach, message-passing channels between
content script / worker / page, and any remote code loading (eval, dynamic
script injection, update endpoints). Map each capability to the file and
function that implements it. Distinguish declared permissions from observed
behavior.

PWA / service-worker offline logic

Use REA on  to recover the service worker's behavior: cache strategy
per resource class (cache-first, network-first, stale-while-revalidate), what
data persists offline (IndexedDB stores and their schemas from the code), and
how queued actions sync when connectivity returns. Show the worker file and
the functions proving each rule.

---

12. Anti-cheat & protection research

Scope these at your own machine, your own software, a vendor bug bounty,

a CTF, or academic study. Never at other players'