PaperlayerView exact revision on arXiv

Source-linked AI summary

Scalpel3: A High-Performance Data Carving Architecture for Recovery of Fragmented Files

Karley Waguespack, Samuel Goodwin, George Hendrick, Samuel Hildebrand, Thomas Landaiche, Mingyang Li, Joshua McCain, Tyler Saizan, Jacob Tucker, James M. Ghawaly, Golden G. Richard

arXiv:2608.20363v2cs.DCcs.CR

TL;DR

Fragmented files challenge carvers built around contiguous storage, while publicly available frameworks combining contiguous and fragmented recovery have been lacking. Scalpel3 provides a massively threaded, extensible architecture for both, achieving high throughput in contiguous recovery and accelerating fragmented reassembly.

  • Problem

    Traditional signature-based carvers assume contiguous storage, while fragmented files require recovering noncontiguous blocks from raw data without filesystem metadata.

    Source: §1 · p. 2

  • Method

    Scalpel3 provides a massively parallel, modular carving framework in which format-specific validators and reassembly logic plug into shared recovery infrastructure.

    Source: §1 · p. 2, §10 · p. 46

  • Results

    Scalpel3 achieves high throughput for contiguous recovery and substantially accelerates fragmented reassembly; on GAP, runtime fell from 1,646 s with one thread to 104 s with 128.

    Source: §7.1 · p. 36, §10 · p. 46

  • Takeaways & Limitations

    The authors aim for the open-source release to provide a shared platform that lowers experimentation barriers and helps translate file-carving research into practical tools.

    Source: §10 · p. 46

    Fragmented reassembly is less accurate for formats without checkable internal structure, as entropy-coded JPEG data supports less accurate reordering than CRC-protected PNG.

    Source: §8 · p. 45

Abstract

from arXiv · show

File carving recovers files from raw storage without filesystem metadata, a key capability in digital forensics, data recovery, and digital exploration. Existing tools recover contiguous files effectively, but, to our knowledge, no publicly available, format-agnostic, high-performance framework exists in which researchers can develop and deploy new fragmented recovery strategies. Scalpel3 fills this gap with a massively threaded architecture for contiguous and fragmented recovery. Researchers need only write single-threaded validation and reassembly code for a new file type; Scalpel3 supplies worker scheduling, synchronization, checkpointing, and I/O. This separation allows new recovery methods to be added without modifying the backend infrastructure. The architecture also integrates the ONNX Runtime, allowing learned models to be used within validators and recovery strategies. Operational features include interactive human-in-the-loop control, block deduplication, persistent restart checkpoints, incremental output, and a FUSE filesystem for hybrid workflows. We evaluate Scalpel3 on a mixed corpus of more than 80,000 files under contiguous recovery and three controlled fragmentation scenarios: gaps, out-of-order block placement, and both together. Results show fast and accurate contiguous recovery and demonstrate that Scalpel3's massively threaded architecture makes validated fragmented results available substantially earlier than single-threaded execution. Furthermore, strategies tailored to individual file types maintain high overall accuracy across increasingly difficult layouts. Together, these results demonstrate that Scalpel3 provides a practical foundation for developing and deploying fragmented recovery strategies at scale.

1. Introduction

File carving recovers data from raw storage without filesystem metadata, but traditional signature-based tools cannot reconstruct fragmented files. Scalpel3 introduces an extensible, massively parallel framework for contiguous and fragmented recovery, with APIs and tools for developing and deploying file-specific strategies.

1. Introduction

  • Traditional signature-based carvers assume contiguity and cannot reconstruct fragmented or out-of-order files, while exhaustive block-selection searches quickly become infeasible.Fragmentation can interleave a file’s blocks with unrelated data and free space, leaving the carver to locate and reassemble them without filesystem metadata.Source: §1 · p. 2

1.1. Contributions

  • Scalpel3 combines extensibility, contiguous and fragmented recovery, and massively parallel execution in a publicly available carving framework.The authors describe it as the first publicly available framework, to their knowledge, to combine these capabilities.Source: §1 · p. 2, §1.1 · p. 4

1. Introduction

  • File-specific structural constraints and heuristics, including signals such as checksums and chunk structure, prune the search space and guide validation and reassembly.Scalpel3 also integrates learned models through ONNX Runtime.Source: §1 · pp. 2–3, §1.1 · p. 4

