Software Reverse Engineering: A Simple Guide with Real Examples

Software reverse engineering played a key part in stopping one of the biggest cyberattacks in history. On May 12, 2017, the WannaCry ransomware spread across the world, locking files on hospital computers in the UK's National Health Service and on machines at companies in many countries. While studying a sample of the malware, security researcher Marcus Hutchins noticed that the code tried to contact a long, unregistered web domain. He registered that domain, initially so he could monitor how far the outbreak had spread. Only afterwards did it become clear that the malware checked whether the domain existed and stopped spreading when it did. That check became known as WannaCry's "kill switch."

Nobody had WannaCry's source code. Everything researchers learned about it, including why registering one domain stopped it, came from taking the compiled program apart and studying what it did. That's software reverse engineering: understanding how a program works by working backwards from the finished product.

It's not only a security skill. Developers use reverse engineering to understand legacy systems nobody documented, to make software work with closed file formats and protocols, to check what their own mobile apps reveal to attackers, and to recover data from old systems. Interviewers for security, mobile, and backend roles ask about it too.

This guide explains reverse engineering in plain English, from the basic idea to the tools, techniques, legal rules, and defenses. Each section is written so you can understand it on its own and explain it in an interview. The code examples were run, and the outputs shown are real.

Reverse engineering in 60 seconds

• What: analyzing a finished product (software, a protocol, a file format, a device) to understand how it works, without the original design documents or source code.
• Why: security (malware analysis, finding vulnerabilities), interoperability (making systems work together), maintaining legacy systems, recovering lost knowledge, and checking your own products.
• How: set a clear goal, collect information, use static analysis (study it without running it) and dynamic analysis (watch it while it runs), then document and test what you learned.
• Tools: Ghidra, IDA Pro, debuggers, Wireshark, decompilers like jadx for Android apps.
• Law: it's legal for many purposes in many countries, but limits come from copyright, anti-circumvention laws, contracts, and trade secret law. Check before you start.
• Lesson for every developer: anything you ship to a user's device can be read. Never put secrets in client code.

A note on responsible use: this article covers reverse engineering for learning, security defense, interoperability, and maintaining your own systems. It's not legal advice. Before analyzing software you don't own, check the license, your contract, and the law where you live.

What Is Software Reverse Engineering?

Reverse engineering is the process of analyzing an existing product to understand how it works, what its parts are, and how those parts fit together, usually without access to its original design documents or source code. The goal is to rebuild knowledge, not necessarily to rebuild the product.

A widely cited definition in software comes from a 1990 IEEE Software paper by Elliot Chikofsky and James Cross. In simple words, they described reverse engineering as studying a system to identify its components and how they relate, and then describing that system in a different form or at a higher level of understanding. An important point in their definition: reverse engineering itself is about understanding and describing, not changing the system.

Forward engineering vs reverse engineering

Normal software development is forward engineering: you go from an idea to requirements, then a design, then code, then a running program. Reverse engineering travels the same path backwards.

FORWARD ENGINEERING  (how software is normally built)
  Idea ─► Requirements ─► Design ─► Source code ─► Compiled program
                                                          │
REVERSE ENGINEERING  (working backwards)                  │
  Requirements ◄─ Design ◄─ Pseudo-code ◄─ Assembly ◄────┘
  "what is it for?"  "how is it structured?"  "what does each part do?"

You don't always need to go all the way back. Sometimes the goal is small ("what server does this app talk to?"), and you stop as soon as you have the answer.

A simple analogy: working out a recipe from a dish

Imagine you eat an amazing biryani at a restaurant, and you want to cook it at home. You don't have the recipe. So you:

