Reverse Engineering Firmware: Is Your Code Safe from Hackers?

Author: Srihari Maddula • Technical Lead, EurthTech

Reading Time: 25 mins

Topic: Embedded AI

Bridging the gap between academic projects and industry reality.

1. The Hook: The Illusion of Compiled Safety

There is a dangerous myth that persists in the embedded systems industry: “Once the C code is compiled into a binary and flashed onto the microcontroller, our intellectual property is safe.”

Nothing could be further from the truth.

Every day, competitors, security researchers, and malicious actors are ripping firmware straight off PCBs. They aren't deterred by missing source code. They are armed with logic analyzers, oscilloscopes, and decompilers capable of translating stripped machine code back into highly readable pseudo-C. In the world of hardware, physical access is root access. If your device leaves your facility without a robust, multi-layered security architecture, your proprietary algorithms, cryptographic keys, and device control flows are an open book.

In this deep dive, we will tear back the veil on hardware hacking. We’ll walk through the exact methodologies reverse engineers use to extract and analyze firmware, the advanced physical attacks used to bypass security boundaries, and ultimately, the professional defense layers you must implement to protect your hardware ecosystem.

2. The Extraction: Pulling the Ghost from the Machine

Before an attacker can reverse engineer your code, they have to get it. Firmware extraction is the process of pulling the binary payload off the physical device.

A technician soldering components onto a motherboard

SWD and JTAG: The Front Door

Joint Test Action Group (JTAG) and Serial Wire Debug (SWD) are standard debugging interfaces. Developers use them to step through code, set breakpoints, and read memory. Unfortunately, so do attackers. If these ports are left active in production, an attacker can simply plug in a Segger J-Link or an open-source tool like OpenOCD and dump the entire flash memory in seconds.

SENIOR SECRET

Dynamic Pin Multiplexing (Silencing Debug Ports): Don't just rely on eFuses to disable JTAG, as glitches can sometimes bypass eFuse checks. Instead, multiplex your SWD/JTAG pins to perform critical, high-frequency IO functions immediately upon boot. If an attacker tries to hold the pins for debugging, the device functionally bricks itself because the expected IO signals fail.

Flash Dumping: The Desoldering Approach

If debug ports are locked down, the next step is attacking the memory directly. For systems using external SPI or I2C flash chips, attackers will simply use a hot air rework station to desolder the EEPROM/Flash chip, drop it into a standard EEPROM reader (like a CH341A), and read the raw `.bin` file.

SPI Sniffing (In-Transit Interception)

If the flash chip is a BGA (Ball Grid Array) and too risky to desolder, attackers use logic analyzers (like a Saleae) attached to the trace lines between the MCU and the flash chip. By triggering a device reboot, they capture the firmware as it is loaded from the external flash into the MCU's RAM over the SPI bus.

---

3. The Hacker’s Toolkit: Decompiling the Binary

Once the binary is extracted, the real work begins. The file is a seemingly meaningless blob of hex data. To make sense of it, reverse engineers turn to a specific set of powerful disassemblers and decompilers.

• Ghidra: Created by the NSA and released as open-source, Ghidra has revolutionized firmware reverse engineering. Its standout feature is its highly capable auto-decompiler, which takes raw ARM, MIPS, or x86 assembly and turns it back into readable C-like pseudocode. It is the undisputed king of free RE tools.

• IDA Pro: The historical industry standard. IDA Pro is incredibly expensive but offers unparalleled processor module support and a massive ecosystem of plugins. For deeply obscure microcontrollers, IDA is often the only tool that works flawlessly.

• Binary Ninja: A modern, rapidly growing alternative known for its blazing-fast UI and its powerful intermediate languages (IL). It excels at lifting assembly into higher-level logical structures for automated vulnerability analysis.

• Radare2 / Cutter: A highly flexible, command-line driven, open-source framework. While the learning curve is steep, its scriptability makes it a favorite for CI/CD pipeline integration and automated binary patching.

SENIOR SECRET

The Honey-Trap Function: When reverse engineers analyze a binary, they look for strings and recognizable initialization functions (like `printf` or `UART_Init`). Create highly complex, mathematically intense dummy functions that appear to be crypto routines, heavily referencing strings like `AES_KEY_GEN_START`. Attackers will waste weeks reversing this "honey-trap" code while your actual logic executes in obfuscated, inline assembly elsewhere.

4. Advanced Physical Attacks: Breaking the Unbreakable

What happens when you do implement basic security? What if you encrypt the flash and lock the debug ports? This is where attackers turn to physics.