1.1. Contributions

  • Researchers implement single-threaded validation and reassembly logic for each file type, while Scalpel3’s backend supplies thread pools, I/O, synchronization, and checkpointing.Researchers need not create or manage threads.Source: §1.1 · p. 3
  • Public APIs support block and file validators, state, and custom reassembly strategies, allowing new file types to be added without backend changes.ONNX support enables learned models within these components.Source: §1.1 · p. 4
  • The toolchain supports reproducible experiments and hybrid workflows through synthetic-image generation, blockmap utilities, and a FUSE filesystem exposing uncovered image portions.Source: §1.1 · p. 4
  • The paper presents file-type case studies and evaluates recovery on more than 80,000 files across contiguous and fragmented layouts and increasing thread counts.The system and toolchain are released under GPLv3.Source: §1.1 · p. 4

2. Related Work

Prior carving work developed along signature-based recovery, fragmented-file reconstruction, and fragment classification, each addressing part of the recovery pipeline. Scalpel3 brings these strands together in an extensible, massively threaded framework for contiguous and fragmented recovery.

2.1. Header–footer Carving

  • Earlier header–footer carvers such as Foremost and Scalpel v1 largely assumed contiguity, while Scalpel3 supports extensible contiguous and fragmented reassembly and parallelizes every major stage.Prior signature carving could produce false positives without strong format checks; Scalpel3 parallelizes detection, block and file validation, reassembly, and I/O.Source: §2.1 · p. 5

2.2. Fragmented File Carving

  • Fragmented-recovery research ranges from bifragment gap carving to out-of-order methods, but practical validation and efficient out-of-order carving remain open challenges.BGC assumes two fragments separated by an unknown gap and works best with strong internal validation; nearly half of fragmented files in a 220-laptop study were out of order.Source: §2.2 · pp. 5–6
  • Fragmented-recovery methods span JPEG seam-based reassembly, ELF block placement using function-call evidence, and systems for other formats, while available tools remain prototypes or limited in scope.JPEG work includes graph-based seam compatibility and sequential fragmentation-point testing; Bin-Carver uses code relationships, while related work also addresses OOXML, video, and MP3.Source: §2.2 · pp. 6–7
  • No prior usable general tool combined public source, format-neutral extensions, content-based recovery of unknown fragmented files, and parallel execution across major carving stages at demonstrated scale.Scalpel3 combines format-aware validators and reassembly with massively threaded scheduling, checkpointing, and I/O.Source: §2.2 · p. 7

2.3. File Fragment Classification

  • Fragment classification advanced from statistical signatures and SVMs to deep-learning models, but integrations with reassembly remained format-specific; Scalpel3 uses pluggable classifiers to guide recovery.Classifier confidence scores can complement format-specific validation and guide candidate reassembly.Source: §2.3 · p. 8

3. Scalpel3: Architectural Overview · 3.1. The Carver

Scalpel3’s carver coordinates contiguous and fragmented recovery over a virtualized disk image, progressing from easier recoveries to more expensive strategies. Dedicated thread pools support the workflow, while checkpointing and operator controls enable intervention during long-running jobs.

3. Scalpel3: Architectural Overview

  • Scalpel3 is a multithreaded framework whose carver coordinates contiguous and fragmented recovery using format-specific validation and reassembly components.The architecture also includes a file mirror and data structures such as blockvectors, blockmaps, and a promising queue.Source: §3 · pp. 9–10

