fix: honor partition boundaries when a finding overruns them - #33
Merged
Merged
Conversation
A finding's size comes from its own header, so a stale superblock left in unpartitioned space can claim an extent covering partitions written long after it. The scanner skipped that whole extent, so the superblocks of the partitions inside it were never validated: they went missing entirely rather than being demoted to also_matched. Clamp the skip-ahead at the next partition start, and stop resolve() from demoting a finding that begins exactly on a partition boundary.
nmatt0
added a commit
that referenced
this pull request
Sep 17, 2026
test: regression for the partition-boundary overrun fix (#33)
jacobocasado
pushed a commit
to starredjaco/moria
that referenced
this pull request
Sep 21, 2026
A stale/oversized finding must not hide a real partition behind it: the scanner clamps its skip-ahead at partition boundaries, and resolve() no longer demotes a finding that starts exactly on a partition boundary. Adds tests/test_partition_overlap.py — fully self-contained (a hand-built GPT plus synthetic ext superblocks, no mkfs tools). It is a differential: a stale ext at 0x8000 overruns a real partition at 0x40000; with the GPT present the real partition is recovered, and with the GPT zeroed the same stale finding hides it. That both asserts the fix and confirms the partition table is what makes the difference (it fails on pre-fix master). Wired into run.sh and CTest.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Updates the scanning logic to treat a discovered partition table as the authoritative source for partition boundaries, so a finding's own recorded size can no longer hide a real partition behind it.
In a dumped firmware image, I had the issue that various stale or false positive findings overlapping with real partitions caused those real partitions not to be extracted. A stale ext superblock at 0x200000 records an 80 MB size, so its extent runs to 0x5200000 — well past the start of the 1.4 GB partition at 0x1800000. The scanner skipped that entire extent, so the real partition was never validated and simply went missing.
Moria before the fix:
Moria after the fix:
Note how after the fix, moria cleanly detects and extracts the actual partitions. Most of the previously listed findings are just files inside those partitions, and are now extracted properly by the ext extractor under their real names and paths. Nothing is lost by them disappearing from the listing: certificate, elf and private_key are identify-only types with no extractor, so they never produced a single file.
The stale ext partition at 0x200000 is still reported and extracted itself, but its recorded size no longer lets the scanner skip past 0x1800000. In this firmware image, a similar issue cause p4 to be skipped as well, which this also resolves. Any findings cleanly fitting between the partitions in the partition table are unaffected and still extracted as before, and an image without a partition table behaves exactly as it did.
The partition table is used for boundaries only, not as a list of things to extract. For example, as p1 holds no recognisable filesystem, it is not extracted like before.
All present tests pass.
Note: the code was written by Claude Code. This PR description was largely written by me with validation from Claude, and code and functionality was all manually verified.