• taste carefully and list what you can identify: saffron, fried onions, mint (that's static analysis, examining the finished product),
• watch the cook through the kitchen window, noticing the order of steps (that's dynamic analysis, observing the process in action),
• guess and test at home, adjusting until it tastes right (that's validation),
• write down your recipe so you can make it again (that's documentation).

You've reverse engineered the dish. You didn't steal the restaurant's recipe card; you rebuilt the knowledge from what you could observe. Software reverse engineering follows the same pattern.

Key terms in plain English

Interview answer: "Reverse engineering is analyzing a finished system to understand its components and how they interact, without the original source or design documents. It's forward engineering in reverse: from the binary back to code-level understanding, then design, then purpose. We use it for security, interoperability, legacy maintenance, and verifying our own products."

Why Reverse Engineering Exists: The Problems It Solves

Reverse engineering exists because, very often, the people who need to understand a system don't have the documents that explain it. Here are the main situations, each with the problem it solves.

1. Security: understanding malware and finding vulnerabilities

Malware authors don't publish their source code. To defend against an attack, analysts take the malicious program apart to answer questions like: How does it spread? What does it steal? Where does it send data? How can we detect or stop it? The WannaCry kill switch is the classic example.

Security teams also reverse engineer legitimate software, including their own, to find vulnerabilities before attackers do. Many security bugs are found this way and reported to vendors through responsible disclosure.

2. Interoperability: making systems work together

Sometimes your system must talk to another system that uses an undocumented protocol or file format. Without reverse engineering, you're locked out. The Samba project is the famous example: it reverse engineered Microsoft's file-sharing protocol so Linux and Unix servers could share files and printers with Windows computers.

3. Legacy systems: when nobody remembers how it works

Companies run old systems whose original developers left years ago. The documentation is missing or wrong, and sometimes even the source code is lost. Before you can fix, migrate, or replace such a system, you have to figure out what it really does. This is often called design recovery or software archaeology.

4. Compatibility and competition (done legally)

Companies sometimes need to build products compatible with a competitor's, for example a BIOS chip compatible with IBM PC software in the 1980s. Using a careful legal process called clean room design (explained later), they study the behavior of the original and rebuild it independently.

5. Verifying your own products

Reverse engineering your own app shows you what an attacker sees. If you can pull an API key out of your compiled app in five minutes, so can anyone. This is one of the most practical uses for everyday developers.

6. Data recovery and migration

Old software often stores data in custom file formats. When you migrate to a new system, you may need to work out the format to extract years of customer records.

7. Learning

Reading compiled code teaches you how compilers, operating systems, and CPUs actually work. Many engineers become much better debuggers after learning some reverse engineering.

Types of Reverse Engineering

Reverse engineering isn't one activity. The target decides the techniques.

Software (binary) reverse engineering

Analyzing compiled programs: Windows .exe and .dll files, Linux ELF binaries, macOS apps, firmware. This is what most people mean by "reverse engineering." It involves disassemblers, decompilers, and debuggers, and some knowledge of assembly language.

Mobile app reverse engineering

Android apps (APK files) contain DEX bytecode, resources, and a manifest. Tools like apktool and jadx can unpack and decompile them into readable Java-like code. iOS apps are compiled to native machine code and are usually encrypted on the device, which makes them harder to analyze, but they can still be studied with native-code tools. Mobile developers should understand this well, because it's exactly how attackers look for leaked keys and hidden endpoints.

Protocol and network reverse engineering

Working out how two programs talk to each other by capturing and studying their network traffic: message formats, the order of messages, and what each field means. Samba's work on Microsoft's SMB protocol is the best-known example.

File format reverse engineering

Figuring out how a program stores data in files: headers, field layouts, compression, and encoding. This matters for data recovery, migration, and building compatible tools.

Web and API reverse engineering

Studying how a web or mobile app talks to its backend: which endpoints exist, what parameters they take, and how authentication works. Developers do this to integrate with services that lack documentation (where the terms of service allow it), and security testers do it to find exposed or poorly protected APIs.

Hardware reverse engineering

Taking apart physical devices: identifying chips, reading circuit boards, extracting firmware. Hardware "teardowns" of phones and laptops are a well-known public example.

Legacy system and design recovery

Rebuilding the architecture and business rules of an old system from its code, database, logs, and behavior, so it can be maintained or replaced.

Data and database reverse engineering

Inferring the structure and meaning of a database with poor or missing documentation: tables, relationships, hidden constraints, and the meaning of cryptic columns like flg_3.

How Reverse Engineering Works: The Process Step by Step

Experienced reverse engineers rarely start by reading every line of code. They follow a goal-driven process.

 ① Define the goal ........... "What exactly do I need to know?"
        │
        ▼
 ② Gather information ........ file type, platform, compiler, docs, strings, public info
        │
        ▼
 ③ Static analysis ........... disassemble/decompile, map structure, find interesting functions
        │
        ▼
 ④ Dynamic analysis .......... run it safely, debug, trace calls, watch files and network
        │
        ▼
 ⑤ Form a hypothesis ......... "This function encrypts the config with key X"
        │
        ▼
 ⑥ Test the hypothesis ....... change an input, predict the output, check
        │            ▲
        └── wrong? ──┘   (loop until the model is right)
        ▼
 ⑦ Document .................. diagrams, specs, notes, rules, test cases

Step 1: Define the goal

Reverse engineering a large program completely can take months. A clear question makes it take hours. "Does this app send location data to third parties?" is a good goal. "Understand this app" is not. Good goals also keep you inside legal and ethical limits, because you know exactly what you're looking for and why.

Step 2: Gather information

Before opening any heavy tool, collect the easy facts:

• What kind of file is it? The first few bytes of a file, called its magic number or file signature, usually tell you. Java class files start with CA FE BA BE, PNG images with 89 50 4E 47, ZIP files (including APKs and JARs) with 50 4B, Windows executables with 4D 5A ("MZ"), and Linux ELF binaries with 7F 45 4C 46.
• Which platform and compiler? Windows or Linux, 32 or 64 bit, Java, .NET, C++, Go, Rust. Each needs different tools.
• Readable strings: error messages, URLs, file paths, and log messages often reveal what a program does.
• Public information: documentation, earlier versions, open-source components inside it, and published research.

Step 3: Static analysis

Study the program without running it: disassemble or decompile it, map its functions, look at what libraries it imports, and find the interesting parts (for example, the code that builds network requests). This is covered in detail below.

Step 4: Dynamic analysis

Run the program in a safe, isolated environment and watch what it actually does: set breakpoints in a debugger, record which files it opens, capture its network traffic. Static analysis tells you what the code could do; dynamic analysis shows what it does.

Steps 5 and 6: Form a hypothesis, then test it

Reverse engineering is a scientific loop. You guess ("this byte is a message type"), predict ("if I send a login message, this byte should be 0x01"), and check. When the prediction fails, you revise. Each confirmed guess becomes solid knowledge.

Step 7: Document

Write down what you learned: diagrams, data formats, function names you assigned, and test cases. Undocumented reverse engineering is easily lost, and if the work ever needs to be defended legally, good records matter a lot.

Interview answer, as a checklist:

• Start with a specific goal.
• Identify the file type, platform, and compiler, and grab readable strings.
• Use static analysis to map structure, then dynamic analysis to watch real behavior.
• Hypothesize and test in a loop.
• Document everything.

From Source Code to Binary: Why Reverse Engineering Is Hard

To understand reverse engineering, you need to understand what's lost when code is compiled.

When you compile a C program, the compiler turns your readable code into machine code. Along the way it throws away a lot:

• Variable and function names usually disappear (unless debug symbols are kept). calculateTax(price) becomes code at some address like 0x401a30.
• Comments are gone completely.
• Types and structures mostly disappear. A struct Order becomes "8 bytes at offset 16."
• Code structure changes. Optimizations inline functions, reorder instructions, unroll loops, and remove code that never runs.

That's why turning a native binary back into source code is never perfect. A decompiler produces plausible code that does the same thing, but with made-up names and sometimes confusing structure. The reverse engineer's job is to rebuild the missing meaning.

Native code vs bytecode: a big difference

Not all compiled code is equally hard to read.

This is why Android apps written in Java or Kotlin are so easy to inspect: their bytecode keeps class names, method names, and string constants, so a decompiler can produce surprisingly readable code. Tools like R8 (Android's default code shrinker and obfuscator) rename classes and methods to short meaningless names, which helps, but string values and app logic are still there to be found.

Static Analysis: Studying a Program Without Running It

Static analysis means examining a program's file and code without executing it. It's safe (malware can't do anything if it isn't running) and gives you the full picture of what the code contains, including paths that rarely run.

Main static analysis techniques

Seeing it for real: what a compiled file reveals

The program below writes a small Java class with a mistake that's common in real apps: a secret key hard-coded in client code. It compiles the class, deletes the source code, and then inspects the compiled file using only the two simplest static techniques: checking the file signature and extracting readable strings.

import javax.tools.ToolProvider;
import java.nio.charset.StandardCharsets;
import java.nio.file.*;
import java.util.*;

// Compile a small "app" class, then look inside the compiled file without its source code,
// the way a reverse engineer would: check the file signature, then pull out readable strings.
public class PeekInside {
    public static void main(String[] args) throws Exception {
        Path dir = Files.createTempDirectory("re-demo");
        Path src = dir.resolve("PaymentClient.java");
        Files.writeString(src, """
            public class PaymentClient {
                private static final String API_KEY = "demo-secret-NOT-A-REAL-KEY-42";   // a mistake: secret in client code
                private static final String BASE_URL = "https://api.example-payments.com/v1/charges";
                public String charge(int amountPaise) {
                    return BASE_URL + "?amount=" + amountPaise + "&key=" + API_KEY;
                }
            }
            """);
        int rc = ToolProvider.getSystemJavaCompiler().run(null, null, null, "-d", dir.toString(), src.toString());
        if (rc != 0) throw new IllegalStateException("compile failed");
        Files.delete(src);                                   // throw away the source: only the binary is left

        byte[] bin = Files.readAllBytes(dir.resolve("PaymentClient.class"));

        // Step 1: identify the file from its first bytes ("magic number")
        int magic = ((bin[0] & 0xFF) << 24) | ((bin[1] & 0xFF) << 16) | ((bin[2] & 0xFF) << 8) | (bin[3] & 0xFF);
        int major = ((bin[6] & 0xFF) << 8) | (bin[7] & 0xFF);
        System.out.printf("size: %d bytes, magic: %08X, class file major version: %d%n", bin.length, magic, major);

        // Step 2: list runs of printable characters, like the Unix `strings` tool
        System.out.println("readable strings (8+ chars):");
        StringBuilder run = new StringBuilder();
        for (byte b : bin) {
            if (b >= 32 && b < 127) { run.append((char) b); continue; }
            if (run.length() >= 8) System.out.println("  " + run);
            run.setLength(0);
        }
        if (run.length() >= 8) System.out.println("  " + run);
    }
}

Run it with java PeekInside.java on JDK 21. Output:

size: 943 bytes, magic: CAFEBABE, class file major version: 65
readable strings (8+ chars):
  java/lang/Object
  makeConcatWithConstants
  (I)Ljava/lang/String;
  PaymentClient
  Ljava/lang/String;
  ConstantValue
  demo-secret-NOT-A-REAL-KEY-42
  BASE_URL
  +https://api.example-payments.com/v1/charges
  LineNumberTable
  SourceFile
  PaymentClient.java
  BootstrapMethods
  Vhttps://api.example-payments.com/v1/charges?amount=
  &key=demo-secret-NOT-A-REAL-KEY-42
  $java/lang/invoke/StringConcatFactory
  (Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;Ljava/lang/String;[Ljava/lang/Object;)Ljava/lang/invoke/CallSite;
  InnerClasses
  %java/lang/invoke/MethodHandles$Lookup
  java/lang/invoke/MethodHandles

What this shows:

• The magic number CAFEBABE identifies a Java class file, and major version 65 means it was compiled for Java 21. Two bytes told us the platform and the compiler version.
• The secret key appears in plain text, twice. Once as the constant itself, and once inside the string template the compiler built for the charge method. No decompiler, no debugger, just a byte scan.
• The API endpoint, the class name, and even the original source file name (PaymentClient.java) are all visible.
• The odd first characters on some lines (+, V, $, %) aren't part of the strings. In a class file, each text constant is stored with a two-byte length in front of it. The first length byte is usually 0x00, which breaks the run of printable characters, but when the second length byte happens to be printable, the scan picks it up. For example, the URL is 43 bytes long, and 43 is 0x2B, which is the + character. Little details like this are exactly what reverse engineers learn to recognize.

Obfuscation tools would rename PaymentClient and charge, but they wouldn't hide the key's value. Encrypting the string in the app only moves the problem, because the app must contain the code and key to decrypt it. The only real fix is not to ship the secret at all (more on this in the defense section).

Try it on your own Android app: decompile your APK in five minutes

The same check works on a real Android app, and doing it on your own app is one of the most useful security habits a mobile developer can build. With jadx installed:

# 1. Decompile your release build into readable Java-like code and decoded resources
jadx -d decompiled/ app-release.apk

# 2. Search the output for things that should never be in a client
grep -rniE "api[_-]?key|secret|token|password|https?://" decompiled/ | less

Look through the results for API keys, tokens, internal or staging URLs, and feature flags that unlock paid features. Anything you find, an attacker can find too.

A very common misconception: moving a key into local.properties or a Gradle property and injecting it with a BuildConfig field or resValue hides it from Git, not from users. BuildConfig fields are compiled into the app as constants, and resValue entries end up in the app's resources. Both show up in the decompiled output above. Keeping keys out of source control is good practice, but it isn't client-side protection.

Look after R8's mapping.txt. When R8 obfuscates a release build, it writes a mapping file (by default under build/outputs/mapping/release/) that records how every class and method was renamed. You need it to turn obfuscated crash stack traces back into real names, so keep it with each release (Google Play Console lets you upload it for deobfuscated crash reports). But never ship it inside the app or publish it: anyone who has it can undo the renaming completely.

Automate it. Add a secret scanner such as gitleaks or trufflehog to CI so keys are caught before they reach a commit, and consider a release-time step that scans the built APK the same way.

Dynamic Analysis: Watching a Program Run

Dynamic analysis means running a program and observing what it actually does. It answers questions that static analysis struggles with: which code paths really run, what values variables hold at a given moment, what gets decrypted in memory, and what the program sends over the network.

Main dynamic analysis techniques

Static vs dynamic analysis

In practice, reverse engineers switch between both constantly: static analysis to find an interesting function, dynamic analysis to see what it does with real data, back to static analysis to understand the rest.

If the interviewer asks "static or dynamic, which is better?": Neither. Static analysis is safe and complete but can be misled by obfuscation and packed code. Dynamic analysis shows real behavior and real values but only covers the paths you actually trigger, and malware may detect the analysis environment and behave differently. Good analysis combines both.

Reverse Engineering Protocols and File Formats

Many reverse engineering jobs don't involve reading code at all. You study the data a program sends or saves.

The basic method

1. Capture samples. Record many messages or files, ideally from your own controlled use of the software.
2. Look for structure. Fixed headers at the start, length fields before variable-size data, repeated patterns, readable text, timestamps.
3. Change one thing at a time. Do one action differently and compare the captures. If the only thing you changed was the username, the bytes that changed are probably the username field.
4. Name the fields and write a parser. Then test the parser against new samples. If it handles them all, your understanding is probably right.

Andrew Tridgell, Samba's creator, has described working this way on Microsoft's SMB protocol: perform an operation on a real Windows network, watch the traffic, change one detail, and compare, building understanding from observation rather than from Microsoft's code.

Seeing it for real: decoding a message without its schema

Suppose you captured this message from your own app's network traffic, but the original schema file is lost:

08 ce 86 f2 c6 24 12 07 75 5f 34 38 32 31 33 18 8c 93 09 20 01 2a 0b 53 48 4f 45 2d 52 45 44 2d 34 32 2a 0a 53 4f 43 4b 2d 42 4c 4b 2d 4d

Some readable text is visible (75 5f 34 38... is u_48...), and the pattern of small numbers before each text block suggests length fields. A developer who recognizes this as Protocol Buffers can use its public wire format rules: each field starts with a key containing a field number and a type, numbers are stored as variable-length integers, and text is stored as a length followed by bytes. That's enough to recover the structure:

import java.nio.charset.StandardCharsets;
import java.util.HexFormat;

// Protocol reverse engineering in miniature: we captured these bytes from our own app's traffic,
// but we don't have the schema. Protobuf's wire format is public, so we can still recover the structure.
public class DecodeUnknown {
    static int pos = 0;

    static long readVarint(byte[] b) {
        long result = 0;
        int shift = 0;
        while (true) {
            int x = b[pos++] & 0xFF;
            result |= (long) (x & 0x7F) << shift;   // low 7 bits are data
            if ((x & 0x80) == 0) return result;      // high bit clear = last byte
            shift += 7;
        }
    }

    public static void main(String[] args) {
        byte[] msg = HexFormat.ofDelimiter(" ").parseHex(
            "08 ce 86 f2 c6 24 12 07 75 5f 34 38 32 31 33 18 8c 93 09 20 01 2a 0b 53 48 4f 45 2d 52 45 44 2d 34 32 2a 0a 53 4f 43 4b 2d 42 4c 4b 2d 4d");

        while (pos < msg.length) {
            long key = readVarint(msg);
            int field = (int) (key >>> 3), wireType = (int) (key & 7);
            switch (wireType) {
                case 0 -> System.out.printf("field %d  varint  %d%n", field, readVarint(msg));
                case 2 -> {
                    int len = (int) readVarint(msg);
                    String text = new String(msg, pos, len, StandardCharsets.UTF_8);
                    pos += len;
                    System.out.printf("field %d  bytes   len=%-2d \"%s\"%n", field, len, text);
                }
                default -> throw new IllegalStateException("wire type " + wireType + " not handled in this demo");
            }
        }
    }
}

Output:

field 1  varint  9812345678
field 2  bytes   len=7  "u_48213"
field 3  varint  149900
field 4  varint  1
field 5  bytes   len=11 "SHOE-RED-42"
field 5  bytes   len=10 "SOCK-BLK-M"

Without any schema, we now know the message has five fields: a large number (likely an order ID), a user ID, an amount (149900, which looks like ₹1,499.00 in paise), a small number (likely a status code), and a repeated text field (product SKUs). The last step of real protocol work is exactly this kind of guessing and testing: place an order for a different amount, capture again, and confirm field 3 changes.

The lesson goes beyond Protobuf. Binary formats feel secret, but they aren't. Without encryption, anyone who can capture your traffic can work out its structure. Confidentiality comes from TLS and access control, never from an unusual format.

Reverse Engineering Legacy Systems

This is the kind of reverse engineering most backend developers actually do, often without calling it that.

The situation: a 15-year-old billing system calculates late fees. The developers who built it left long ago. The documentation says one thing, the code does something else, and nobody is sure which one customers rely on. You've been asked to migrate it to a new service.

How to reverse engineer a legacy system

 Legacy billing system (black box)
        │
        ├── database schema + real data ──► business rules, hidden states
        ├── logs and traces ──────────────► actual request flows
        ├── code entry points ────────────► what can be triggered, and how
        ├── characterization tests ───────► locked-in current behavior
        └── interviews with users ─────────► unwritten rules and exceptions
                         │
                         ▼
            Documented design ──► safe migration or rewrite

Interview answer: "To understand an undocumented legacy system, I'd map its components and dependencies, read the database schema and real data, trace real transactions end to end, start reading code from entry points, write characterization tests that lock in current behavior, and talk to the people who use it. Then I document the design before changing anything."

Reverse Engineering Tools

You don't need all of them. A beginner can go a long way with file, strings, a hex editor, Ghidra, and Wireshark.

Real-World Examples

WannaCry (2017): reverse engineering stops an outbreak

On May 12, 2017, WannaCry ransomware spread rapidly by exploiting a Windows file-sharing vulnerability, encrypting files and demanding payment in Bitcoin. It disrupted parts of the UK's National Health Service and organizations in many countries. While analyzing a sample, researcher Marcus Hutchins noticed that the malware tried to reach an unregistered domain, and he registered it, at first to track infections. It then became clear that the malware checked for this domain before spreading further and stopped if the domain responded. With the domain live, the spread of that version was halted.

Why it matters: the registration started as a monitoring step, but understanding why it worked, and confirming it was a reliable kill switch rather than luck, came from analyzing the binary. Fast, focused reverse engineering turns observations into defensive actions within hours, which is why security teams invest in the skill.

Stuxnet (2010): reverse engineering a cyberweapon

Stuxnet was discovered in 2010. Over months of reverse engineering, researchers, including teams at Symantec (which published a detailed technical dossier) and industrial control specialists, worked out that it targeted specific industrial control systems and could manipulate physical equipment while hiding that from operators. It was an unusually complex piece of malware, and much of what the public knows about it comes from patient reverse engineering by independent researchers.

Why it matters: reverse engineering isn't only for quick wins. Some analyses take months and require knowledge of very different domains, from Windows internals to industrial hardware.

Samba: interoperability through protocol analysis

Samba, started by Andrew Tridgell in the early 1990s, reverse engineered Microsoft's SMB file and print sharing protocol so non-Windows systems could interoperate with Windows networks. Tridgell received the Free Software Foundation's 2005 Award for the Advancement of Free Software (presented in January 2006), with the FSF citing Samba's reverse engineering of SMB and its use on millions of servers.

Why it matters: it's the textbook example of reverse engineering for interoperability, one of its most widely accepted legitimate uses.

BitKeeper and the birth of Git (2005)

For several years, Linux kernel developers used BitKeeper, a proprietary version control system, under a free-of-charge license. In 2005, Tridgell worked on a free tool that could interoperate with BitKeeper. BitKeeper's owner, Larry McVoy, said this was done by reverse engineering its protocols (Tridgell said the BitKeeper server itself offered protocol help to anyone who asked), and the free license for Linux development was withdrawn. Linus Torvalds then started writing his own version control system in April 2005. That system was Git.

Why it matters: it shows that reverse engineering can be controversial even when the goal is interoperability, and that license terms matter. It also changed software history.

Clean room BIOS clones (1980s)

In the early 1980s, IBM PC compatibility depended on the PC's BIOS (the low-level startup software), which IBM owned. Companies including Compaq and Phoenix Technologies built compatible BIOS software using clean room design: one team studied the original and wrote a functional specification of what it did, and a separate team that had never seen IBM's code wrote new code from that specification alone. This helped create the market for IBM-compatible PCs.

Why it matters: clean room design is the standard way to use reverse engineering for compatibility while reducing the risk of copying protected code.

Hard-coded cloud credentials in mobile apps (2022)

In 2022, Symantec's Threat Hunter team reported finding 1,859 publicly available Android and iOS apps containing hard-coded Amazon Web Services credentials. According to the report, over three-quarters of those apps contained valid AWS access tokens, and some tokens gave broad access to private cloud data. In one case, five banking apps used the same third-party SDK containing cloud credentials, putting more than 300,000 users' biometric fingerprint records at risk. Many of the credentials came from shared libraries and SDKs, making it a supply chain problem.

Why it matters: this is reverse engineering from the defender's side. If researchers can extract keys from apps at scale, so can attackers. It's the real-world version of the PeekInside demo above.

Is Reverse Engineering Legal?

Short answer: reverse engineering is legal for many purposes in many countries, but it's restricted by copyright law, anti-circumvention laws, contracts and licenses, and trade secret law. The details depend on the country, the purpose, and how you obtained the product. This section is general information, not legal advice.

The main legal questions

1. Copyright. Software is protected by copyright. Disassembling or decompiling it involves making copies, which raises copyright questions. Courts in the United States have accepted some reverse engineering as fair use. In Sega v. Accolade (1992), a US appeals court held that disassembling Sega's software to learn how to make compatible games was fair use, because it was the only way to access the functional elements needed for compatibility. In Sony v. Connectix (2000), another appeals court reached a similar conclusion for reverse engineering done to build a PlayStation emulator. The key idea: studying functional, unprotected parts to achieve compatibility can be allowed; copying protected expression into your product is not.

2. Anti-circumvention laws. In the US, Section 1201 of the Digital Millennium Copyright Act (DMCA) generally prohibits bypassing technical protection measures (like encryption or DRM) that control access to copyrighted works, even if you aren't infringing copyright otherwise. There are exceptions, including one for interoperability in Section 1201(f), and the US Copyright Office grants additional exemptions through a rulemaking every three years, which have included good-faith security research. Other countries have similar laws with their own exceptions.

3. The European Union. The EU's Software Directive (2009/24/EC), in Article 6, allows decompilation without the owner's permission when it's necessary to achieve interoperability of an independently created program, under conditions: you must have a legal right to use the program, the information must not already be readily available, and you may only decompile the parts needed for interoperability. Article 5 also allows a lawful user to observe, study, or test how a program works to understand its underlying ideas.

4. Contracts and licenses. Many end-user license agreements (EULAs) and terms of service forbid reverse engineering. Whether those terms are enforceable varies by country (EU law, for example, prevents contracts from overriding the Article 6 decompilation right), but breaking them can still lead to account bans or legal claims.

5. Trade secrets. In the US, the Defend Trade Secrets Act of 2016 explicitly says that reverse engineering is not an "improper means" of acquiring a trade secret. So discovering how a lawfully obtained product works is generally not trade secret theft, though a contract you signed might still restrict it.

Clean room design: reducing legal risk

When companies reverse engineer for compatibility, they often use clean room design:

  Team A ("dirty room")                     Team B ("clean room")
  studies the original product   ──────►    has never seen the original code
  writes a functional spec:      spec only  writes new code from the spec alone
  "given X, it returns Y"                   
            │                                          │
            └──────── a reviewer checks that no protected code or expression ──┘
                      crosses from A to B; everything is documented

The goal is to prove that the new product was written independently, using only facts about what the original does, not its protected code.

Ethical guidelines

• Have a legitimate purpose you could explain openly: security research, interoperability, maintenance, education, or analysis of your own systems.
• Respect the law and contracts where you are. When unsure, ask a lawyer before starting.
• Don't use findings to harm users, steal content, or bypass payment.
• Report vulnerabilities responsibly to the vendor and give them time to fix the issue before publishing details. Many companies run bug bounty programs that explicitly permit testing within defined rules.
• Handle malware carefully, in isolated environments, so you don't spread it by accident.

How to Protect Your Software from Reverse Engineering

Here's the uncomfortable truth every developer should accept: you cannot stop a determined reverse engineer from analyzing software that runs on their own device. They control the hardware, the operating system, and the debugger. What you can do is raise the cost of reverse engineering and, more importantly, design your system so that reverse engineering doesn't give attackers anything valuable.

This idea connects to Kerckhoffs's principle, from 19th-century cryptography: a system should stay secure even if everything about it, except the key, is public. Security that depends on attackers not understanding your code is fragile.

1. Never ship secrets to the client (the most important rule)

Anything inside your app (API keys, signing keys, database passwords, admin URLs) can be extracted, as the PeekInside demo and the Symantec research showed. Instead:

• Keep secrets on your server. The app calls your backend, and your backend calls the third-party service with its secret key.
• Issue short-lived, limited tokens to the app after the user logs in, scoped to only what that user may do.
• If a key must be in the app (some SDKs require it), make sure it's a public, restricted key: limited to specific APIs, specific app signatures or domains, and with usage quotas.
• Scan your builds for secrets before release, and rotate any key that has ever shipped in a client.

2. Enforce everything important on the server

Prices, discounts, permissions, game scores, feature flags for paid features: if the app decides, an attacker can change the decision. The server must validate every request as if the client were hostile, because sometimes it is.

3. Obfuscate to raise the cost

• Android: enable R8 for release builds to shrink code and rename classes and methods. It removes meaningful names, which slows analysis down considerably.
• Other platforms: commercial obfuscators can rename symbols, flatten control flow, and encrypt strings.
• Remember the limits: obfuscation slows people down; it doesn't stop them. String encryption doesn't hide a key, because the decryption code ships too.

4. Detect tampering and untrusted environments

• App integrity checks: on Android, the Play Integrity API lets your server check whether requests come from your genuine app on a genuine device. Apple offers App Attest for iOS.
• Root and jailbreak detection, anti-debugging checks: useful for raising the bar in high-risk apps like banking, but all of them can eventually be bypassed by someone who controls the device. Treat them as signals your server considers, not as walls.
• Certificate pinning: makes intercepting your app's HTTPS traffic harder on normal devices. It's a reasonable layer, but on a device the attacker fully controls, pinning can be disabled, and it adds operational risk (you must plan for certificate rotation).

5. Move sensitive logic to native code or the server (with realistic expectations)

Native code (C/C++ via the Android NDK, for example) is harder to reverse than bytecode, but far from impossible. The server is the only place an attacker can't inspect.

6. Monitor for abuse

Assume your API will be reverse engineered. Monitor for unusual clients, request patterns that don't match your app, and spikes in sensitive operations. Rate limiting and anomaly detection at your API gateway catch what client-side protections miss.

Interview answer: "You can't prevent reverse engineering of code that runs on a user's device; you can only raise the cost. So the real defense is architectural: no secrets in the client, all important decisions validated on the server, short-lived scoped tokens, plus obfuscation, integrity checks, and API monitoring as extra layers."

Reverse Engineering in System Design Interviews

Some system design interviews include a version of reverse engineering: "How do you think WhatsApp, Uber, or Google Docs works?" You're asked to infer an architecture from what you can observe as a user. This is a different skill from binary analysis, but the thinking pattern is the same: observe, hypothesize, test against evidence.

A method for "how does this product work?" questions

1. List observable behaviors. What does the product do that hints at its design?

• Messages show "sent" and "delivered" states, and arrive instantly on another phone. → a persistent connection or push channel, plus acknowledgements.
• A ride app shows the driver's car moving smoothly. → frequent location updates from the driver, streamed to the rider.
• Two people edit the same document and see each other's cursors. → real-time synchronization with some conflict resolution method.

2. Turn behaviors into components. Each behavior suggests building blocks: a connection service for persistent connections, a message store, a queue for offline delivery, a location service keyed by region, and so on.

3. Estimate scale from public information. Use publicly reported numbers where they exist, and clearly label your own assumptions where they don't.

4. Check your design against constraints. Mobile networks drop connections, phones go offline, users switch devices. Does your design explain how the product behaves in those cases?

For the building blocks themselves, such as persistent connections, acknowledgements, and push updates, see Communication Protocols in System Design and API Gateway in System Design.

5. Be honest about what's known vs guessed. Say "I believe" or "a common way to build this is" rather than claiming to know a company's internal design. Interviewers respect that distinction, and it's also simply accurate.

Interview tip: the interviewer is testing your reasoning, not your knowledge of a company's private architecture. "The double tick suggests a delivery acknowledgement from the recipient's device, so I'd design an ack flow back through the server" is a strong answer. "WhatsApp uses exactly X" is a weak one unless you can cite a public source.

How to Learn Reverse Engineering Safely

A practical learning path, using only legal targets:

1. Learn the foundations. How programs are compiled and loaded, how memory and the stack work, basic assembly for one architecture (x86-64 or ARM64), and common file formats.
2. Reverse engineer your own code. Write small C or Java programs, compile them, and examine the output in Ghidra or a decompiler. Compare what you see with the source you wrote. This is the fastest way to learn what compilers do.
3. Inspect your own apps. Decompile your own Android APK with jadx and look for exposed strings and endpoints. Capture your own app's traffic.
4. Use practice challenges made for this. "Crackme" exercises are small programs written specifically to be reverse engineered for practice. Capture the Flag (CTF) competitions include reverse engineering categories.
5. Study published analyses. Malware analysis reports from security companies, and write-ups of old CTF challenges, show how experts think.
6. Practice malware analysis only in isolated labs. Use virtual machines with no network access to your real systems, and take snapshots.
7. Learn the legal rules where you live before working on software you don't own.

Common Mistakes

Reverse Engineering Interview Questions (with Answers)

FAQ

Key Takeaways