When I get a Windows drive with a corrupted or partially destroyed NTFS file system — a failed Windows update, a partition table disaster, or physical sector damage — Scrounge-NTFS is one of the low-level recovery tools I still keep in my kit. It’s a lightweight, no-frills utility built to reconstruct and recover files from an NTFS volume even when the Master File Table (MFT) is partially damaged. This guide covers exactly how I use it, from basic recovery to more advanced troubleshooting.
What Scrounge-NTFS Is and How It Works
Scrounge-NTFS is a small C program originally written to recover data after catastrophic NTFS corruption. Rather than mounting the file system through the normal NTFS driver (which typically refuses to mount a damaged volume at all), it works directly against the raw device or disk image and:
- Locates and parses the Master File Table (MFT) directly, even if the boot sector or normal file system metadata is damaged, by scanning for MFT record signatures (
FILE0) - Reconstructs directory structure and filenames from MFT entries where possible
- Copies recovered file content out to a specified destination directory, sector by sector, following the file’s data run information from the MFT record
Because it operates below the level of a “mount,” it can often pull data off a volume that Windows itself considers completely unreadable.
Installing Scrounge-NTFS
On Debian/Ubuntu:
sudo apt update
sudo apt install -y scrounge-ntfs
If not available in your distro’s repos, build from source:
git clone https://github.com/Distrotech/scrounge-ntfs.git
cd scrounge-ntfs
make
sudo make install
Verify:
scrounge-ntfs --help
Basic Syntax
scrounge-ntfs -f <device_or_image> -d <output_directory> [options]
Typical usage I run:
# Step 1: generate a list of recoverable files from the MFT
scrounge-ntfs -f damaged_drive.img -m mft_list.txt
# Step 2: recover files based on the generated list
scrounge-ntfs -f damaged_drive.img -d /recovery/output/ -m mft_list.txt
Always work against a forensic image (created with Guymager or dd) of the damaged drive rather than the physical device directly, so repeated recovery attempts don’t risk further wear on failing media.
Real Example
$ dd if=/dev/sdb of=/evidence/damaged_drive.img bs=4M conv=noerror,sync status=progress
$ scrounge-ntfs -f /evidence/damaged_drive.img -m /cases/case002/mft_list.txt
Scanning for MFT records...
Found 184203 valid MFT entries
Written file list to /cases/case002/mft_list.txt
$ mkdir /recovery/output
$ scrounge-ntfs -f /evidence/damaged_drive.img -d /recovery/output/ -m /cases/case002/mft_list.txt
Recovering file 1420: Documents/quarterly_report.docx ... OK
Recovering file 1421: Documents/budget.xlsx ... OK
Recovery complete: 184203 entries processed, 179988 recovered successfully
From here I sort recovered files by extension and manually verify a sample against known-good file signatures to gauge the overall integrity of the recovery.
Real-World Use Cases
Corrupted NTFS volume recovery for incident response — a ransomware event that partially damaged the file system table before encryption completed, where standard file recovery tools can’t mount the volume at all.
Hardware failure recovery — a failing drive with bad sectors in the boot sector or early partition area, where Scrounge-NTFS’s MFT-first approach bypasses the damaged boot metadata entirely.
Digital forensics on damaged evidence — recovering as much file content as possible from a drive an adversary attempted to sabotage before it could be properly seized.
Integration with Other Tools
- Guymager/dd — I always image the damaged drive first; Scrounge-NTFS then works exclusively against that image.
- Scalpel — for files Scrounge-NTFS can’t reconstruct through MFT parsing (severely damaged records), I fall back to signature-based carving with Scalpel as a second recovery pass.
- Autopsy — recovered files get imported into an Autopsy case alongside any other recovered evidence for unified analysis and reporting.
Performance and Troubleshooting
- On very large volumes, MFT scanning can take a long time; running from a fast local disk image (not a network share) speeds this up considerably.
- If recovered filenames appear garbled or missing, it usually means the MFT’s
$FILE_NAMEattribute was itself damaged — in that case, recovered content is still often usable, but you’ll need to identify file types manually usingfileor hex signature inspection. - A mistake I made early on: running Scrounge-NTFS directly against a physical failing drive repeatedly during testing, which risked further degrading the media — always work from an image after the very first (and ideally only) physical read pass.
Best Practices
- Image first, recover second — never run repeated recovery attempts directly against failing physical media.
- Cross-check a sample of recovered files against expected file signatures/magic bytes to assess recovery quality before reporting completion.
- Keep detailed logs of the MFT list and recovery output for chain-of-custody documentation in forensic contexts.
FAQ
Does Scrounge-NTFS work on modern ReFS volumes? No — it’s specifically built for NTFS; ReFS requires different recovery tooling.
Can it recover files from a fully formatted drive? Recovery success drops significantly after a full format overwrites the MFT, though a quick format may still leave enough MFT structure intact for partial recovery.
Is Scrounge-NTFS still actively maintained? It’s a mature, stable utility; it hasn’t needed frequent updates since NTFS’s on-disk structure it targets has remained largely consistent.
Summary
Scrounge-NTFS earns its place in my recovery toolkit specifically for the scenario where a Windows volume is too damaged to mount normally but its MFT records are still partially intact. Combined with proper imaging discipline, it’s saved more than one “unrecoverable” drive during real incident response work.
References
- Source repository: https://github.com/Distrotech/scrounge-ntfs
- Man page:
man scrounge-ntfs(after installation)
