One Research Loop, Evidence Matched to the Target

A protocol implementation, a native library, and an operating-system kernel do not fail in the same way. Testing them with one generic prompt or one universal scanner erases the details that determine whether a result is real.

The harness should match the target. The standard of evidence should not change.

That distinction is shaping pwnkit’s research architecture inside 0sec. Its specialized engines can preserve their native inputs, execution traces, and oracles while moving through the same staged discipline:

Discover → Reachability? → Harness? → Execute? → Verify → Novelty? → Impact?

Verification is mandatory before a hypothesis can be promoted. The other stages are target-dependent. If a stage cannot run, it stays skipped or inconclusive; it does not silently turn green.

Different systems need different proof

For HTTP protocol conformance, a concrete request and response can be judged against a deterministic rule. The model may propose where an implementation diverges from the specification, but it does not decide whether its own theory is correct.

For userspace memory safety, the useful evidence is a sanitizer or Miri observation bound to the build and input that produced it. A bounded campaign that finds no crash is not proof that the program is safe.

For Linux kernel work, a single crash can be boot-order luck or an ambient sanitizer report. Stronger evidence requires the same signature across fresh VM boots, tied to the kernel tree, configuration, reproducer, and captured dmesg.

For mobile applications, passive intake can identify backend targets and risky configuration. Those indicators are not vulnerabilities by themselves. An authorized backend can be handed to a web-testing engine; passive signals remain hypotheses until dynamic verification exists.

For XNU and IOKit, deterministic selector modeling and input generation are useful today. A panic log alone is not yet enough: attribution, minimization, and repeated fresh-VM reproduction are still required before promotion.

Proof strength is not novelty

We track proof strength as a monotone ladder:

candidate → reachable → observed → reproduced → impact-proven

This answers: How strongly did we demonstrate the behavior?

Novelty answers a different question: Has the same issue already been fixed, reported, or queued elsewhere? A reproduced bug can be a duplicate. A source review that finds no matching advisory has not necessarily proved novelty.

That is why a novelty check with no successfully queried sources is recorded as unchecked, never novel. Mailing lists, commits, pull requests, advisories, issue trackers, and ecosystem databases provide different receipts depending on the target.

Impact is separate again. A crash does not automatically imply data access, authentication bypass, controlled memory corruption, or privilege escalation. Those claims need their own evidence.

Differential execution turns patches into experiments

Security patches are unusually valuable research inputs because they provide a natural pair: vulnerable and fixed behavior.

Run the same input against the two revisions. If only one side exhibits the behavior, the patch supplies a deterministic comparison point. The same method works across versions, configurations, protocol implementations, and vendor backports.

If either side fails to build or execute, the comparison is inconclusive. An infrastructure failure must never become a vulnerability claim.

This approach also makes variant hunting more disciplined. A generated checker should identify the vulnerable revision and stop identifying the fixed one before it is trusted to sweep sibling code.

What exists today

The shared research plane currently connects:

• deterministic HTTP conformance checking
• userspace sanitizer and fuzzing campaigns
• agentic best-of-N investigation with independent verification
• repeated-boot Linux kernel reproduction
• mobile static intake with explicitly scoped backend handoff
• XNU selector discovery and deterministic input generation
• the existing web, AI, source, package, and on-chain pipeline

Some paths intentionally stop at inconclusive because their stronger proof machinery is not complete yet. In particular, XNU panic observations are not promoted without attribution, minimization, and repeated fresh-VM reproduction.

The goal is not to make every target look identical. It is to make every claim auditable: what ran, against which build, what the oracle observed, what did not run, what was checked for novelty, and which security impact was actually demonstrated.

That is the difference between an interesting hypothesis and a finding an engineer can trust.