3.1. The Carver

  • After block validation and header/footer discovery, the carver iterates through contiguous recovery (C), promising-fragment reassembly (F1), and remaining-boundary reassembly (F2).Boundary discovery uses regular expressions or custom discovery functions.Source: §3.1 · p. 10
  • In C, the carver validates candidates built from boundary, footer, metadata, or configured-limit evidence, covers recovered blocks, and queues partial structures for F1.The file mirror can reveal logical contiguity by hiding covered blocks, and C repeats because each recovery may expose further candidates.Source: §3.1 · pp. 10–11
  • F1 extends partially validated candidates with structural evidence, then periodically returns active work to the promising queue while C retries after blockmap updates.Existing structural evidence constrains F1’s search more than F2’s.Source: §3.1 · pp. 11–12
  • When the promising queue has no candidates available for dispatch, F2 seeds it from unused headers or footers, prioritizing constrained candidates over speculative work that may require backtracking.The phases prioritize easier recoveries first, remove validated blocks from the search space, and escalate to more expensive strategies.Source: §3.1 · p. 11
  • Dedicated thread pools handle boundary search, validation, and reassembly, while priority queues schedule candidates and distribute fragmented-recovery work by accumulated service time.Vectorized boundary scanning is up to 2.2× faster on Apple Silicon and 4.7× faster with AVX-512 than a scalar implementation.Source: §3.1 · p. 12
  • The carver supports restart checkpoints and human-in-the-loop control, letting operators checkpoint, query status, or abandon specific candidates.State can be flushed to disk and threads halted using global synchronization primitives so recovery can resume from a checkpoint.Source: §3.1 · p. 12

3.2. A Running Example · 3.3. The Promising Queue · 3.4. Blockvectors

The running trace shows how Scalpel3 turns detected fragments into validated files. A service-aware queue and per-candidate blockvectors support prioritized, format-specific reconstruction.

3.2. A Running Example

  • The 14-block example places a contiguous JPEG at blocks 3–4, PNG-1 around it, and PNG-2 around a recurring filler block and unrelated compressed data.Blocks 8 and 12 contain identical filler; blocks 0 and 13 are unrelated.Source: §3.2 · pp. 12–13, Figure 4 · p. 13
  • Initialization deduplicates blocks 8 and 12, uses MoDiCo confidence scores to prioritize but not invalidate blocks, and truncates failed PNG spans at CRC-consistent boundaries while writing the valid JPEG.The resulting PNG fragments ⟨1, 2⟩ and ⟨6, 7⟩ enter the promising queue.Source: §3.2 · p. 13

3.3. The Promising Queue

  • The promising queue schedules partially validated candidates by service-adjusted priority, so candidates receiving less service rise toward the front; per-file-type priority bias is optional and disabled by default.Candidate priorities are initialized at creation and serialized across restart checkpoints.Source: §3.3 · p. 14
  • Reassembly threads dispatch the least-served candidate, extend it with format-specific logic, and write successful files while marking their blocks covered; unsuccessful candidates are requeued or abandoned after a kill request.Queue maintenance enforces operator kill requests and removes stale entries.Source: §3.3 · p. 14

3.4. Blockvectors

  • Each candidate’s blockvector provides an ordered reconstruction workspace and maps apparent positions in the file mirror to actual blocks in the original image.Candidate bytes are accessed through the mapped image when possible or materialized into a contiguous buffer when required.Source: §3.4 · p. 15
  • The blockvector API lets strategies reason in logical file order while preferring nearby physical blocks; Scalpel3’s left-to-right strategy tracks tried choices, backtracks, and tests longer consecutive runs by galloping.Each slot records its apparent and actual block numbers; the validity flag and choices structure track usable data and alternatives already tried.Source: §3.4 · pp. 15–16
  • PNG-2 was completed as ⟨6, 7, 10, 11⟩ after CRC-based filtering excluded blocks 8 and 9, and inflate/filter checks plus block 11’s footer validated the reconstruction.For formats without a deterministic constraint, the strategy can instead extend by trial and backtrack when incremental validation regresses.Source: §3.4 · p. 16

3.5. The File Mirror

The file mirror gives recovery threads a consistent logical view of the evidence while preserving physical block references. It coordinates address translation, duplicate and coverage handling, and I/O for reconstruction.

3.5. The File Mirror

  • The mirror maps shifting apparent block numbers to actual disk locations, giving components a logical carving view while retaining references to the evidence image.As validated blocks are removed, the mirror updates the apparent image and maintains the corresponding actual positions.Source: §3.5 · p. 16
  • Covered blocks are excluded from recovery, while fragmented recovery coalesces duplicate blocks through exemplars and contiguous recovery retains uncovered physical copies.Per-block metadata tracks coverage and duplication status.Source: §3.5 · pp. 16–17
  • The mirror provides uniform read and write access, using sequential readahead to reduce scan latency and an asynchronous vector write pool for recovered output.Candidate data can be read through memory mappings or materialized into contiguous buffers.Source: §3.5 · p. 17
  • Scalpel3 shares one read-only mapping of the evidence image across threads, while metadata scales with image blocks and file types and worker buffers are bounded.The image need not fit in physical memory because the operating system can discard cached pages; a configuration option reduces aggressive allocation on memory-limited systems.Source: §3.5 · p. 17
  • When validated data is covered, the apparent image can make another candidate contiguous, allowing mild fragmentation to be recovered by a second contiguous pass.In the example, covering JPEG blocks 3 and 4 makes actual block 5 apparent block 3, enabling PNG-1 to validate without fragmented reassembly; blockvectors track candidate blocks and rely on the mirror for translation, data access, and coverage updates.Source: §3.5 · p. 17

