CS STUDENT // SYSTEMS ENGINEER // REVERSE ENGINEER // NONCHALANT
19, studying computer science. Most of my time goes into low-level code — reverse engineering, kernel internals, and building tools that hold up under real load.
people served by software I built and ran solo
shipped projects
years writing low-level code
languages I reach for when it matters
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.
Languages I actually use day to day, not just listed for the sake of it.
Native tools, Win32 API, user-mode and driver-level dev, reverse engineering. Primary language for anything systems-adjacent.
.NET internals, Blazor/WASM, backend tooling. Used heavily in FCAT.
OS theory, bare-metal programming, kernel driver development.
x86/x64 instruction sets, reading compiler-generated disassembly, shellcode analysis.
Fast automation, scripting, RE tooling, backend prototyping.
Node.js backends, React/Next.js frontends.
PostgreSQL schema design, query optimization, indexing under real load.
University coursework, algorithm theory.
Actively learning. The borrow checker forces ownership thinking that makes C++ better too.