PoC / exploit development (authorized targets)

When it applies

You've identified a vulnerability (a versioned CVE, or your own discovered bug) and need a reliable proof-of-concept to demonstrate impact on an authorized target.

Why it works

A version+advisory tells you the root cause and the primitive; a methodical build turns that into repeatable code. For 1-days, most of the work is understanding and adapting, not inventing.

Method

1. Identify precisely: exact product+version → advisory/CVE → root cause and affected code path. searchsploit <product version>; read the advisory and any public PoC.
2. Understand before running: never fire an unread exploit at a target — read the code, know what it does (esp. anything destructive), and check it matches your exact version.
3. Set up a local mirror when possible (same version in a VM/container) to develop safely.
4. Build incrementally: reach the vulnerable code → trigger the primitive (leak/overwrite/ inject) → stabilize → deliver payload. For web, a clean scripted request chain; for binaries, pwntools with the leak→control→shell steps.
5. Make it reliable & minimal: parameterize target/port, add checks, remove noise; it must reproduce for a report/triager.

Gotchas

• Public PoCs are often broken, version-specific, or backdoored — read every line before running.
• Match the exact version/build; an off-by-one minor version silently fails or crashes the service.
• On live bug-bounty targets, prove the primitive without destructive payloads (no DoS/data loss).

Verify success

The PoC reproducibly demonstrates the vulnerability's impact (shell, read, auth bypass) against the authorized target/version, with clear steps.

References

Exploit-DB/searchsploit; pwntools docs; the vendor advisory/CVE for the specific bug.