3.6. Blockmaps

Scalpel3’s blockmap tracks block coverage, duplication, and reservations to support recovery bookkeeping. Its deduplication and checkpointed update mechanisms reduce redundant work and contention while changing the apparent view used for recovery.

3.6. Blockmaps

  • The blockmap tracks coverage, duplication, and reservation status; covering File A can make File B’s remaining fragments appear contiguous for recovery.Figure 5 illustrates this interaction between blockvectors, disk layout, and the apparent logical view.Source: §3.6 · pp. 17–18, Figure 5 · p. 18

3.6.1. Deduplication and Reservations

  • Blockwise deduplication preserves duplicate blocks at their actual positions for contiguous recovery but lets fragmented reassembly consider only each group’s exemplar.Coverage marks excluded blocks; exemplar reference counts track uncovered occurrences in a duplicate group.Source: §3.6.1 · pp. 18–19
  • Reservations provide optional soft coverage: candidate blockvectors increment an exemplar’s counter, allowing strategies to deprioritize highly reserved blocks and reduce contention.Scalpel3’s default strategy uses this preference to reduce fruitless validator calls on candidates likely to be covered by others.Source: §3.6.1 · p. 19

3.6.2. Blockmap Updates

  • During reassembly, coverage updates accumulate in a shadow blockmap and merge into the primary map at checkpoints, batching updates without a global blockmap lock.Threads become quiescent for the swap, after which apparent-to-actual mappings are rebuilt.Source: §3.6.2 · pp. 19–20, Figure 6 · p. 20

3.7. Validators … 3.10. Scalpel3 Output

Scalpel3 provides extensible block- and file-level validation, including learned inference to guide reassembly. Its operational features support checkpointed work, interactive operator control, and incremental output.

3.7. Validators

  • Block validators assess file-type consistency while minimizing false negatives, so the same block may be accepted for multiple file types.They can also record per-block labels and metadata, including CRCs used during reassembly.Source: §3.7 · pp. 20–21
  • File validators check assembled-fragment integrity in contiguous recovery, incrementally during left-to-right reassembly, or at custom-strategy-selected points.Both block and file validators are developer-extensible through Scalpel3’s APIs.Source: §3.7 · p. 21

3.7.1. Machine Learning

  • ONNX Runtime integrates learned inference into validators and custom reassembly; MoDiCo scores guide candidate order without removing blocks from the search space.MoDiCo runs before block validators, which may retain or change its per-class confidence scores; duplicate blocks inherit exemplar scores, and inference can run on CPUs or available accelerators. Extending learned methods to more file types and evaluating them at scale remain active research directions; MoDiCo development is described in, and prediction interpretability in.Source: §3.7.1 · p. 21

3.8. Checkpointing

  • Scalpel3 uses periodic, progress, and restart checkpoints for blockmap updates, in-progress work inspection, and recovery after termination, respectively.Restart checkpoints are scheduled every 5m by default and save restartable state, avoiding redundant computation and preserving progress across interruptions or deliberate pauses.Source: §3.8 · p. 21

3.9. Human in the Loop Carving

  • Human-in-the-loop control lets operators monitor and adjust carving in real time to align work with investigative priorities.Analysts can inspect jobs and block coverage, review statistics, and cancel UUID-tracked jobs; the IPC facility also supports visualization of coverage, partial files, and progress management.Source: §3.9 · p. 22

3.10. Scalpel3 Output

  • Scalpel3 writes validated files as soon as validation succeeds and can emit partial fragments for inspection.Outputs use VALIDATED/, PROMISING/, and INPROGRESS/ status directories; optional blockvector output records the actual blocks used for auditability and post hoc analysis.Source: §3.10 · p. 22

