Software Reverse-Engineering

This post is an introduction to software reverse-engineering (RE).

Software reverse-engineering is the process of reverse-engineering existing software where there is no or little or no insight about how the program works.

For example, if we have already access to the source code or design documentation, there is no RE involved because we already full insight of its mechanisms. Do not confuse studying or documenting software with software RE.

A software reimplementation is the process of creating again existing software from scratch. You can read this post about software reimplementation.

A software mod (short for modification) is the modification of existing software. You can read this post about software modding.

Software RE Goals

The need of software RE could arise when dealing with closed source software or when the original source code has been lost.

The general goal on software RE is:

  1. Software analysis: Understanding how a closed source software works.
  2. Software reimplementation: Being able to recreate the original software in an open source way.

Software analysis possible deliverables:

  • Documentation explaining what it does and how it works
  • Design diagrams
  • Clarifying comments to the original machine or assembly code

Software reimplementation can also be referred as reconstructive decompilation, when it involves decompilation of binaries with partial recreation.

Software reimplementation possible deliverables:

  • Source code reimplementation (in assembly or high-level code)
  • Multimedia resources recovery (as graphics, sounds or documents)
  • Build automation instructions
  • Executable instances

The source code reimplementation needs to set some sub-goals hitherto:

  • Fidelity
  • Code openness
  • Portability

The software RE goals and specific desired deliverables must be set when starting a software reverse-engineering.

If the project is a recompilation going to be open source, it may make sense to substitute third-party proprietary libraries with equivalent open source libraries in the recompilation.

If portability is one of the priorities, it makes sense to substitute platform-dependent libraries or resources with equivalent cross-platform libraries.

Software RE Techniques

Techniques to reverse-engineer software:

  • Binary inspection
  • Disassembling/decompiling. Obtaining the assembly language or high-level programming language source code from the original binary code.
  • Debugging. Use a debugging tool to analyze the binary code.
  • Reverse Engineering. By examining the behavior and output of the binary, you might be able to infer parts of the original source code. This process involves analyzing the program’s functionality and trying to reconstruct the logic behind it.
  • Data Recovery. In some cases, old development files or remnants of the source code might be present in the binary as strings or symbols. Scouring the binary for such information could lead to partial source code recovery.
  • Black box analysis

Binary Inspection

Binary inspection can be performed through hex dumpers (at lower level) or binary analyzers (at higher level).

You can read this post about hex dumpers.

You can read this post about binary analyzers.

You can use the command “strings” in Unix-like systems to find ASCII characters within a binary file.

Disassembling/decompiling Software Binaries

Software binaries is one of the biggest assets for software RE. Unfortunately, it is not always available. When it isn’t, we should look for a different software RE technique.

An example where software binaries are not available is when we want to RE software related to a website with code run on server side. Another example is when software is run locally but we do not have control over the local system.

On the other hand, we will have access when software is run locally and we have some administration capabilities over the machine, as the system needs to possess the software binaries containing the software machine code in order to run it.

A disassembler is a computer program that converts machine code into assembly language.

The diassembled code is the assembly code that is obtained from a binary file from a diassembler.

Machine code and assembly code are dependent on the processor for which the original code has been coded, assembled or compiled. So it is valuable to have a good understanding of the specific assembly language used on the software binaries. You can read this post about assembly code.

Take note that the disassembled code is not equivalent to the original assembly code.

A decompiler is a computer program that converts a machine code into a high-level code.

The decompiled code is the high-level code that is obtained from a binary file using a decompiler.

There are some information that will be lost, for example,

There is no a 1:1 correspondence between machine and source code (either assembly or high-level code), so it is virtually impossible to retrieve the original source code from the machine code. The closest we can get is a reimplementation of the original software using new source code.

Different assemblers or compilers produces different machine languages. So it is valuable to know, when possible and it applies, which compiler has been used.

You can read this post about disassemblers and decompilers.

Debugging

You can get a list of popular debugging tools on this post.

Black Box Analysis

Black box analysis is used just by observing the inputs and corresponding outputs of a system where we have no insight.

Tools for Software Reverse-Engineering

Tools to obtain source code from software binaries

  • Disassembles and decompilers
  • Debugging tools
  • RE frameworks

RE Frameworks

You can read this post about reverse engineering frameworks.

Resource Editors

Resource Hacker, also known as ResHack, is a tool to viewing and editing resources in Windows executables, and it is used on video game modding.

Legal Aspects of Software Reverse Engineering

This sections is about the legal aspects of software reverse engineering.

This section has not been written by a lawyer; please consult one for any serious enquire about the topic.

Laws affecting RE

There are laws affecting:

  • EU
  • USA
  • Contract Law

EU Laws affecting RE

EU laws affecting RE:

  • EU Directive 2001/29/EC – EU Copyright Directive (EUCD)
  • EU Directive 2009/24/EC on the legal protection of computer programs
  • EU Directive 2016/943 on trade secrets

