Control Flow Integrity, or CFI, is a catch-all term for a family of mitigations that try to constrain indirect branches—calls, jumps, returns—to a set of targets that are either statically or dynamically approved. On paper, it closes the gap left by W^X and ASLR: even if an attacker gets arbitrary write, they can’t redirect execution to a gadget of their choosing. In practice, the implementations shipping in Windows, macOS, iOS, Android, and various hypervisors are a patchwork of coarse-grained checks, shadow stacks, and compiler-inserted validation that often fails in ways the vendors don’t advertise. This article is a field report on what actually happens when you try to bypass or reproduce those claims on x86-64 and ARM64.

For anyone working at the bench—whether that means extracting a baseband bootloader over JTAG, fault-injecting a SEP, or emulating a UEFI module—CFI is not an abstract security property. It is a set of concrete constraints on the indirect branch instructions you can hijack, the return addresses you can forge, and the exception paths you can abuse. The gap between the vendor’s threat model and the silicon’s actual behavior is where the interesting bugs live.

What CFI Actually Checks

At the instruction level, CFI splits into two broad categories: forward-edge protection for indirect calls and jumps, and backward-edge protection for returns. Forward-edge schemes typically insert a check before an indirect call or jump to verify that the target address belongs to a set of valid function entry points. Backward-edge schemes protect the return address, either by keeping a separate shadow stack or by encrypting the return address with a key stored in a register or memory that the attacker cannot easily read.

The devil is in the granularity. A fine-grained CFI policy would validate every indirect branch against the exact set of functions whose address could legitimately flow to that call site. That requires precise points-to analysis, which is expensive and brittle across shared libraries and JIT code. What ships instead is usually a coarse approximation: all functions with the same signature, all functions in the same module, or all functions whose address has been taken anywhere in the program. Coarse-grained CFI stops some exploits, but it leaves a large gadget space for an attacker who can chain existing call targets.

Windows: Control Flow Guard and CET

Windows Control Flow Guard (CFG) is a forward-edge check inserted by the compiler before indirect calls. The target address is passed to a bitmap lookup that records which addresses are valid function entry points. If the bit is not set, the process terminates. The bitmap is stored in a read-only section, but the check itself is a function call into ntdll!LdrpValidateUserCallTarget or a direct bitmap test in newer builds. The problem is that the bitmap is coarse: any function whose address has been taken is marked valid, regardless of whether that function could legitimately be called from the current site. An attacker who can overwrite a function pointer can redirect it to any other address-taken function in the module. That is not a full bypass, but it is a large reduction in attacker effort.

Intel CET adds a hardware shadow stack for returns and an indirect branch tracking (IBT) mechanism for forward edges. On x86-64, IBT uses the ENDBR64 instruction as a landing pad. If an indirect call or jump lands on an instruction that is not ENDBR64, the CPU raises a control-protection fault. The shadow stack is a separate stack in memory that stores only return addresses, protected by a page-table bit that makes it writable only by dedicated CALL and RET operations. In theory, this is a strong combination. In practice, the shadow stack is only as good as the OS’s handling of setjmp, longjmp, exception unwinding, and signal delivery. Each of those paths must manually adjust the shadow stack pointer, and each adjustment is a potential hole.

macOS and iOS: Pointer Authentication

Apple’s ARM64 devices use Pointer Authentication Codes (PACs). A PAC is a short cryptographic hash of the pointer value and a context value, computed with a key held in a system register. The PAC is stored in the unused high bits of the pointer. Before an indirect branch or a return, the hardware or compiler-inserted code verifies the PAC. If the check fails, the CPU raises an exception. The keys are supposed to be inaccessible to user code, but they are not per-process; they are per-exception-level. A kernel exploit that can read the PAC keys or sign arbitrary pointers defeats the scheme for the entire system.

PAC is not a shadow stack. It authenticates the pointer value, not the control flow path. An attacker who can forge a valid PAC for a chosen target can redirect execution to that target. The PAC is only 16 to 24 bits depending on the pointer size and the reserved bits, so a brute-force attack is possible if the target does not crash the process on failure. Apple mitigates this by rate-limiting PAC failures in some contexts, but the underlying weakness remains: PAC is a probabilistic check, not a deterministic one.

Android and Linux: Clang CFI and Shadow Stacks

Android uses Clang’s forward-edge CFI for the kernel and some userspace components. The compiler generates type-based checks: before an indirect call, it compares the target’s type identifier against the expected type for that call site. The type identifiers are stored in a read-only section, and the check is a simple comparison and branch. This is finer-grained than Windows CFG because it distinguishes function signatures, but it still allows any function with a matching signature to be called. In the kernel, where many functions share the same signature, the gadget space remains large.

Linux has been slower to adopt CFI. The mainline kernel has supported Clang CFI for arm64 since 5.13, but x86-64 support is still not universal. The kernel’s indirect call sites are numerous, and the performance cost of type checks is measurable. Shadow stacks for the kernel are also in progress, but the interaction with ptrace, kprobes, and perf makes the implementation messy. Each of those subsystems can legitimately modify control flow, and each modification must be reflected in the shadow stack.

Where CFI Breaks in Practice

The most reliable bypasses do not attack the CFI check itself. They attack the assumptions underneath it. A shadow stack assumes that the return address is the only thing that matters. But an attacker who can overwrite a saved frame pointer, a function pointer, or a vtable entry can still redirect execution without touching the return address. CFI protects the branch, not the data that feeds the branch.

Another common failure is the exception path. On Windows, structured exception handling (SEH) uses a linked list of exception registration records on the stack. The list is protected by SafeSEH and later by __C_specific_handler validation, but the unwinding itself can be abused. On ARM64, the PAC instruction signs the link register, but the exception return path uses a different register (ELR_EL1 or ELR_EL2) that may not be protected by the same mechanism. A fault injection that corrupts ELR_EL1 during an exception can bypass the return-address check entirely.

JIT code is another weak point. A JIT compiler generates code at runtime, and that code must be marked executable. The CFI policy must either exempt JIT code from checks or dynamically update the valid-target set. Both approaches create windows where an attacker who can write to the JIT code cache can redirect execution. Browsers and language runtimes have spent years hardening their JIT implementations, but the fundamental tension remains: CFI wants a static set of valid targets, and JIT wants to create new targets on the fly.

Fault Injection and CFI

At the bench, fault injection changes the calculus. A voltage glitch or electromagnetic pulse can skip the CFI check instruction entirely, or corrupt the comparison result so that an invalid target is accepted. The check is just a few instructions; skipping it is often easier than finding a gadget that passes the check. This is why hardware-enforced CFI is not a substitute for physical security. If an attacker has physical access to the device, the CFI check is just another instruction to glitch.

On embedded devices with custom firmware, the CFI story is even weaker. Many baseband and automotive ECUs do not use CFI at all, or they use a vendor-specific implementation that has never been publicly audited. The firmware is often extracted over JTAG and reverse-engineered, and the CFI checks, if any, are identified and patched out. The vendor’s claim of “hardware-enforced control flow integrity” often means a single check in the bootloader that can be bypassed with a well-timed glitch.

Reproducing Vendor Claims

When a vendor claims that their system uses CFI, the first step is to reproduce the claim. That means disassembling the firmware or binary and looking for the actual check instructions. On Windows, CFG is visible as a call to LdrpValidateUserCallTarget or a bitmap test before indirect calls. On macOS, PAC is visible as PACIA, PACIB, AUTIA, and AUTIB instructions around function entry and exit. On Android, Clang CFI is visible as a comparison of a type identifier before an indirect call.

The next step is to test the granularity. For each indirect call site, what is the set of valid targets? If the set is large, the CFI is coarse. If the set is small, the CFI is fine-grained. The difference matters because it determines how much work an attacker must do to find a usable gadget. A coarse-grained policy may still stop a simple stack smash, but it will not stop a determined attacker who can chain existing functions.

Finally, test the edge cases. What happens when an exception is thrown? What happens when a signal is delivered? What happens when a JIT compiler generates code? Each of these paths must interact with the CFI mechanism, and each interaction is a potential bypass. The vendors do not document these interactions in detail, so the only way to know is to test them.

What This Means for the Bench

For anyone extracting firmware from a locked-down device, CFI is a hurdle, not a wall. The checks can be identified, analyzed, and bypassed. The bypass may be as simple as finding a valid target that does what you need, or as complex as glitching the check instruction. The key is to understand the specific implementation, not the marketing claim. A vendor that says “hardware-enforced CFI” may mean a shadow stack, a PAC, a bitmap check, or nothing at all. The only way to know is to look at the silicon and the firmware.

The broader lesson is that CFI is a mitigation, not a security boundary. It raises the cost of exploitation, but it does not eliminate the underlying vulnerability. An attacker who can write to memory can still corrupt data, and data corruption is often enough to achieve the attacker’s goal. CFI is one layer in a defense-in-depth strategy, and it should be treated as such.

FAQ

Does CFI stop all code-reuse attacks?

No. CFI constrains indirect branches to a set of valid targets, but the set is often large enough to contain useful gadgets. Coarse-grained CFI, in particular, allows an attacker to chain existing functions that share a signature or module. CFI also does not protect against data-only attacks, where the attacker corrupts non-control data to change the program’s behavior without redirecting execution.

What is the difference between a shadow stack and pointer authentication?

A shadow stack stores a separate copy of the return address on every call and verifies it on every return. It is a deterministic check: if the return address is modified, the check fails. Pointer authentication signs the return address with a cryptographic key and verifies the signature on return. It is a probabilistic check: an attacker who can forge a valid signature can bypass the check. Shadow stacks are stronger in theory, but they require more memory and more complex exception handling.

