[EPIC][module-framework] Native Hackmode security module framework with Metasploit-inspired concepts #197

New issue

Open

opened 2026-09-05 08:07:21 +00:00 by nsaspy · 1 comment

nsaspy commented

2026-09-05 08:07:21 +00:00

Owner

Mission

Build a native Hackmode module framework that captures the useful operator and architecture concepts people expect from Metasploit-style frameworks while remaining idiomatic to Hackmode's Common Lisp + StarLang + Tek9 + Hackpert architecture.

This is not a port of Metasploit internals and does not make Metasploit the source of truth. The goal is conceptual parity where useful:

module catalog / search / info
module families
use/select module
structured options + defaults
operation/workspace scoping
check / run lifecycle
background jobs
interactive run/session handles
result/evidence capture
module metadata + references
LISH-native operator UX

Hackmode remains authoritative for operation scope, capabilities/providers, effects, canonical state, evidence, and policy.

Architectural placement

LISH / Emacs / clients
        ↓
Hackmode module framework
  catalog / metadata / option schemas
  module selection + instantiated module runs
  jobs + session/run handles
        ↓
Hackmode capability/provider runtime
        ↓
operation scope + authority/effect admission
        ↓
provider execution / observation
        ↓
Tek9 graph + findings + evidence
        ↓
Hackpert / Prolog-RLM reasoning over typed state

Do not create a second execution engine, second operation database, second capability registry, or second authority plane.

Metasploit-inspired concept mapping

The framework should provide native equivalents for concepts such as:

Familiar concept	Hackmode-native equivalent
module	typed module descriptor + implementation binding
exploit/check module	scoped active verification/action module with explicit authority requirements
auxiliary/scanner	observation/recon/detection module
post module	operation/session-scoped follow-up module using existing authorized capability handles
payload/handler concept	typed interactive capability/session contract where applicable; no ambient executable authority
datastore/options	typed immutable/default + per-operation/per-run option layers
workspace	canonical Hackmode operation
jobs	supervised StarLang module-run jobs
sessions	typed run/session handles linked to operation/evidence graph
search/info/show	catalog queries over module metadata
console	LISH native module UX

These are conceptual mappings, not requirements to preserve Ruby APIs, file layout, command syntax, or unrestricted payload semantics.

Required child tracks

Create/maintain separate implementation epics for:

module contract, families, registry, discovery, metadata and lifecycle;
typed options/datastore/config layering and validation;
supervised module runs, jobs, cancellation, result/evidence lifecycle and typed sessions;
LISH module console/search/use/info/options/run/jobs/sessions UX;
compatibility/interoperability boundary for external frameworks such as Metasploit without importing their authority model;
conformance fixtures and documentation proving native framework behavior.

Module families

Initial registry should support extensible categories rather than hard-coded dispatch logic. Families may include:

recon / discovery;
scanner / auxiliary observation;
detection / corroboration;
active verification / exploit-oriented module;
protocol/service interaction;
operation/session follow-up;
evidence collection;
reporting / artifact production;
framework adapter.

The family affects metadata, validation and policy expectations but does not itself grant capability authority.

Core invariants

module discovery does not grant execution permission;
selecting a module does not change Hackpert passive|active authority;
every effectful operation still crosses the canonical Hackmode scope/capability/effect boundary;
module options are typed and validated before dispatch;
module output is typed result/evidence, not opaque canonical state mutation;
module runs have stable operation/run/module identities;
cancellation is first-class and suppresses later effects from cancelled jobs;
background execution uses existing StarLang supervision rather than ad-hoc threads/process managers;
Tek9 remains canonical for operation/evidence state;
Hackpert/Prolog-RLM may select or reason about modules but do not bypass the Common Lisp execution boundary;
local-first operation works without Prolog-RLM or an LLM.

Relationship to existing issues

#24 — Hackpert expert layer over canonical Hackmode state.
#27 — active typed action/state-delta orchestration.
#14 / #178 — LISH and expert/operator surfaces.
#191 — artifact generation can emit native Hackmode module artifacts, but this epic owns the runtime/framework they target.
lost-rob0t/prolog-rlm#389 — generic reasoning harness consumed by Hackmode; it does not own this module framework.

Acceptance

