nsaspy/hackmode
1
0
Fork 0
Code Issues 46 Pull requests 55 Projects Releases Packages Wiki Activity Actions

Adapt Hackpert into Hackmode as an optional Prolog expert layer #138

Closed
nsaspy wants to merge 13 commits from feature/24-hackpert-expert-layer into master
pull from: feature/24-hackpert-expert-layer
merge into: nsaspy:master
Conversation 2 Commits 13 Files changed 10 +919 -4
nsaspy commented 2026-09-04 20:37:22 +00:00
Owner
Copy link

Summary

Adapts the useful Hackpert reasoning ideas into the canonical Hackmode runtime without importing its legacy operation/target state model or direct tool runner.

Closes #24 when the foundational expert bridge is accepted; the expanded graph/KB/expert-engine program is explicitly tracked in #24 as follow-on implementation slices rather than being hidden in comments.

The passive traffic-intelligence path is now tracked separately as IPX in #26, with its architecture contract added to this PR in docs/architecture/ipx.org.

What changed

  • optional SWI-Prolog expert bridge in Hackmode core
  • deterministic projection of current operation, typed assets, and capability providers into disposable Prolog facts
  • fixed-goal query boundary with escaped data facts
  • target classification for URL/domain/IPv4/IPv6/unknown
  • deterministic provider/capability recommendations by typed input compatibility and priority
  • typed Common Lisp recommendation results and explicit unavailable/query-failed conditions
  • no provider execution or Tek9 mutation from expert recommendation
  • regression coverage for escaping/injection safety, missing SWI behavior, live classification, recommendation ordering, and read-only behavior
  • SWI-Prolog added to CI and Nix dev shell
  • expanded Hackpert architecture incorporating graph-shaped outputs, scoped KBs, learning/promotion, plans/playbooks, and expert-family direction
  • added IPX passive traffic architecture: capture proxy -> append-only evidence spool -> typed exchange parser -> passive Hackpert graph delta -> Common Lisp acceptance -> Tek9/KB + StarIntel durable outbox

Architecture correction from #24

Hackpert is an expert plane that consumes canonical state plus typed tool calls/results and ultimately returns a typed graph delta.

Hackmode state + tool call/result
            -> deterministic snapshot
            -> Prolog reasoning
            -> graph delta
            -> Common Lisp validation/effect boundary
            -> Tek9/KB and/or provider dispatch

Prolog never mutates canonical state. The Common Lisp wrapper owns every effect.

The graph direction covers tool calls, inputs, outputs, findings, discovered assets, success/failure evidence, attack/recon steps, plans/playbooks, KB provenance, and—through IPX—passively observed application traffic.

KB direction

The architecture defines three scopes:

  • operational KB — per-operation working knowledge, failed paths, current observations, temporary fuzz/word candidates, active plans, recent execution/traffic graph context
  • long-term KB — reusable validated working paths, useful payload/fuzz/word knowledge, stable constraints, repeated failure conditions, reusable playbook/fingerprint fragments
  • global KB / looting — optional explicit export of selected long-term knowledge for reuse across operations

Prolog may propose promotion/export candidates. Common Lisp validates and persists them. Global looting is explicit, never implicit.