Can fault injection bypass CFI?

Yes. A voltage glitch or electromagnetic pulse can skip the CFI check instruction or corrupt the comparison result. The check is just a few instructions, and skipping it is often easier than finding a gadget that passes the check. Hardware-enforced CFI is not a substitute for physical security. If an attacker has physical access to the device, the CFI check is just another instruction to glitch.

Why do vendors use coarse-grained CFI instead of fine-grained?

Fine-grained CFI requires precise points-to analysis to determine the exact set of valid targets for each indirect call site. That analysis is expensive, brittle across shared libraries and JIT code, and often produces false positives that break legitimate code. Coarse-grained CFI is cheaper to implement and has lower performance overhead, but it leaves a larger gadget space for attackers. The tradeoff is between security and compatibility.

This article is part of a continuing series on hardware-enforced mitigations. The next installment will examine how CET shadow stacks interact with setjmp and longjmp on x86-64, and whether the exception unwinding path can be abused to corrupt the shadow stack pointer. If you have a specific device or firmware image you would like analyzed, the bench is always open.

Reverse engineering embedded firmware means pulling a binary image out of a microcontroller, baseband processor, UEFI SPI flash, or secure enclave and reconstructing what it actually does without any vendor documentation. The work sits next to static disassembly, dynamic instrumentation, emulation, fault injection, and glitching. On this blog, that means treating every vendor claim about “secure boot” or “hardware root of trust” as a hypothesis to test against silicon, not a marketing slide to believe. If you are here, you probably already know the datasheet is often a work of fiction and the real specification lives in the silicon bugs.

This walkthrough is not a generic “use Ghidra and hope” tutorial. It is a field note on the sequence that works when the target is a locked-down automotive ECU, a baseband image with a custom RTOS, or a UEFI capsule that refuses to parse. The steps assume you have a way to get the image out — JTAG, SPI dump, eMMC read, or fault-injected boot — and that you are willing to treat every abstraction layer as suspect.

Step 1: Acquire the Image Without Trusting the Vendor’s Tool

Vendor update tools are convenient and wrong. They often decrypt, decompress, or re-sign the image before it ever hits your disk, which means you are reversing a transformed artifact, not the firmware the device actually runs. The correct first move is to read the flash directly. For SPI NOR, that means a SOIC-8 clip and a programmer that does not try to be clever. For eMMC, that means a low-level reader that can dump the boot partitions, not just the user area. For baseband or SEP targets, that usually means finding a debug UART or a test point that exposes the internal bus.

If the device has a hardware root of trust that gates the flash, you have two choices: fault injection to bypass the read protection, or emulation of the boot ROM to extract the decryption keys. I have had more luck with the second approach on ARM64 targets where the boot ROM is small enough to emulate in an afternoon. The first approach works better on older microcontrollers where the read-out protection is a single fuse and a well-timed voltage glitch is enough to make the CPU skip the check.

Step 2: Identify the Architecture and Load Address Before You Disassemble

Loading a raw binary into Ghidra or IDA without knowing the base address is a waste of time. The disassembler will happily produce nonsense, and you will spend hours chasing branch targets that point into the middle of nowhere. The first thing to do is look for the vector table. On ARM Cortex-M, that is the first 32-bit word, which is the initial stack pointer, followed by the reset vector. On ARM64, the exception vectors are at a fixed offset from the base of the image, usually 0x0 or 0x200000. On x86-64 UEFI, the image is a PE32+ binary, and the load address is in the optional header.

If the image is encrypted or compressed, you need to find the loader. That is usually a small stub at the beginning of the image that sets up the memory controller, decrypts the payload, and jumps to it. The stub is often not encrypted, because the CPU has to execute it before the decryption engine is initialized. That is your entry point. Emulate the stub, dump the decrypted payload, and then disassemble that.

Step 3: Map the Memory and Peripherals From the Silicon, Not the Datasheet

Datasheets lie. They omit undocumented registers, mislabel interrupt numbers, and sometimes describe a completely different chip revision. The only reliable way to map peripherals is to read the silicon itself. If you have a working device, use a debugger to read the peripheral registers and compare them to the datasheet. If you do not have a working device, use the firmware’s own initialization code as the map. The code that writes to a specific address to configure a UART or a timer is telling you what that address does, even if the datasheet calls it “reserved.”

For baseband and SEP targets, the peripheral map is often split across multiple security domains. The application processor sees one view, the baseband sees another, and the secure enclave sees a third. You need to reconstruct all three views to understand the full attack surface. That means emulating the memory protection unit, not just the CPU.

Step 4: Reconstruct the Boot Flow and Trust Chain

Every locked-down device has a boot flow. The CPU starts in ROM, verifies the first-stage bootloader, which verifies the second-stage, which verifies the OS or application. The verification is usually a hash or a signature check. The bug is usually in the implementation, not the algorithm. Common failure points include:

• Hash comparison that stops after the first mismatch, allowing a timing side channel.
• Signature check that uses a key embedded in the same flash you can read.
• Boot mode pins that bypass verification entirely when strapped a certain way.
• Fault injection that skips the branch instruction after the verification call.

Reconstructing the boot flow means finding the verification code, identifying the key or hash, and then determining whether the check is actually enforced or just decorative. On one automotive ECU I worked on, the “secure boot” checked a CRC32 of the first 4 KB and then jumped to the rest of the image without any further validation. The vendor’s security whitepaper described a multi-stage chain of trust with ECC signatures. The silicon did not care.

Step 5: Disassemble With a Purpose, Not a Prayer

Once you have the image loaded at the correct base address with the correct architecture, you can start disassembling. But do not just scroll through the listing looking for strings. That is how you waste a week. Instead, work backward from the behavior you want to understand. If you want to find the update mechanism, look for the code that writes to flash. If you want to find the crypto, look for the AES S-box or the SHA constants. If you want to find the debug interface, look for the UART initialization and the command parser.

Use the cross-references. Every function that is called from the boot flow is part of the boot flow. Every function that is called from an interrupt handler is part of the interrupt handling. Every function that is called from a command parser is part of the command interface. The call graph is the map. The disassembly is just the terrain.

Step 6: Emulate the Interesting Parts Instead of the Whole System

Full-system emulation of a baseband or SEP is a multi-month project. Emulating a single function is an afternoon. The trick is to extract the function you care about, provide the minimal set of memory and peripheral stubs it needs, and run it in a controlled environment. For ARM64, that means QEMU in user mode or a custom Unicorn script. For x86-64 UEFI, that means a small EFI shell environment. For older ARM or MIPS targets, that means a custom emulator that implements only the instructions and peripherals the function actually touches.

The goal is not to boot the whole system. The goal is to answer a specific question: What does this function do with this input? Does it check a signature? Does it decrypt a payload? Does it write to a protected register? Emulation lets you answer that question without fighting the rest of the firmware.

Step 7: Validate Your Findings Against the Hardware

Reverse engineering is not complete until you have validated your findings against the actual device. That means taking the behavior you reconstructed and testing it on the silicon. If you think a certain command unlocks the debug interface, send that command and see if the UART responds. If you think a certain fault injection point bypasses the signature check, glitch the device and see if it boots your modified image. If you think a certain register controls the memory protection, write to it and see if the device crashes.

Validation is where most reverse engineering projects die. It is easy to produce a plausible-looking disassembly. It is hard to prove that your understanding matches the silicon. The difference is the difference between a blog post and a working exploit.

Common Pitfalls That Are Not in the Vendor’s App Note

Here are the mistakes I see repeatedly, including my own early ones:

• Trusting the string table. Strings are hints, not facts. A string that says “secure boot failed” does not mean the boot is secure. It means someone wrote an error message.
• Assuming the image is not encrypted. Many vendors encrypt the firmware but leave the decryption key in the boot ROM. If you can read the boot ROM, you can decrypt the image. If you cannot read the boot ROM, you need fault injection or emulation.
• Ignoring the memory protection unit. The CPU may be able to execute code from a region that it cannot read as data. That means your disassembler sees garbage, but the CPU sees instructions. You need to model the MPU to get a correct disassembly.
• Forgetting about the second core. Many baseband and automotive SoCs have multiple cores with shared memory. The code you are reversing may be running on a core you are not emulating, and the behavior you are seeing is the result of an inter-core race condition.

FAQ

What is the first step in reverse engineering embedded firmware?

The first step is to acquire the firmware image directly from the flash or storage medium, not through the vendor’s update tool. Vendor tools often transform the image, so a direct read gives you the actual bytes the device executes. For SPI flash, use a clip and programmer. For eMMC, use a low-level reader that can access boot partitions. For protected targets, you may need fault injection or emulation of the boot ROM.

How do I know the correct load address for disassembly?

Look for the vector table or the executable header. On ARM Cortex-M, the first word is the initial stack pointer and the second is the reset vector. On ARM64, the exception vectors are at a fixed offset. On x86-64 UEFI, the image is a PE32+ binary with the load address in the optional header. If the image is encrypted or compressed, find the loader stub, emulate it, and dump the decrypted payload.

What is the most common mistake when reversing firmware?

Trusting the vendor’s documentation or the string table. Datasheets omit registers and mislabel interrupts. Strings are hints, not facts. The only reliable map is the firmware’s own initialization code and the silicon itself. Validate every assumption against the hardware before you build an exploit or a patch.

Do I need to emulate the entire system to reverse a function?

No. Emulate only the function you care about, with minimal stubs for the memory and peripherals it touches. Full-system emulation is a multi-month project. A single function can be emulated in an afternoon with QEMU user mode, Unicorn, or a custom emulator. The goal is to answer a specific question, not to boot the whole device.