a first-class native module descriptor/schema exists;
modules are searchable and introspectable by typed metadata;
an operator can select a module and instantiate a run without mutating global module metadata;
typed options/defaults/per-operation/per-run overrides are validated deterministically;
modules dispatch only through canonical Hackmode capabilities/providers;
background runs appear as supervised jobs with cancellation/status;
long-lived/interactive activity is represented by typed session/run handles linked to evidence;
all results/failures/denials become graphable typed evidence;
LISH exposes a coherent native module workflow;
module selection/execution remains independent of Hackpert reasoning strategy;
passive authority cannot execute effectful modules;
external-framework interoperability cannot bypass Hackmode scope or effect admission;
deterministic local fixtures prove catalog -> configure -> run -> evidence -> inspect -> cancel lifecycle;
native Hackmode modules generated by #191 can target this framework without a Metasploit runtime dependency.

Non-goals

No Ruby/MSF internal API compatibility requirement.
No unrestricted payload generation/execution primitive.
No second shell or standalone framework database.
No direct module writes to Tek9.
No module-owned target scope.
No authority changes caused by module family or selection.

First slice

Implement the smallest deterministic native module fixture proving: register -> search/info -> instantiate -> validate options -> execute one read-only capability through the canonical provider path -> persist typed evidence -> inspect from LISH/test surface.

## Mission Build a **native Hackmode module framework** that captures the useful operator and architecture concepts people expect from Metasploit-style frameworks while remaining idiomatic to Hackmode's Common Lisp + StarLang + Tek9 + Hackpert architecture. This is **not** a port of Metasploit internals and does not make Metasploit the source of truth. The goal is conceptual parity where useful: ```text module catalog / search / info module families use/select module structured options + defaults operation/workspace scoping check / run lifecycle background jobs interactive run/session handles result/evidence capture module metadata + references LISH-native operator UX ``` Hackmode remains authoritative for operation scope, capabilities/providers, effects, canonical state, evidence, and policy. ## Architectural placement ```text LISH / Emacs / clients ↓ Hackmode module framework catalog / metadata / option schemas module selection + instantiated module runs jobs + session/run handles ↓ Hackmode capability/provider runtime ↓ operation scope + authority/effect admission ↓ provider execution / observation ↓ Tek9 graph + findings + evidence ↓ Hackpert / Prolog-RLM reasoning over typed state ``` Do not create a second execution engine, second operation database, second capability registry, or second authority plane. ## Metasploit-inspired concept mapping The framework should provide native equivalents for concepts such as: | Familiar concept | Hackmode-native equivalent | | --- | --- | | module | typed module descriptor + implementation binding | | exploit/check module | scoped active verification/action module with explicit authority requirements | | auxiliary/scanner | observation/recon/detection module | | post module | operation/session-scoped follow-up module using existing authorized capability handles | | payload/handler concept | typed interactive capability/session contract where applicable; no ambient executable authority | | datastore/options | typed immutable/default + per-operation/per-run option layers | | workspace | canonical Hackmode operation | | jobs | supervised StarLang module-run jobs | | sessions | typed run/session handles linked to operation/evidence graph | | search/info/show | catalog queries over module metadata | | console | LISH native module UX | These are conceptual mappings, not requirements to preserve Ruby APIs, file layout, command syntax, or unrestricted payload semantics. ## Required child tracks Create/maintain separate implementation epics for: 1. module contract, families, registry, discovery, metadata and lifecycle; 2. typed options/datastore/config layering and validation; 3. supervised module runs, jobs, cancellation, result/evidence lifecycle and typed sessions; 4. LISH module console/search/use/info/options/run/jobs/sessions UX; 5. compatibility/interoperability boundary for external frameworks such as Metasploit without importing their authority model; 6. conformance fixtures and documentation proving native framework behavior. ## Module families Initial registry should support extensible categories rather than hard-coded dispatch logic. Families may include: - recon / discovery; - scanner / auxiliary observation; - detection / corroboration; - active verification / exploit-oriented module; - protocol/service interaction; - operation/session follow-up; - evidence collection; - reporting / artifact production; - framework adapter. The family affects metadata, validation and policy expectations but does not itself grant capability authority. ## Core invariants - module discovery does not grant execution permission; - selecting a module does not change Hackpert `passive|active` authority; - every effectful operation still crosses the canonical Hackmode scope/capability/effect boundary; - module options are typed and validated before dispatch; - module output is typed result/evidence, not opaque canonical state mutation; - module runs have stable operation/run/module identities; - cancellation is first-class and suppresses later effects from cancelled jobs; - background execution uses existing StarLang supervision rather than ad-hoc threads/process managers; - Tek9 remains canonical for operation/evidence state; - Hackpert/Prolog-RLM may select or reason about modules but do not bypass the Common Lisp execution boundary; - local-first operation works without Prolog-RLM or an LLM. ## Relationship to existing issues - #24 — Hackpert expert layer over canonical Hackmode state. - #27 — active typed action/state-delta orchestration. - #14 / #178 — LISH and expert/operator surfaces. - #191 — artifact generation can emit native Hackmode module artifacts, but this epic owns the runtime/framework they target. - `lost-rob0t/prolog-rlm#389` — generic reasoning harness consumed by Hackmode; it does not own this module framework. ## Acceptance - [ ] a first-class native module descriptor/schema exists; - [ ] modules are searchable and introspectable by typed metadata; - [ ] an operator can select a module and instantiate a run without mutating global module metadata; - [ ] typed options/defaults/per-operation/per-run overrides are validated deterministically; - [ ] modules dispatch only through canonical Hackmode capabilities/providers; - [ ] background runs appear as supervised jobs with cancellation/status; - [ ] long-lived/interactive activity is represented by typed session/run handles linked to evidence; - [ ] all results/failures/denials become graphable typed evidence; - [ ] LISH exposes a coherent native module workflow; - [ ] module selection/execution remains independent of Hackpert reasoning strategy; - [ ] passive authority cannot execute effectful modules; - [ ] external-framework interoperability cannot bypass Hackmode scope or effect admission; - [ ] deterministic local fixtures prove catalog -> configure -> run -> evidence -> inspect -> cancel lifecycle; - [ ] native Hackmode modules generated by #191 can target this framework without a Metasploit runtime dependency. ## Non-goals - No Ruby/MSF internal API compatibility requirement. - No unrestricted payload generation/execution primitive. - No second shell or standalone framework database. - No direct module writes to Tek9. - No module-owned target scope. - No authority changes caused by module family or selection. ## First slice Implement the smallest deterministic native module fixture proving: register -> search/info -> instantiate -> validate options -> execute one read-only capability through the canonical provider path -> persist typed evidence -> inspect from LISH/test surface.

