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&amp;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 <a href="https://emproof.com/en/solution">Emproof's Nyx</a> hardens it in place.<img src="https://s3-us-west-1.amazonaws.com/wevolver-project-images/froala%2F1790776375099-Emproof_Binary-Protection_Automotive.jpg" style="width:100%px" class="fr-fic fr-dib" />Emproof Binary Protection for Automotive. Source: emproof<h2>The Binary Is the Real Attack Surface</h2>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.<h3>Why Readout Protection Is Not Enough</h3>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.<h2>Large Language Models Lowered the Skill Barrier</h2>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.<h2><img src="https://s3-us-west-1.amazonaws.com/wevolver-project-images/froala%2F1790702404656-1790702404656.jpeg" width="624" height="367" class="fr-fic fr-dii" />Close-up of an electronic board with components. Source: AdobeStock. </h2><h2>What Emproof Nyx Does to the Compiled Binary</h2><a href="https://emproof.com/en/home">Emproof</a> 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.<a href="https://emproof.com/en/nyx-microcontroller">Nyx Microcontroller</a> applies several layers of protection in a single pass:<ul><li>Control-flow obfuscation restructures the code layout so that decompiler output no longer mirrors the original program structure.</li><li>Secret hiding conceals keys and sensitive data held inside the image.</li><li>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.</li><li>Anti-debug and anti-emulation techniques frustrate dynamic analysis on a live device.</li><li>Exploit mitigation adds stack canaries and control-flow integrity (CFI) to defend against memory-corruption attacks.</li></ul>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].<img src="https://s3-us-west-1.amazonaws.com/wevolver-project-images/froala%2F1790776477002-Emproof_Code-Hardening+Kopie.jpg" style="width:100%px" class="fr-fic fr-dib" />Source: emproof<h3>Overhead and Toolchain Integration</h3>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.<h2>Why This Lands Hardest in Automotive</h2>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].<h2>Protection at the Binary Level Becomes the Baseline</h2>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.<hr /><h3>References</h3>[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.

A modern vehicle's competitive advantage lies in compiled firmware. Binary-level protection secures that code without source access, hardware changes, or a heavy memory budget.

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

Deep Trekker ROV controller and software interface.

Learn about the software used by ROV companies. See how Deep Trekker uses its software to benefit the users of its products. 

What Types of Software Are Commonly Used For ROVs?

