RD / Services

Targeted fuzzing

Exercise selected components with unexpected inputs, investigate failures and identify security-relevant weaknesses. Start with a target that matters to your product.

  • Components & libraries
  • Unexpected inputs
  • Failure investigation

For teams building parsers, libraries, SDKs, protocols or application components that process untrusted input.

When malformed files, messages or inputs could expose a weakness.

What we examine

  • Assess target feasibility, build requirements, entry points and test objectives.
  • Set up and run the agreed testing approach for the selected component.
  • Investigate and deduplicate failures, minimize useful examples and assess security relevance.

A clear start. A useful finish.

Tell me the problem

Share the product, stack, goal and deadline. A short overview is enough to start the conversation.

Agree the engagement

Receive a written scope, deliverables, acceptance criteria, price and schedule before we begin.

Review the work as it develops

For assessments, examine the evidence and priorities. For engineering, review agreed implementation milestones.

Put the result to work

Get a technical walkthrough and useful handoff. Agree any further implementation or verification your team needs.

I investigate down to the cause.

Facebook and Instagram research, 300+ Linux kernel reports and findings investigated, eight patches and two published CVEs. I connect a suspicious behavior to the code, the conditions that trigger it and the impact on your product.

See the kernel findings and fixes

Questions before we begin

What makes a useful fuzzing target?

A component with clear input boundaries and a build or execution environment we can exercise. Parsers, libraries and protocol handlers are useful candidates. We confirm suitability before committing to a campaign.

Can we start with a small pilot?

Yes. A paid feasibility phase can establish whether the target is practical, what setup it needs and what a larger campaign should include.

Will you deliver a harness or ongoing test setup?

We agree the artifacts during scoping. Depending on the target, these may include a harness, seed inputs, run instructions, reproducers or integration guidance. They are specified in the proposal.

Does every crash mean a vulnerability?

No. Failures need investigation. The report distinguishes observed behavior, confirmed security impact and unresolved questions; it does not promise a number of vulnerabilities or CVEs.

Useful lessons from security research

Services

08Contact

Let’s solve the next hard problem.

Tell me what you’re building, what is at stake and when you need a result. I’ll discuss the fit and propose a defined scope, deliverables and price.