Next up on the bench: a teardown of a baseband boot ROM that uses a custom hash function the vendor calls “proprietary.” Spoiler: it is a truncated SHA-256 with a broken IV. If you have a target you want me to look at, send the image and a scope trace. No vendor whitepapers, please.

Build systems are the least trusted part of the software supply chain, and the most trusted by the people who consume the output. A build system is the collection of compilers, linkers, package managers, signing tools, CI runners, and configuration files that turn source code into a distributable artifact. Adjacent concepts include reproducible builds, provenance attestation, hermetic toolchains, and binary transparency. For anyone who has spent time extracting firmware from a locked-down baseband or glitching a secure enclave, the irony is obvious: we spend years reverse-engineering trust boundaries in silicon, while the industry ships binaries produced by a pile of shell scripts running on rented x86-64 instances with no meaningful integrity story. This matters because a compromised build system can inject code that no amount of runtime mitigation will catch. The hardware will faithfully execute whatever the build produced.

I have spent enough time staring at disassembled UEFI images and SEP firmware to know that the most elegant microarchitectural defense is useless if the attacker owns the compiler. Supply chain attacks target build systems because that is where trust is manufactured. The rest of this article is about how that trust gets broken, what the vendors claim, and why the abstractions keep failing.

The Build System as a Trust Anchor

Every signed binary is a statement: the organization that holds the signing key asserts that this artifact corresponds to a particular source revision and was produced by a known process. The signing key is not the interesting part. The interesting part is everything that happens before the signature is applied. Compilers, linkers, post-link optimizers, code-signing wrappers, and the CI orchestrator itself all sit in the trust path. If any of them is subverted, the signature is still valid. The key did exactly what it was told.

This is not a theoretical concern. The 2021 SolarWinds incident showed how a build environment compromise can propagate to thousands of downstream organizations. The attackers did not need to break any cryptographic primitive. They modified source code in the build environment and let the legitimate signing process do the rest. The resulting binaries were signed, distributed, and trusted. The hardware-enforced mitigations on the target machines — SMEP, SMAP, CET, pointer authentication — did not matter because the malicious code was part of the legitimate application.

For firmware and embedded targets, the problem is worse. A compromised build system for a baseband image or a UEFI module can inject code that runs before the OS loads, outside the visibility of most endpoint detection tools. The attacker does not need a zero-day in the target. They need a zero-day in the build pipeline, which is usually a much softer target.

Why Build Systems Are Soft Targets

Build systems are soft targets for the same reason that test infrastructure is a soft target: they are treated as internal plumbing, not as production systems. The people who run them are often under pressure to ship, not to audit. The machines are ephemeral, the configuration is sprawling, and the security model is usually “the CI runner can do anything.”

Consider the typical CI setup for a firmware project. A developer pushes a commit. The CI runner checks out the source, pulls in dependencies from a package registry, runs a build script, and produces a signed artifact. The runner has access to the signing key, or at least to a signing service that does not distinguish between a legitimate build and a malicious one. The build script is often a shell script with no sandboxing, no network egress controls, and no verification of the toolchain it is using. If an attacker can modify the build script, or the package registry, or the toolchain cache, they own the output.

This is not a failure of cryptography. It is a failure of process. The signing key is doing its job. The problem is that the build system is not a trustworthy environment, and the signature does not attest to the environment. It attests to the artifact, which is a different thing entirely.

The Broken Abstraction: Signatures vs. Provenance

The core abstraction that breaks here is the idea that a signature is a statement about the artifact’s origin. It is not. A signature is a statement that the holder of the private key approved the artifact. The holder of the private key is usually a machine, not a human, and the machine does not know whether the artifact is the result of a legitimate build or a compromised one.

Provenance attestation is supposed to fix this. The idea is that the build system records what source revision was used, what toolchain was used, what dependencies were pulled, and what commands were run. The artifact is then signed along with this provenance data. In theory, a consumer can verify that the artifact corresponds to a known source revision and a known build process. In practice, the provenance data is only as trustworthy as the system that generated it. If the build system is compromised, the provenance data is compromised too.

This is the same problem that reproducible builds try to solve from a different angle. A reproducible build is one where the same source revision and the same toolchain produce a byte-for-byte identical artifact, regardless of where the build is run. This makes it possible to detect tampering by comparing artifacts from independent builders. But reproducible builds are hard to achieve in practice, especially for firmware and embedded targets where the toolchain is often proprietary, the build process is not documented, and the output is not deterministic. The vendors claim reproducibility, but the claims rarely survive contact with a real build environment.

What the Vendors Claim

Vendors love to talk about secure boot, signed firmware, and hardware root of trust. These are real mechanisms, and they do provide meaningful protection against runtime tampering. But they do not protect against a compromised build system. If the attacker injects code at build time, the code is signed by the legitimate key, and the secure boot chain will happily load it. The hardware root of trust is not a root of trust in the build process. It is a root of trust in the boot process. Those are different things.

I have seen vendor documentation that describes a “secure development lifecycle” as if it were a technical control. It is not. It is a process document. The actual technical controls are often absent: no hermetic builds, no signed toolchains, no verification of dependencies, no isolation between build stages. The signing key is stored on a CI runner that also runs arbitrary test code. The build script pulls dependencies from a public registry without pinning versions or verifying hashes. The toolchain is installed from a tarball that nobody has audited.

This is not a hypothetical. The 2022 CISA advisory on the XZ Utils backdoor described a supply chain compromise that targeted a widely used compression library. The attacker spent years building trust in the project, then introduced a backdoor into the build process. The backdoor was not in the source code in an obvious way; it was in the build scripts and the test infrastructure. The resulting binaries were signed and distributed by the legitimate maintainers. The attack was caught by accident, not by any systematic control.

The Microarchitectural Angle

For readers of this blog, the interesting question is not whether supply chain attacks happen. It is how they interact with the hardware-enforced mitigations we spend so much time studying. The answer is that they bypass them entirely. A build-time injection is not a runtime exploit. It does not need to defeat ASLR, or bypass CET, or forge a pointer authentication code. It is simply part of the legitimate code. The CPU executes it because the CPU is designed to execute whatever the binary says, and the binary says it is legitimate.

This is why I am skeptical of vendor claims about “hardware-enforced security.” The hardware is not the problem. The problem is the software supply chain that produces the binaries the hardware runs. A secure enclave is only as secure as the code that runs inside it. If that code was compiled by a compromised toolchain, the enclave is compromised. The microarchitectural details do not matter.

There is a deeper point here about the nature of trust. Hardware-enforced mitigations are designed to protect against a particular class of attacks: runtime exploitation of memory corruption vulnerabilities. They do nothing against a build-time injection. The attacker does not need to corrupt memory. They need to corrupt the build process. The result is a binary that is malicious by design, not by accident.

Practical Examples from the Bench

Let me give you a concrete example from my own work. I was extracting firmware from an automotive ECU a while back. The firmware was signed, and the signature verified against a public key stored in the boot ROM. The boot ROM was read-protected, so I had to use fault injection to dump it. That is a hardware problem, and it is the kind of problem this blog usually covers. But once I had the firmware image, I found something more interesting: the build system that produced it had left behind a build path string that included a username and a hostname. The username was “jenkins.” The hostname was an internal CI server. The firmware was built on a Jenkins instance that was probably not isolated from the rest of the corporate network.

That is a supply chain vulnerability hiding in plain sight. The vendor had signed the firmware, but the build environment was a Jenkins server with a predictable username and an internal hostname. If an attacker had compromised that Jenkins server, they could have injected code into the firmware, and the signature would have been valid. The hardware root of trust would have loaded it without complaint. The only reason I noticed the build path string is that I was looking for clues about the build process, not because the vendor had disclosed anything about it.

Another example: I was working on a UEFI module for a laptop. The module was signed, and the signature verified against the platform key. But the build script that produced the module pulled in a precompiled object file from a third-party vendor. The object file was not signed, not hashed, and not documented. It was just a blob that got linked into the final image. If that blob had been malicious, the signature on the final image would have been valid. The platform key would have trusted it. The secure boot chain would have loaded it. The hardware would have executed it.

These are not exotic attacks. They are the result of treating the build system as a black box that produces trustworthy output. The trust is misplaced. The build system is not a black box. It is a collection of scripts, tools, and dependencies that are all subject to compromise.

What Actually Works

If you want to defend against supply chain attacks on build systems, you need to start with the assumption that the build system is compromised. That is the only safe assumption. From there, you can design controls that limit the damage.

The first control is hermetic builds. A hermetic build is one that does not depend on anything outside a declared set of inputs. The toolchain is pinned, the dependencies are pinned, the build script is pinned, and the environment is isolated. This makes it harder for an attacker to inject code through a dependency or a toolchain update. It also makes the build reproducible, which is a prerequisite for independent verification.

The second control is provenance attestation. This is not a silver bullet, but it is better than nothing. The idea is to record what went into the build and sign that record along with the artifact. The record is only as trustworthy as the system that generated it, but if the system is isolated and the record is independently verifiable, it can catch some attacks. The key is to make the provenance data useful, not just a JSON blob that nobody reads.

The third control is independent verification. This is the hardest one, but it is the most effective. If you can build the same source revision on an independent system and compare the output, you can detect tampering. This is what reproducible builds are for. It is not easy, especially for firmware and embedded targets, but it is the only control that actually catches a compromised build system. Everything else is just making the attack harder.

