The Growing Cost of Embedded IP Theft and How Firmware Hardening Helps

Most engineering organizations ship something they would rather a competitor never saw. In cloud software, that code stays on a server the company controls. In embedded products, however, it does not, because the software that defines the product gets compiled, flashed, and handed to whoever buys the device.

That gap carries a real price. The Institute for Employment Research (IAB) puts the economic damage from industrial and economic espionage at roughly $400 billion a year in the United States, about 2.1 percent of GDP, and around €200 billion in Germany. Its 2025 survey also found that 22 percent of German firms conducting research and development confirmed an espionage attack in the previous five years, compared with 8.3 percent of those without an R&D function ^[1]. Innovation, in other words, attracts attention.

Automotive is a particularly clear case. A single electronic control unit (ECU) can hold years of calibration work, a proprietary control algorithm, and cryptographic keys, all within one binary. This article looks at why that binary is exposed by default, what modern tooling can pull out of it, and how Emproof's Nyx hardens it in place.

The Binary Is the Real Attack Surface

Firmware leaves the building through more doors than most teams count. Most microcontrollers expose a debug or readout interface, and over-the-air update packages can often be downloaded and unpacked ^[2]. Diagnostic interfaces sit on the vehicle bus. In automotive programs specifically, binaries also move routinely between Tier 1 suppliers and OEMs as a normal part of integration work.

Once someone has the file, the tooling is free. Ghidra, the reverse engineering suite released by the US National Security Agency, disassembles the image, reconstructs control-flow graphs, and decompiles machine code into C-like pseudocode. Signature databases identify known library functions, while constant-finder plugins locate cryptographic routines by their lookup tables ^[2].

In practice, an analyst can therefore find the function that validates a license, read the conditions gating a paid feature, or locate a hardcoded key by pattern rather than by luck. None of this requires access to the original source code.

Why Readout Protection Is Not Enough

Readout protection is a single barrier, and a hardware one at that. Fault injection, which glitches supply voltage or clock timing at precisely the right instant, can skip the check outright, while bootloader logic bugs and side-channel methods offer other ways in ^[2].

It also guards only one path, doing nothing about an image pulled from an update server or shared with an integration partner. Meanwhile, the code underneath stays fragile, since roughly 70 percent of severe vulnerabilities at major technology companies trace back to memory-safety issues, and about 80 percent of embedded systems will continue to rely on C and C++ over the next decade.

Large Language Models Lowered the Skill Barrier

Decompilation was never the real bottleneck. Interpreting the output was always the slower and more expensive half of the job.

Ghidra hands back pseudocode full of names such as FUN_0800a1c4 and undefined4 uVar7, and turning that into a working understanding of the code has traditionally required an experienced engineer and a considerable number of hours. That step is now largely automated. When decompiler output is fed to a capable large language model (LLM), the model will describe a function's purpose in plain English, propose meaningful variable names, annotate the control flow, and flag branches that resemble a licensing or safety check.

The shift is economic rather than technical. Analysis that once cost expert-days now costs minutes, so an attacker can review far more binaries, and someone without deep reverse engineering experience can still obtain useful results. Complexity was never security, although it did reliably buy time, and that time is now shrinking.

Close-up of an electronic board with components. Source: AdobeStock. 

What Emproof Nyx Does to the Compiled Binary

Emproof is a German embedded security company, and Nyx is its binary transformation tool. It runs after compilation, directly on the binary, with no source code requirement and no hardware change. As a result, it can also be applied to third-party, legacy, and already-deployed firmware.

Nyx Microcontroller applies several layers of protection in a single pass:

• Control-flow obfuscation restructures the code layout so that decompiler output no longer mirrors the original program structure.

• Secret hiding conceals keys and sensitive data held inside the image.

• Anti-tamper checks the deployed image against a verified reference at startup, then triggers a response defined by the manufacturer, such as entering a safe state.

• Anti-debug and anti-emulation techniques frustrate dynamic analysis on a live device.

