In the context of programming, the term “obfuscation” is typically taken to mean “deliberately making source code hard to read or understand while keeping it functionally correct.” The reason I used the “typically” qualifier is that I’ve just been exposed to the concept of obfuscation at the machine code level. Now my head hurts.
Since we’re already talking obfuscation, I feel it would be remiss of me not to mention the International Obfuscated C Code Contest (IOCCC). This started in 1984, and it’s the granddaddy of them all. Entrants attempt to write the most creatively obscure C programs. Winners include tiny one-liners, ASCII art source code, self-reproducing programs, and other delightful horrors. The IOCCC is still active, and its archive and winners are online.
There’s also the Underhanded C Contest. This is (or was—I fear it may no longer be active) a related but philosophically opposite contest. The idea is (or was) to write code that appears correct and innocent but secretly performs malicious actions. This contest ran from the 2000s into the mid-2010s. Entries are exercises in hiding backdoors that could plausibly pass casual inspection.
The reason I mention this here is that I was just chatting with Brian Kelly, CEO, and Dr. Nils Albartus, Embedded Security Specialist and Technical Solutions Director at Emproof.
Nils and Brian explained how Emproof’s founders—Dr. Tim Blazytko, Dr. Philipp Koppe, and Dr. Marc Fyrbiak—met at Ruhr University Bochum (one of Europe’s leading research centers for cybersecurity) and the Max Planck Institute. Their doctoral work involved breaking into embedded systems, analyzing firmware, and reverse-engineering microcontrollers. A professor suggested they flip their approach, saying, “If you can help industry stop people like you from breaking code, you might have a company.” That suggestion resulted in the founding of Emproof in 2021.
The team was joined by Nils, whose PhD focused on hardware vulnerabilities, thereby bridging the gap between hardware and software security. As Nils told me, “We work right at that interface where attacks most often occur.”
Why should the designers of embedded systems be interested in Emproof? I’m glad you asked. Traditional protections, such as secure boot, debug locks, and HSMs (hardware security modules), don’t stop reverse engineering. They ensure integrity and authenticity, but once an attacker has a binary, it can still be analyzed. That’s why Emproof adds software-centric layers such as obfuscation, anti-debugging, and integrity checks. As Nils puts it: “Obfuscation is the last line of defense when readout protections fail. It makes the firmware look totally different while it still behaves the same.” Meanwhile, Brian framed Emproof’s differentiation succinctly as follows: “Most security protects against intrusion. We protect the value inside the software—the IP itself.”
All of which leads us to Emproof’s flagship product, Emproof Nyx. This is a binary-level security solution aimed at embedded systems (firmware, microcontrollers, RTOS, etc.). It works after compilation, directly on binaries or libraries, so you don’t need to modify your source code or redesign your hardware.
Emproof Nyx combines IP protection, reverse-engineering defenses, tamper/hacking mitigation, and runtime exploit protection (in languages like C/C++) into a single package. It supports multiple architectures (e.g., ARM Cortex-M, RISC-V, x86) and is generally “architecture-agnostic” within the embedded domain.
Just to give you a tempting teaser of what’s to come, Ghidra is an open-source software reverse-engineering (SRE) suite developed by the U.S. National Security Agency (NSA). It’s used to analyze compiled executables—binaries with no source code—and reconstruct a human-readable representation of how they work. The decompiler is Ghidra’s crown jewel. It takes machine code (raw bytes) and produces a C-like pseudocode view that’s far easier to understand than raw assembly. This allows reverse engineers to reason about logic, variables, and control flow rather than CPU registers and jumps.
Emproof Nyx transformations are designed to break or confuse decompilers, which will often produce pseudocode that is incorrect or incomplete. The upper portion of the image below shows an unprotected function in the Ghidra decompiler. By comparison, the lower portion of the screenshot shows how the decompiler encounters problems when working with the same function after it has been protected with Emproof Nyx. The decompiler is typically not able to correctly decompile the protected function anymore. Reverse engineers are now forced to look deeper into the disassembly, where further protections await.
Now, although I’ve been waffling on about obfuscation, I want to make sure to convey that this is just one facet of Emproof Nyx’s capabilities. This bodacious beauty combines both passive (hiding) and active (reacting) protections to make reverse engineering significantly more costly for bad actors.
Passive protections—such as code and data obfuscation—rewrite binaries into complex, misleading forms that defeat decompilers (as we’ve already seen above, even sophisticated tools like Ghidra produce nonsensical results). What do I mean by “data” in this context? Well, Emproof Nyx can hide data such as encryption keys or calibration constants by dynamically decrypting or transforming them at runtime, thereby ensuring that they’re never plainly visible in memory.
Additionally, we have active protections, which include runtime guards that detect breakpoints, tracing hooks, and virtualized execution. If tampering is detected, the firmware can stop executing, revert to a safe path, or continue running but with misleading data. As Nils explained, “If a debugger connects, it leaves traces in CPU registers. We look for those changes.”
When I heard all this, my first thought was, “But what about the overhead?” After all, classic obfuscation on its own can easily add 100X code bloat. Using proprietary techniques, Emproof Nyx reduces this overhead to 10–20%, making it viable for real-time embedded systems. As Nils says, “We make firmware look messy on purpose, so attackers waste time trying to make sense of chaos. Security is never free, but a 15% overhead is a small price to pay for keeping your IP safe.”
To reduce overhead still further, Emproof Nyx facilitates granular protection. Developers can selectively protect only critical functions (security-irrelevant ones can remain unprotected). This mitigates runtime overhead, which is crucial in safety-critical applications, such as those involving airbags and motor controls.
To prove their protections don’t alter firmware function, Emproof uses translation validation via SMT solvers as part of their ISO 26262 (ASIL B) safety compliance.
The thing that really boggles my brain is the fact that all of this works on existing binaries. Customers receive a binary-level framework; they feed in their firmware and receive a hardened version in return. Configuration files let them specify which functions to protect (by name, using symbol tables). As Brian noted, “We protect code after it’s compiled, which means we can even secure legacy or third-party binaries.”
Emproof utilizes proprietary analysis tools to identify optimal spots for inserting protections, minimizing the impact on timing and memory. As an unexpected benefit, Emproof can harden existing vulnerabilities. They distinguish between logic bugs and security vulnerabilities, focusing on the latter (such as buffer overflows and use-after-free errors), which remain common in embedded C/C++. For example, if the existing firmware code has memory-corruption bugs but still runs, Emproof’s hardening makes these bugs almost impossible to exploit.
Prior to meeting Nils and Brian, I thought obfuscation was just a way to make source code unreadable. I now realize it’s also a way to make machine code unbreakable. Emproof’s passive protections conceal the intent—twisting binaries into deceptive, misleading forms that confound reverse-engineering tools and leave attackers scratching their heads. Their active defenses stand guard at runtime, detecting debuggers, spotting tampering, and refusing to cooperate when something looks suspicious.
Together, these two layers form a dynamic defense that conceals secrets while watching for threats. When attackers meet Emproof-protected firmware, they aren’t greeted by open doors; instead, they end up lost in a labyrinth of confusion, with tripwires waiting at every turn. That’s not just clever coding; that’s elegant engineering!
