JoasASantos/REA-Prompts

REA Investigation Prompts — Reverse Engineering with your Coding Agent

Sources & credits

Table of contents

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 <program>: 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 <FEATURE> works in <PATH TO APPLICATION>.

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 <app>. Start at the <button name> 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 <behaviour> in <program>. 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 <PATH TO EXECUTABLE> 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 <binary>. Pick the function that handles <operation> 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 <binary>. 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 <FEATURE>. Flag any
signs of packing, obfuscation or control-flow flattening.

File-format reverse engineering

Use REA on <program> to work out how it reads and writes <file type>.
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 <binary> to recover the wire format used for <feature>'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

Full application clone (behavioral)

Use REA to study <application> 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 <FEATURE> in <application>: trigger,
inputs, processing steps, outputs, side effects and failure modes.

Then implement <FEATURE> from scratch in <MY LANGUAGE/PROJECT> 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 <MY IMPLEMENTATION> with the observed behavior of <ORIGINAL
APPLICATION>.

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 <application> to document its interaction model: layout logic,
keyboard shortcuts, command dispatch, undo/redo semantics and clipboard
formats. Recreate the behavior in <my framework> 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 <GAME> 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 <game>. Why does <difficulty/speed> 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 <game executable/data folder>. 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 <offline single-player game> to locate the code that controls
<weapon stats / spawn rates / economy>. 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 <game executable/source> 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 <game>, 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 <game>'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 <firmware image / bin / img>.

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 <firmware blob> for a <ARM Cortex-M / MIPS / AVR / ESP32> 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 <firmware> 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 <PATH TO APK>.

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 <APK> to trace <FEATURE> 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 <APK>. Determine how the app stores <data>: 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 <APK> 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 <driver binary: .sys / .ko>.

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 <driver>. 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 <kernel binary or module> to explain how <subsystem/syscall>
processes <input>. 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 <authorized application or binary>.

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 <binary>. 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 <vulnerable version> and <patched version> of <component>.

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 <application>.

Available evidence:
<STACK TRACE, LOGS, DUMP OR REPRO STEPS>

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 <program>. Use REA to find where it stores or sends
<kind of data>. 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 <PATH TO ELECTRON APP>.

Locate the JavaScript files and any app.asar archives. Map the main and
renderer processes, the preload scripts and the IPC channels.

Then trace <FEATURE> from the UI to its implementation, including network
calls and filesystem operations. Show the evidence.

IPC & contextIsolation security review

Use REA on <Electron app>. 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 <app.asar / bundle.js> to trace <FEATURE> 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 <site> while I use <feature>. 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://<site>/. 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.

12. Anti-cheat & protection research

Map an anti-cheat's detection surface

Use REA to analyze <anti-cheat driver/service binary> on a lab machine I own.

Identify: what it enumerates (processes, modules, handles, callbacks), which
integrity checks it performs, what it hooks or registers with the kernel, and
what data it sends out (endpoints, intervals, payload fields).

For each finding cite the function/address. Separate "code present" from
"behavior observed". Do not run the target game; static analysis first.

Test my own product's protections

I own <my application> and its protection scheme. Use REA to assess it as an
attacker would: locate the license check, the integrity checks, the
anti-debug/anti-VM tricks, and trace what a failed check does. Report which
checks are trivially bypassable, which are load-bearing, and concrete fixes —
each claim backed by file/function/address evidence.

DRM / license flow analysis (interoperability)

Use REA on <application> to document its licensing flow: where entitlement is
validated, what local and remote checks exist, what state is stored on disk,
and how offline mode behaves. Goal is interoperability and security review of
software I legitimately own. Report facts with evidence; flag anything you
could not confirm.

13. DMA & hardware-assisted cheat research (defensive)

How DMA memory access works on a target platform

Use REA on <anti-cheat driver / DMA-protection firmware (e.g. Thunderbolt
security, IOMMU/VT-d config)> in my lab.

Explain, with function/address evidence: how the platform restricts external
PCIe memory reads (IOMMU mappings, Thunderbolt ACLs, kernel DMA protection),
what the anti-cheat enumerates to spot a DMA device (PCIe topology, BAR
regions, unknown root ports, timing anomalies), and which checks are
load-bearing versus cosmetic.

Analyze a DMA-cheat toolchain sample (malware-style)

I have a sample <DMA firmware / PCILeech-style driver / user-mode reader> for
defensive research. Use REA to document: how it opens physical memory
(XNVIPHYSTREE-style access, PCIe BAR mapping), how it locates the game process
(PEB walking, page-table traversal), what it reads/writes, and any
anti-detection tricks (pattern scanning avoidance, timing padding). Give the
function chain with addresses for each stage. Do not run it against any live
game — analysis only.

Detection-gap analysis for my own product

Use REA to evaluate how <my application/my anti-cheat component> would react
to external physical memory access: which integrity checks exist, whether
sensitive values sit in predictable memory, what side-channel validation the
server performs. Propose concrete hardening (value obfuscation, server-side
validation, memory layout randomization) mapped to the code locations that
need each change.

FPGA/microcontroller device firmware study

Use REA on <device firmware dump> from a PCIe/USB device I own. Identify the
MCU/FPGA soft-core, the protocol it speaks to the host, the memory-read
primitives it implements, and how it hides from host enumeration. Show
evidence per claim and label anything that needs runtime confirmation.

14. Software cracking research

Keygen-repair style analysis (document, don't bypass)

Use REA on <binary> to find the validation routine for <license key / serial>.
Recover the algorithm (decompile it), identify the input encoding, the
checksum/transform steps and the success/failure branches with addresses.
Then write a test harness that exercises the recovered algorithm against
sample inputs. Do not patch or bypass anything — I want the algorithm
documented, not the check removed.

Crackme / CTF challenge solving

Use REA on this crackme: <path>. Enumerate entry points, strings, imports and
any packer/protection indicators. Identify the flag-checking logic, decompile
it, and derive the correct input from the recovered algorithm. Show the full
evidence chain: address → instruction → conclusion.

Protection-diffing between versions

Use REA to compare <protected app v1> and <v2>. Identify what changed in the
protection layer: new integrity checks, new anti-debug tricks, changed
validation paths. Map each change to functions/addresses and explain the
hardening intent.

15. Version comparison & crash work

Compare two versions

Use the compare_application_versions workflow, if available, to compare
<OLD VERSION> and <NEW VERSION> of <application>.

Identify functional changes, API changes, dependency and permission changes,
and possible security fixes.

Map each change to the corresponding functions or files and explain the
impact. Differentiate build changes from behavior changes.

16. Long-running investigations

Continue where you left off

Review the evidence and notes of this investigation.

Use audit_residual_unknowns, if available, to list what has not been
demonstrated yet.

Prioritize the next analyses by how much they can reduce uncertainty. Update
an INVESTIGATION.md file with findings, evidence, discarded hypotheses and
next steps.

Wildcard prompt (start here)

Use REA to understand how <FEATURE> works in <PATH TO APPLICATION>.

Check first which tools are actually available. Start with static analysis
and trace the feature down to the responsible functions.

Present evidence for each conclusion, separate facts from hypotheses, and
record the limitations. At the end, generate a behavioral specification and
propose tests to verify it.

Prompt-writing tips (why these work)

License