What is reverse engineering?

Reverse engineering in plain English

Imagine a chef who tastes a dish and wants to recreate it. There’s no recipe. But from the taste, texture, and appearance, the chef can work out what’s in it. That’s exactly how reverse engineering works: you start with the finished result and work your way back to the blueprint.

In IT security, that finished result is usually a program, an app, or the firmware of a device – the software permanently built into a router or an industrial controller, for example. Communication protocols, the rules devices follow when they exchange data, are examined this way, too. The source code – the human-readable version of a program – isn’t available. All that exists is the compiled version, such as machine code: a long sequence of instructions that the processor understands but a human can barely read.

Reverse engineering makes this code understandable again. That way, you can check what a piece of software actually does – not just what the manufacturer promises.

How reverse engineering works

Experts usually combine several steps:

1. Obtain and unpack: First, the software is obtained – as a program file, as an app package, or, in the case of devices, by extracting it from the memory chip. If it’s packed or compressed, it’s unpacked first.
2. Disassemble: A disassembler translates the machine code into assembly language – a low-level representation of the individual processor instructions that experts can read.
3. Decompile: A decompiler then reconstructs code that resembles an ordinary programming language. Original names and comments are often missing, but the logic becomes much easier to follow.
4. Analyze dynamically: The program runs in an isolated test environment while the experts observe it – which files it opens, which servers it talks to, and what it stores in memory.
5. Assess: Based on their findings, the experts determine where vulnerabilities lie and how dangerous they are.

Typical findings include hard-coded passwords, hidden maintenance access, weak or incorrectly implemented encryption, and flaws in custom-built protocols.

A practical example

Here’s a typical scenario: A mid-sized manufacturer of building automation equipment buys a wireless module from a supplier for its new central control unit. It doesn’t receive the module’s source code, so before market launch, it has the firmware examined using reverse engineering.

The result comes as a surprise: the module has an active maintenance login whose password is hard-coded and identical on every device. Anyone who extracts it from a single device could later take over every control unit the company sells. The supplier removes the login before the first device reaches a customer.

Why does this matter for businesses?

Attackers use reverse engineering, too. They take apart apps, devices, and updates to find vulnerabilities. Some compare a security update with the previous version to understand the vulnerability it closes – and then exploit it on systems that haven’t been updated yet. If you have your products tested first, you stay one step ahead of them.

Manufacturers of connected products face an additional obligation: the Cyber Resilience Act will require them to exercise due diligence for purchased components as well. If no source code is available, reverse engineering is often the only way to understand exactly what such a component actually does. The method is also central to malware analysis: experts dissect a piece of malware to understand what it can do and how to recognize it.

In Germany, reverse engineering is not prohibited per se. The German Trade Secrets Act (GeschGehG) expressly allows knowledge to be acquired by observing, studying, disassembling, or testing a product that has been made publicly available. For software, however, copyright law sets tighter limits, and license agreements may also come into play. If in doubt, it’s advisable to get a legal review beforehand.

How to protect your organization

• No secrets in the code: Passwords and keys should never be hard-coded in software or firmware – whatever is in the code can be extracted sooner or later.
• Individual credentials: Give every device its own credentials instead of a shared default password.
• Signed updates: Devices should only accept updates that the manufacturer has digitally signed – that is, provided with a tamper-proof electronic seal.
• Test purchased components: Have modules and software from suppliers examined before you build them into your own products.
• Don’t overestimate obfuscation: Techniques that make code hard to read increase the effort for attackers, but they’re no substitute for real security.
• Close test access: Troubleshooting ports on circuit boards, known as debug interfaces, should be disabled in the finished product.

How Rootsektor can help

With our Code Review & Reverse Engineering service, we analyze software, mobile apps, firmware, and proprietary protocols – even without source code. We work independently of vendors, clarify the legal framework with you before the project starts, and provide concrete remediation recommendations. After scoping, you’ll receive a fixed-price quote; you can describe your project via our Pentest Quote page.