nsaspy/hackmode

Fork 0

[EPIC][zeroforge-artifacts] Public symbolic exploit + detection artifact generation #200

New issue

Open

opened 2026-09-09 15:07:29 +00:00 by nsaspy · 0 comments

nsaspy commented

2026-09-09 15:07:29 +00:00

Owner

Mission

Implement the public Hackmode destination for the authorized ZeroForge migration tracked by #190 and private source authorization lost-rob0t/zero-forge#147.

This epic is specifically about preserving and expanding ZeroForge's useful security-artifact generation capabilities inside Hackmode as symbolic-first expert machinery.

Capability goal

Hackmode should be able to take an authorized operation objective plus normalized vulnerability/evidence context and produce validated security artifacts through Hackpert + Prolog-RLM.

Initial artifact families:

Metasploit modules
OWASP ZAP active plugins/scripts
OWASP ZAP passive plugins/scripts
native Hackmode exploit modules
native Hackmode detection modules

The public implementation may extend to additional artifact families later through the same typed registry/IR.

Architecture

Hackmode operation + scope
        ↓
objective / vulnerability hypothesis / evidence
        ↓
Hackpert artifact expert
        ↓
Prolog-RLM symbolic reasoning + expert routing
        ↓
artifact strategy / requirements / constraints
        ↓
typed Artifact IR
        ↓
artifact-family renderer/generator
        ↓
deterministic validator(s)
        ↓
valid? ── yes → artifact + provenance
  │
  no
  ↓
validation evidence
        ↓
repair expert / bounded generative fallback
        ↓
new typed candidate → validate again

Symbolic-first design

The useful ZeroForge behavior should not simply move from Python prompts into Common Lisp prompts.

Represent as much as practical as inspectable symbolic data/rules:

artifact_family(...).
applicable_artifact(...).
requires_fact(...).
requires_evidence(...).
requires_capability(...).
output_contract(...).
validation_rule(...).
repair_rule(...).
incompatible_when(...).
verified_when(...).

Generative fallback may fill implementation details when symbolic knowledge cannot fully synthesize an artifact, but the result remains a typed candidate and never bypasses validation.

Track A — typed Artifact IR

Define a common artifact-generation IR containing at minimum:

artifact family + schema version;
operation/objective reference;
vulnerability/finding reference;
intended environment/adapter;
required capabilities;
preconditions and assumptions;
generated files/units;
validation plan;
success oracle;
provenance;
generation/repair attempts;
validator results;
publish/execute eligibility state.

Artifact-family-specific schemas may extend this core.

Track B — Metasploit

Public Hackmode path should support:

symbolic selection of when a Metasploit artifact is appropriate;
typed Metasploit module IR/contract;
module generation/rendering;
syntax/structural/runtime validation where available;
explicit validator evidence;
repair loop driven from failed checks;
provenance linking the artifact to the finding/objective and generation path.

Track C — ZAP

Support separate active and passive families.

Active

typed active-security-check contract;
explicit target/scope requirement;
effectful execution remains behind Hackmode authority/capability gates;
validator proves plugin/script structure before use.

Passive

no new network activity by the generated module itself;
consume existing request/response/evidence streams;
return typed observations/findings;
validator proves passive contract where possible.

Track D — native Hackmode exploit modules

Add a native Hackmode module format that can be invoked through the canonical provider/capability path rather than requiring Metasploit.

A native exploit module should declare:

stable module ID/version;
applicable objective/finding predicates;
required target facts and evidence;
authority requirement;
required capabilities;
typed inputs/outputs;
success oracle;
expected evidence;
cleanup/stop behavior when relevant;
provenance.

Hackpert experts select/propose modules; Hackmode remains the execution authority.

Track E — native Hackmode detection modules

Add a parallel native detection format for safe corroboration and defensive/security evidence gathering.

Detection modules should support:

passive or explicitly bounded active probes;
typed detection conditions;
confidence/evidence semantics;
false-positive/negative notes;
finding correlation;
repeatability requirements;
no automatic privilege/authority widening.

The same vulnerability knowledge should be able to produce both an exploit-oriented artifact and a detection-oriented artifact when appropriate.

Track F — validator + repair experts

Validation is first-class evidence, not a boolean hidden in a generator.

For each artifact family:

candidate
  -> schema validation
  -> syntax/static validation
  -> family-specific contract checks
  -> optional bounded local/lab runtime validation
  -> success/failure evidence