These are directives that have been transposed differently by each EU state member. Please check local implementations.

You can read the EU Directive 2009/24/EC on the legal protection of computer programs on this external link.

Article 5(3): Users may observe, study, or test a program to understand its underlying ideas and principles, as long as they are lawfully using the software

Article 6 (Decompilation): Decompilation is allowed only to achieve interoperability between independently created programs, and only if:
The information is not already available.
The acts are limited to what’s necessary.
The information is not used to create a substantially similar program or for other infringing purposes

According to EU Directive 2016/943, reverse engineering of a lawfully acquired product is considered a lawful means of acquiring information, unless contractually prohibited.

In CJEU Case C-13/20 (2021), the court ruled that decompilation may be permitted for debugging, even if not explicitly allowed by the license, provided it’s necessary and done lawfully

CJEU UsedSoft v. Oracle case The CJEU ruling in UsedSoft v. Oracle clarified that a lawful acquirer of a software license has the right to use the software, including downloading it, and that the vendor’s copyright is exhausted with respect to that specific copy. However, this right is tied to lawful acquisition of the license

CJEU Sony vs Datel add-on (2025) stated that creating software to modify copyrighted program is not illegal. You can read more about this on this external link.

You can find a list of EU copyright case law on this external link.

USA Laws affecting RE

USA laws affecting RE:

  • Defend Trade Secrets Act (DTSA)
  • Uniform Trade Secrets Act (UTSA)
  • 17 U.S. Code § 1201(f) of the Digital Millennium Copyright Act (DMCA)

According to DTSA and UTSA, reverse engineering is generally considered a lawful means of acquiring information, provided it is done independently and without breaching any agreements.

The 17 U.S. Code § 1201(f) of the DMCA states that reverse engineering is allowed for the purpose of achieving interoperability between computer programs, provided the person has lawfully obtained the software.

Recent law in the USA:

USA Sony v. Connectix (2000): Analyzing BIOS behavior (not code) to create emulators was allowed.

In ams-OSRAM USA Inc. v. Renesas Electronics America Inc. (2025) the Federal Circuit clarified that a trade secret becomes accessible as soon as it can be reverse engineered, not necessarily when it is actually reverse engineered

The contract law may add restrictions to RE.

Examples of contract law:

  • End User License Agreements (EULAs)
  • Terms of Service (ToS)
  • Non-Disclosure Agreements (NDAs)

Sometimes the contract law explicitly forbids reverse engineering.

Software RE Legal Requirements

This is a summary of RE law requirements:

  • Lawful obtention of software
  • Purpose of interoperability achievement
  • No DRM circumvent

Take into account that contract law may add additional restrictions.

Lawful Obtention of Software

The lawful obtention of software is a requisite for software ER, as mentioned in:

  • 17 U.S. Code § 1201(f) DMCA (the lawful obtention of sofware is a condition for reverse engineering)
  • Article 5(3) of Directive 2009/24/EC (the lawful use of the software is a condition to study a program)
  • UsedSoft v. Oracle case (the right to use software is tied to lawful adquisition of a license)

Lawful ways to obtain software:

  • Software legal purchase
  • Software publisher authorization

Purpose of Interoperability Achievement

The purpose of interoperability is mentioned in:

  • 17 U.S. Code § 1201(f) of the DMCA (RE with the purpose of achieving interoperability between computer programs is allowed)
  • Article 16 of EU Directive 2009/24/EC: decompilation is allowed only to achieve interoperability between independently created programs, and more conditions)

Interoperability might be justified in the following video game scenarios:

  • Accessibility features
  • Creation of external mods that interact with the game engine
  • Multiplayer clients or servers that can communicate with the original game
  • Game port to other platforms or OSs

EU may offer other exceptions such as educational or research purposes.

No DRM Circumvention

The no DRM circumvention:

  • United States: Digital Millennium Copyright Act (DMCA) – 17 U.S.C. § 1201
  • EU Copyright Directive (EUCD) – Directive 2001/29/EC, Article 6

The European Union: EU Copyright Directive (EUCD) – Directive 2001/29/EC, Article 6 prohibits:

  • Circumvention of “effective technological measures” protecting copyrighted works.
  • Distribution or marketing of tools or services primarily designed to circumvent such measures.

There are limited exceptions for lawful uses (e.g., education, research, interoperability).

The DMCA United States: Digital Millennium Copyright Act (DMCA) – 17 U.S.C. § 1201 prohibits:

  • Circumventing technological measures that control access to copyrighted works.
  • Manufacturing, distributing, or trafficking in tools or services that enable such circumvention.

Even if the use is legal (e.g., fair use), circumvention is still prohibited unless an exemption applies.

The Library of Congress reviews and grants exemptions every three years (e.g., for accessibility, security research, or device repair).

You might also be interested in…

External References

Leave a Reply

Your email address will not be published. Required fields are marked *