Research
Exploit Development
A bug report says something went wrong. An exploit says what somebody could do with it. We build the second, so the decision to ship a fix rests on evidence rather than a number in a spreadsheet.
The work
What this actually involves
Not a checklist worked through in order. These are the parts of the job, and the target decides how much of each it needs.
-
Reproduction
A crash, a patch note or a half-written report, turned into a case that fails the same way every time. Nothing can be reasoned about until this exists.
-
Root cause
What the flaw is, not what the stack trace printed. The crashing line is usually the victim, not the culprit.
-
Reachability
Whether the code path can be reached at all: from where, by whom, holding what. A serious bug nobody can reach is a maintenance ticket, and saying so is part of the job.
-
Primitives
What the bug hands over: a read, a write, a value somebody else controls. That decides severity, not the crash.
-
Proof of concept
The smallest thing that shows the flaw is real and what it grants. Enough for a vendor to act on, and never built as a weapon.
-
Mitigations
What the platform's defences still stop, and what is left once they are counted. An exploit that only works with every protection disabled has proved very little.
Next
How it runs, and how to commission it
Every piece of research follows the same four steps, and the same terms apply to what comes out.
Ask about exploit development
Tell us what the target is and what you need to know about it.