[PR #4204] [CLOSED] docs(skill): add cryptographic algorithm recovery reference #6124

Closed
opened 2026-10-31 01:12:02 +00:00 by bsakaguchi · 0 comments
Owner

📋 Pull Request Information

Original PR: https://github.com/morluto/rea/pull/4204
Author: @icloudza
Created: 10/15/2026
Status: ❌ Closed

Base: main ← Head: docs/crypto-algorithm-recovery-reference


📝 Commits (3)

  • 8af7779 docs(skill): add cryptographic algorithm recovery reference
  • 946c7b4 docs(skill): expand crypto recovery constant cheat sheet
  • 0205945 fix(skill): register crypto recovery reference and correct its constants

📊 Changes

4 files changed (+227 additions, -0 deletions)

View changed files

📝 .agents/skills/reverse-engineer-anything/SKILL.md (+7 -0)
➕ .agents/skills/reverse-engineer-anything/references/cryptographic-algorithm-recovery.md (+218 -0)
📝 src/application/SetupSkill.ts (+1 -0)
📝 tests/boundary/filesystem/setupSkill.test.ts (+1 -0)

📄 Description

Summary

Add a reference workflow to the reverse-engineer-anything skill for
identifying — and, where the trace's own observed inputs allow, reconstructing —
a cryptographic, signing, or encoding algorithm from a recorded execution trace
or passive runtime observation, and route to it from SKILL.md.

Documentation-only. No new provider, tool, engine, or target interaction.

Problem and expected behavior

The skill's references cover capture and evidence handling (evidence-workflows,
runtime-observation, native-and-artifacts, javascript-applications,
android-applications, connection-and-recovery) but none gives a methodology
for the recurring question "which cryptographic algorithm produced this output,
and can it be reconstructed from the trace?"
An agent handed a trace plus a
ciphertext/token/MAC/signature has no routed, evidence-disciplined path for it
today.

Expected behavior with this doc: the agent correlates multiple signals (constant
fingerprints, instruction fingerprints, data-flow shape, I/O boundary) instead
of single-point attribution, runs a four-phase recovery (locate → reconstruct
data flow → identify + modification check → closed-loop byte-exact verification),
and reports an identification/reconstruction with evidence anchors and explicit
unknowns — never an unverified claim.

Change and scope

Adds references/cryptographic-algorithm-recovery.md and one route line in
SKILL.md. The doc is written in the existing reference style (evidence record,
authority, limitations, unknowns; hypotheses are not causal proof).

Intentionally not included: anything that defeats a protection. The doc is
identification-and-evidence only. Static protection detection
(packer / control-flow obfuscation / VM / white-box) is included as
recognize-and-report; the documented behavior on hitting such protection is to
identify it, report it, record_unknown, and stop. Protection defeat, VM
bytecode lifting, white-box key extraction, and signature/token forgery are
explicitly out of scope per CONTRIBUTING.

Follow the contribution scope.

  • Contribution scope fit and linked maintainer decision: documentation-only,
    no new provider and no capability involving target execution, injection,
    mutation, or protection recovery. No prior scope issue was opened; this PR
    introduces a new workflow area (cryptographic recovery) in a sensitive domain,
    so a maintainer scope read of the doc's boundary is explicitly invited. Happy
    to move this to a design discussion or narrow it if preferred.

Contract and boundary impact

  • Semantic owner and earliest changed stage: reverse-engineer-anything skill, authored instructions only.
  • Contribution scope fit and linked maintainer decision: see above — documentation-only; maintainer scope read invited; no linked decision yet.
  • CLI and MCP/tool-catalog contract: none. No tool, input, or output changed.
  • Provider, bridge, target-format, or platform compatibility: none.
  • Evidence, artifact, provenance, or reconstruction contract: none changed; the doc reinforces existing evidence/unknown discipline and cites existing references.
  • Target selection, authority, upstream behavior, and cleanup details: not applicable — no target interaction.
  • Generated metadata / package / installation impact: none. The skill metadata.version is unchanged, so metadata:check output is unchanged; no skills/ build output or docs/public/product-catalog.json edited.

Expected effects:

  • Read existing files or captured data.
  • Launch or attach to a process.
  • Inject instrumentation or run scripts/code.
  • Change process memory, registers, files, or configuration.
  • Contact network services.
  • Recover protected code or work around protections.
  • Documentation or usability only; no target interaction.
  • Not sure yet; investigation or maintainer guidance needed.

Evidence and regression coverage

Documentation-only change; evidence is source/link based.

  • Tests added or updated: none (documentation-only).
  • Base reproduction or other evidence: on main, the skill has no reference for
    cryptographic algorithm recovery; this adds one and routes to it.
  • User-visible CLI/MCP output (if applicable): none.
  • Remaining proof gaps: full CI (docs:check, metadata:check, lint,
    format:check) has not been run locally; it runs on this PR.