nsaspy referenced this issue

2026-09-05 08:18:43 +00:00

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

nsaspy commented

2026-09-05 08:18:47 +00:00

Author

Owner

Child epic index

The native framework queue is now split so workers can execute in parallel without collapsing the architecture into one issue:

#193 — module contract, families, registry, discovery, lifecycle
#194 — typed options / datastore-style layering / validation / operation scoping
#195 — supervised runs, jobs, cancellation, evidence, typed session handles
#196 — LISH module console (search/use/info/options/run/jobs/sessions)
#197 — external-framework interoperability / Metasploit adapter boundary
#198 — SDK, fixtures, conformance matrix, packaging, docs

Existing #191 remains the artifact-generation track. It can generate native Hackmode modules that target this framework; #192-#198 own the runtime/operator framework itself.

Related execution/reasoning authorities remain #24/#27/#28/#29 and lost-rob0t/prolog-rlm#389; none of these child epics should create a parallel authority plane.

## Child epic index The native framework queue is now split so workers can execute in parallel without collapsing the architecture into one issue: - #193 — module contract, families, registry, discovery, lifecycle - #194 — typed options / datastore-style layering / validation / operation scoping - #195 — supervised runs, jobs, cancellation, evidence, typed session handles - #196 — LISH module console (`search/use/info/options/run/jobs/sessions`) - #197 — external-framework interoperability / Metasploit adapter boundary - #198 — SDK, fixtures, conformance matrix, packaging, docs Existing #191 remains the artifact-generation track. It can generate native Hackmode modules that target this framework; #192-#198 own the runtime/operator framework itself. Related execution/reasoning authorities remain #24/#27/#28/#29 and `lost-rob0t/prolog-rlm#389`; none of these child epics should create a parallel authority plane.