Research

Large language models have grown markedly more capable, and offensive security is one of the areas where that shift matters most. What is still unclear is the shape of the capability: which parts of an attack an agent can now carry out on its own, and which remain out of reach.

I work on measuring that shape. Reverse engineering and binary exploitation are useful subjects because each is a long chain of dependent steps, so it is possible to observe not merely whether an agent succeeded but how far it got and where it stopped. Aggregate success rates hide exactly this: an agent that understands a program but cannot turn that understanding into a working exploit is a very different adversary from one that never understood it in the first place.

Knowing where agents break down is what makes the defensive question tractable. Protection aimed at a stage an agent already handles well returns little for the effort it costs; the same effort spent on a stage where agents reliably fail goes considerably further. I work on turning that into concrete guidance for software protection, so that resistance to LLM-driven attacks becomes something a system can be designed for rather than hoped for.

RISC-V is an open instruction set architecture that has moved quickly from a research curiosity to production silicon. Its privileged-software ecosystem — the firmware and hypervisors running beneath the operating system — is correspondingly young, and everything layered above machine mode trusts that code unconditionally. A defect there does not weaken the guarantees above it; it voids them.

To find those defects efficiently I build fuzzing tooling for the layer. Hisame is a coverage-guided fuzzer for RISC-V SBI implementations such as OpenSBI and RustSBI: it instruments the emulator, restricts coverage to machine-mode execution so that only firmware counts, generates call sequences valid enough to get past argument checking, and detects memory errors inside the firmware itself. Ordinary fuzzers do not reach this code at all, because it runs before the infrastructure they depend on exists.

Shrinking a crashing input is well understood when the input is a file. It stops being understood when the target is stateful: the message you delete may be the one that put the server into the state where the bug exists at all, so a naive reduction quietly destroys the property it is supposed to preserve.

Minimization for protocol implementations therefore has to reason about state, not only bytes. Recovering an approximate state machine from the target’s own responses gives a criterion for which messages are load-bearing; only once those are pinned down does byte-level reduction mean anything. The payoff is unglamorous and practical: a smaller, faster test case for whoever has to sit down and diagnose the crash.