There is a fourth control that is often overlooked: treat the build system as a production system. That means access controls, network segmentation, audit logging, and incident response. The build system is not a development tool. It is the thing that produces the artifacts you ship. If you would not let a developer run arbitrary code on a production server, you should not let them run arbitrary code on a build server.

The Vendor Abstraction Problem

The reason supply chain attacks keep working is that vendors keep selling abstractions that do not hold. “Secure boot” is an abstraction. “Hardware root of trust” is an abstraction. “Signed firmware” is an abstraction. These abstractions are useful, but they are not complete. They protect against runtime tampering, not build-time injection. The vendors know this, but they do not talk about it because it is not a problem they can solve with a marketing slide.

The same is true of “reproducible builds.” The vendors claim reproducibility, but the claims are often aspirational. A build is reproducible only if the toolchain is deterministic, the dependencies are pinned, and the environment is controlled. Most firmware builds are none of those things. The toolchain is a proprietary compiler with undocumented behavior. The dependencies are pulled from a vendor portal that does not provide hashes. The environment is a developer’s laptop with a random set of packages installed. The result is a build that is reproducible only in the sense that it produces the same output on the same machine on the same day.

I am not saying these abstractions are useless. They are useful. But they are not sufficient. The problem is that they are sold as sufficient, and the people who buy them do not ask the hard questions. The hard question is not “is the firmware signed?” The hard question is “what produced the firmware, and can I trust that process?”

What This Means for Firmware Extraction and Analysis

For those of us who spend our time extracting firmware from locked-down devices, supply chain attacks are both a threat and an opportunity. They are a threat because the firmware we extract may already be compromised. They are an opportunity because the build system is often the weakest link in the chain, and the artifacts it leaves behind can be a goldmine of information.

Build path strings, usernames, hostnames, toolchain versions, dependency hashes, and CI configuration files are all clues about the build environment. They can tell you who built the firmware, where it was built, and what tools were used. They can also tell you whether the build environment was isolated or exposed. If you are doing firmware analysis, these clues are worth more than a thousand hours of disassembly. They tell you where to look.

This is a topic I plan to return to. The next logical step is a deep dive into reproducible builds for firmware, with a focus on the specific challenges of embedded toolchains and the ways vendors fail to meet their own claims. If you have a firmware image with a suspicious build path string, or a vendor that claims reproducibility but does not deliver, I would like to hear about it. The bench is always open.

Frequently Asked Questions

Why do attackers target build systems instead of runtime vulnerabilities?

Build systems are softer targets than runtime environments. They are often less monitored, less isolated, and less understood by the people who run them. A successful build system compromise produces a signed, legitimate-looking artifact that bypasses runtime mitigations entirely. The attacker does not need to defeat ASLR, CET, or pointer authentication because the malicious code is part of the legitimate binary. The hardware will execute it without complaint.

Does secure boot protect against supply chain attacks?

No. Secure boot verifies that the firmware or bootloader is signed by a trusted key. It does not verify that the signed artifact is the result of a legitimate build process. If the build system is compromised, the attacker can inject code into the artifact before it is signed. The signature is valid, the secure boot chain is satisfied, and the malicious code runs. Secure boot protects against runtime tampering, not build-time injection.

What is the difference between a signature and provenance attestation?

A signature is a cryptographic statement that the holder of a private key approved an artifact. It says nothing about how the artifact was produced. Provenance attestation is a record of the build process: what source revision was used, what toolchain was used, what dependencies were pulled, and what commands were run. The provenance record is signed along with the artifact. In theory, this gives consumers a way to verify that the artifact corresponds to a known build process. In practice, the provenance record is only as trustworthy as the system that generated it.

Are reproducible builds a practical defense for firmware?

Reproducible builds are the most effective defense against build system compromise, but they are hard to achieve for firmware and embedded targets. The toolchain is often proprietary, the build process is not documented, and the output is not deterministic. Vendors claim reproducibility, but the claims rarely survive contact with a real build environment. Independent verification is the goal, but it requires a level of discipline that most firmware teams do not have.

If you want to dig deeper into the hardware side of this problem, the next article will look at how fault injection can be used to extract boot ROMs from read-protected microcontrollers, and what that means for the trust model of secure boot. The build system is where trust is manufactured. The boot ROM is where it is enforced. Both are worth understanding.

eBPF is a kernel-resident virtual machine that lets you attach sandboxed programs to tracepoints, kprobes, uprobes, and a growing set of LSM hooks without loading a kernel module. It sits adjacent to the same machinery that enforces CET shadow stacks, PAC return-address signing, and MTE tag checks, but it does not magically inherit their guarantees. For anyone doing low-level vulnerability research on x86-64 or ARM64, eBPF is less a security product and more a way to inspect what the kernel, scheduler, and compiler-generated code actually do before an abstraction layer lies to you.

This guide is for people who already distrust vendor claims about runtime visibility. It covers what eBPF can observe, where its isolation model breaks down, and how to use it as an instrumentation tool rather than a replacement for hardware-enforced control-flow integrity.

What eBPF Actually Is

eBPF is an in-kernel register-based VM with a verifier that attempts to prove memory safety and termination before a program is JIT-compiled to native x86-64 or ARM64 instructions. The verifier is the interesting part: it performs abstract interpretation over the eBPF instruction stream, tracks register types, and rejects programs that could read arbitrary kernel memory or loop indefinitely. In practice, the verifier is a large C program with a long history of privilege-escalation bugs, which should temper any claim that eBPF is inherently safe.

The execution model is event-driven. You attach a program to a hook, the kernel invokes it when the event fires, and the program can read a limited context structure, update maps, and in some cases modify the event’s outcome. The hooks that matter for security monitoring are:

• Tracepoints — static markers in the kernel source, such as sys_enter_execve or sched_process_exec.
• kprobes/kretprobes — dynamic probes on kernel function entry and return, useful for functions that lack tracepoints.
• LSM hooks — security module callbacks that can deny operations, not just observe them.
• Network hooks — XDP, TC, and socket filters that see packets before or after the network stack.

Each hook exposes a different slice of kernel state. A tracepoint gives you a stable ABI-ish structure. A kprobe gives you raw register state and a function name. An LSM hook gives you the ability to block. Conflating these is how vendor marketing produces nonsense like “full kernel visibility.”

Why Security Teams Adopt eBPF

The standard pitch is that eBPF replaces kernel modules, auditd, and ptrace-based monitoring with lower overhead and fewer stability risks. There is some truth to that. A well-written eBPF program attached to a tracepoint can run in microseconds, and the verifier prevents the most obvious crashes that plague out-of-tree kernel modules.

But the real reason security teams adopt eBPF is that it gives them a programmable filter in the kernel. Instead of shipping every syscall event to userspace and filtering there, you can filter in the kernel, aggregate in maps, and only wake userspace when something interesting happens. That is a genuine architectural improvement over auditd, which is essentially a syscall-level firehose with a userspace parser.

For low-level researchers, eBPF is also a cheap way to instrument kernel behavior without rebuilding the kernel or fighting with ftrace’s limited scripting. You can attach a kprobe to copy_from_user, record the size and destination, and correlate that with page-fault activity. You can trace do_mmap and see exactly what the dynamic linker is doing. You can watch flush_icache_range on ARM64 and catch JIT code generation in real time.

The Isolation Model Is Not a Security Boundary

Here is where vendor claims need scrutiny. eBPF programs run in kernel context, but they are not isolated from the kernel in any hardware-enforced sense. The verifier is a software gate. If the verifier has a bug, or if the JIT compiler emits incorrect native code, the eBPF program can read or write arbitrary kernel memory. This has happened repeatedly.

On x86-64, the JIT compiler emits native code that runs with the kernel’s normal privilege level. There is no separate page table, no ring transition, and no CET shadow stack for eBPF programs unless the kernel explicitly enables it. On ARM64, the situation is similar: eBPF JIT output runs at EL1, and PAC is not automatically applied to eBPF-generated code. If you are relying on eBPF as a security boundary, you are relying on a C program that has been wrong before.

The correct mental model is that eBPF is a constrained execution environment, not a sandbox. It reduces the attack surface of kernel instrumentation, but it does not eliminate it. Anyone who tells you otherwise is selling something.

What eBPF Can Actually See

Let’s be concrete. Here is what eBPF can observe at each major hook type, and what it cannot.

Syscall Tracepoints

Attaching to sys_enter_execve gives you the filename, argv, and envp pointers. You can read the filename string with bpf_probe_read_user or bpf_probe_read_kernel, depending on the kernel version. You can record the process’s PID, UID, and cgroup. You cannot see the file’s contents, the ELF headers, or what the process will do after execve returns. You also cannot see syscalls that bypass the tracepoint, such as direct int 0x80 invocations on x86-64, which still work and still hit the syscall table but may not trigger the same tracepoint path in all kernel versions.

kprobes on Memory Management

A kprobe on do_mmap or __vmalloc shows you the requested size, flags, and protection bits. This is useful for detecting JIT spraying, where an attacker allocates executable memory and fills it with shellcode. But a kprobe only sees the function entry and exit. It does not see the page-table walk, the TLB flush, or the actual physical page allocation. On ARM64 with MTE enabled, a kprobe does not see the tag assignment unless you also probe the MTE-specific functions, which are not always exported.

LSM Hooks

LSM hooks are the only eBPF attachment points that can deny an operation. A program attached to file_open can return -EPERM and block the open. This is powerful, but it is also a policy enforcement point, not an observation point. If you use LSM hooks for monitoring, you are changing kernel behavior, and that has consequences for stability and correctness. A buggy LSM program can prevent the system from booting or lock out legitimate processes.

Network Hooks