<h2 id="isPasted">The days of monolithic binaries are over</h2>As the IoT market is slowly maturing, IoT systems are becoming increasingly complex and versatile. As a result, embedded devices are composed of distinct firmware components made by different parties working together, often running on multiple MCUs simultaneously.This multi-party involvement has implications for how firmware is developed and updated. Rather than creating single binaries which are built and flashed to devices at once, firmware is constructed from multiple components. Each of these components can be managed and updated separately, just like cloud applications, allowing you to do what you do best. Whether it’s developing modem firmware, application code, bootloader software, drivers for sensors, or interfaces with hardware secure modules.Let’s explore the opportunities of remotely managing multi-component firmware in IoT devices by using the LwM2M standard.This article is the part of a series about OTA software updates for IoT devices. Read the first article <a href="https://www.avsystem.com/blog/remote-firmware-updates-for-iot-devices/" rel="noopener" target="_blank">here</a>.<h2>Problems with full-firmware updates</h2>When dealing with IoT devices which are highly constrained due to their limited available bandwidth, power and memory size, the process for device firmware updates (DFU) has to be carefully crafted. Updating the firmware can be resource-intensive, certainly when the network connection is unstable, leading to a lengthy update process which requires the radio to be on and drains the device’s battery.As IoT devices become more complex, so do their firmware, leading to increasingly large update files. This not only increases the necessary time and required energy to perform an update, it also makes the update more prone to errors as the devices require a stable connection for a longer period of time.In contrast to single-binary firmware which are to be updated fully (as described in our <a href="https://www.avsystem.com/blog/remote-firmware-updates-for-iot-devices/" rel="noopener" target="_blank">latest article</a>), embedded firmware can be composed of separated code blocks which can be configured and updated independently. A component-based update process can significantly reduce the required resources for updating the device’s firmware.<h2 id="isPasted">Deconstructing embedded device firmware</h2>Firmware is usually stored in the device’s flash memory; non-volatile memory which persists after a reboot and can be electronically rewritten. To virtually isolate different firmware components, flash memory is split into multiple partitions. Different firmware components – such as the bootloader, application firmware or the tinyML model – reside in dedicated flash partitions. Consequently, one partition can be safely updated while the others remain untouchedEmbedded devices usually don’t contain just one MCU. Instead they often contain multiple processors each being responsible for a dedicated task. Next to the main MCU, the device may include one or multiple radio modems for cellular or Bluetooth communication. It may include smart sensors which include local processing to add more intelligence. For example, cameras which detect the number of cars, bikes or people passing by, or microphones which only detect specific sound events. All of these MCUs may contain flash partitions which can become updatable.<img src="https://images.wevolver.com/eyJidWNrZXQiOiJ3ZXZvbHZlci1wcm9qZWN0LWltYWdlcyIsImtleSI6ImZyb2FsYS8xNjk4MDc1NDgxMzg4LWJsb2dwb3N0LWZsYXNoLW11bHRpLTEuanBnIiwiZWRpdHMiOnsicmVzaXplIjp7IndpZHRoIjo5NTAsImZpdCI6ImNvdmVyIn19fQ==" style="width: 302px;" class="fr-fic fr-dib">A multi-MCU IoT device with partitioned flash memoryMaking flash partitions updatableIn order to make a firmware component updatable, a dedicated partition – called the update partition – needs to be created for each component. In essence, this means that each component consists of two partitions; one that runs the actual firmware, and one which is reserved to store new firmware images during firmware updates. In case flash size is restricted, update partitions can be created in external flash memory.<img src="https://images.wevolver.com/eyJidWNrZXQiOiJ3ZXZvbHZlci1wcm9qZWN0LWltYWdlcyIsImtleSI6ImZyb2FsYS8xNjk4MDc1NDk5MTc1LWJsb2dwb3N0LWZsYXNoLW11bHRpLXVwZGF0ZS1tY3UtMi5qcGciLCJlZGl0cyI6eyJyZXNpemUiOnsid2lkdGgiOjk1MCwiZml0IjoiY292ZXIifX19" style="width: 302px;" class="fr-fic fr-dib">A multi-MCU IoT device with partitioned flash memory containing update partitions<h2 id="isPasted">Multi-Component Firmware Updates</h2>Let’s explore what really happens deep down in the device’s flash memory when a firmware component is being updated.The process starts when new firmware is released and uploaded to the repository. Once uploaded, the LwM2M Server informs the device about the availability of new firmware, enabling the device to download the firmware image.DownloadingOnce the firmware update is initiated for a specific component, the device starts downloading the new firmware image into the dedicated update partition. After the download has completed, the application initiates a reboot. At boot, the bootloader validates the authenticity and integrity of the new firmware, once validated it initiates the swapping process.Swapping firmwareIn contrast to Linux-based systems which support “position-independent code”, microcontrollers usually can’t boot firmware directly from the update partition. As a result, the firmware residing in the update partition needs to be swapped with the original firmware. When using the open source MCUboot bootloader, the two images are swapped using the flash partition known as the scratch partition. The scratch partition acts as a buffer, allowing the bootloader to switch the new and existing firmware images between their respective partitions. Throughout the swapping process, the device goes offline and becomes unresponsive to server commands.In the swap process, the bootloader first copies a chunk of the new firmware from the update partition to the scratch partition. It then moves the existing firmware to the update partition. Finally, it moves the new firmware chunk from the scratch partition to the original partition. This process repeats until the entire new firmware image has been moved into the original partition, completing the swap.Running new firmwareAfter the swap has been completed, the bootloader initiates the new firmware from the newly flashed image. If initialized successfully, the device starts running the new firmware. The new firmware is expected to write a flag in the flash memory to indicate that the update was successful, which is done after performing several self-checks, e.g. initializing the hardware.RollbackIf no successful update flag is added to the flash memory, the bootloader assumes something went wrong and performs a rollback during the next boot. The rollback triggers the swap procedure to revert the initial firmware. Once the swap is complete, the bootloader initiates the old firmware, ensuring the device remains operational.<img src="https://images.wevolver.com/eyJidWNrZXQiOiJ3ZXZvbHZlci1wcm9qZWN0LWltYWdlcyIsImtleSI6ImZyb2FsYS8xNjk4MDc1NTYxNzk2LXJvbGxiYWNrLndlYnAiLCJlZGl0cyI6eyJyZXNpemUiOnsid2lkdGgiOjk1MCwiZml0IjoiY292ZXIifX19" style="width: 302px;" class="fr-fic fr-dib">DFU process for a distinct firmware component<h2 id="isPasted">Presenting the LwM2M Advanced Firmware Update Object</h2>In the <a href="https://www.avsystem.com/blog/remote-firmware-updates-for-iot-devices/" rel="noopener" target="_blank">previous article</a>, we’ve discussed the Firmware Update Object (/5) as defined in the <a href="https://technical.openmobilealliance.org/OMNA/LwM2M/LwM2MRegistry.html" rel="noopener" target="_blank">LwM2M Object and Resource Registry</a>. The creation of updatable firmware components can be accomplished through implementing the Advanced Firmware Updates Object (/33629). Object 33629 extends the functionality of the Firmware Update Object (/5) by enabling multiple Object Instances to represent the different components of device's firmware. The specific purpose of these components are not standardized and can vary depending on the implementation.Similar to Object 5, the Advanced Firmware Updates process comprises 4 States (idle, downloading, downloaded, updating) and no less than 13 Update Results which contain all the likely outcomes of the firmware update process; providing developers with information about the update status and results.Currently, developers are using Object 33629 as a custom LwM2M Object implementation, until it’s officially adopted into the <a href="https://technical.openmobilealliance.org/OMNA/LwM2M/LwM2MRegistry.html" rel="noopener" target="_blank">LwM2M Object and Resource Registry</a>. <img src="https://images.wevolver.com/eyJidWNrZXQiOiJ3ZXZvbHZlci1wcm9qZWN0LWltYWdlcyIsImtleSI6ImZyb2FsYS8xNjk4MDc1NTg4MTYzLTExLmpwZyIsImVkaXRzIjp7InJlc2l6ZSI6eyJ3aWR0aCI6OTUwLCJmaXQiOiJjb3ZlciJ9fX0=" style="width: 302px;" class="fr-fic fr-dib">View of the Firmware Update feature within&nbsp;<a href="https://www.avsystem.com/coiote-iot-device-management-platform/" rel="noopener" target="_blank" id="isPasted">Coiote IoT Device Management Platform</a><h2 id="isPasted">Conclusion</h2>The shift from monolithic firmware to a multi-component structure in embedded devices presents an opportunity to streamline and enhance the OTA device firmware update process. This approach offers flexibility in updating specific components independently, reduces resource usage, and provides a more efficient update process.As IoT devices become increasingly complex, moving towards multi-component FOTA updates is a logical and beneficial step. It facilitates the concurrent development of different firmware components by various parties which ensures the overall quality and functionality of IoT systems over time. As the IoT market continues to mature, this practice is likely to become the norm, making firmware updates more efficient, reliable, and user-friendly.

As the IoT market is slowly maturing, IoT systems are becoming increasingly complex and versatile. As a result, embedded devices are composed of distinct firmware components made by different parties working together, often running on multiple MCUs simultaneously.

Firmware

ORGANIZATIONS. SHAPING THE INDUSTRY.

Latest Posts

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

What Types of Software Are Commonly Used For ROVs?

Long live multi-component FOTA updates