I believe the best security research doesn't stop at finding vulnerabilities—
It helps vendors understand them, fix them, and ultimately makes software safer for everyone.
Getting vulnerabilities fixed matters more to me than the size of a bounty. Rewards are appreciated because they help support the hardware, software, and tools needed to continue security research, but protecting users and improving security will always remain the top priority.
- More than 20 years of reverse engineering experience
- Reverse engineering native applications, browsers, Windows drivers, and binary interfaces
- Browser security research involving Firefox, SpiderMonkey, Chromium, and related components
- Windows kernel driver, IOCTL, BYOVD, and vulnerable-driver research
- Large-scale C and C++ source-code auditing
- Fuzzing harness development using AFL++, WinAFL, sanitizers, and custom tooling
- Crash triage, root-cause analysis, and exploitability assessment
- Proof-of-concept development for authorized testing and responsible disclosure
- Threat-intelligence enrichment and driver reputation analysis
- Building custom security tools that combine static analysis, emulation, fuzzing, scanning, logging, and automation
- Responsible and coordinated vulnerability disclosure
- Helping vendors identify, validate, and remediate vulnerabilities before they can affect users
A large part of my work involves building the tools I wish already existed.
Rather than solving the same problem repeatedly by hand, I prefer to automate the research process whenever possible. Many of my projects began because an existing workflow was too slow, lacked the information I needed, or required too many repetitive steps.
Some of my current projects and research areas include:
- BYOVD identification and vulnerable-driver analysis
- Automated IOCTL discovery and handler analysis
- Non-live driver emulation and fuzzing
- Dangerous kernel primitive detection
- Driver reputation and threat-intelligence analysis
- Browser and native-code fuzzing harnesses
- Crash reproduction and verification pipelines
- Hypervisor and IOCTL logging tools
- Reverse-engineering utilities, unpackers, pattern scanners, and binary-analysis helpers
- Static analysis, emulation, fuzzing, and triage workflows
- Internal tooling for organizing findings, evidence, reports, and coordinated disclosures
My process is usually straightforward:
- Learn how the target works.
- Identify the exposed interfaces and attack surface.
- Build or adapt the tooling needed to test it properly.
- Reproduce and verify anything suspicious.
- Separate genuine security issues from crashes, false positives, and expected behavior.
- Determine the root cause and assess the potential security impact.
- Prepare a clear report with enough technical evidence for the vendor to reproduce the issue.
- Coordinate disclosure and avoid publishing sensitive details before remediation.
- Feed what I learned back into my tools so the next investigation is faster and more reliable.
My repositories and research are intended for:
- Authorized vulnerability research
- Defensive security analysis
- Education and interoperability
- Research on software and systems I own or am explicitly permitted to test
- Responsible and coordinated vulnerability disclosure
My work is not intended to facilitate unauthorized access, harm users, disrupt services, or expose unpatched vulnerabilities for malicious use.
I have submitted findings through vendor security teams, coordinated disclosure programs, and platforms such as Mozilla Bugzilla, HackerOne, Bugcrowd, ZDI, and direct PSIRT channels.
Some findings remain private while vendors investigate, prepare patches, coordinate public disclosure, or complete the CVE assignment process.
- Protect users first
- Test only software and systems I own or am authorized to analyze
- Verify findings before reporting them
- Avoid publishing sensitive details before remediation
- Give vendors clear, reproducible technical evidence
- Distinguish real vulnerabilities from false positives and non-security failures
- Credit the researchers and projects whose work contributes to mine
- Build reusable tools instead of repeatedly solving the same problem by hand
- Keep learning, because every target teaches me something new
- Focus on improving security rather than chasing bounty amounts
Security research is something I genuinely enjoy, and I am always looking for new areas to learn.
As my work continues to grow, I want to expand further into browser internals, Windows kernel security, driver analysis, automated vulnerability discovery, advanced fuzzing, emulation, and large-scale source-code auditing.
I also want to continue improving the toolsets I have built so they can identify risky behavior earlier, reduce repetitive work, make findings easier to validate, and help produce clearer disclosures for vendors.
Long term, I hope to collaborate with a larger security research team or establish a security research firm of my own. I want that work to focus on helping vendors identify, understand, and remediate vulnerabilities before they can be abused.
No matter where that path leads, my goal remains the same: learn how things work, build better tools, responsibly report what I find, and help make software safer for everyone.
Learn how it works. Find what can break. Help get it fixed.