5 Poc Generator

Craft bespoke proof-of-concept programs for all zeroize-audit findings. Each PoC is individually tailored to the specific vulnerability: read the finding details and the actual source code, then write custom C or Rust code that exercises the exact code path and variable involved. Do NOT use generic templates or boilerplate — every PoC must reflect the specific function signatures, variable names, types, and sizes from the audited codebase.

Each PoC exits 0 if the secret persists (exploitable) or 1 if wiped (not exploitable). PoC generation is mandatory — every finding gets a PoC regardless of confidence level.

Input

You receive these values from the orchestrator:

Process

Step 0 — Load Configuration and Findings

1. Read config_path to load the merged config. Extract PoC-relevant settings:

• secret_fill_byte (default: 0xAA)
• stack_probe_max (default: 4096)
• source_inclusion_threshold (default: 5000 lines)

1. Read final_report to load all findings. Filter to findings in poc_categories.

Step 1 — Write Shared PoC Infrastructure

Write {poc_output_dir}/poc_common.h with these helpers:

• POC_PASS() macro — prints "EXPLOITABLE: secret persists" and exits 0
• POC_FAIL() macro — prints "NOT EXPLOITABLE: secret wiped" and exits 1
• volatile_read_nonzero(ptr, len) — reads len bytes through a volatile pointer, returns 1 if any byte is non-zero
• volatile_read_pattern(ptr, len, pattern) — reads len bytes through a volatile pointer, returns 1 if ≥ len/4 bytes match pattern
• stack_probe(frame_size) — noinline/noclone function that reads frame_size bytes of uninitialized stack locals, checks for SECRET_FILL_BYTE pattern
• heap_residue_check(alloc_size) — malloc/fill/free/re-malloc/check cycle to detect heap residue

Set SECRET_FILL_BYTE and STACK_PROBE_MAX from config values. Mark stack_probe with attribute((noinline, noclone)) to prevent frame reuse.

Step 2 — Craft Each PoC

For each finding, follow this process:

2a — Read and Understand the Source

1. Use Read to examine the function at finding.location.file:finding.location.line. Read at least 50 lines of context around the finding location.

1. Identify:

• Function signature: name, parameters, return type
• Sensitive variable: exact name, type, size (from finding.object)
• Wipe presence: does the source contain an approved wipe call for this variable? Where?
• Error paths: for error-path findings, identify what inputs trigger the error return
• Control flow: for path-coverage findings, identify which paths lack the wipe

1. Use Grep to find:

• Callers of the target function (to understand valid argument patterns)
• Type definitions for the sensitive object (structs, typedefs)
• Include dependencies needed by the target function

2b — Determine Inclusion Strategy

• If the target function is static or the source file is ≤ source_inclusion_threshold lines: use #include to include the source file directly
• If the target function is extern and the file is large: compile the target source to an object file and link via the Makefile

2c — Write the PoC

Write {poc_output_dir}/poc_za_NNNN_category.c (or .rs for Rust). The PoC must:

1. Include poc_common.h for shared helpers
2. Set up required context: include necessary headers, define structs/types used by the target function, declare external symbols if linking
3. Initialize the sensitive buffer: fill with SECRET_FILL_BYTE using memset() before calling the target function. This establishes the "secret" content that should be wiped.
4. Call the target function with valid arguments: use actual types and realistic values. If the function requires allocations, file handles, or other setup, include that setup code. For error-path findings, provide arguments that trigger the specific error path.