4. Adding New File Types

Scalpel3 lets developers add file types through single-threaded validation functions and optional format-specific state and reassembly hooks. Its APIs guide recovery while the backend schedules registered types and manages checkpoints.

4.1. Validator API

  • Adding a file type requires single-threaded validation functions; block validation is optional because some formats can rely on header/footer discovery and file-level checks.Source: §4.1 · p. 22

4.1.1. Block Validators

  • Block validators assign or update per-type block confidence scores from 0 to 100 and should favor inclusiveness to avoid false negatives, leaving ambiguity for file validators or reassembly.The scores signal eligibility and ordering, not calibrated probabilities.Source: §4.1.1 · pp. 22–23

4.1.2. File Validators

  • File validators report whether fragments are promising or complete and the last validated byte, guiding truncation, queuing, and format-consistent incremental reassembly.Source: §4.1.2 · p. 23

4.2. State API

4.2.1. Block State

  • Block state records structural hints or other per-block metadata, remains immutable after block validation, and supports serialization, cloning, and freeing.Source: §4.2.1 · p. 24

4.2.2. Carve State

  • Carve state stores mutable metadata for a reassembly candidate, letting validators and reassembly logic track progress and format structures; it can be serialized and restored across checkpoints.Source: §4.2.2 · p. 24

4.3. Custom Reassembly Functions

  • Custom reassembly functions control candidate initialization, block selection and placement, validation, backtracking, and checkpoint handling, enabling format-aware or machine-learning-guided strategies without backend changes.Source: §4.3 · pp. 24–25

4.4. Registering New File Types

  • At minimum, a new file type requires a file validator and configuration registration; custom reassembly is optional, and the left-to-right baseline is used when it is omitted.Once compiled in, the backend schedules the type through discovery, validation, and reassembly.Source: §4.4 · pp. 25–26

5. Scalpel3 Toolchain

Scalpel3’s toolchain supports reproducible fragmentation experiments, blockmap creation and maintenance, and hybrid recovery workflows that expose only uncovered image data to downstream tools.

5.1. Dataset Generation

  • fragmentator generates reproducibly fragmented disk images and ground-truth key files for byte-for-byte recovery checks, with directives controlling gaps, missing blocks, and block order.Its configuration also controls image parameters, padding, filler blocks, and whether file headers remain contiguous.Source: §5.1 · p. 27

5.2. Blockmap Maintenance

  • crblockmap builds a reusable per-block index, detects zero blocks, and deduplicates blocks using SHA-256 hashes followed by direct comparison of candidate duplicates.The blockmap stores coverage and deduplication metadata for reuse across runs.Source: §5.2 · p. 28
  • modblockmap supports offline coverage edits and imports recovery-tool logs, while cmpblockmaps compares blockmaps to quantify coverage changes and recovery progress.These utilities enable third-party tools to mark recovered regions as covered so Scalpel3 can focus on the remaining search space.Source: §5.2 · p. 28

5.3. Blockmapfs

  • blockmapfs mounts a disk image with covered blocks removed, letting downstream scanners and carving tools work only on data not already validated by Scalpel3 or other tools.It is a FUSE (Filesystem in Userspace) filesystem.Source: §5.3 · p. 28
  • Together, modblockmap and blockmapfs support staged hybrid recovery: mark third-party results covered, run Scalpel3 on residual data, then expose the remaining uncovered view to another tool.Newly validated Scalpel3 files are also marked covered before the final tool targets formats not handled by earlier tools.Source: §5.3 · p. 28

6. Format-Specific Carving

Scalpel3 uses format-specific validation and, where useful, custom reassembly to exploit each format’s structural evidence. The section also shows how developers can extend the framework and run reproducible recovery experiments.

6. Format-Specific Carving

  • Format-specific validators exploit each file type’s internal structure, and fragmented recovery may require custom reassembly routines.The examples include PNG, JPEG, GIF, ELF, MP3, and ZIP/Office Open XML; the section focuses on structures and evidence used by their strategies.Source: §6 · pp. 28–29

6.1. PNG File Carving

  • PNG reassembly solves for blocks using chunk CRC32 constraints, then checks proposed placements through structural and decompression validation.For one unresolved position, inverse CRC shifting and a lookup identify a block; multiple gaps use structured searches, meet-in-the-middle, and bounded fallbacks. [70]Source: §6.1 · pp. 29–30

