Blog
AI reverse engineering: software is no longer a black box
REA lets an AI agent study how an application works without its source code. It is controversial and disruptive, and it makes us rethink how we design, protect and build custom apps.
A developer opens their coding agent and asks a precise question: how does an authenticator app generate its six-digit code? There is no source code, only the published app. The agent opens the package, follows the functions involved and explains why the code changes every 30 seconds.
Until recently, that kind of analysis needed a reverse-engineering specialist and tools such as Ghidra or IDA. Now any team with a well-configured agent can attempt it.
AI-assisted reverse engineering turns published software into something that can be studied, and that changes how we design, protect and build applications. It is a controversial and disruptive technology, and both sides deserve to be understood before taking a position.
What REA is and why everyone is talking about it
REA (Reverse Engineer Anything) is an open-source project under the MIT licence that connects coding agents such as Claude Code, Codex, Cursor or Gemini CLI to reverse-engineering tools. According to its repository, it runs as an MCP server and a command-line tool, analyses everything locally and handles native binaries, Electron and JavaScript applications, websites, .NET assemblies, Android APKs, WebAssembly and firmware.
Its showcases are specific: how the Aegis authenticator calculates its login code, how Notion keeps formatting when blocks are copied, and how DX-Ball, a 1996 game, decides whether a sound plays on the left or the right. In that last case, InfoQ reports that the reconstructed function passes tests matching all 3,205 cases from the original x86 code.
On 17 October 2026, InfoQ counted more than 200,000 GitHub stars; two days later the repository had passed 300,000. The novelty is not the decompiler: REA relies on existing engines such as Ghidra, Hopper and IDA and, as InfoQ points out, does not claim to recover the original source code. What is new is that an agent forms hypotheses, queries the program and tests them again and again.
The controversial part: can any program be opened and copied?
The idea now circulating is that any application can be "decrypted" and replicated. Reality is more nuanced, but the concern is legitimate.
REA examines what software delivers to the device: compiled code, JavaScript bundles, resources and network calls. Whatever runs on a server never reaches the machine being analysed. Its own responsible-use disclaimer also warns that decompilation output may be incomplete or wrong.
Yet a lot does reach the device: the logic behind a feature, its calculations and the services it calls. If all of that lives on the client, understanding and reproducing it now takes far less effort. InfoQ reports concerns from independent developers who fear copies of their games and apps or people bypassing paid features, along with a Hacker News comment predicting that this will accelerate big tech moving apps to the cloud.
The project draws its own line: it declines to help with DRM or licence circumvention, game cheats or copying proprietary code, and it reminds users that receiving source-like output grants no rights to the original program.
What the law says: study, yes; clone, no
In the European Union, Directive 2009/24/EC, which Spain applies through article 100 of its Intellectual Property Act, draws a fairly clear boundary:
- A lawful user of a program may observe, study or test how it works to determine the ideas and principles behind it, while using it normally.
- Decompiling without permission is only allowed when it is indispensable for interoperability with an independently created program, when that information was not already available, and only for the parts needed.
- The information obtained may not be used to develop a program substantially similar in its expression, or for any other act that infringes copyright.
In short: ideas can be studied; someone else's code cannot be copied. Each product's licence and contract terms also apply, and for any specific case it is worth getting legal advice before analysing anything.
The other side: technical knowledge within reach of small teams
Used well, it democratises expertise that used to belong to very few people. For a studio like ours, it opens up concrete possibilities:
- Understanding infrastructures similar to a project's before designing it: how another application handles synchronisation, caching or communication between processes.
- Auditing the security of our own applications through an outsider's eyes.
- Integrating systems a client uses that lack proper documentation, within the limits of interoperability.
- Analysing the software a company already owns to design a custom tool that covers what it really uses.
- Recovering data from older tools a client wants to leave behind.
When we wrote that SaaS is dead "as we knew it", we were talking about building your own tools with AI in days. AI-assisted reverse engineering completes that shift: it is now also easier to fully understand the tool you want to replace.
What changes in the apps and experiences we build
Many of our trade fair activations run on kiosks, tablets or visitors' phones, in public spaces. With tools like REA, we start from a simple premise: anyone with time and curiosity can study what we install on a device.
In the MITMA interactive quiz, visitors answer questions, collect stars and, depending on their score, scan a QR code to claim a prize. For a mechanic like this, we propose validating the score and the prize on the server, with single-use codes, not only in the app the visitor is holding.
Photo AI is one of the flagship activations of WOMI, our own platform, and Turespaña 2026 is one of its best examples: visitors take a photo and, in three steps, appear in places across Spain. When a platform like this travels from fair to fair, the logic that gives it value and any credentials for AI services belong on the server; the kiosk only needs to display the experience.
How we propose to build it into our method
The aim is not to use it for everything, but at specific points in development:
- Review before delivery. Analyse our own builds (web, desktop or Android) the way an outsider would: exposed keys, reachable services, source maps or forgotten debug modes.
- Sensitive logic on the server. Prizes, scores, credentials and personal data are designed off the device from day one.
- Technical discovery of the client's software. With a licence and permission, understand formats and workflows to integrate with it or design an alternative. We ask the vendor for documentation first; reverse engineering comes in if that route does not exist.
- Study ideas, do not copy code. If another product solves a problem well, we document the principle and write our own implementation.
- Verify with tests. Every conclusion from the agent is checked with tests and human review, as in the DX-Ball case.
What the coming months will bring
Our view is that the value of software is shifting. Code delivered to the device protects less and less; what sets a product apart is the service behind it, its data, the experience and the judgement with which it is built. Expect more logic on servers, licences that mention agent-driven analysis, and teams that study other people's software as naturally as they read documentation today.
For anyone commissioning an application, the question is no longer only what it does, but also what it reveals.
If you want to find out what your current app exposes, integrate a tool you already use or design a custom one with this new landscape in mind, tell us about your project. At Viseni, we will look at it with you, with technical judgement and within the law.
