[GH-ISSUE #1853] [Feature] Make partial firmware extraction recovery explicit for missing dependencies #630

New issue

Closed

opened 2026-10-15 18:26:47 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-15 18:26:47 +00:00

Owner

Originally created by @N0zoM1z0 on GitHub (Oct 11, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/1853

Before submitting

I searched open and closed issues and pull requests for related work.
I removed credentials, private paths, and sensitive target data.

Area

Evidence, artifacts, or reconstruction.

Current limitation

extract_firmware can retain a carved filesystem region with partial coverage when an extractor dependency is missing. The user needs a clear account of which bytes are retained, which contents remain unexamined and which existing REA actions can continue the investigation.

Use cases

Recover a selected member from a retained filesystem region after incomplete recursive firmware extraction.

Desired outcome and success criteria

Explain the exact missing dependency and extraction stage.
Preserve original region offsets/digests and distinguish carving from content extraction.
Describe a supported continuation using already configured capabilities where available.
Retain partial/unknown coverage rather than implying a corrupt target or empty filesystem.

Authority boundaries and non-goals

No unrelated software installation, implicit target execution, lost carved evidence or automatic completeness claim.

Alternatives considered

The current partial result preserves the source region and named dependency. A complete dependency stack is a separate configuration and must be verified explicitly.

Possible direction

Inspect the producing extractor diagnostics and typed continuation/recovery contract; use existing firmware inspection/extraction operations.

Originally created by @N0zoM1z0 on GitHub (Oct 11, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/1853 ### Before submitting - [x] I searched open and closed issues and pull requests for related work. - [x] I removed credentials, private paths, and sensitive target data. ### Area Evidence, artifacts, or reconstruction. ### Current limitation `extract_firmware` can retain a carved filesystem region with partial coverage when an extractor dependency is missing. The user needs a clear account of which bytes are retained, which contents remain unexamined and which existing REA actions can continue the investigation. ### Use cases Recover a selected member from a retained filesystem region after incomplete recursive firmware extraction. ### Desired outcome and success criteria - Explain the exact missing dependency and extraction stage. - Preserve original region offsets/digests and distinguish carving from content extraction. - Describe a supported continuation using already configured capabilities where available. - Retain partial/unknown coverage rather than implying a corrupt target or empty filesystem. ### Authority boundaries and non-goals No unrelated software installation, implicit target execution, lost carved evidence or automatic completeness claim. ### Alternatives considered The current partial result preserves the source region and named dependency. A complete dependency stack is a separate configuration and must be verified explicitly. ### Possible direction Inspect the producing extractor diagnostics and typed continuation/recovery contract; use existing firmware inspection/extraction operations.

bsakaguchi

2026-10-15 18:26:47 +00:00