• Exploit mitigation adds stack canaries and control-flow integrity (CFI) to defend against memory-corruption attacks.

Because these transformations rewrite the binary, correctness matters as much as protection. Emproof therefore preserves program semantics and uses formal methods, including translation validation, to prove that the transformed code behaves as the original did ^[3].

Overhead and Toolchain Integration

Weight and runtime are the reasons embedded code so often ships unprotected. Emproof puts typical memory overhead for Nyx at 10 to 15 percent, and that figure is tunable. Engineering teams can protect the full image or scope transformations to specific modules, optimize each one for size or for speed, and exclude sections with hard real-time deadlines ^[3].

For integration, the tool ships as a Docker container that drops into pipelines such as Jenkins, GitLab CI, GitHub Actions, and Azure DevOps, through a command-line interface (CLI) or a REST API. Analysis and transformation run entirely inside the customer's own infrastructure, and reproducible builds and delta testing keep the tool compatible with existing verification workflows.

Why This Lands Hardest in Automotive

Nyx Microcontroller covers the architectures that dominate automotive design, including Infineon AURIX (TriCore), Arm Cortex-M and Cortex-R, and Renesas RH850 ^[4]. The requirements tighten further in safety. A compromised braking or steering ECU is not only an intellectual property (IP) problem; it is a functional safety one. The enterprise edition of Nyx therefore carries ISO 26262 ASIL-D certification, the highest Automotive Safety Integrity Level, assessed by TÜV Nord, and it generates audit artifacts for safety documentation ^{[4, 5]}. One of the world's largest Tier 1 suppliers is a reference customer.

Regulation pushes in the same direction. UNECE WP.29 R155 ties vehicle type approval to a certified cybersecurity management system ^[6], ISO/SAE 21434 defines the engineering process behind it ^[7], and the EU Cyber Resilience Act extends secure-by-design obligations to connected products more generally ^[8].

Protection at the Binary Level Becomes the Baseline

Firmware IP protection is shifting from a differentiator to an expectation. The binary was always readable, but what has changed is that reading it now takes hours instead of weeks, and regulators have started asking manufacturers what they did about it.

Working at the binary level is what makes the answer practical, since it doesn't require rewriting, silicon changes, or recompiling of code a supplier may not even own, at an overhead small enough for devices that previously had no room for security at all. Emproof offers browser-based demos for engineers who want to see what the transformed output looks like.

References

[1] A. Glitz, S. Kohaut, and I. Möller, "Nine percent of businesses fall victim to espionage," IAB Short Policy Report, no. 2/2025, Institute for Employment Research, Nuremberg, Germany, May 2025. [Online]. Available: https://doku.iab.de/kurzber/2025/kb2025-02_en.pdf 

[2] Emproof, "Defend against the threat of reverse engineering with Emproof Nyx." [Online]. Available: https://emproof.com/en/reverse-engineering. [Accessed: Aug. 2, 2026].

[3] Emproof, "Solution: Emproof Nyx." [Online]. Available: https://emproof.com/en/solution. [Accessed: Aug. 2, 2026].

[4] Emproof, "Nyx Microcontroller." [Online]. Available: https://emproof.com/en/nyx-microcontroller. [Accessed: Aug. 2, 2026].

[5] Emproof, "Emproof Nyx awarded ISO 26262 certification for functional safety in automotive components." [Online]. Available: https://emproof.com/news-posts/emproof-nyx-awarded-iso-26262-certification-for-functional-safety-in-automotive-components/. [Accessed: Aug. 3, 2026].

[6] United Nations Economic Commission for Europe, UN Regulation No. 155 — Uniform provisions concerning the approval of vehicles with regards to cyber security and cyber security management system, Geneva, Switzerland, 2021.

[7] ISO/SAE 21434:2021, Road vehicles — Cybersecurity engineering, International Organization for Standardization, Geneva, Switzerland, 2021.

[8] European Parliament and Council of the European Union, Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements (Cyber Resilience Act), Oct. 2024.