Failed validation should produce structured facts usable by repair experts.

Prefer deterministic repair rules for known failure classes. Use model/RLM generation only as explicit bounded fallback.

Track G — public provenance / ZeroForge lineage

Each migrated artifact family should document that its architecture descends from the authorized ZeroForge symbolic port without requiring the private repo at runtime.

Public provenance may identify the migration program and relevant public issue IDs, but must not leak private source lines, credentials, targets, or unrelated private data.

Relationship to BBP + CTF

The artifact subsystem is shared infrastructure for both planned workflows:

BBP finding -> validate exploitability -> generate reproducer/module + detection artifact
CTF objective -> generate/adapt exploit artifact -> verify challenge objective

BBP and CTF policy/scope remain distinct even though they share artifact machinery.

Acceptance

common typed Artifact IR exists;
artifact family registry is extensible;
Metasploit modules can be proposed/generated/validated through the public stack;
ZAP active modules can be proposed/generated/validated with explicit effect authority;
ZAP passive modules can be proposed/generated/validated without introducing traffic;
native Hackmode exploit-module format exists;
native Hackmode detection-module format exists;
artifact applicability is expressible as symbolic expert/rule knowledge;
validator failures become typed reasoning evidence;
deterministic repair rules can resolve known failure classes;
generative fallback produces candidates only and is bounded/traced;
artifacts carry objective/finding/provenance links;
migrated features run without the private ZeroForge repository present;
synthetic/lab conformance tests cover every initial artifact family;
BBP and CTF workflows can both reuse the artifact subsystem without sharing unauthorized scope.

#190 — umbrella public ZeroForge symbolic port
#24 — Hackpert expert architecture
#27 — active orchestration/effects
#29 — open objective loop
#28 — Prolog-RLM integration
lost-rob0t/prolog-rlm#389 — cyber harness
lost-rob0t/prolog-rlm#390 — semantic-port pipeline
lost-rob0t/zero-forge#147 — private-source migration authorization

First slice

Define the public Artifact IR + registry and port one ZeroForge-derived artifact contract into a deterministic synthetic fixture. Prefer the Metasploit family first because it exercises generation, validation, repair evidence and downstream execution-admission boundaries without requiring a second runtime.