Validation performed

Only checks that actually ran, with results:

  • git diff --cached — exactly two files: new
    references/cryptographic-algorithm-recovery.md and a one-line route addition
    in SKILL.md; no other files touched.
  • Link/path check — the doc's internal links resolve to existing files
    (references/runtime-observation.md, references/evidence-workflows.md,
    references/native-and-artifacts.md), and SKILL.md now links the new file,
    which exists.
  • Version/catalog check — SKILL.md metadata.version left unchanged, so no
    generated package metadata or skills/ build output needs regeneration.

Not yet run locally (will run in CI): npm run docs:check, metadata:check,
lint, format:check.

Compatibility, safety, and release

  • Breaking changes or migration steps: none.
  • Real Hopper/Ghidra, browser, or OS coverage: not applicable (documentation-only).
  • Package or release metadata impact: none (skill version unchanged).
  • Security, privacy, process, or containment review: the doc is identification
    and evidence only and explicitly defers all protection-defeat workflows to
    CONTRIBUTING; no credentials, private samples, or target data included.

Author readiness

Human owner: @icloudza

  • I reviewed the final diff and relevant existing code, understand the change and its edge cases, and take responsibility for the complete PR, including AI-assisted work.
  • I checked the evidence above, confirmed it supports the current change, and recorded meaningful validation gaps.
  • I declare this PR ready for initial maintainer review.

Before merge

  • This PR addresses a concrete problem or an agreed enhancement.
  • Material scope and authority questions are resolved, and any required maintainer scope decision covers the final diff.
  • The PR has one focused outcome and the title follows type(scope): outcome.
  • Related issue is linked, or the reason for not linking one is stated above.
  • Tests cover changed observable behavior and meaningful failure paths.
  • Owning docs, contracts, and generated metadata are updated where needed.
  • User-visible CLI/MCP changes include representative output.
  • I checked the final diff for secrets, unrelated cleanup, and unsupported claims.

🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.

