About

I'm 19, studying computer science, and most of my time for the last four years has gone into understanding systems most people never have a reason to look at — and building things that actually hold up once real people depend on them.

My work lives near the bottom of the stack: reverse engineering, native Windows tooling, kernel internals, static analysis, binary instrumentation. Not because low-level is inherently better than high-level, but because understanding what's actually happening — the instruction stream the CPU executes, the page table walk on every memory access, the dispatch chain when a driver handles a request — is the only way to reason clearly about performance, security, and correctness in software that matters.

It started at 15 with game security research, the same way a lot of people in this field get their start: by trying to build something and discovering it was a much bigger project than expected. Reading another process's memory from outside it requires a kernel driver. Writing a kernel driver means weeks with the WDK docs, learning to read a bugcheck as a diagnostic message instead of a disaster, and understanding the EPROCESS structure well enough to know what lives at which offset. The defensive side of that world — anti-cheat, EDR-adjacent tooling — operates at ring-0 too, so you end up in a genuine arms race against engineers who do this professionally. Brutal as a learning environment. Also the most effective one I've been in.

Two years of that work became a commercial software product that peaked at 11,000 active users — every component built by me: the kernel driver, the obfuscated loader, a hardware-bound auth backend running RSA-4096 signed tokens, a React dashboard, billing, support tooling, the works. Running production infrastructure solo at 16 taught me things a classroom doesn't get close to: what it means when thousands of people depend on something you personally wrote, how to debug a kernel panic at 2am when a routine OS patch quietly changed a struct offset you'd hardcoded, how to design systems that degrade gracefully instead of falling over completely. I wound it down eventually — the operational load wasn't sustainable running it solo alongside everything else — but the technical foundation it gave me is most of the reason I can do the work I do now.

The pattern since has stayed consistent: understand a thing properly or don't use it. I wrote a PE loader from scratch not because LoadLibrary is bad, but because you can't actually reason about what the Windows loader is doing until you've implemented base relocations and TLS callbacks yourself and hit the edge cases that only show up when you do. Same reason behind the sandbox engine, the custom allocator, the weeks spent stepping through ntdll in WinDbg just to understand what a function I already knew how to call was actually doing underneath.

Right now most of my time goes to FCAT — a full PE static analysis suite in C#, compiled to WebAssembly, entirely client-side. The interesting problems are all about the WASM memory model: processing a 200MB binary inside a linear-memory sandbox without exhausting it, keeping an entropy heatmap responsive while it scans, writing packer heuristics that don't false-positive on binaries that are just legitimately small. I'm also working through the LLVM codebase methodically — IR representation, the pass pipeline, how SelectionDAG turns IR into machine instructions — with a disassembly backend as the eventual goal. I'd rather build the tool than only know how to use someone else's.

Outside of that: competitive problem solving, and working through Tanenbaum's Modern Operating Systems and the Intel SDM, which is not a comfortable read but is a genuinely useful one. A lot of modern software feels unsatisfying to me because the people shipping it don't know what the machine underneath is actually doing. That's probably not a universally popular opinion. I still think it's correct.