Standardmäßig ist der Prompt ausgewählt, der zuerst die Quelle prüft. Sie können zu einem direkten Befehl wechseln oder eine lokale Kopie herunterladen.
Quelldateien prüfen
Lesen Sie SKILL.md und alle von SkillsMP angezeigten Begleitdateien, bevor Sie sich für eine Installation entscheiden.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Ein direkter Befehl überspringt den Prüf-Prompt. Prüfen Sie die Quelle, bevor Sie ihn ausführen.
"The patch is a confession. Read it carefully and it will tell you exactly where the bug lives, what shape it has, and how to walk to it from any front door." — traditional vuln-research maxim, paraphrased from Project Zero's "Patch Gapping" methodology.
Summary
The patch-to-poc-pipeline is kali-claw's workflow skill for turning a published patch diff into a working PoC plus detection coverage. It is the pipeline itself: the discipline of reading a diff, forming a bug-class hypothesis, walking the code path from attacker-controlled input to the patched sink, generating a trigger input (manually or via fuzzer harness), differentially verifying the input crashes the pre-patch binary and leaves the post-patch binary clean, and finally shipping YARA + Sigma rules that fire on the vulnerable pattern and the exploitation telemetry respectively. This skill solidifies the methodology of validation/scenarios/SCEN-008.md into a reusable knowledge base — the scenario is the per-CVE runbook; this skill is the standing capability that executes it.
The skill is distinct from its constituents: it does not teach Ghidra decompilation (binary-reverse / reverse-engineering-advanced own that), full exploit construction (exploit-development owns ROP / shellcode / heap feng shui), fuzzer operation (ai-fuzzing owns AFL++/libFuzzer tuning), or generic Sigma/YARA authoring discipline (detection-engineering owns that). What this skill owns is the orchestration contract between them — the bug-class hypothesis taxonomy that drives Phase 1, the call-chain walking pattern that drives Phase 2, the harness-vs-manual decision matrix that drives Phase 3, the CyberGym-style differential stop condition that drives Phase 4, and the Schema 3 reproduction memory that knits every phase into a memory-driven convergence loop.
The strategic value of this skill is calibration. CyberGym (ICLR 2026, UC Berkeley; 1,507 CVEs across 188 OSS projects) evaluates AI agents on exactly this task: given pre-patch source, produce a PoC that crashes the vulnerable build but not the patched build, offline. kali-claw's Q3 2026 external calibration goal is to run this pipeline against a curated CyberGym subset and produce a public success-rate number. Each phase emits a Schema 3 memory delta; the runner halts only when verification_results.vulnerable.crashed == true AND verification_results.patched.crashed == false — any other terminal state fires an anti-pattern alert. This is the MopMonk "三招" (structured memory + memory-driven convergence + shared-memory multi-agent) applied to vulnerability reproduction.
This skill is the meta-pipeline for SCEN-008-class work. When you have a patch in hand and need a PoC plus detection coverage by morning, this is the door you walk through.
Distinct from adjacent skills
Skill
Scope
Boundary with this skill
binary-reverse
RE techniques (disassembly, decompilation, Ghidra basics)
Consumed by Phase 2 when source is unavailable
reverse-engineering-advanced
Deep RE (type recovery, angr symbolic execution, decompiler-aided analysis)
Consumed by Phase 2 for binary-only call-chain reconstruction
exploit-development
Full exploit construction (ROP, shellcode, heap grooming, GOT overwrite)
This skill stops at a crashing PoC — weaponization is out of scope
Consumed post-PoC for fleet-scale rollout of the new YARA rule
patch-to-poc-pipeline (this)
The pipeline that orchestrates the above — bug-class taxonomy, 5-phase contract, CyberGym differential stop condition, Schema 3 reproduction memory
Owns the workflow itself
Use Cases
Reconnaissance & Triage
Acquire patch from a CVE advisory — pull *.patch from a distro gitweb, GitHub advisory, or the upstream commit ref
Triage patch severity — git diff --stat to scope blast radius; classify as "adds a check" (informative), "refactor" (low signal), or "backdoor" (xz-utils special case)
Cross-reference patch to CWE — match protective pattern to CWE (bounds check → CWE-787/125, integer guard → CWE-190, free + NULL → CWE-416, etc.)
Rank candidate CVEs for reproduction by ROI — exploitability × deployment breadth × patch recency
Detect malicious patches (xz-utils case) — triage for obfuscated control flow, IFUNC hooks, build-system tampering
Map patch to MITRE ATT&CK detection coverage — pre-stage the Sigma rule's ATT&CK tags before Phase 5
Phase 1 — Patch Analysis
Read unified diff and identify the protective pattern — bounds check, type check, sanitize, length validation, NULL check, integer-overflow guard, capability drop
Compute file/line hunk stats — lines_added vs lines_removed; patches that only add are most informative
Choose strategy via decision matrix — manual craft (well-understood bug, fast) vs fuzzer harness (subtle bug, thorough)
Manual craft via hex editor / Python struct — take a valid sample, mutate the field that controls the vulnerable parameter
Author AFL++/libFuzzer harness — LLVMFuzzerTestOneInput calling the public API with attacker bytes
Compile with sanitizer matrix — -fsanitize=fuzzer,address,undefined (ASan + UBSan) for memory bugs; MSan for uninitialized reads; TSan for race conditions
Construct seed corpus — valid samples from project's test suite + boundary inputs (max sizes, zero lengths, off-by-one)
Run fuzzer with budget — max_total_time=1800 for first pass; record crashes to artifact_prefix=/work/crashes/
Triage crash with ASan — asan_symbolize to map stack frames to source lines; verify the crashing function matches Phase 1 hypothesis
Apply convergence rule — if 3 candidate inputs fail to crash, switch strategy (manual ↔ fuzzer); log failed_attempts delta
Phase 4 — Differential Verification
Build patched binary with identical harness + sanitizer flags
Run identical PoC against both versions — capture exit codes and ASan traces separately
Apply CyberGym stop condition — vuln crashes AND patched clean = CONFIRMED; any other combination = loop back
Detect wrong-root-cause failure — both crash → re-enter Phase 1 with new hypothesis
Detect PoC-doesn't-reach-bug failure — neither crashes → re-enter Phase 3 with new candidate input
The pipeline is a memory-driven state machine. Each phase reads Schema 3 memory, executes its task, writes a delta, and emits a convergence check. The runner halts only on the CyberGym stop condition (Phase 4 pass) or an anti-pattern abort.
Phase 1 — Patch Analysis
Goal: read the patch, identify the protective pattern, hypothesize the bug class, and pick the suspected vulnerable function.
Convergence trigger: if patch_analysis.key_change is empty after this phase, abort — no point walking code paths without a hypothesis (招二: memory-driven convergence).
Phase 2 — Code Path Walking
Goal: trace attacker-controlled input from the public API surface down to the patched sink.
Source-available path:
grep -rn "<vuln_func>" /targets/<pkg>-<vuln_ver>/src/
# Build call graph from public entry to vuln function
ctags -R /targets/<pkg>-<vuln_ver>/ && your_callgraph_tool
Binary-only path:
/opt/ghidra/support/analyzeHeadless /work proj \
-import /targets/<pkg>-<vuln_ver>.so \
-postScript DecompileFunction.java -scriptPath /work/scripts \
-functionName <vuln_func>
bindiff /targets/<pkg>-<vuln_ver>.so /targets/<pkg>-<patched_ver>.so \
-o /work/<pkg>.BinDiff
# BinDiff marks <vuln_func> as "changed" — start there
Memory contract:
Field
Before
After Phase 2
code_path.entry_function
null
"main() → parse_input()"
code_path.call_chain_to_vuln
[]
["main", "parse_input", "decode_chunk"]
code_path.input_to_vuln_distance
null
3
Convergence trigger: if no path exists from public API to vuln function (distance = -1), abort — the bug may be unreachable from attacker input (defender's win, but no PoC).
Phase 3 — PoC Generation
Goal: produce a candidate input that triggers the patched bug on the vulnerable version.
Strategy decision matrix:
Condition
Strategy
Bug class well-understood (memory_corruption from obvious overflow)
A — Manual craft
Bug class subtle (type_confusion, race_condition)
B — Fuzzer harness
Public test corpus exists
A first, B as backup
Phase 1 confidence < 0.7
B mandatory (manual likely to miss)
Sanitizer crash already observed in OSS-Fuzz tracker
A — clone and minimize
Strategy A — Manual craft: take a valid sample, mutate the field that controls the vulnerable parameter with a hex editor or python3 -c 'import struct; ...'.
"ERROR: AddressSanitizer: heap-buffer-overflow on address 0x..."
convergence_state.iterations
1
N (one per candidate)
Convergence trigger (招二): if test_status stays PENDING after 3 candidates, switch strategy (A ↔ B). Increment failed_attempts; force path switch at >= path_switch_threshold.
Phase 4 — Differential Verification (the CyberGym Stop Condition)
Goal: confirm PoC crashes vulnerable AND leaves patched clean. This is the deterministic stop condition CyberGym scores on.
Decision matrix:
Vulnerable
Patched
Verdict
Next
crashes
clean
CONFIRMED
Phase 5
crashes
crashes
Wrong root cause
Phase 1 with new hypothesis
no crash
no crash
PoC doesn't reach bug
Phase 3 with new candidate
no crash
crashes
Impossible
Recheck build / harness
Memory contract (the convergence event):
Field
Before
After Phase 4
verification_results.vulnerable.crashed
null
true
verification_results.patched.crashed
null
false
convergence_state.status
"IN_PROGRESS"
"POC_CONFIRMED_DIFFERENTIALLY"
convergence_state.stop_condition_met
false
true
Stop condition: runner halts only when vulnerable.crashed == true AND patched.crashed == false. Any other terminal state with stop_condition_met=true fires the "Premature stop" anti-pattern alert (see SCEN-MEMORY-SCHEMA.md).
Phase 5 — Detection Rule Authoring
Goal: ship a YARA rule that fires on the vulnerable pattern across the fleet + a Sigma rule that fires on exploitation telemetry.
YARA: source pattern (function name + missing-guard regex) AND binary symbol pattern. Test: MUST match <pkg>-<vuln_ver>.so, MUST NOT match <pkg>-<patched_ver>.so.
Sigma: host/network telemetry rule — e.g., process loading <vuln_lib>.so AND accessing crafted file extension; or auth-bypass URL pattern in reverse-proxy logs. Convert to Splunk / KQL / EQL backends via sigma-cli.
Fleet rollout: syft + grype --only-fixed to find every deployment of the vulnerable version. Submit detection rule to detection-engineering CI for staged rollout.
Memory Schema Integration
This skill operates on Schema 3 — Patch-Diff Reproduction Memory (see validation/scenarios/SCEN-MEMORY-SCHEMA.md):
招三 (Shared-memory multi-agent): parallel agents claim distinct paths (patch-diff, harness-entry, sanitizer) against the same memory file via atomic writes + version vector
Anti-patterns the runner enforces:
Anti-Pattern
Detection
Free-form exploration
memory_lock.last_read_at is null when write attempted
Memory drift
Decision-log entry references finding not in findings[]
Repeat-without-delta
failed_attempts >= 3 on same hypothesis
Path-claim deadlock
active_paths has duplicate values
Premature stop
stop_condition_met=true but verification_results has null fields
rule CVE_2023_4863_libwebp_huffman_overflow {
meta:
description = "libwebp BuildHuffmanTable heap-buffer-overflow (CVE-2023-4863)"
cve = "CVE-2023-4863"
cvss = 8.8
patched_in = "libwebp 1.3.2"
author = "kali-claw patch-to-poc-pipeline"
strings:
$vuln_func_src = "BuildHuffmanTable"
$table_accum = "root_table + table_size"
$no_guard = "table_size <\\s*\\d+" nocase
$bin_symbol = "BuildHuffmanTable" ascii
condition:
($vuln_func_src at 0 and $table_accum and $no_guard)
or ($bin_symbol and not $no_guard)
}
# Test both versions — differential YARA check
yara -s /work/rules/CVE-2023-4863.yar /targets/libwebp-1.3.1.so # MUST match
yara -s /work/rules/CVE-2023-4863.yar /targets/libwebp-1.3.2.so # MUST NOT match
# Sigma rule for exploitation telemetry
title: Potential CVE-2023-4863 libwebp Exploitation
id: 7c4f8a9b-1e2d-4a3b-9c5d-7e8f9a0b1c2d
status: experimental
description: Detects processes loading a vulnerable libwebp and accessing crafted WebP inputs.
author: kali-claw patch-to-poc-pipeline
date: 2026/07/03
logsource:
product: linux
service: sysmon_linux
detection:
selection_load:
ImageLoaded|endswith:
- '/libwebp.so.7.0.3'
- '/libwebp.so.7.0.4'
- '/libwebp.so.7.0.5'
selection_file:
CommandLine|contains: ['.webp', '.webm']
condition: selection_load and selection_file
falsepositives:
- Legitimate WebP processing on patched systems
level: medium
tags: [attack.initial-access, attack.t1190, cve.2023.4863]
CyberGym (ICLR 2026, UC Berkeley; 1,507 CVEs across 188 OSS projects) evaluates AI agents on exactly this task. Phase 4's stop condition is the CyberGym scoring criterion.
CyberGym task component
This skill's phase
Receive (vuln source, patch)
Phase 1 input
Identify root cause
Phase 1 + 2
Generate PoC
Phase 3
Differential verification
Phase 4 (the stop condition)
Detection rule (kali-claw extension)
Phase 5
Q3 2026 calibration plan: run this pipeline against a 50-100 instance CyberGym subset spanning memory_corruption, integer_overflow, type_confusion, auth_bypass, sqli, xss, ssrf, path_traversal. Success criterion: convergence_state.stop_condition_met == true AND status == "POC_CONFIRMED_DIFFERENTIALLY" for ≥ 50% of subset. See docs/mopmonk-research-and-kali-claw-plan.md §5.4 for the long-term plan.
Defense Perspective
Compiler flags that close the bug class at the source
Flag
Bug class closed
Why
-fsanitize=address
Heap/stack OOB, UAF, double-free
Runtime trap; CI failures on regression
-fsanitize=undefined
Integer overflow, shift OOB, type confusion
Catches CWE-190 feeding CWE-787
-fsanitize=memory
Uninitialized reads
Catches CWE-908
-fsanitize=thread
Race conditions
Catches CWE-362
-D_FORTIFY_SOURCE=3
libc memcpy/sprintf overflow
GLIBC 2.34+ fortify at compile + runtime
-ftrapv
Signed integer overflow
Trap instead of wrap
-fstack-protector-strong
Stack buffer overflow
Canary on functions with buffers
-fstack-clash-protection
Stack-clash probes
Guard page enforcement
-fcf-protection=full
ROP / JOP
Intel CET shadow stack + IBT
Static analyzers that flag the bug class pre-build
Function-level diff: Track changes in security-sensitive functions (alloc, copy, parse).
Runtime Detection
Vulnerability scanner: Nessus, Qualys; identify unpatched versions in environment.
IDS signatures: Snort / Suricata rules for known exploits.
EDR detection: Process anomalies matching known exploit patterns.
SIEM Detection Rules
Splunk SPL: index=vuln scanner=nessus | where cve_id matches "2025-*" | stats count by host
CISA KEV catalog: Cross-reference internal vuln scan with Known Exploited Vulnerabilities.
Defense Evasion Techniques
PoC Weaponization Stealth
Single-shot exploitation: One exploit attempt per target; below sustained-pattern detection.
Memory-only execution: Run exploit from RAM; no disk artifacts.
Use legitimate processes: Inject exploit into legitimate process (e.g., browser, web server).
Detection Evasion
Slow exploitation: Pace exploit attempts below IDS threshold.
Use new CVEs: Exploit CVEs less than 30 days old; detection rules lag.
Variants: Modify public PoC to evade signature detection.
Cross-architecture: Port PoC to less-monitored architecture (e.g., ARM64 vs x86_64).
Learning Resources
Berkeley CyberGym paper (ICLR 2026) — UC Berkeley; benchmark of 1,507 CVEs across 188 OSS projects; differential stop condition is the scoring criterion this skill is calibrated against