## Mission Implement the public Hackmode destination for the authorized ZeroForge migration tracked by #190 and private source authorization `lost-rob0t/zero-forge#147`. This epic is specifically about preserving and expanding ZeroForge's useful **security-artifact generation capabilities** inside Hackmode as symbolic-first expert machinery. ## Capability goal Hackmode should be able to take an authorized operation objective plus normalized vulnerability/evidence context and produce validated security artifacts through Hackpert + Prolog-RLM. Initial artifact families: 1. **Metasploit modules** 2. **OWASP ZAP active plugins/scripts** 3. **OWASP ZAP passive plugins/scripts** 4. **native Hackmode exploit modules** 5. **native Hackmode detection modules** The public implementation may extend to additional artifact families later through the same typed registry/IR. ## Architecture ```text Hackmode operation + scope ↓ objective / vulnerability hypothesis / evidence ↓ Hackpert artifact expert ↓ Prolog-RLM symbolic reasoning + expert routing ↓ artifact strategy / requirements / constraints ↓ typed Artifact IR ↓ artifact-family renderer/generator ↓ deterministic validator(s) ↓ valid? ── yes → artifact + provenance │ no ↓ validation evidence ↓ repair expert / bounded generative fallback ↓ new typed candidate → validate again ``` ## Symbolic-first design The useful ZeroForge behavior should not simply move from Python prompts into Common Lisp prompts. Represent as much as practical as inspectable symbolic data/rules: ```prolog artifact_family(...). applicable_artifact(...). requires_fact(...). requires_evidence(...). requires_capability(...). output_contract(...). validation_rule(...). repair_rule(...). incompatible_when(...). verified_when(...). ``` Generative fallback may fill implementation details when symbolic knowledge cannot fully synthesize an artifact, but the result remains a typed candidate and never bypasses validation. ## Track A — typed Artifact IR Define a common artifact-generation IR containing at minimum: - artifact family + schema version; - operation/objective reference; - vulnerability/finding reference; - intended environment/adapter; - required capabilities; - preconditions and assumptions; - generated files/units; - validation plan; - success oracle; - provenance; - generation/repair attempts; - validator results; - publish/execute eligibility state. Artifact-family-specific schemas may extend this core. ## Track B — Metasploit Public Hackmode path should support: - symbolic selection of when a Metasploit artifact is appropriate; - typed Metasploit module IR/contract; - module generation/rendering; - syntax/structural/runtime validation where available; - explicit validator evidence; - repair loop driven from failed checks; - provenance linking the artifact to the finding/objective and generation path. ## Track C — ZAP Support separate active and passive families. ### Active - typed active-security-check contract; - explicit target/scope requirement; - effectful execution remains behind Hackmode authority/capability gates; - validator proves plugin/script structure before use. ### Passive - no new network activity by the generated module itself; - consume existing request/response/evidence streams; - return typed observations/findings; - validator proves passive contract where possible. ## Track D — native Hackmode exploit modules Add a native Hackmode module format that can be invoked through the canonical provider/capability path rather than requiring Metasploit. A native exploit module should declare: - stable module ID/version; - applicable objective/finding predicates; - required target facts and evidence; - authority requirement; - required capabilities; - typed inputs/outputs; - success oracle; - expected evidence; - cleanup/stop behavior when relevant; - provenance. Hackpert experts select/propose modules; Hackmode remains the execution authority. ## Track E — native Hackmode detection modules Add a parallel native detection format for safe corroboration and defensive/security evidence gathering. Detection modules should support: - passive or explicitly bounded active probes; - typed detection conditions; - confidence/evidence semantics; - false-positive/negative notes; - finding correlation; - repeatability requirements; - no automatic privilege/authority widening. The same vulnerability knowledge should be able to produce both an exploit-oriented artifact and a detection-oriented artifact when appropriate. ## Track F — validator + repair experts Validation is first-class evidence, not a boolean hidden in a generator. For each artifact family: ```text candidate -> schema validation -> syntax/static validation -> family-specific contract checks -> optional bounded local/lab runtime validation -> success/failure evidence ``` Failed validation should produce structured facts usable by repair experts. Prefer deterministic repair rules for known failure classes. Use model/RLM generation only as explicit bounded fallback. ## Track G — public provenance / ZeroForge lineage Each migrated artifact family should document that its architecture descends from the authorized ZeroForge symbolic port without requiring the private repo at runtime. Public provenance may identify the migration program and relevant public issue IDs, but must not leak private source lines, credentials, targets, or unrelated private data. ## Relationship to BBP + CTF The artifact subsystem is shared infrastructure for both planned workflows: ```text BBP finding -> validate exploitability -> generate reproducer/module + detection artifact CTF objective -> generate/adapt exploit artifact -> verify challenge objective ``` BBP and CTF policy/scope remain distinct even though they share artifact machinery. ## Acceptance - [ ] common typed Artifact IR exists; - [ ] artifact family registry is extensible; - [ ] Metasploit modules can be proposed/generated/validated through the public stack; - [ ] ZAP active modules can be proposed/generated/validated with explicit effect authority; - [ ] ZAP passive modules can be proposed/generated/validated without introducing traffic; - [ ] native Hackmode exploit-module format exists; - [ ] native Hackmode detection-module format exists; - [ ] artifact applicability is expressible as symbolic expert/rule knowledge; - [ ] validator failures become typed reasoning evidence; - [ ] deterministic repair rules can resolve known failure classes; - [ ] generative fallback produces candidates only and is bounded/traced; - [ ] artifacts carry objective/finding/provenance links; - [ ] migrated features run without the private ZeroForge repository present; - [ ] synthetic/lab conformance tests cover every initial artifact family; - [ ] BBP and CTF workflows can both reuse the artifact subsystem without sharing unauthorized scope. ## Related - #190 — umbrella public ZeroForge symbolic port - #24 — Hackpert expert architecture - #27 — active orchestration/effects - #29 — open objective loop - #28 — Prolog-RLM integration - `lost-rob0t/prolog-rlm#389` — cyber harness - `lost-rob0t/prolog-rlm#390` — semantic-port pipeline - `lost-rob0t/zero-forge#147` — private-source migration authorization ## First slice Define the public Artifact IR + registry and port one ZeroForge-derived artifact contract into a deterministic synthetic fixture. Prefer the Metasploit family first because it exercises generation, validation, repair evidence and downstream execution-admission boundaries without requiring a second runtime.