Low Level, a vulnerability researcher, used Reverse Engineer Anything (REA) to inspect the compiled Linux version of GNOME Calculator. An agent produced a Python recreation in roughly 28 minutes. It looked close and passed the on-camera arithmetic check. Its mode control was in a different position, and its layout broke when the window was enlarged. That is a striking assisted build, but not a recovered codebase or a complete reproduction of the application.
REA's contribution is a repeatable investigation loop: let an agent ask an analysis tool about a binary, inspect the returned evidence, and ask a better follow-up question. Low Level's demo shows that loop can help create a usable slice of a desktop app quickly. It does not isolate REA's advantage over a plain coding agent, establish full feature parity, or settle the legal and security questions raised by copying software.
Watch Low Level's Test
Credit and disclosure: The experiment, interpretation, and demonstrations are Low Level's. His video includes a CodeRabbit-sponsored segment on pull-request triage before the REA walkthrough; it is not part of the calculator test. This article also checks the REA project documentation and GNOME's public source repository.
What REA Does, and What a Decompiler Cannot Give Back
At 02:57, Low Level explains the basic problem: a compiled program contains machine instructions, while variable names, comments, and some other source-level details may be gone. A decompiler such as Ghidra infers pseudocode and relationships from the executable. Its output can reveal behavior, but it is not the original source file.
Low Level first shows a small constant-recovery example. The number 0x1337 in hexadecimal is 4919 in decimal, so he can identify the expected input from the compiled program (04:38). That illustrates what binary inspection can reveal. It does not mean every algorithm, asset, network service, or product workflow can be recovered equally well.
REA is the layer that makes such investigation easier for a coding agent. Its project guide says native analysis can use an existing Ghidra, Hopper, or IDA installation; the agent receives observations and limits through CLI or MCP, then chooses what to inspect next. REA also documents other target types, including JavaScript and Electron applications. Low Level explicitly says he did not test those paths in this video. A website's browser code and behavior can be examined; merely visiting it does not expose the private implementation running on its server.
The GNOME Calculator Reconstruction
Low Level chooses GNOME Calculator, which is open source, but instructs the agent to work from the local binary rather than consulting the source. The resulting Python window arrives after about 28 minutes (06:27). The public source matters as an eventual answer key, although the video does not show a source-to-output audit.
| Visible check | What the video establishes |
|---|---|
| Appearance | A familiar calculator window, with a misplaced programming-mode control. |
| Basic arithmetic | Low Level runs one short calculation in the recreation and original; both show the same result. |
| Window resizing | The recreated layout visibly fails to scale cleanly. |
| Coverage | No systematic test of advanced modes, keyboard use, localization, accessibility, error cases, or long-term maintenance. |
He reports a roughly 936 KB ELF file and about 2,000 functions, then estimates that a person could take days or weeks to do the same job (08:21). Those are his observations and estimate, not a controlled human-versus-agent benchmark. The video also does not report total tokens, monetary cost, retries, or a measured correctness score.
The Missing Comparison
Low Level acknowledges that he has seen similar recreations made without REA (11:04). That makes the causal question important: how much did binary evidence help, and how much could an agent have inferred from the visible calculator UI and common arithmetic behavior? His one run cannot answer it. Our Mac Preview comparison follows a two-route attempt, but that video also lacks a controlled, repeatable benchmark.
The strongest supported conclusion is narrower: REA gave this agent a structured way to explore a binary and reach a plausible first implementation. A convincing window is not proof of the original algorithms, complete product behavior, or production readiness. The resizing failure is useful evidence because it shows exactly where resemblance stopped.
Who Maintains the Copy, and Can You Trust It?
Low Level then leaves the calculator and asks three strategic questions. Maintenance: who fixes an AI-generated alternative after the exciting first build? Supply chain: should a user run a new lookalike application without checking its provenance, dependencies, permissions, and update process? Ownership: might vendors move more functionality to servers to make it harder to inspect locally? These are reasonable questions, but they are forecasts and risk judgments, not outcomes measured by the demo.
Open source is not inherently unsafe, and a paid vendor is not inherently safe. For either source, check who maintains it, how releases are built, what permissions it requests, how vulnerabilities are handled, and whether the source matches the package you run. Building from source helps with provenance only if you trust and review the source and build chain. The REA disclaimer also frames the tool for lawful, authorized analysis. Technical ability to inspect an app does not grant permission to copy its code, assets, name, or protected workflows.
A Safer First Test
- Choose an authorized target. A small app you own is ideal; keep its source as a hidden answer key.
- Specify the behavior first. Write tests for ordinary input, errors, resizing, keyboard use, and accessibility before asking for a recreation.
- Compare two routes. Give one agent only the documented behavior and screenshots; give another the same brief plus approved binary analysis. Hold the model, time budget, and reviewer constant.
- Record the whole cost. Include tool setup, token use, elapsed time, failed tests, and human repairs. Do not call a visual match a feature match.
- Review the environment. Read REA's setup changes, isolate untrusted binaries, and decide whether findings may leave your machine for a model provider.
Jump to a Segment
| Time | Topic |
|---|---|
| 00:00 | The viral REA claim and Low Level's questions |
| 01:19 | CodeRabbit sponsor segment |
| 02:57 | How reverse engineering works |
| 04:38 | Constant-recovery example |
| 05:29 | Ghidra, IDA, Hopper, and pseudocode |
| 06:27 | REA analyzes GNOME Calculator |
| 07:18 | Side-by-side result and visible bugs |
| 08:58 | REA as an investigation harness |
| 11:04 | Missing baseline and token cost |
| 11:57 | Maintenance and software economics |
| 13:11 | Supply-chain trust |
| 14:12 | Server-side software forecast |
| 15:37 | Why learn reverse engineering anyway? |
Copyable Brief for an Authorized Test
Use this to request a measured comparison on a program you own. It starts with scope and permission rather than assuming a particular agent or tool is installed.
Measure the rebuild, not just the screenshot
Same target, two routes, written acceptance tests.
Sources and Credits
Primary video: Low Level's REA walkthrough and GNOME Calculator test, with the supplied transcript. Project documentation: REA repository, REA guides, and REA disclaimer. Analysis tools and target: Ghidra, GNOME Calculator, and its source repository. The calculator timing, file size, function count, and human-effort estimate are Low Level's reported observations; no independent run logs or full acceptance-test results accompany the transcript.