XDP programs see packets before the network stack allocates an skb. This is the lowest-overhead packet filtering point in the kernel. You can drop, redirect, or modify packets at line rate on many NICs. But XDP does not see TCP state, connection tracking, or application-layer data without additional parsing. TC hooks see packets after the stack has done some work, which means more context but also more overhead.

Where eBPF Breaks Down

eBPF’s limitations are not always obvious from the documentation. Here are the ones that matter for security monitoring.

Verifier Complexity

The verifier is a multi-thousand-line C program that attempts to prove properties about eBPF bytecode. It has known limitations: it cannot handle loops with variable bounds, it has a maximum instruction count, and it rejects some programs that are actually safe. This means you will spend time restructuring code to satisfy the verifier, and you will occasionally hit verifier bugs that cause false positives or false negatives. The verifier is also version-dependent: a program that passes on Linux 6.1 may fail on 6.6 because the verifier’s analysis changed.

Spectre Mitigations

On x86-64, the kernel applies Spectre mitigations to eBPF programs, including retpolines and, on some CPUs, eIBRS. This adds overhead and changes the native code that the JIT emits. If you are trying to measure exact instruction counts or cache behavior, eBPF is not a clean instrument. The JIT output is also affected by the kernel’s hardening options, such as CONFIG_BPF_JIT_ALWAYS_ON and CONFIG_RETPOLINE.

ARM64 PAC and BTI

On ARM64, the kernel can enable pointer authentication and branch target identification for eBPF JIT output, but this is not universal. Some kernels disable PAC for eBPF because the verifier does not model PAC correctly. If you are researching PAC bypasses, eBPF is not a reliable way to test them. The JIT output may or may not have PAC instructions, and the verifier may reject programs that manipulate pointers in ways that PAC would otherwise protect.

Map Semantics

eBPF maps are the shared memory between eBPF programs and userspace. They are not coherent with the CPU cache in the way you might expect. On x86-64, map updates use atomic operations, but the memory ordering is not always what you want. On ARM64, the kernel uses stlr and ldar for some map operations, but not all. If you are using eBPF to detect race conditions or memory-ordering bugs, you need to understand the exact instructions the JIT emits for map access.

Practical Examples for Low-Level Researchers

Here are three concrete use cases that fit this blog’s focus.

Detecting JIT Code Generation

Attach a kprobe to bpf_int_jit_compile on x86-64 or bpf_jit_compile on ARM64. Record the program’s instruction count and the address of the JIT output. Correlate that with do_mmap calls that request PROT_EXEC. This gives you a timeline of when executable memory is allocated and when code is written to it. It does not give you the code itself, but it narrows the search space for JIT spraying.

Tracing Page-Fault Handling

Attach a kprobe to do_page_fault and record the faulting address, the error code, and the current process. On x86-64, the error code tells you whether the fault was a protection violation or a not-present fault. On ARM64, the equivalent is do_mem_abort, which gives you the fault status register. This is useful for detecting attempts to probe kernel memory from userspace, which is a common first step in privilege-escalation exploits.

Monitoring Firmware Extraction Attempts

On embedded devices, firmware extraction often involves reading from /dev/mem or a baseband-specific device node. Attach an LSM hook to file_open and filter for paths that match /dev/mem or /dev/kmem. Record the PID, UID, and parent process. This does not prevent the read, but it gives you an audit trail. If you want to block the read, you can return -EPERM from the LSM hook, but be prepared for the device to misbehave if a legitimate process needs that access.

Tooling That Does Not Suck

The eBPF tooling ecosystem is fragmented, but a few tools are worth using.

• bpftrace — a high-level tracing language that compiles to eBPF. Good for quick experiments, but the abstraction leaks when you need precise control over the generated code.
• libbpf — the C library for loading eBPF programs. This is the lowest-level stable interface, and it is what you should use for production monitoring.
• cilium/ebpf — a Go library that generates eBPF programs from Go code. Useful if you are already in a Go environment, but the generated code is not always what you expect.
• bpftool — the Swiss Army knife for inspecting loaded programs, maps, and JIT output. Use bpftool prog dump jited to see the native instructions.

For low-level work, bpftool prog dump jited is essential. It shows you the exact x86-64 or ARM64 instructions that the JIT emitted, which is the only way to verify that the verifier’s model matches reality.

Vendor Claims vs. Reality

Several commercial products claim to use eBPF for “runtime security” or “zero-trust workload protection.” The marketing usually omits the following:

• eBPF programs run with kernel privileges. A verifier bug is a kernel bug.
• eBPF does not see everything. It sees what the hooks expose, and the hooks are not comprehensive.
• eBPF overhead is not zero. The verifier adds compile-time overhead, and the JIT output adds runtime overhead. On some workloads, the overhead is measurable.
• eBPF is not a replacement for hardware-enforced mitigations. CET, PAC, and MTE operate at a different level of the stack. eBPF can observe some of their effects, but it cannot enforce them.

If a vendor claims their eBPF agent provides “complete visibility,” ask them to show the kprobe that sees a PAC authentication failure on ARM64. There is not one, because PAC failures are handled by the hardware before the kernel’s exception handler runs, and the exception handler does not expose the failed authentication context to eBPF.

What to Build Next

If you are setting up eBPF monitoring on your own systems, start with syscall tracepoints and a small set of kprobes on memory-management functions. Use bpftool prog dump jited to verify the JIT output. Do not trust the verifier blindly; read the generated native code and look for places where the verifier’s assumptions might not hold.

For this blog, the natural next step is a deep dive into the eBPF verifier’s abstract interpretation algorithm, with a focus on the register-state tracking that prevents out-of-bounds reads. That is a topic that deserves its own article, and it connects directly to the microarchitectural focus of this site.

FAQ

Can eBPF detect Spectre or Meltdown attacks?

Not directly. Spectre and Meltdown are microarchitectural attacks that exploit speculative execution. eBPF programs run after speculation has been resolved, so they cannot see the transient execution window. What eBPF can do is detect the effects of a Spectre attack, such as unusual cache-access patterns or attempts to read kernel memory from userspace. But that is indirect evidence, not direct observation.

Is eBPF safe to run on production systems?

It depends on what you mean by safe. The verifier prevents most memory-safety bugs, but it is not a formal proof. The JIT compiler has had bugs that produced incorrect native code. The kernel’s eBPF subsystem has had privilege-escalation vulnerabilities. If you are running eBPF on a production system, you are accepting a small but nonzero risk of kernel compromise. For most security-monitoring use cases, that risk is acceptable. For high-assurance systems, it may not be.

How does eBPF interact with CET, PAC, and MTE?

On x86-64, eBPF JIT output is subject to the same CET shadow-stack and IBT enforcement as other kernel code, but only if the kernel is built with those options. On ARM64, PAC and BTI for eBPF JIT output are optional and not always enabled. MTE operates at the memory-tag level and is orthogonal to eBPF; eBPF programs do not see MTE tags unless they explicitly probe the MTE-specific kernel functions. In general, eBPF does not weaken these mitigations, but it does not strengthen them either.

What is the difference between eBPF and kernel modules for security monitoring?

A kernel module has full access to kernel memory and can do anything the kernel can do. eBPF is constrained by the verifier and the hook definitions. A kernel module can crash the kernel with a single bad pointer dereference. eBPF is supposed to prevent that, but the verifier is not perfect. The practical difference is that eBPF programs are easier to load and unload, do not require kernel headers, and are less likely to cause a kernel panic. But they are also less capable. If you need to hook a function that has no tracepoint or kprobe-accessible path, a kernel module may be your only option.

eBPF (extended Berkeley Packet Filter) lets you run sandboxed programs inside the kernel without loading a module or touching source code. For security monitoring, that sounds like a clean win: deep visibility into syscalls, network flows, and file access, all wrapped in a verifier that promises safety. But if you’ve spent any time staring at CPU pipeline diagrams or pulling apart baseband firmware, you know that “safety” is a contract written in sand. The real question isn’t whether eBPF can spot an attack. It’s whether the monitoring infrastructure itself becomes the most reliable pivot point for someone who understands speculative execution, cache coherency, and the gap between what the verifier proves and what the silicon actually does.

This article picks apart eBPF-based security monitoring through the lens of microarchitectural attack surface, kernel memory management, and the compiler toolchains that turn C into verified eBPF bytecode. We’ll look at where the verifier’s formal model diverges from physical reality, how JIT-compiled eBPF programs interact with CPU mitigations, and why the current generation of eBPF security products may be handing attackers the very primitives they claim to detect.

The eBPF Architecture Model vs. Microarchitectural Reality

eBPF programs run inside a lightweight virtual machine in the Linux kernel. Before execution, the verifier performs static analysis to prove termination, memory safety, and the absence of out-of-bounds accesses. Then the program is JIT-compiled to native x86-64 or ARM64 instructions. Security monitoring tools—Falco, Cilium, Tracee, and various commercial EDR products—use eBPF probes attached to kprobes, tracepoints, or syscall entry points to watch system behavior.

The verifier’s safety guarantees rest on a CPU model that excludes speculative execution, cache side channels, and branch prediction state. This is the same class of abstraction failure that gave us Spectre, Meltdown, and their variants. When an eBPF program is JIT-compiled to native code, it emits real x86-64 or ARM64 instructions that interact with the branch predictor, fill cache lines, and occupy entries in the BTB (Branch Target Buffer) and RSB (Return Stack Buffer)—all shared resources on SMT cores.

The Verifier’s Blind Spot: Speculative Execution Paths

