Technical investigation
Reverse engineering
& forensics
Understand how a system works, trace what actually happened, and establish the conditions that make an exposure exploitable.
From code to runtime behavior
My investigations span source code, executables, memory, network traffic, serialized objects, and application behavior. I combine static analysis with controlled testing to trace execution paths, understand prerequisites, and explain what a result actually demonstrates.
Source and patch comparisons help isolate what changed. Debugging and reproduction test whether those changes affect reachable behavior. The outcome can be a detection, a regression test, a clearer exposure assessment, or a documented limitation.
Methods & capabilities
Take the system apart.
Make the findings useful.
Source & patch analysis
Compare versions, follow data and control flow, inspect serialization and input handling, and distinguish a documentation change from a behavioral fix.
Exploit analysis & reproduction
Build test environments, inspect runtime configuration, attach debuggers, and challenge assumptions with repeatable positive and negative tests.
Protocol & artifact forensics
Inspect packet captures, custom communications, executable artifacts, and memory to reconstruct behavior and connect observations across a system.
Detection & quality engineering
Turn findings into practical checks, retain failing cases, test false-positive conditions, and document the versions and prerequisites behind a conclusion.
Example: pandas query exposure
Public technical discussion · August 2025
In the pandas discussion, I compared version-specific source with the development branch and examined how expression evaluation reaches objects in scope. My contribution focused on execution paths and the boundary between trusted expressions and attacker-controlled input.
The exposure assessment depends on how an application passes input to the API. An installed package alone does not establish exploitability; a warning or documentation change alone does not demonstrate that execution behavior was removed.
This was a contribution to an existing discussion, rather than authorship of the original report or a claim of a completed fix.
Read my source-analysis contribution ↗Reproduction, records & reliable conclusions
In PHP2Shell research, I directed agent-driven lab work, used live debugging, and challenged a model’s incorrect exploit attribution against observed execution. That work connects reverse engineering to reproducible tests and defender-facing detection.
In AI Logging, source-linked histories, retained artifact versions, and integrity checks support reconstruction of tool actions and generated outputs. In Connector Forge, provenance and replay help explain how a result was assembled.
I keep observed behavior, inferred explanations, and unresolved questions distinct. A forensic record is useful when another engineer can follow the inputs, versions, tests, and limits behind the finding.
Get in touch
Have a challenge
worth solving?
Start a conversation about engineering, research, or a problem that needs a closer look.