Vulnerability research
I study the trust boundaries that privileged software quietly depends on: caller identity, authorization checks, memory ownership, and the assumptions between a public interface and the code that acts with greater authority.
This page contains public research only. Vendor-coordinated findings appear here after the corresponding security update is available; technical details follow the applicable disclosure and patch-adoption window.
Public work
Reproducible lab methods and analysis of already-public vulnerabilities. These pieces show the research process without previewing a finding under coordination.
Vulnerability analysis
Copy Fail and Dirty Frag, three Linux CVEs in ten days, share one root cause: in-place crypto fast paths that write over paged fragments they do not own.
Pattern analysis of three Linux CVEs found and disclosed by other researchers. These are not my findings.
Read the analysisSupply-chain analysis
The xz incident shows why inspectability, release provenance, and independent verification matter, not that open source is inherently safer.
Read the analysisWindows internals
How Control Flow Guard validates indirect call targets, why it cripples JOP on Windows 8.1+, and how Win11 hardware shadow stacks layer on via Intel CET.
Read the tutorialFirmware research
Extract firmware from an IoT update file, unpack the filesystem, identify interesting binaries, and reverse engineer them in Ghidra to find bugs.
Read the tutorialResearch practice
A live vulnerability stays private while the vendor investigates and prepares a fix. Public work during that period is limited to reusable methods that do not identify the affected product or make the finding reversible. After remediation, the public record begins with the vendor advisory and grows into a technical teardown only after the relevant patch-adoption window.