The eBPF verifier proves properties about architectural execution—the path the program takes when branch conditions resolve correctly. It does not, and architecturally cannot, reason about speculative execution paths where the CPU guesses a branch direction and executes instructions transiently. A JIT-compiled eBPF program that does a bounds check followed by a memory access looks safe to the verifier. But on a core vulnerable to Spectre v1, an attacker controlling the unchecked input can train the branch predictor to mispredict the bounds check, causing speculative access to out-of-bounds memory.

This isn’t a thought experiment. Researchers have shown that eBPF programs can be used as speculative execution gadgets. The verifier’s own analysis routines run in kernel context and can be influenced by unprivileged users—a fact documented in CVE-2021-33624 and related vulnerabilities. When you deploy an eBPF-based security monitor, you’re adding verified-but-speculatively-unsafe code to a kernel that may already be running with SMT enabled and mitigations turned off for performance.

JIT Compilation and the Transient Execution Window

The eBPF JIT compiler translates verified bytecode into native instructions. On x86-64, that means emitting actual mov, call, and ret instructions that interact with the CPU’s front-end, execution units, and memory subsystem. Each JIT-compiled eBPF program becomes a sequence of native instructions that can:

• Occupy BTB entries, potentially evicting entries used by kernel mitigation code
• Generate speculative loads that fill cache lines, creating measurable timing differences
• Execute transient instructions under misprediction that leave microarchitectural state changes

On ARM64 systems with Pointer Authentication (PAC), the situation gets more tangled. eBPF programs running with PAC enabled must handle signed return addresses. The verifier doesn’t model PAC signing or authentication—it sees abstract eBPF instructions, not the PACIASP and AUTIASP instructions the JIT compiler emits. A JIT-compiled eBPF program that corrupts a signed pointer won’t be caught by the verifier; it’ll be caught by a PAC authentication failure at runtime. But that failure generates a fault that may be observable through timing or other side channels, potentially leaking information about the corrupted pointer’s value.

eBPF Security Monitors as Attack Surface

Security monitoring tools that use eBPF typically load multiple programs into the kernel: syscall probes, network filters, file integrity watchers. Each loaded program is a potential gadget. The more comprehensive the monitoring, the larger the attack surface. This creates an uncomfortable trade-off: the very instrumentation meant to detect attacks may provide the primitives needed to construct them.

Map Leakage and Covert Channels

eBPF maps are shared memory regions between kernel and userspace. Security monitors use them to pass event data to userspace agents. While maps have access controls, the timing of map operations can create covert channels. A compromised userspace process with access to an eBPF map can observe:

• Map update frequency, revealing system call patterns of other processes
• Map lookup latency, potentially exposing kernel data structure states
• Map eviction behavior, leaking information about kernel memory pressure

These channels are low-bandwidth but can be enough to leak cryptographic key material or ASLR randomization bits. The eBPF verifier explicitly permits bounded loops since Linux 5.3, which means timing side channels through loop iteration counts are now verifier-approved in certain configurations.

Kernel Stack Probing via eBPF

eBPF programs can access limited kernel stack data through helper functions like bpf_get_stackid() and bpf_get_stack(). These helpers return stack trace information that includes return addresses—the very values that KASLR (Kernel Address Space Layout Randomization) attempts to hide. While the returned addresses are hashed or masked in some configurations, the raw values may be recoverable through repeated sampling and statistical analysis, especially on kernels with limited entropy in their KASLR implementation.

On ARM64 systems with PAC, stack return addresses are signed. But the eBPF helper returns the raw signed pointer, not the authenticated value. An attacker who can observe these signed pointers and trigger controlled PAC authentication failures can potentially forge valid signed pointers—a technique that has been demonstrated in academic research against userspace PAC but has clear kernel-space implications.

Firmware-Level eBPF: The Hidden Frontier

While most eBPF discussion focuses on the Linux kernel, eBPF is increasingly appearing in firmware contexts. UEFI firmware can include eBPF-based network drivers. Embedded baseband processors in mobile devices are exploring eBPF for packet filtering. These environments lack the mature verifier implementations of mainline Linux and often run on CPUs with different microarchitectural characteristics.

Consider a smartphone baseband processor running a lightweight RTOS with an eBPF interpreter for network packet filtering. The interpreter may not implement all verifier checks, especially those related to speculative execution. A crafted packet that triggers an eBPF program could exploit microarchitectural side channels in the baseband CPU—a CPU that typically has direct DMA access to application processor memory. This isn’t theoretical; baseband-to-AP attacks have been demonstrated using other vectors, and eBPF provides a convenient programmable interface.

Verifier Divergence Across Kernel Versions

The eBPF verifier is not a static specification; it evolves with each kernel release. A program that passes verification on kernel 5.15 may fail on 6.1 due to stricter checks, or—more concerning—a program that fails on 6.1 may pass on a vendor kernel with backported features but incomplete verifier updates. Android OEMs are notorious for shipping kernels with cherry-picked eBPF features that don’t include the corresponding verifier improvements.

This creates a fragmentation problem: security monitoring tools that rely on eBPF must target the lowest-common-denominator verifier, which means they can’t use newer safety features. Or they must maintain per-kernel-version program variants, which increases complexity and the risk of deploying a variant with insufficient safety checks.

Practical Recommendations for the Skeptical Engineer

If you’re deploying eBPF-based security monitoring, here are concrete steps to reduce the risk of your monitoring becoming the attack vector:

• Disable SMT on security-critical hosts. Simultaneous multithreading is the primary enabler of cross-thread microarchitectural attacks. If you’re running eBPF programs that access sensitive kernel data, SMT effectively gives an attacker a co-resident thread on the same physical core.
• Audit eBPF map access patterns. Monitor which userspace processes have read access to eBPF maps. A process with CAP_BPF or CAP_SYS_ADMIN that shouldn’t need map access is a red flag.
• Pin eBPF programs to specific cores. If your monitoring workload can be isolated to dedicated cores, you reduce the microarchitectural attack surface. This is especially relevant on ARM64 big.LITTLE systems where core types have different speculative execution behaviors.
• Verify the verifier. Run your eBPF programs through multiple kernel versions’ verifiers in a CI pipeline. Flag any program that passes on an older verifier but fails on a newer one—it may be exploiting a verifier bug.

FAQ

Does eBPF’s verifier guarantee that a program is safe against all attacks?

No. The verifier proves safety within its formal model, which covers memory access bounds, loop termination, and instruction validity. It does not model CPU speculative execution, cache timing, branch predictor state, or other microarchitectural behaviors. A program that passes verification can still be used as a gadget in Spectre-type attacks or leak information through timing side channels. The verifier is a necessary but insufficient safety mechanism.

How does eBPF JIT compilation affect security on ARM64 systems with Pointer Authentication?

On ARM64 systems with PAC enabled, the JIT compiler emits PACIASP and AUTIASP instructions to sign and authenticate return addresses. However, the verifier operates on eBPF bytecode and has no visibility into these PAC instructions. A JIT-compiled eBPF program that corrupts a signed pointer will trigger a PAC authentication fault, which may be observable through timing or other channels. Additionally, eBPF helper functions that return kernel pointers (like bpf_get_stack()) may expose signed pointer values that an attacker can use to forge valid PAC signatures.

Can eBPF-based security monitoring tools be used to bypass CET (Control-flow Enforcement Technology)?

Indirectly, yes. CET’s shadow stack protects return addresses, but eBPF programs that run in kernel context can access and modify memory through helper functions. If an attacker compromises a userspace process that has access to eBPF maps, they may be able to influence kernel execution flow by manipulating map contents that are consumed by eBPF programs. Additionally, eBPF programs themselves are JIT-compiled to native code and placed in kernel memory; if an attacker can locate and modify that memory (through a separate kernel vulnerability), they can bypass CET protections for the eBPF program’s execution.

What are the risks of using eBPF for security monitoring on systems with MTE (Memory Tagging Extension)?

MTE assigns 4-bit tags to memory allocations and checks them on access. eBPF programs that access kernel memory through helpers like bpf_probe_read() may interact with MTE-tagged memory in ways the verifier doesn’t anticipate. If an eBPF program reads MTE-tagged memory and the tag check fails, the resulting fault could be observable from userspace, creating a side channel. Additionally, eBPF maps themselves are kernel allocations that may or may not be MTE-tagged depending on the kernel configuration—inconsistent tagging can create information leaks between eBPF programs and other kernel subsystems.

Introduction: The Promise and the Illusion

eBPF gets pitched as a cure-all for security monitoring—a way to peer into the kernel without kernel modules, trace syscalls, inspect network packets, and enforce access control, all from the safety of a sandboxed virtual machine. The marketing suggests a transparent, unbypassable observability layer. The reality, as anyone who has spent time staring at x86-64 or ARM64 disassembly knows, is that eBPF sees what the kernel’s tracing infrastructure allows it to see. That infrastructure is built on a set of abstractions that leak, hide, and sometimes outright lie about what’s happening at the microarchitectural level. This article is for those who need to understand the gap between the eBPF sales pitch and the silicon truth—specifically, how speculative execution, memory ordering, and hardware design decisions create blind spots that no BPF program can illuminate.

What eBPF Actually Sees: The Tracepoint and Kprobe Model

eBPF programs attach to predefined hooks: tracepoints, kprobes, uprobes, and USDT probes. These hooks fire when the kernel’s instrumented code paths execute. For security monitoring, the most common attachment points are syscall entry/exit tracepoints and kprobes on security-sensitive functions like cap_capable or selinux_file_permission. The eBPF program receives a fixed set of arguments—register values, stack pointers, or tracepoint-specific fields—and can make a decision based on that data.

