Software reverse engineering: what it is, what it is for, and where the boundaries are

Reverse engineering is an investigation method. It can support interoperability, security, and preservation, but it does not automatically turn copying, circumvention, or distribution into permitted uses.

Open-source projects that reproduce familiar application workflows, game ports, and server reconstructions have put reverse engineering back at the center of the conversation. With AI agents accelerating analysis and implementation, the term now covers very different activities.

Observing an interface, studying a format, capturing traffic, disassembling a binary, decompiling a function, building an emulator, copying assets, and bypassing DRM are not equivalent activities. They use different techniques, create different risks, and may receive different legal treatment.

Reverse engineering starts with one question: how does this work?

A useful definition comes from NIST: examining a system to identify its components, relationships, and representations in another form or at a higher level of abstraction. In software, the process starts from something finished — behavior, a file, a protocol, or a binary — and tries to build a verifiable explanation.

Investigating a system is not the same as copying its code

Imagine a legacy application that exports files no modern tool can open. Without source code or documentation, a team may compare samples, vary inputs, and describe headers, fields, versions, and error conditions. The first result can be an independent specification used by another program to import the data.

Compare that with extracting proprietary code or assets, removing a license check, and redistributing the result. Some tools may overlap, but purpose, authorization, incorporated material, and effect are different. Saying only “it was reverse engineered” explains very little.

What an investigation looks like in practice

• Behavioral observation: vary inputs and watch outputs, states, and errors.
• Static analysis: inspect strings, headers, imports, symbols, resources, assembly, and pseudocode without running the artifact.
• Dynamic analysis: use debugging, tracing, and process or network capture to confirm what happens during execution.
• Disassembly: translate bytes into machine instructions.
• Decompilation: produce a high-level approximation that helps reason about the binary.
• Reimplementation: write new code from understood behavior and validate it against examples and boundary cases.

A decompiler does not recover the original source code. Names, comments, types, and part of the structure may be gone; optimization and obfuscation also distort the result.

Where reverse engineering can help

• Interoperability: understand formats and protocols so independent programs can exchange information.
• Security: analyze malware, investigate incidents, and research vulnerabilities within an authorized scope.
• Maintenance and migration: document or replace unsupported libraries, closed formats, and components from vanished vendors.
• Preservation: retain access to software and game behavior when hardware, media, operating systems, or servers disappear.
• Research and education: study compilers, systems, formats, and architectures in owned labs, CTFs, and authorized artifacts.

These uses do not automatically authorize distributing executables, ROMs, keys, protected assets, or circumvention tools. Purpose helps explain a case, but it does not replace the applicable license, contract, and law.

Modding, emulation, piracy, and circumvention are not synonyms

• Interoperability asks how independent programs can exchange and use information.
• Modding changes or extends a game and depends on its license, official tooling, assets, monetization, and online impact.
• Emulation reproduces platform behavior; the emulator, BIOS, ROMs, and keys remain separate questions.
• Preservation seeks to retain access and historical knowledge without automatically removing distribution restrictions.
• Piracy involves unauthorized copying or distribution; reverse engineering does not legitimize copying by itself.
• Circumvention involves access controls, DRM, or keys and may receive separate legal treatment.

What a clean-room process tries to demonstrate

A clean-room reimplementation tries to separate functional knowledge from protected expression. In a classic arrangement, one team observes behavior and permitted documentation and writes a specification. Another team, without access to protected code, implements from that specification. Sources, hashes, decisions, and role separation help establish provenance.

Clean room does not mean legal immunity. Trademarks, patents, trade secrets, visual expression, contracts, and protected assets may still matter. The process answers a narrower question: was the implementation written independently, or does it reproduce material from the original?

Why the Adobe-related projects attracted so much attention

In October 2026, projects from the ArtCraft community gained attention by presenting themselves as open-source Rust applications for workflows associated with Photoshop, Illustrator, Premiere, Lightroom, After Effects, InDesign, and Acrobat. PhotoCraft, for example, describes itself as a clean-room reimplementation based on public specifications and observed behavior, without proprietary code, shaders, or assets.