6.2. JPEG File Carving

  • JPEG reassembly ranks continuations using decoded image continuity and structural validation, but lacks checksum evidence for reliable block ordering.The validator decodes scans, uses restart markers when present, and requires the EOI marker for full validation; weaker ordering evidence contributes to lower out-of-order recovery than checksum-constrained PNG.Source: §6.2 · p. 30

6.3. GIF File Carving

  • GIF recovery combines LZW decoding, sub-block alignment phase, and image-continuity checks to guide fragmented block selection.The validator also tracks compressed-byte consumption per decoded row and clean end-of-information termination; these structural and heuristic signals support stronger out-of-order recovery than JPEG.Source: §6.3 · p. 31

6.4. ELF File Carving

  • ELF length recovery uses internal metadata to estimate file bounds, while fragmented block validation uses a learned model. [72]When section headers are absent, the estimate uses the header, program header table, and non-null file-backed segments; metadata checks validate contiguous candidates.Source: §6.4 · p. 32

6.5. MP3 File Carving

  • MP3 detection chains predicted frame-header locations, while fragmented reassembly uses compatible block-boundary offsets and further join evidence. [74]Optional frame CRCs or decoded-audio spectral peaks help disambiguate joins; file-level checks reject impossible lengths, invalid parameters, and inconsistent continuations.Source: §6.5 · p. 33

6.6. ZIP and Office Open XML File Carving

  • ZIP validation cross-checks central-directory entries against local headers, and recovered ZIP containers are classified as Office formats after carving.The EOCD supplies the archive length; DOCX, PPTX, and XLSX labels are assigned by searching for characteristic entry names after recovery.Source: §6.6 · pp. 33–34

6.7. Using and Extending Scalpel3

  • Scalpel3 supports direct forensic use, registered validators for standard formats, and custom recovery strategies without backend changes.Its experiment workflow generates fragmented images and ground-truth keys, builds blockmaps, runs carving, monitors progress, and compares recovered files against originals.Source: §6.7 · pp. 34–35

7. Performance

Scalpel3 recovers contiguous files in PhotoRec’s performance range while recovering more files exactly, and its multithreaded architecture makes fragmented-recovery results available sooner. Recovery accuracy depends on fragmentation layout and file format, with JPEG the limiting case under out-of-order layouts.

7.1. Experimental Setup and Methodology

  • The evaluation used 80,549 files, 16 KiB carving blocks, and ground-truth scoring; results distinguish exact, partial, incorrect, and unrecovered files.Experiments ran on a 96-core, 192-hardware-thread workstation, but results are reported through 128 threads because greater speedup was inconsistent across workloads.Source: §7.1 · p. 35

7.2. Contiguous Recovery

  • Scalpel3 recovered 80,524–80,525 of 80,549 files exactly versus PhotoRec’s 75,434–75,540, while remaining in PhotoRec’s performance range at realistic multicore counts.With random padding, PhotoRec was faster in this workload, while Scalpel3 also performed setup work PhotoRec did not attempt.Source: §7.2 · p. 36, Figure 14 · p. 37, Table 4 · p. 38

7.3. Fragmented Recovery

  • Fragmented recovery tested GAP, OOO, and GAP+OOO layouts on PNG, GIF, and JPEG files; added threads reduce completion time in GAP and improve time to result under fixed OOO budgets.The experiments fragmented 20% of targeted files in GAP and 10% in OOO and GAP+OOO; their reassembly budgets were 400 s, 3,300 s, and 5,400 s, respectively.Source: §7.3 · p. 39

7.3.1. Gap Fragmentation

  • 1,646 s fell to 104 s as GAP recovery scaled from one to 128 threads, a 15.9× speedup, with every configuration reaching the same final validated count.The 128-thread runs recovered all 13,510 fragmented files exactly; the total ground-truth exact count was 80,525.Source: §7.3.1 · pp. 40–41, Figure 17 · p. 40, Table 5 · p. 41