The problem is that these hooks are placed at the software-visible boundary. They capture the architectural state: the values in rax or x0, the contents of the sockaddr struct, the pathname string. They do not capture what the CPU did speculatively before the hook fired, nor do they reveal what the memory controller reordered behind the scenes. If you’re monitoring for unauthorized memory access, you’re relying on the kernel’s page fault handler to trigger a tracepoint. But speculative execution doesn’t generate page faults; it generates microarchitectural side effects that are invisible to eBPF unless you’re also instrumenting performance counters—and even then, the correlation is noisy.

Speculative Execution: The Elephant in the Trace Buffer

Consider a simple security use case: detecting when a process attempts to read from a protected memory region. You attach an eBPF program to the security_file_open LSM hook or the openat syscall tracepoint. Your program checks the filename against a denylist and drops the event if it matches. This works for overt attempts. It fails completely for Spectre-v1 gadgets that probe the protected file’s contents without ever reaching the hook. The CPU speculatively executes the load, fills the cache, and the attacker recovers the data via a timing side channel. Your eBPF monitor sees nothing because the architectural path—the one that triggers the hook—was never taken.

This isn’t a bug in eBPF; it’s a fundamental limitation of attaching probes to the architectural instruction stream. The verifier ensures your BPF program won’t crash the kernel, but it can’t ensure the kernel’s own code is free of Spectre gadgets. On ARM64, where Pointer Authentication (PAC) adds a cryptographic signature to return addresses, the situation is more layered. A PAC miss triggers an exception, which does create an architectural event. But the speculative window before the exception is still wide enough to leak data, and the exception handler itself may not be instrumented by your eBPF program. You’re monitoring the cleanup, not the crime.

Case Study: Bypassing eBPF-Based File Integrity Monitoring

Imagine an eBPF program attached to the security_file_permission LSM hook, designed to log any attempt to open /etc/shadow for writing. A user-space attacker with knowledge of the CPU’s branch predictor can train the predictor to mispredict the conditional branch that checks the file path. The attacker then triggers a speculative load of the shadow file’s contents into the cache, using a covert channel to exfiltrate the data. The eBPF program never fires because the speculative execution never reaches the LSM hook—it’s squashed by the branch resolution. The only trace is a cache timing perturbation, which eBPF can’t natively capture without custom tracepoint instrumentation that most kernels don’t ship.

This isn’t theoretical. The PACMAN attack against Apple’s M1 demonstrated that PAC-protected return addresses can be brute-forced speculatively, bypassing the architectural exception. An eBPF monitor on the arm64_insn_abort tracepoint would see the PAC miss, but only after the speculative window closed. The damage—a leaked kernel pointer or worse—is already done.

Memory Ordering and the Visibility Problem

Even without speculative execution, eBPF’s view of memory is constrained by the kernel’s memory model. On x86-64, the strong total-store order (TSO) model means that stores appear in program order to all observers. But eBPF programs running on different cores can still see stale data if the kernel code they’re tracing uses WRITE_ONCE without an accompanying memory barrier. The eBPF program reads the value that was visible at the time the tracepoint fired, which may not be the value that another core has already written.

On ARM64, the situation is worse. The weaker memory model allows more aggressive reordering, and eBPF programs inherit the memory ordering of the kernel context they’re attached to. If you’re monitoring a network socket buffer via a kprobe on tcp_sendmsg, the data you read from the sk_buff might not reflect the most recent writes from the DMA engine. The kernel’s dma_wmb() barrier ensures the NIC driver sees the correct data, but that barrier doesn’t guarantee visibility to an eBPF program running on a different core. You’re monitoring a snapshot that’s already out of date.

Kernel Memory Management: The Page Table Blind Spot

eBPF programs can read kernel memory via helper functions like bpf_probe_read_kernel, but they’re still subject to the kernel’s page table mappings. If a page is unmapped from the kernel’s direct map—a common technique for mitigating ret2dir attacks—the eBPF program will trigger a fault and be terminated. This is by design, but it means eBPF can’t monitor the very memory regions that are most interesting from a security perspective: the unmapped pages containing sensitive kernel data.

More insidiously, eBPF programs can’t detect when a page table entry is modified to redirect a virtual address to a malicious physical page. The modification happens via a store to the page table, which is just another memory write from the kernel’s perspective. Unless you’re tracing every set_pte call—which would be prohibitively expensive—you’re blind to page table manipulation. This is a fundamental limitation of monitoring at the software-visible level; the hardware’s memory management unit (MMU) operates below the eBPF instrumentation layer.

Firmware Extraction: When eBPF Can’t Even See the Target

On embedded devices—baseband processors, UEFI firmware, automotive ECUs—eBPF is often touted as a lightweight alternative to kernel modules for extracting firmware. The reality is messier. eBPF requires a running Linux kernel with CONFIG_DEBUG_INFO_BTF and a reasonably modern BPF subsystem. Most embedded devices run stripped, ancient kernels without BTF, or they use proprietary RTOSes where eBPF simply doesn’t exist. Even on Linux-based devices, the firmware is often mapped into memory regions that are explicitly excluded from the kernel’s direct map, making them inaccessible to bpf_probe_read_kernel.

I’ve spent weeks trying to dump baseband firmware from a Qualcomm modem using eBPF, only to discover that the relevant memory regions were behind an SMMU (System Memory Management Unit) that the kernel never mapped. The eBPF program could see the kernel’s view of the world, but the firmware lived in a separate address space, accessible only via a proprietary RPC mechanism. eBPF is a tool for monitoring the kernel’s internal state, not for breaking out of the kernel’s sandbox. If you need to extract firmware from a locked-down device, you’re better off with JTAG, fault injection, or DMA attacks—none of which are observable via eBPF.

Control Flow Integrity: The eBPF Verifier’s Own Blind Spots

eBPF itself is subject to control flow integrity (CFI) enforcement. The verifier ensures that BPF programs don’t contain indirect jumps to arbitrary addresses, and the JIT compiler emits code with hardware CFI support (e.g., Intel CET endbranch instructions). But the verifier’s analysis is static; it can’t account for speculative execution attacks against the BPF program itself. A Spectre-BTB attack could cause a BPF program to speculatively execute a gadget that leaks kernel memory, even though the architectural path is safe. The verifier’s safety guarantees are architectural, not microarchitectural.

On ARM64, the situation is complicated by PAC and BTI (Branch Target Identification). The kernel’s eBPF JIT can emit BTI instructions, but if the CPU speculatively executes a branch before the BTI check, the attacker can still redirect control flow. The hardware mitigations are probabilistic, not absolute. Relying on eBPF for security monitoring means relying on a subsystem that itself is vulnerable to the same microarchitectural attacks you’re trying to detect.

Practical Limitations: Performance and Probe Overhead

Attaching eBPF programs to high-frequency events—every syscall, every network packet—incurs measurable overhead. The verifier’s complexity limits (currently 1 million instructions) prevent deep analysis in a single program. Tail calls and BPF-to-BPF functions help, but they introduce latency and complicate the control flow. On ARM64, the situation is worse: the eBPF JIT is less mature, and some helper functions are not available, forcing fallback to the slower interpreter.

For security monitoring, this means you can’t simply attach a comprehensive eBPF program to every kernel function. You must choose a subset, which creates coverage gaps. An attacker who understands your eBPF policy can route their activity through unmonitored code paths. This is not a theoretical concern; it’s the same cat-and-mouse game that has plagued syscall monitoring since the days of strace evasion.

What eBPF Gets Right (and Why It Still Matters)

Despite these limitations, eBPF is a powerful tool when used with a clear understanding of its boundaries. It excels at monitoring the kernel’s architectural state: syscall arguments, network packet headers, file operations. It can enforce security policies at LSM hooks with minimal overhead. It can capture performance events and correlate them with system activity. The key is to treat eBPF as a supplementary mechanism, not a silver bullet. Pair it with hardware performance counters, firmware integrity checks, and microarchitectural side-channel detection to build a more complete picture.

For example, you can use eBPF to monitor perf_event_open calls and detect when a process is setting up a cache timing attack. Combine that with PEBS (Precise Event-Based Sampling) on Intel or SPE (Statistical Profiling Extension) on ARM to catch the speculative execution patterns that eBPF misses. This hybrid approach acknowledges that the kernel’s view is incomplete and compensates with hardware-level telemetry.

FAQ

Can eBPF detect Spectre or Meltdown attacks?

Not directly. eBPF operates on architectural events—syscalls, tracepoints, kprobes—while Spectre and Meltdown exploit microarchitectural side channels that leave no architectural trace. You can use eBPF to monitor for suspicious cache timing activity (e.g., frequent perf_event_open calls with precise event selection), but this is a heuristic, not a detection mechanism. The actual speculative execution happens below eBPF’s visibility threshold.

Is eBPF a viable replacement for kernel modules in security monitoring?

In many cases, yes—but with caveats. eBPF avoids the stability and security risks of loading custom kernel modules, and the verifier provides strong safety guarantees. However, eBPF programs are limited in what they can access: no arbitrary kernel memory, no direct hardware access, and no modification of kernel data structures. If your monitoring requires deep kernel introspection or hardware interaction, a kernel module may still be necessary. The tradeoff is safety versus capability.

How does eBPF handle ARM64 Pointer Authentication (PAC)?

eBPF itself doesn’t interact with PAC directly. The kernel’s eBPF JIT can emit PAC instructions to protect the BPF program’s control flow, but this is transparent to the eBPF developer. From a monitoring perspective, PAC adds complexity: a PAC miss generates an exception that eBPF can trace, but the speculative execution before the exception is still a blind spot. If you’re monitoring for control flow attacks, you need to correlate PAC miss exceptions with other signals—cache misses, branch mispredictions—to catch the speculative window.