The accurate phrasing is “the project states.” A README does not replace an independent provenance audit or settle questions about interfaces, trademarks, patents, contracts, or incorporated material. Attention must also be separated from maturity: independent testing found missing capabilities, bugs, slow behavior, and compatibility problems. GitHub stars measure interest, not professional parity.

I also found no evidence that these projects used REA, the tool covered in the next article. They belong to the same wave of agent-assisted development, but no causal relationship has been demonstrated.

Games show how the boundaries change from case to case

In Sony Computer Entertainment v. Connectix, decided in the United States in 2000, the court found certain intermediate BIOS copies necessary to build an independent emulator to be fair use. The final product did not contain infringing BIOS material. The result helps explain why emulation is not automatically piracy, but it does not create worldwide permission for every emulator.

The 2024 Yuzu shutdown shows another scenario. Nintendo and Tropic Haze filed a joint motion for final judgment; the order recorded the use of unauthorized cryptographic keys to circumvent technological measures and imposed damages and a permanent injunction. Because the parties consented, the case is not a full trial establishing a general rule for every emulator. It still shows how DRM, keys, and distribution change risk.

Preservation projects face other boundaries. A native P.T. port for PC requires users to supply their own game copy. Concord Delta attempted to reconstruct the server API of a discontinued game and restricted access after video takedowns and legal concerns. Preserving behavior, redistributing assets, and replacing online infrastructure are different problems.

What AI agents actually change

Disassemblers, decompilers, debuggers, and protocol analyzers have existed for decades. Agents did not invent these tools. They lower the cost of coordinating them: locating strings and functions, following references, comparing versions, summarizing evidence, proposing hypotheses, writing an initial implementation, and generating differential tests.

The same speed creates new risks. A model may invent plausible names and relationships, treat pseudocode as original source, accept a few tests as complete equivalence, or reproduce the happy path while missing rare states and security boundaries. It becomes faster to find an explanation — and to spread the wrong one.

A checklist before starting or publishing an investigation

1. Was the software or artifact obtained lawfully?
2. Is there explicit authorization, an applicable license, or a research program?
3. Does the goal require this depth of analysis?
4. Are DRM, keys, authentication, licensing, or access controls involved?
5. Does the target contain personal data, credentials, or third-party secrets?
6. Does the result incorporate code and assets, or only documented behavior?
7. Is a clean-room process with role separation necessary?
8. Were version, hash, commands, environment, and evidence preserved?
9. Do the conclusions separate observed facts, inferences, and unknowns?
10. Does publication, distribution, or commercialization require specialist legal review?

A note on laws and contracts

This article is a technical and editorial analysis, not legal advice. Jurisdiction, contract, access, purpose, technological protection, and distribution change the assessment.

Brazil’s Software Law, Lei nº 9.609/1998, does not create a broad permission called reverse engineering. Article 6 lists specific situations, including backup copies, limited educational quotation, similarities resulting from functional characteristics, and certain technically indispensable integration for exclusive use. Article 12 establishes penalties for software copyright infringement.

In the United States, section 1201(f) of the Copyright Act addresses acts necessary for interoperability under specific conditions. In the European Union, Directive 2009/24/EC allows a lawful user to observe and study operation and permits decompilation indispensable to interoperability within defined limits. None of these rules fits the generic claim “reverse engineering is legal.”

Conclusion

Reverse engineering supports interoperability, malware analysis, format recovery, legacy maintenance, emulation, and digital preservation. The key caution is not turning usefulness into automatic permission.

AI agents make observation, analysis, documentation, and implementation cheaper to coordinate. This expands what one person or team can investigate, but it increases the responsibility to preserve evidence, test conclusions, and respect boundaries.

The next article makes this discussion concrete through REA. The interesting part is not inventing another decompiler, but integrating existing tools into a shared workflow for agents, evidence, and validation.