ntfstool parses NTFS structures that Windows will not show you

It reads the structures the operating system hides

The project describes itself as a forensic tool focused on NTFS volumes, and the list of structures it handles is long enough to say what kind of tool this is. It reads partition information, meaning MBR, the partition table and the VBR, and it displays the complete structure of the master boot record, the volume boot record, the partition table and the $MFT file record. On top of that it handles the Master File Table, BitLocker encrypted volumes, EFS encrypted files and the USN journal. The repository topics list adds the terminology that shows the scope of the parsing: btree, compressed, disk, efs, fve, gpt, logfile, mbr, mft, reparse, smart, sparse, undelete, usn, vbr, vmk and vss. This is a parser first. The tool reads structures and prints them, and it does not need the volume to be mounted or the files to be recoverable through the normal file system.

Dumping the MFT is the core operation, and it comes in three formats

The command table is the clearest description of what the tool does, and the MFT commands sit at its centre. The mft.dump command dumps the $MFT file in a specified format, and the README names the options as csv, json and raw. The mft.record command displays the FILE record details for a specified MFT inode, with almost all attribute types supported. The mft.btree command displays VCN content and the Btree index for an inode, which matters when a file is fragmented and the run list needs interpreting. Alongside them, logfile.dump and usn.dump offer the same three output formats for the $LogFile and the $UsnJrnl. Reading the $MFT is what lets an examiner find files that no longer exist in the directory tree, and the tool also handles the Zone.Identifier alternate data stream with parsing, which the README says is for quickly identifying downloaded files. That is the kind of detail that decides whether a tool is used by a working examiner or only read about.

Undelete looks for records not in use, and can return partial data

The undelete command is described with an honesty that is unusual for the category. It searches for any file record marked as not in use and allows you to retrieve the file, or part of the file if it was already rewritten. That second clause is the important one. The MFT record can survive the deletion of the file, but the clusters the record points at may have been reused, in which case what you recover is a partial file with the first part still correct. The tool will not pretend otherwise. A related capability is that any file can be dumped, including $MFT or the SAM hive, and the extract command pulls a file out of a volume. The image command works the other way, creating an image file of a disk or a volume, which is how you take a copy before analysis. The undelete and image commands together are the standard forensic workflow: image first, then work on the copy.

BitLocker support stops at the key, and says so

The BitLocker section describes exactly what the tool does and does not attempt. For a bitlocked partition it can display FVE records, check a password and a key, and extract the VMK and the FVEK. The VMK is the volume master key and the FVEK is the full volume encryption key, so extracting them is the point of the feature. Then comes the limitation, stated without hedging: there is no bruteforce feature because GPU based cracking is better, with links to the Bitcracker paper and to Hashcat. What the tool offers instead is the hash for those tools. So the division of labour is clear. ntfstool performs the parsing that produces the data a cracking tool needs, and it hands the workload to specialised GPU software rather than pretending a CPU brute force is competitive. The bitlocker.decrypt command then decrypts a volume to a file using a password, a recovery key or a bek, so once you hold the key itself the rest is straightforward.

EFS keys can be backed up, moved to another machine and used

The EFS support is a round trip, which is what makes it useful beyond a single case. Masterkeys, private keys and certificates can be listed, displayed and decrypted using the needed inputs, which are the SID and the password. Certificates with private keys can be exported with the backup command in PKCS12, or pfx, format. The README then explains the point of that export: reimport the backup on another machine to be able to read the encrypted file again, or use the efs.decrypt command to decrypt a file with the backed up key. The efs.certificate command lists, displays and exports system certificates from the SystemCertificates and My\Certificates stores, while efs.key handles private keys in the Crypto\RSA store and efs.masterkey handles masterkeys in the Protect store. The README points at the Mimikatz wiki for the corresponding EFS procedure, which tells you the audience.

USN journal analysis runs JSON rules against the journal

The usn.analyze command analyses the $UsnJrnl file with specified rules and outputs csv or json. The rules are JSON documents, and the default set lives at Rules/default.json in the repository. The example rule included in the README shows the shape.

  {
    "id": "lsass-dump",
    "description": "Dumped LSASS.exe process.",
    "severity": "high",
    "rule": {
      "filename": "lsass(\\.(dmp|dump))?"
    }
  }

Each rule carries an id, a human description, a severity and a matching clause. The README says the journal can be analysed using custom rules to detect suspicious programs and actions, and also to get an overview of the journal, such as the percentage of files deleted or created. So the same command serves two purposes, which is worth knowing: a triage pass over the whole journal, and a targeted hunt for a specific filename pattern. A rule that matches lsass with a dmp or dump extension is the canonical example of the first use.

The shell is a convenience, not a real shell

There is a shell command, and the README is careful to call it limited. The available commands are exit, cd, ls, cat, pwd, cp, quit and rec, where rec shows the MFT record details. That is enough to move around a volume and pull single records without memorising the MFT command syntax, and nothing more. The help command displays a description and examples for each command, and the invocation form is a single line.

    ntfstool help [command]

One detail that will save you a confused afternoon is documented under the help section: options can be entered as decimal or hex number with a 0x prefix, for example an inode. Since the commands that take an inode are the ones you use most, mft.record and mft.btree, being able to paste a hex value straight from a hex dump is the difference between a quick and a slow investigation. The README also notes the tool accepts input from an image file, a live disk, or a virtual volume such as VeraCrypt or TrueCrypt, and mentions mounting an image with a tool like OSFMount as an alternative.

The project admits its own gaps in two lines

There is a Limitations section and it is short. It says some unsupported cases, work in progress, and no documentation. That is the entire list, and it is worth taking at face value rather than reading as false modesty. The tool handles sparse and compressed files with lznt1 and xpress, per the forensics section, but the limitations note tells you the coverage is not complete across the range of NTFS features. The documentation situation is equally candid. The README links to an alternative documentation made by deepwiki, hosted at deepwiki.com/thewhiteninja/ntfstool, which tells you the in-repository documentation is not sufficient on its own. Binaries are distributed through AppVeyor, with a link to the AppVeyor project page and to the GitHub artefacts from the last workflow run, and the build section starts with installing Visual Studio 2022. The repository is a Visual Studio solution, NTFS.sln, with a vcpkg.json file for dependency management and a Rules directory holding the default analysis rules. The badge row also carries x64 and x86 Windows badges and a version badge reading 1.6, while the release list shows v1.7 from 2023-07-23, v1.6 from 2022-03-30 and v1.5 from 2022-03-16, and the last push was on 2026-06-26.

Editorial conclusion

Adopt ntfstool when you are analysing NTFS evidence on Windows and need the MFT, USN journal, LogFile, BitLocker metadata or EFS keys parsed rather than inferred. Do not adopt it as a cross platform tool, since the build is a Visual Studio project for Windows 64 bit and 32 bit targets, and do not expect cracking, because the README states there is no brute force feature and points to dedicated GPU tools instead. Verify first by running ntfstool info against a disk image, confirm the mft.dump output matches the MFT you expect, and check the version badge, because the latest release tag is v1.7 from 2023-07-23 while the last push was on 2026-06-26.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. thewhiteninja/ntfstool on GitHub