Can eBPF be used to extract firmware from locked-down devices?

Rarely. eBPF requires a running Linux kernel with BTF support, which is absent from most embedded devices. Even when present, firmware is often mapped outside the kernel’s direct map or behind an IOMMU/SMMU, making it inaccessible to bpf_probe_read_kernel. For firmware extraction, you’re better off with hardware-level techniques: JTAG, SPI flash dumping, or fault injection. eBPF is a kernel observability tool, not a hardware hacking tool.

Conclusion: Trust, but Verify at the Microarchitectural Level

eBPF is a remarkable piece of engineering that has transformed kernel observability. But it’s not magic. It sees what the kernel’s instrumentation points expose, and those points are designed for the common case, not for the adversarial microarchitectural edge cases that define modern security research. If you’re building a security monitoring system on eBPF, understand its limitations: speculative execution, memory ordering, page table manipulation, and firmware isolation all create blind spots that no amount of BPF code can eliminate. Use eBPF as one layer in a defense-in-depth strategy, and always ask yourself: what is the hardware actually doing right now, and how much of it can I really see?

Binary protocols hold together the quiet guts of embedded systems—firmware updates, proprietary radio links, locked-down bootloaders. Vendors ship these things assuming the obscurity of a custom wire format and some tight parsing will keep attackers out. I’ve yet to meet a binary protocol parser that didn’t break when you pointed a well-tuned fuzzer at it. The problem? Off-the-shelf tools like AFL or libFuzzer are built for flat files and syscall interfaces. They stumble hard on stateful, length-delimited, checksummed protocols. This piece walks through building a custom mutation-based fuzzer that respects the protocol’s structure enough to get past the boring checks—and then twists the semantics to trigger the kind of bugs that make a vendor’s “secure by design” claim look hollow.

Why Generic Fuzzers Miss the Mark

Coverage-guided fuzzers treat input as a flat buffer. A binary protocol parser doesn’t. It reads a length byte, grabs exactly that many bytes, checks a type field, validates a CRC. If your fuzzer flips a bit in the length field without adjusting the payload, the packet gets rejected at a boundary check. The parser’s deeper logic—the part that actually handles the command—never runs. You’re stuck fuzzing the error path, not the state machine. Worse, many embedded parsers live on bare-metal or an RTOS where you can’t just recompile with instrumentation. You need a fuzzer that speaks the protocol’s language: one that generates mostly valid packets but occasionally slips in a length that wraps an integer, a type tag that doesn’t match the payload, or a checksum that’s correct for the wrong reasons.

Modeling the Protocol as a Mutable Tree

Start by capturing traffic with a logic analyzer—I use a Saleae Logic Pro 16 for SPI and UART sessions. Parse the raw bytes into a tree of typed fields: magic, length, sequence, command ID, payload, CRC. Each field gets a type and constraints. The fuzzer doesn’t mutate raw bytes; it mutates the tree. It can replace a length field with a value that’s valid but inconsistent with the payload size. It can splice a payload from a different session. It can flip a command ID to one that’s only valid after authentication. After mutating, the tree serializer recalculates the CRC so the packet passes the first line of defense. This gets you past the boring checks and into the parser’s actual logic, where the real bugs live.

State Awareness

Most binary protocols are stateful. You can’t just fire a single mutated packet and expect to hit deep code. The fuzzer needs a model of the protocol’s state machine. I implement this as a Python class that tracks the current state and prepends the necessary setup sequence before each test case. To fuzz a flash-write command on a microcontroller bootloader, the fuzzer first sends the unlock sequence, then the erase command, then the mutated write packet. It also deliberately violates state transitions—sending a write before the unlock—to see if the parser’s state tracking has holes. Those holes are where the best bugs hide: a buffer overflow that only triggers when a command arrives out of sequence, or a use-after-free when the parser resets state mid-handshake.

Coverage Without Recompilation

On x86-64, you can get basic block coverage without touching the target binary. I run proprietary firmware inside a minimal QEMU system emulation and parse the execution trace with a Python script that maps instruction pointers to basic blocks. It’s coarse—block-level, not edge-level—but it’s enough to guide mutations. For ARM64 targets, CoreSight ETM trace works if the SoC exposes it, though many cheap microcontrollers don’t. When trace hardware is absent, I fall back to a crash monitor: a GPIO toggle or UART heartbeat that the fuzzer watches. If the heartbeat stops, the target faulted, and the fuzzer logs the last packet sent.

Side Channels as Coverage Signals

Coverage alone is a weak signal. A parser can take an error path that’s functionally correct but leaks information through timing or cache state. I instrument the fuzzer to measure response latency with high precision—using the target’s hardware timer or an external FPGA-based cycle counter—and flag any input that causes a statistically significant deviation. On x86-64, I also monitor performance counters for cache misses and branch mispredictions via perf_event_open. A spike in L1 data cache misses on a specific input often means the parser accessed a lookup table with an attacker-controlled index. That’s a classic gadget for speculative execution attacks. The fuzzer can lock onto that input and start a focused mutation campaign to turn the side channel into a covert channel or a Spectre-style leak. I’ve used this exact technique to pull firmware encryption keys from a locked-down IoT hub by watching the timing of AES-GCM tag verification over a UART console.

Differential Fuzzing Across Parser Versions

Vendors update firmware to fix bugs and often introduce new parsers that behave slightly differently. A differential setup feeds the same mutated input to two firmware versions—say, the boot ROM and the main OS driver—and compares their responses. A mismatch points to a semantic gap you can exploit. The boot ROM might accept a malformed packet that the OS driver rejects, letting an attacker inject code during early boot before the OS hardens the interface. I run this in QEMU with two separate VM instances, synchronizing input delivery and comparing register dumps at the end of each packet processing routine. The fuzzer’s grammar model ensures both parsers get identical, well-formed packets, so any divergence is a genuine parser differential, not a framing error.

A Minimal Fuzzer in Python

Here’s a sketch of the core loop. It assumes you’ve built a ProtocolTree class that can serialize to bytes, recalculate CRCs, and apply mutations from a grammar. The coverage tracker is a placeholder for your specific instrumentation.

import random
from protocol_model import ProtocolTree
from coverage_tracker import CoverageTracker

def main():
    tracker = CoverageTracker()
    corpus = [ProtocolTree.from_capture("seed.pcap")]
    total_cases = 0

    while total_cases < 100000:
        parent = random.choice(corpus)
        child = parent.mutate()
        packet = child.serialize()
        send_packet(packet)
        new_coverage = tracker.get_coverage()
        if new_coverage or caused_crash():
            corpus.append(child)
            if caused_crash():
                save_crash(packet, child)
        total_cases += 1

The mutation engine is where the real work happens. It includes operators like flip_bit_in_field, swap_fields, duplicate_field, set_length_to_payload_size, and set_length_to_overflow. Each operator targets a specific protocol assumption. set_length_to_overflow sets a length field to a value that, when added to the header size, wraps around a 16-bit or 32-bit integer. This reliably triggers buffer overflows in parsers that use unchecked addition to calculate buffer offsets. I’ve built up a library of these operators from years of breaking real-world firmware, and each new target usually adds one or two more.

FAQ

Why not just use AFL with a custom mutator?

AFL’s custom mutator API lets you plug in a grammar-aware mutator, but the fuzzer still treats the input as a flat buffer. For stateful protocols, you need to control the sequence of packets, not just the content of one. You also need to reset the target to a known state between test cases, which AFL’s fork-server model doesn’t handle well for embedded targets. Building a dedicated fuzzer gives you full control over delivery, timing, and state management—things that matter when you’re hunting deep bugs.

How do you handle checksums without knowing the algorithm?

If the checksum algorithm is unknown, you can often infer it by analyzing the firmware binary. Look for tight loops that XOR or accumulate bytes, or for lookup tables used in CRC calculations. If firmware analysis isn’t possible, try a differential approach: send the same packet with a valid checksum and a mutated one, and see if the target’s behavior changes. Some parsers skip checksum verification entirely for certain command types—that’s a bug in itself. I’ve also had success using symbolic execution to solve for the checksum that produces a desired parser state.

What’s the most common bug you find?

Integer overflows in length calculations, by a wide margin. A parser reads a 16-bit length field, adds it to a fixed header size, and allocates a buffer without checking for wrap-around. Send a length of 0xFFFF, the addition wraps to a small value, and the subsequent memcpy of the payload overwrites the heap or stack. The second most common is an off-by-one in the length check, where the parser allows one byte more than the buffer can hold, leading to a single-byte overflow that corrupts a saved frame pointer or a size field in an adjacent heap chunk. Both are trivial to find with a custom fuzzer that understands the protocol’s length fields.

From Crash to Code Execution

Finding a crash is just the start. The real work is figuring out exploitability. For each crash, I triage using a minimal QEMU replay that logs the faulting instruction, register state, and recent branches. If the crash is a write to a controlled address, I map the target’s memory layout and look for useful overwrite targets: function pointers, return addresses, or data that influences a later authentication check. On ARM64, pointer authentication can complicate exploitation, but many embedded implementations leave PAC disabled for interrupt handlers or boot ROM code, creating a window for code reuse attacks. The fuzzer’s output becomes the starting point for a hand-crafted exploit, and the protocol knowledge gained during fuzzer development is what makes the exploit reliable.

Building a custom fuzzer is an investment, but if you work at the boundary between software and hardware, it’s the only way to systematically uncover the flaws vendors insist aren’t there. Next time a datasheet claims a protocol is “secure by design,” run your own fuzzer against it. The results will speak for themselves.