How to protect software from AI attacks?

Your binary is your source code now. An attacker with a state-of-the-art LLM and a decompiler needs an afternoon to prove it.

Table of contents

• Exploited before anyone is warned

• The Cyber Resilience Act: 24 hours to report

• How reverse engineering lost its entry barrier

• AI agents: from weeks of analysis to hours

• Binary hardening: making the attacker’s work expensive again

Every binary a company ships eventually ends up on hardware the manufacturer no longer controls, inside a car or an industrial controller somewhere out in the field. Whoever owns that hardware can read out the flash and study what the vendor shipped, at leisure and without asking anyone's permission. Contracts and copyright law raise the cost of doing so and deter a fair share of the people who might try. Anyone who has decided the risk is worth taking proceeds anyway.

A competitor who understands the control logic inside a device spares his own engineers years of development from scratch. Someone who defeats a licence check can go on to sell activations and spare parts, and the manufacturer loses that revenue. A third group worries security teams most. It has no interest in the business model or the engineering and simply wants to find a flaw and take the device over.
All of them have to start in the same place, by reading a compiled file and working out what the program actually does. That translation work is called reverse engineering, and for decades it was a specialist trade with a steep price of entry. This price has collapsed over the past eighteen months.

More vulnerabilities than anyone can work through

The Zero Day Clock counts 57,883 published CVE records for the first eight months of 2026, drawing on the CVE databases together with the catalogues of known exploited vulnerabilities. In the first half of the year, 485 vulnerabilities were newly listed as actively exploited, and 134 of those were already under attack on the day they went public.

Some caution is in order with the first of those figures, because CVE numbering was opened up to many more organisations and vendors now file records against their own products as a matter of routine. The rise therefore partly measures how many bodies are entitled to report at all. The second figure carries more weight, precisely because the practice of issuing identifiers has no bearing on it. More than one in four newly catalogued exploited vulnerabilities was already being used against defenders who had no warning whatsoever.

The Cyber Resilience Act sets the first hard deadline

For manufacturers of connected products this now carries an immediate legal consequence. Article 14 of the Cyber Resilience Act applies from 11 September 2026. Once anyone in the company becomes aware of an actively exploited vulnerability in one of its products, an early warning has to reach the coordinating CSIRT and ENISA within 24 hours, followed by a fuller notification within 72 hours. The obligation covers products that have been in the field for years, along with everything shipped from here on out.

A defect in shipped code used to sit on the risk register until a customer or a researcher happened to find it, which kept the cost of a late discovery largely reputational. From 11 September a one-day clock starts the moment somebody inside the company hears that the flaw is being exploited. How fast outsiders can read your firmware therefore translates directly into how much legal exposure you carry.

Thirty years of tool building

An analyst in the 1990s worked through assembly by hand, reading registers and jump addresses one line at a time. The skill took years to build, and the number of people who had built it stayed small. IDA Pro arrived in the middle of that decade as the first tool that imposed structure on the code and resolved cross-references automatically. It was priced accordingly and remained the preserve of professional teams. Decompilers were the bigger step. Because they rendered machine code as something close to C, an analyst no longer had to read assembly in order to understand what a function does, and the pool of people who could do useful work widened considerably.

In 2019 the NSA released Ghidra at the RSA Conference and published the source a few weeks later. A decompiler framework built over roughly two decades was now a free download, so the entry barrier came down to bandwidth and patience. The population of people able to work seriously on binaries grew accordingly, and it has kept growing ever since.

What an AI-agent actually does to a firmware image

Since late 2024 there has been an open standard, the Model Context Protocol, describing how a large language model drives external tools. The first MCP servers for Ghidra appeared publicly on GitHub a few months later. They expose the decompiler's own capabilities to a model, from listing and decompiling individual addresses through to renaming variables and following cross-references.

A mid-sized firmware image contains several thousand unnamed functions, and the expensive part of the work was always working out which twenty of them matter. What an AI-agent brings to that problem is stamina. It walks the entire set, names what it recognises and leaves behind a map that a human can then search from, hypotheses included. That groundwork used to take weeks. It now takes hours.

The Google Threat Intelligence Group reported in May 2026 that the same tools which support defensive research also lower the barrier for adversaries to reverse-engineer applications and build exploits from what they find. One tracked group prompted a model to pose as a C and C++ binary security expert in order to audit an extracted TP-Link firmware file system for pre-authentication remote code execution. Another sent thousands of near-identical prompts that recursively analysed CVEs and validated proof-of-concept exploits.

The same report describes the first documented case of a criminal group discovering and weaponising a zero-day with AI support. The target was a two-factor authentication bypass in a widely used open-source administration tool, and the underlying flaw was a hardcoded trust assumption in the authentication logic. Fuzzers and static analysis look for crashes and unsanitised input, so a defect of that shape passes their tests cleanly while remaining broken from a security point of view. Google warned the vendor before the planned mass exploitation campaign got going. Established automated methods reliably miss defects of this class, and a model found one anyway.

What manufacturers can put in the way

An agent's advantage depends on the decompiler output being legible. It leans on clean function boundaries and on control flow that collapses neatly into a summary. Binary hardening attacks those preconditions directly. Nyx rewrites the shipped binary so that the decompiler's output loses its structure while runtime behaviour stays exactly the same. Each function then has to be worked out on its own terms, so the agent stops scaling across thousands of them, and the economics that made agentic reverse engineering attractive begin to work against the attacker.

We are currently measuring how large that effect is against concrete targets. The numbers, together with a case study, will appear in a separate white paper.

Until then there is something a product security team can test for itself. Load your most recently shipped firmware into Ghidra with one of the public MCP servers attached, then let a state-of-the-art model work on it for an afternoon. What sits on the screen afterwards is roughly what an attacker would see for the same effort. The whole exercise costs nothing beyond compute time and a spare afternoon.