## 📋 Pull Request Information **Original PR:** https://github.com/morluto/rea/pull/4204 **Author:** [@icloudza](https://github.com/icloudza) **Created:** 10/15/2026 **Status:** ❌ Closed **Base:** `main` ← **Head:** `docs/crypto-algorithm-recovery-reference` --- ### 📝 Commits (3) - [`8af7779`](https://github.com/morluto/rea/commit/8af7779f38384563489835050da6496325465cae) docs(skill): add cryptographic algorithm recovery reference - [`946c7b4`](https://github.com/morluto/rea/commit/946c7b4552054805c1c036d96cb973c8d0719d90) docs(skill): expand crypto recovery constant cheat sheet - [`0205945`](https://github.com/morluto/rea/commit/0205945f338812d7eaaca5ca76fa92d374f916c9) fix(skill): register crypto recovery reference and correct its constants ### 📊 Changes **4 files changed** (+227 additions, -0 deletions) <details> <summary>View changed files</summary> 📝 `.agents/skills/reverse-engineer-anything/SKILL.md` (+7 -0) ➕ `.agents/skills/reverse-engineer-anything/references/cryptographic-algorithm-recovery.md` (+218 -0) 📝 `src/application/SetupSkill.ts` (+1 -0) 📝 `tests/boundary/filesystem/setupSkill.test.ts` (+1 -0) </details> ### 📄 Description ## Summary Add a reference workflow to the `reverse-engineer-anything` skill for identifying — and, where the trace's own observed inputs allow, reconstructing — a cryptographic, signing, or encoding algorithm from a recorded execution trace or passive runtime observation, and route to it from `SKILL.md`. Documentation-only. No new provider, tool, engine, or target interaction. ## Problem and expected behavior The skill's references cover capture and evidence handling (`evidence-workflows`, `runtime-observation`, `native-and-artifacts`, `javascript-applications`, `android-applications`, `connection-and-recovery`) but none gives a methodology for the recurring question *"which cryptographic algorithm produced this output, and can it be reconstructed from the trace?"* An agent handed a trace plus a ciphertext/token/MAC/signature has no routed, evidence-disciplined path for it today. Expected behavior with this doc: the agent correlates multiple signals (constant fingerprints, instruction fingerprints, data-flow shape, I/O boundary) instead of single-point attribution, runs a four-phase recovery (locate → reconstruct data flow → identify + modification check → closed-loop byte-exact verification), and reports an identification/reconstruction with evidence anchors and explicit unknowns — never an unverified claim. ## Change and scope Adds `references/cryptographic-algorithm-recovery.md` and one route line in `SKILL.md`. The doc is written in the existing reference style (evidence record, authority, limitations, unknowns; hypotheses are not causal proof). Intentionally **not** included: anything that defeats a protection. The doc is identification-and-evidence only. Static protection **detection** (packer / control-flow obfuscation / VM / white-box) is included as recognize-and-report; the documented behavior on hitting such protection is to identify it, report it, `record_unknown`, and stop. Protection **defeat**, VM bytecode lifting, white-box key extraction, and signature/token forgery are explicitly out of scope per CONTRIBUTING. Follow the [contribution scope](https://github.com/morluto/rea/blob/main/CONTRIBUTING.md#contribution-scope). - **Contribution scope fit and linked maintainer decision:** documentation-only, no new provider and no capability involving target execution, injection, mutation, or protection recovery. No prior scope issue was opened; this PR introduces a new workflow area (cryptographic recovery) in a sensitive domain, so a maintainer scope read of the doc's boundary is explicitly invited. Happy to move this to a design discussion or narrow it if preferred. ## Contract and boundary impact - Semantic owner and earliest changed stage: `reverse-engineer-anything` skill, authored instructions only. - Contribution scope fit and linked maintainer decision: see above — documentation-only; maintainer scope read invited; no linked decision yet. - CLI and MCP/tool-catalog contract: none. No tool, input, or output changed. - Provider, bridge, target-format, or platform compatibility: none. - Evidence, artifact, provenance, or reconstruction contract: none changed; the doc reinforces existing evidence/unknown discipline and cites existing references. - Target selection, authority, upstream behavior, and cleanup details: not applicable — no target interaction. - Generated metadata / package / installation impact: none. The skill `metadata.version` is unchanged, so `metadata:check` output is unchanged; no `skills/` build output or `docs/public/product-catalog.json` edited. Expected effects: - [ ] Read existing files or captured data. - [ ] Launch or attach to a process. - [ ] Inject instrumentation or run scripts/code. - [ ] Change process memory, registers, files, or configuration. - [ ] Contact network services. - [ ] Recover protected code or work around protections. - [x] Documentation or usability only; no target interaction. - [ ] Not sure yet; investigation or maintainer guidance needed. ## Evidence and regression coverage Documentation-only change; evidence is source/link based. - Tests added or updated: none (documentation-only). - Base reproduction or other evidence: on `main`, the skill has no reference for cryptographic algorithm recovery; this adds one and routes to it. - User-visible CLI/MCP output (if applicable): none. - Remaining proof gaps: full CI (`docs:check`, `metadata:check`, lint, `format:check`) has not been run locally; it runs on this PR. ## Validation performed Only checks that actually ran, with results: - `git diff --cached` — exactly two files: new `references/cryptographic-algorithm-recovery.md` and a one-line route addition in `SKILL.md`; no other files touched. - Link/path check — the doc's internal links resolve to existing files (`references/runtime-observation.md`, `references/evidence-workflows.md`, `references/native-and-artifacts.md`), and `SKILL.md` now links the new file, which exists. - Version/catalog check — `SKILL.md` `metadata.version` left unchanged, so no generated package metadata or `skills/` build output needs regeneration. Not yet run locally (will run in CI): `npm run docs:check`, `metadata:check`, `lint`, `format:check`. ## Compatibility, safety, and release - Breaking changes or migration steps: none. - Real Hopper/Ghidra, browser, or OS coverage: not applicable (documentation-only). - Package or release metadata impact: none (skill version unchanged). - Security, privacy, process, or containment review: the doc is identification and evidence only and explicitly defers all protection-defeat workflows to CONTRIBUTING; no credentials, private samples, or target data included. ## Author readiness Human owner: @icloudza <!-- icloudza: these three are yours to check — do not let them be checked on your behalf. Flip the PR from draft to "Ready for review" only after you have. --> - [ ] I reviewed the final diff and relevant existing code, understand the change and its edge cases, and take responsibility for the complete PR, including AI-assisted work. - [ ] I checked the evidence above, confirmed it supports the current change, and recorded meaningful validation gaps. - [ ] I declare this PR ready for initial maintainer review. ## Before merge - [x] This PR addresses a concrete problem or an agreed enhancement. - [ ] Material scope and authority questions are resolved, and any required maintainer scope decision covers the final diff. <!-- pending a maintainer scope read; see Change and scope --> - [x] The PR has one focused outcome and the title follows `type(scope): outcome`. - [x] Related issue is linked, or the reason for not linking one is stated above. <!-- no issue; opened directly for a maintainer scope read, see Change and scope --> - [ ] Tests cover changed observable behavior and meaningful failure paths. <!-- not applicable: documentation-only --> - [x] Owning docs, contracts, and generated metadata are updated where needed. <!-- SKILL.md route added; no generated metadata change --> - [ ] User-visible CLI/MCP changes include representative output. <!-- not applicable --> - [x] I checked the final diff for secrets, unrelated cleanup, and unsupported claims. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
bsakaguchi 2026-10-31 01:12:02 +00:00
Sign in to join this conversation.
No milestone
No project
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
morluto/rea#6124
No description provided.