7.3.2. Out-of-Order Fragmentation

  • 806 s at 128 threads reached 79,000 validated files, versus 1,709 s at 64 threads; those configurations converged near 79,850 by the budget’s end.Among fragmented files, 5,252–5,253 of 5,263 PNG and 489–490 of 493 GIF files were exact, compared with 277–299 of 999 JPEG files; every fragmented file produced a candidate.Source: §7.3.2 · pp. 41, 43, Figure 18 · p. 42, Table 6 · p. 42

7.3.3. Combined Gap and Out-of-Order Fragmentation

  • 1,614 s at 128 threads reached 78,000 validated files, versus 4,545 s at 32 threads; the 64-, 96-, and 128-thread runs converged near 79,700 by the budget’s end.Among fragmented files, 5,217–5,226 of 5,263 PNG, 476–477 of 493 GIF, and 186–192 of 999 JPEG files were exact; JPEG accounted for most of the shortfall.Source: §7.3.3 · pp. 43–45, Figure 19 · p. 44, Table 7 · p. 44

8. Limitations

Scalpel3’s fragmented recovery depends on format-specific validation constraints and research, while speculative searches can lack a termination guarantee. The backend reduces implementation effort and offers controls to mitigate costly searches.

8. Limitations

  • Formats with few internal validation constraints, including encrypted or externally compressed data, are difficult to reassemble; JPEG reordering was less accurate than CRC-protected PNG.Checksums, chunk grammars, decodable streams, and offset-and-length metadata can constrain reassembly.Source: §8 · p. 45
  • Each file type requires separate format analysis to identify cheaply validated structures and search-pruning constraints, and strategies do not necessarily transfer across formats.The backend provides scheduling, I/O, block management, and checkpointing; researchers write selected single-threaded functions, reducing but not replacing format-specific effort.Source: §8 · p. 45
  • With many missing blocks, pathological fragmentation, or weak validators, speculative recovery may have an effectively unbounded search space and no termination guarantee.Stopping criteria, restart checkpoints, operator control, and phase ordering postpone the most speculative candidates until more constrained work has been attempted.Source: §8 · p. 45

9. Future Work

Future work centers on broadening format-specific fragmented recovery, testing generic reassembly alternatives, and exploiting filesystem clues without changing Scalpel3’s architecture.

Additional file formats

  • Scalpel3’s public validator and custom reassembly interfaces support developing recovery strategies for additional file formats, and the open-source project welcomes community contributions.Each format poses distinct challenges involving structures, offsets, checksums, and cross-field constraints that can prune reassembly without rejecting valid fragments.Source: §9 · p. 45

Generic reassembly strategies

  • For formats using default left-to-right reassembly, Scalpel3 could add selectable generic strategies such as bidirectional assembly, seam-based scoring, beam search, or constraint-based placement.These candidates could be evaluated against the default under identical corpus, validation, and scheduling conditions.Source: §9 · pp. 45–46

Filesystem-aware carving

  • Filesystem-aware evidence could sharpen fragmented recovery without architectural changes, as validators record clues and reassembly heuristics favor allocator-consistent gaps and displacements.Examples include ext4’s block-group locality, resident small NTFS data attributes in MFT records, and nonresident data allocated in filesystem clusters; filesystem-aware tools can also mark allocated regions as covered before carving.Source: §9 · p. 46

10. Conclusions

Scalpel3 combines extensible, massively parallel recovery for contiguous and fragmented files with an architecture that lets researchers add file-type logic without implementing backend parallelism or I/O. Its results show high-throughput contiguous recovery and earlier validated fragmented recovery with higher thread counts.

10. Conclusions

  • Its architecture separates pipeline and thread-pool orchestration, disk I/O and blockmap management, and format-specific validation and reassembly, enabling new file-type support through single-threaded code.The backend handles parallelism, synchronization, and I/O automatically.Source: §10 · p. 46
  • The phased recovery model (C, F1, F2) escalates from easy to more expensive recoveries, while blockmap updates between passes and at checkpoints reduce later search spaces.Source: §10 · p. 46
  • Persistent checkpointing, scalpel3-ctl human-in-the-loop control, block-level deduplication, and a FUSE filesystem support investigative workflows; open-source release aims to lower experimentation barriers.Source: §10 · p. 46
  • Scalpel3 achieves high-throughput contiguous recovery and accelerates fragmented reassembly, with higher thread counts recovering more validated files earlier from large candidate sets.Source: §10 · p. 46
Loading 2608.20363v2…