IPX passive traffic stack (#26)

IPX adds a passive evidence path without weakening the Hackpert authority boundary:

client/browser/tool
    -> IPX capture proxy
    -> append-only capture file/spool
    -> parser/tailer actor
    -> typed HTTP/application exchanges
    -> passive Hackpert analysis
    -> typed graph delta
    -> Common Lisp validation
    -> Tek9 operational graph/KB
    -> StarIntel projection + durable outbox

Key invariants:

  • capture evidence is append-only/immutable from the analyzer's perspective
  • Hackpert never rewrites capture files or directly ingests StarIntel documents
  • passive analysis never implicitly performs scanning, replay, exploitation, or provider execution
  • raw traffic may contain secrets, so derived Prolog/StarIntel/long-term/global projections redact credentials/cookies/tokens by default and retain evidence references/digests instead
  • Hackpert or StarIntel may be offline while capture continues
  • replaying the same capture is idempotent
  • HTTP(S) is the first protocol; WebSocket/SSE/raw TCP/DNS can be later adapters

See docs/architecture/ipx.org and #26 for the full contract and acceptance proof.

Learning / expert goals captured from #24

  • import wordlists/fuzz lists as provenance-carrying KB data
  • promote validated working attacks/recon paths into long-term KB candidates
  • retain failed attack paths as negative graph evidence for orchestration
  • make attack plans and playbooks first-class graph structures
  • build shared-substrate experts for recon, web fuzzing, SQLi, OOB testing, XSS, and blind XSS
  • evaluate Prolog-RLM later, only after this direct graph/KB/effect boundary is stable

Deliberately not ported

  • HACKMODE_OP / HACKMODE_PATH authority
  • targets.txt / scope text files / mutable expert state files
  • Hackpert REPL
  • Prolog run_tool
  • direct process execution from expert rules
  • direct Prolog mutation of Tek9, KB state, capture evidence, or StarIntel

Execution stays behind Hackmode's existing provider/job path.

Scope of this PR

This PR remains the foundation slice: optional Prolog bridge, safe snapshots, classification, recommendations, tests, and the now-correct architecture contracts.

The next implementation slices tracked in #24/#26 are:

  1. typed tool-call/result execution graph persisted by Common Lisp/Tek9
  2. operational + long-term KB storage
  3. explicit global-KB export/looting API
  4. graph/KB facts into Prolog + typed graph deltas back
  5. attack-plan/playbook primitives
  6. IPX append-only traffic capture + parser/replay substrate
  7. passive Hackpert traffic analysis + StarIntel projection/outbox
  8. recon expert, then specialized fuzzing/SQLi/OOB/XSS/blind-XSS experts
  9. provenance-aware wordlist/fuzz-list import and success/failure promotion workflows
  10. LISH/Emacs graph/plan/KB/IPX inspection
  11. possible Prolog-RLM integration later
## Summary Adapts the useful Hackpert reasoning ideas into the canonical Hackmode runtime without importing its legacy operation/target state model or direct tool runner. Closes #24 when the foundational expert bridge is accepted; the expanded graph/KB/expert-engine program is explicitly tracked in #24 as follow-on implementation slices rather than being hidden in comments. The passive traffic-intelligence path is now tracked separately as **IPX** in #26, with its architecture contract added to this PR in `docs/architecture/ipx.org`. ## What changed - optional SWI-Prolog expert bridge in Hackmode core - deterministic projection of current operation, typed assets, and capability providers into disposable Prolog facts - fixed-goal query boundary with escaped data facts - target classification for URL/domain/IPv4/IPv6/unknown - deterministic provider/capability recommendations by typed input compatibility and priority - typed Common Lisp recommendation results and explicit unavailable/query-failed conditions - no provider execution or Tek9 mutation from expert recommendation - regression coverage for escaping/injection safety, missing SWI behavior, live classification, recommendation ordering, and read-only behavior - SWI-Prolog added to CI and Nix dev shell - expanded Hackpert architecture incorporating graph-shaped outputs, scoped KBs, learning/promotion, plans/playbooks, and expert-family direction - added IPX passive traffic architecture: capture proxy -> append-only evidence spool -> typed exchange parser -> passive Hackpert graph delta -> Common Lisp acceptance -> Tek9/KB + StarIntel durable outbox ## Architecture correction from #24 Hackpert is an expert plane that consumes canonical state plus **typed tool calls/results** and ultimately returns a **typed graph delta**. ```text Hackmode state + tool call/result -> deterministic snapshot -> Prolog reasoning -> graph delta -> Common Lisp validation/effect boundary -> Tek9/KB and/or provider dispatch ``` Prolog never mutates canonical state. The Common Lisp wrapper owns every effect. The graph direction covers tool calls, inputs, outputs, findings, discovered assets, success/failure evidence, attack/recon steps, plans/playbooks, KB provenance, and—through IPX—passively observed application traffic. ## KB direction The architecture defines three scopes: - **operational KB** — per-operation working knowledge, failed paths, current observations, temporary fuzz/word candidates, active plans, recent execution/traffic graph context - **long-term KB** — reusable validated working paths, useful payload/fuzz/word knowledge, stable constraints, repeated failure conditions, reusable playbook/fingerprint fragments - **global KB / looting** — optional explicit export of selected long-term knowledge for reuse across operations Prolog may propose promotion/export candidates. Common Lisp validates and persists them. Global looting is explicit, never implicit. ## IPX passive traffic stack (#26) IPX adds a passive evidence path without weakening the Hackpert authority boundary: ```text client/browser/tool -> IPX capture proxy -> append-only capture file/spool -> parser/tailer actor -> typed HTTP/application exchanges -> passive Hackpert analysis -> typed graph delta -> Common Lisp validation -> Tek9 operational graph/KB -> StarIntel projection + durable outbox ``` Key invariants: - capture evidence is append-only/immutable from the analyzer's perspective - Hackpert never rewrites capture files or directly ingests StarIntel documents - passive analysis never implicitly performs scanning, replay, exploitation, or provider execution - raw traffic may contain secrets, so derived Prolog/StarIntel/long-term/global projections redact credentials/cookies/tokens by default and retain evidence references/digests instead - Hackpert or StarIntel may be offline while capture continues - replaying the same capture is idempotent - HTTP(S) is the first protocol; WebSocket/SSE/raw TCP/DNS can be later adapters See `docs/architecture/ipx.org` and #26 for the full contract and acceptance proof. ## Learning / expert goals captured from #24 - import wordlists/fuzz lists as provenance-carrying KB data - promote validated working attacks/recon paths into long-term KB candidates - retain failed attack paths as negative graph evidence for orchestration - make attack plans and playbooks first-class graph structures - build shared-substrate experts for recon, web fuzzing, SQLi, OOB testing, XSS, and blind XSS - evaluate Prolog-RLM later, only after this direct graph/KB/effect boundary is stable ## Deliberately not ported - `HACKMODE_OP` / `HACKMODE_PATH` authority - `targets.txt` / scope text files / mutable expert state files - Hackpert REPL - Prolog `run_tool` - direct process execution from expert rules - direct Prolog mutation of Tek9, KB state, capture evidence, or StarIntel Execution stays behind Hackmode's existing provider/job path. ## Scope of this PR This PR remains the **foundation slice**: optional Prolog bridge, safe snapshots, classification, recommendations, tests, and the now-correct architecture contracts. The next implementation slices tracked in #24/#26 are: 1. typed tool-call/result execution graph persisted by Common Lisp/Tek9 2. operational + long-term KB storage 3. explicit global-KB export/looting API 4. graph/KB facts into Prolog + typed graph deltas back 5. attack-plan/playbook primitives 6. IPX append-only traffic capture + parser/replay substrate 7. passive Hackpert traffic analysis + StarIntel projection/outbox 8. recon expert, then specialized fuzzing/SQLi/OOB/XSS/blind-XSS experts 9. provenance-aware wordlist/fuzz-list import and success/failure promotion workflows 10. LISH/Emacs graph/plan/KB/IPX inspection 11. possible Prolog-RLM integration later
Document IPX passive traffic expert stack
Some checks failed
agent-pr-serialization / one-open-pr-per-agent-lane (pull_request_target) Failing after 1s
Details
core / common-lisp-core (pull_request) Failing after 45s
Details
monorepo / hygiene (pull_request) Successful in 4m18s
Details
5be40e8838
nsaspy commented 2026-09-04 20:38:24 +00:00
Author
Owner
Copy link

No there will be 2 engine modes of hackpert

  1. Passive which is the one that does not mutate simply observes
  2. Is active. Active is required for the SQLI/fuzzing engines
  3. Hackpert already runs and orchestrate tool runs
  4. Hackers needs intergration with lish shell
No there will be 2 engine modes of hackpert 1. Passive which is the one that does not mutate simply observes 2. Is active. Active is required for the SQLI/fuzzing engines 3. Hackpert already runs and orchestrate tool runs 4. Hackers needs intergration with lish shell
nsaspy commented 2026-09-04 20:38:25 +00:00
Author
Owner
Copy link

Corrected post-merge architecture per this comment.

PR #25 is now treated as the passive foundation only, not the final Hackpert authority model.

The intended model is:

  • passive mode: observe/reason/recommend only; no dispatch or canonical mutation;
  • active mode: orchestrate registered Hackmode providers, persist tool-call/result graph state, mutate operation-scoped graph/operational KB through typed Common Lisp APIs, and iterate on the resulting evidence.

Hackpert remains an orchestrator in active mode; the Common Lisp wrapper is the validated effect boundary rather than a blanket prohibition on mutation.

I updated parent tracker #24 and created #27 for the active-engine implementation, including LISH mode/run/graph/KB integration.

Corrected post-merge architecture per this comment. PR #25 is now treated as the **passive foundation only**, not the final Hackpert authority model. The intended model is: - **passive mode**: observe/reason/recommend only; no dispatch or canonical mutation; - **active mode**: orchestrate registered Hackmode providers, persist tool-call/result graph state, mutate operation-scoped graph/operational KB through typed Common Lisp APIs, and iterate on the resulting evidence. Hackpert remains an orchestrator in active mode; the Common Lisp wrapper is the validated effect boundary rather than a blanket prohibition on mutation. I updated parent tracker #24 and created #27 for the active-engine implementation, including LISH mode/run/graph/KB integration.
nsaspy closed this pull request 2026-09-04 20:50:11 +00:00
Some checks failed
agent-pr-serialization / one-open-pr-per-agent-lane (pull_request_target) Failing after 1s
Details
core / common-lisp-core (pull_request) Failing after 45s
Details
monorepo / hygiene (pull_request) Successful in 4m18s
Details

Pull request closed

Please reopen this pull request to perform a merge.
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels   
bug
Something isn't working

  
documentation
Improvements or additions to documentation

  
duplicate
This issue or pull request already exists

  
enhancement
New feature or request

  
feature
New feature or capability

  
good first issue
Good for newcomers

  
help wanted
Extra attention is needed

  
invalid
This doesn't seem right

  
question
Further information is requested

  
refactor
Code cleanup without behavior change

  
wontfix
This will not be worked on

No labels
bug
documentation
duplicate
enhancement
feature
good first issue
help wanted
invalid
question
refactor
wontfix
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
nsaspy/hackmode!138
No description provided.