An oscilloscope screen showing green waveforms

Side-Channel Attacks: Power Analysis

Every time a CPU executes an instruction—especially cryptographic operations—it consumes a minuscule amount of power. By attaching highly sensitive probes to the MCU's power rails and monitoring the power consumption with an oscilloscope, attackers can perform Simple Power Analysis (SPA) or Differential Power Analysis (DPA).

Because a bitwise `1` draws slightly different power than a `0` during an AES encryption round, statistical analysis of thousands of power traces can actually extract the secret encryption keys straight out of the silicon, bypassing all software protections.

Fault Injection: Voltage Glitching

Voltage glitching is a form of fault injection where the attacker momentarily drops the voltage to the CPU precisely when it is executing a critical instruction (e.g., `if (firmware_signature_valid == TRUE)`).

The goal isn't to power off the chip, but to starve the CPU of just enough power that the transistor logic fails for a single clock cycle. This can cause the CPU to skip the security check entirely, effectively granting an attacker bypass capabilities over Secure Boot mechanisms.

SENIOR SECRET

Active PCB Shielding: To prevent physical tampering and trace sniffing, route a continuous, tightly woven mesh of traces containing a high-frequency heartbeat signal through the outer layers of the PCB and directly under BGA chips. If an attacker tries to drill or cut the PCB to access internal traces, they break the mesh, the heartbeat stops, and the MCU instantly zeroes out its secure keystore.

5. The Professional Defense Layer

Defending against a determined attacker requires a "defense-in-depth" methodology. No single protection is sufficient.

Hardware Root of Trust (RoT) & Secure Boot

A true defense starts in silicon. A Hardware Root of Trust utilizes an immutable ROM embedded in the chip to verify the digital signature of the first stage bootloader before execution. This chain of trust extends to the OS and the application layer. If an attacker modifies the firmware in external flash, the signature check fails, and the device refuses to boot.

TrustZone and Physical Limitations

ARM TrustZone partitions the MCU into "Secure" and "Non-Secure" worlds. Cryptographic keys and sensitive algorithms live in the Secure world, inaccessible to the main OS (like FreeRTOS or Linux). However, developers often forget that TrustZone is a logical separation. It does not natively protect against physical fault injection (voltage glitching) unless paired with dedicated anti-tamper hardware.

Flash Encryption

Secure Boot prevents modified code from running, but it doesn't hide your IP. Flash Encryption utilizes hardware AES engines (often tied to keys burned into eFuses that cannot be read by software) to encrypt the firmware at rest. The code is decrypted on-the-fly as it is loaded into the CPU instruction cache.

Software Hardening: Anti-Timing Attacks

To mitigate side-channel and timing attacks, critical software paths (like password checking or MAC verification) must execute in constant time, regardless of whether the input is correct or incorrect.

SENIOR SECRET

Constant-Time Memory Comparison: Never use standard `memcmp` or `strcmp` for validating secrets. Standard functions return early the moment they find a mismatched byte. Attackers measure the exact microseconds the function takes to execute to guess secrets byte-by-byte.

Here is a C snippet demonstrating a timing-constant software comparison:

#include 
#include 
/

@brief Timing-safe comparison of two memory buffers.

*

@param a Pointer to the first buffer
@param b Pointer to the second buffer
@param length Number of bytes to compare
@return 0 if buffers are identical, non-zero otherwise.

*/
uint8_t secure_memcmp_constant_time(const uint8_t a, const uint8_t b, size_t length) {
uint8_t result = 0;
// Iterate through the entire buffer regardless of a mismatch.
// The bitwise XOR will be 0 if the bytes match.
// The bitwise OR accumulates any differences.
for (size_t i = 0; i < length; i++) {
result |= (a[i] ^ b[i]);
}
return result;
}

6. Summary

Reverse engineering embedded systems has moved from highly specialized nation-state labs to the desks of hobbyists and competitors. Tools like Ghidra and open-source logic analyzers have lowered the barrier to entry significantly.

Protecting your code requires a fundamental shift in architecture. Relying purely on stripped binaries is security through obscurity. True hardware security requires a synthesis of hardware isolation (TrustZone), cryptographic assurance (Secure Boot and Flash Encryption), and defensively engineered software that resists both logical probing and physical manipulation.

Assume physical access means a breach is imminent, and design your system to make that breach economically unviable for the attacker.

EurthTech.com - Engineering the future of secure embedded systems.

© 2026 EurthTech. Built for the next generation of engineers.

eurthtech.com