Glonce

REA gives coding agents reverse-engineering tools, shown on Chrome's dinosaur game

toolsThe Glonce editorsHacker News🔥68Glonce rating68Impact45Novelty50Relevance80Surprise40Players10Credibility70

REA, presented at rea.tools, is positioned as reverse engineering done with your coding agent. The page says it gives the agent the tools to inspect a program and explain what it does. It defines reverse engineering as finding out how software works by examining the program itself, with the goal of understanding a feature well enough to explain it, change it or rebuild it.

Setup is a pasted prompt. You copy a line into your coding agent asking it to install REA and connect it using npx rea-agents@latest setup, to show the setup plan for approval, and then to verify the installation.

The page walks through two examples. The first is Chrome's dinosaur game, with the question of why the dinosaur gets faster. The goal is to rebuild the game with adjustable speed, which requires the rule in the running game: how fast it starts, how much it increases and when it stops. REA inspected the HTTP browser edition through a local debugging connection and returned the loaded index.js, with its source and digest. The agent read the update function and speed settings. The code increases the current speed by ACCELERATION while it is below MAX_SPEED. The config values are SPEED: 6, ACCELERATION: 0.001 and MAX_SPEED: 13. In plain terms: start at 6, add 0.001 on each update without a collision, while speed is below 13.

To check the rule, the page says it called the original game's update function in a controlled browser check, with obstacles and automatic scheduling disabled. After 4,000 updates the speed was 10.0, and after 10,000 it was 13.0, rounded to one decimal. The new mini-game keeps that speed rule, but its drawing, jumping and collision code is a small teaching implementation. A linked speed lab shows the new code and runs the same speed check.

The second example is the Windows Calculator % button, prompted by one question: why does Calculator give 220 for 200 + 10%? The page says the same button uses different rules after + and ×, and that the installed app was inspected to find which number the percentage is applied to. REA's output is that one branch divides by 100 and the other also multiplies by the first number. In the shown pseudocode, if the operation is multiply or divide, percent is current / 100; otherwise percent is current * previous / 100. With previous = 200 and current = 10, addition takes 10% of the first number (20), so 200 + 20 = 220. Multiplication turns 10% into 0.1, so 200 × 0.1 = 20. The supporting disassembly compares the operation code against 0x5c (IDC_MUL, 92) and 0x5b (IDC_DIV, 91) and loads the constant 0x64, which is 100.

Beyond the demos, the page suggests prompts such as asking REA to inspect https://rea.tools/ and clone the website, or to reconstruct a game from its executable by recovering the gameplay logic in C and testing it against the original. It lists three areas of capability: native binaries (functions, strings, references and call relationships in executables and libraries), JavaScript and Electron (modules, routes, IPC and native dependencies from an application folder or ASAR archive), and browser and runtime activity (capturing selected browser or process activity and comparing results across runs). A starter exercise has you download a Notes example, trace its CSV export and check one changed input. The page points to a FAQ, Discord and GitHub issues for questions and bug reports.

Key facts

  • REA gives a coding agent tools to inspect a program and explain what it does; setup is a pasted prompt that runs npx rea-agents@latest setup, shows a plan for approval, then verifies the install.
  • Chrome's dinosaur game example: REA returned the running index.js, and the recovered rule is start at 6, add 0.001 per update without a collision, while speed is below 13.
  • The speed rule was checked on the original update function: 4,000 updates gave speed 10.0 and 10,000 gave 13.0, rounded to one decimal.
  • Windows Calculator example: after + the % button takes a percentage of the first number (200 + 10% = 220); after × it uses current / 100 (200 × 0.1 = 20). The disassembly shows the constant 0x64 = 100.
  • The page lists three areas: native binaries, JavaScript and Electron apps (including ASAR archives), and browser or process activity capture.

Why it matters

The page makes one claim: reverse engineering, the slow work of finding out how a program behaves, can be handed to the coding agent you already use. Its demos are small but concrete. A speed rule that took reading a running script becomes three numbers (6, 0.001, 13), and a puzzling % result in Calculator becomes two branches and a constant. The stated goal is to understand a feature well enough to explain it, change it or rebuild it.

Who it affects

People who already work with a coding agent and want it to look inside a program rather than only write new code. The page addresses both newcomers, with a what-is-reverse-engineering explainer, and people who already know the field, who can skip to analysis guides. The three listed areas cover native executables and libraries, JavaScript and Electron apps, and browser or process activity.

How to use it

Copy the prompt from the page into your coding agent. It asks the agent to install REA and connect it using npx rea-agents@latest setup, show the setup plan for approval, then verify the installation. After that, you tell the agent what you want to understand or build, for example inspecting a page, or reconstructing a game from its executable and testing it against the original. To inspect a browser target such as the dinosaur game, give your agent the page URL and your local debugging endpoint. The page also offers a Notes example for a first investigation. No pricing, licence or open-source status is stated.

How solid is it

The evidence is the page's own demonstrations. The dinosaur speed rule was checked by calling the original game's update function in a controlled browser check, and the Calculator logic is backed by shown disassembly and matching constants. These are first-party examples. No independent benchmarks or user testimonials are given, and the page names no authors, company or team behind REA.

Risks and caveats

The rebuilt mini-game keeps only the recovered speed rule; its drawing, jumping and collision code is a small teaching implementation, not recovered original code. The number of updates needed to reach the 13 cap is not stated, only the 4,000 and 10,000 checkpoints. The page does not say what exactly the setup command installs beyond connecting REA to the coding agent, which is why the prompt asks for a plan to approve first. No legal or licensing discussion of reverse engineering is given.

“REA gives your agent the tools to inspect a program and explain what it does.”

— rea.tools