An MFT parser is a tool that reads $MFT, the Master File Table at the root of every NTFS volume, and turns its 1,024-byte records into something you can pivot through. CSV, JSON, a timeline, an interactive table. There are several toy implementations on GitHub. There are three that I would put in front of a paying customer. This is how I pick between them.
MFTECmd (Eric Zimmerman)
MFTECmd is the de facto standard in incident response. Windows-only .NET CLI, free, parses $MFT, $Boot, $J (the $UsnJrnl change journal stream), $SDS (security descriptors from $Secure), and $LogFile. Output is CSV in the bodyfile-adjacent layout that the rest of the Eric Zimmerman toolchain (Timeline Explorer, KAPE, RECmd) consumes natively.
Reach for it when:
- You are on a Windows analysis workstation. This is the path of least surprise.
- You want to open the parsed output in Timeline Explorer and pivot interactively. The column mapping is already correct.
- You are running KAPE; MFTECmd is the bundled parser for the
MFTtarget. Skip writing your own pipeline. - You need
$LogFileparsing. Nothing else matches MFTECmd here. - You need
$Jparsing in the same toolchain.
Skip it when you are on macOS or Linux without a .NET runtime (yes, .NET 6+ runs there, but most analysts do not have it set up), or when you want to embed parsing in another program.
A companion GUI, MFT Explorer, browses $MFT interactively in a tree view. Most analysts use both: MFTECmd for batch parsing, MFT Explorer when they need to chase a specific record. The two share the same parser code, so what you see in one will match the other.
The one operational gripe: MFTECmd's defaults emit "all" records including extension records as separate rows. For most workflows you want the base records consolidated. Use --bdl and friends to filter, and read the help text before your first run.
omerbenamram/mft (Rust crate + CLI)
The omerbenamram/mft crate is the parser library this site uses. It ships as a Rust dependency (cargo add mft) and a standalone CLI (mft_dump). The CLI emits CSV or JSON; the library exposes the full record structure, including attribute walks, for programmatic use.
Reach for it when:
- You want to embed MFT parsing in a larger pipeline. Rust, with WebAssembly, or via FFI from Python (
subprocess) or Go. - You want JSON Lines output for piping into
jq, OpenSearch, ClickHouse, or a custom database. The CLI streams JSONL; you can pipe a 5 GB$MFTthroughjqwithout loading the whole thing into memory. - You are on Linux or macOS and do not want to install .NET.
- You want the parser to be auditable. The code is small, idiomatic Rust, and the test corpus is in the repo.
Skip it when you want a turnkey analyst experience with a GUI and bundled timeline tooling. Skip it also when you specifically need $LogFile parsing; that is MFTECmd's territory.
The crate is what runs, compiled to WebAssembly, behind the browser parser on this site.
analyzeMFT (Python)
analyzeMFT is the classic pure-Python parser. Originally by David Kovar, still maintained. CLI-first, but importable. Slower than MFTECmd by a factor of 10 to 50 on large inputs because it is pure Python single-threaded, but fine for ad-hoc scripts and one-off triage where you cannot install native tooling.
I keep it in my back pocket for two cases: an air-gapped Linux analysis VM where cargo is not available, and quick one-liners where I want to extract a specific field across all records without learning the MFTECmd CSV column order. See parsing $MFT in Python for the details and code samples.
Browser-based parsing (this site)
The parser on this site takes the omerbenamram/mft crate, compiles it to WebAssembly, and runs it in a Web Worker. You drop a $MFT file onto the page and the records appear in a paginated, searchable, sortable table. Nothing is uploaded; the bytes stay in your browser's memory.
Reach for it when:
- You want a quick read of
$MFTwithout installing anything. Onboarding a junior analyst, demonstrating NTFS structure, or doing a quick second opinion. - Policy forbids sending evidence to a cloud service. WebAssembly parsing happens locally. You can verify by disconnecting your network before dropping the file.
- You need to share a triage view with a colleague who does not have a forensics toolchain installed and is not going to install one.
- You are teaching NTFS structure and want an interactive sandbox where students can poke records and watch the layout update.
Skip it when you have a multi-gigabyte $MFT from a heavily-used server (the in-memory model scales linearly), or when you need outputs that integrate with the wider Eric Zimmerman pipeline (Timeline Explorer column mapping). For those, MFTECmd is right.
Sleuth Kit, mentioned for completeness
Sleuth Kit's fls -m -r -o <offset> image.dd walks the MFT and emits a bodyfile that includes deleted entries. istat -o <offset> image.dd <inode> prints a single record in human-readable form. icat -o <offset> image.dd <inode> extracts the file's data.
Sleuth Kit is the right answer when you are working from a full disk image rather than an extracted $MFT, when you care about cross-filesystem evidence (FAT/exFAT/HFS+ in the same image), or when you want a parser whose lineage in court is impeccable. The output is less convenient than MFTECmd's, but the tooling has been peer-reviewed for two decades.
How they compare
| Feature | MFTECmd | omerbenamram/mft | Browser parser | analyzeMFT |
|---------|---------|------------------|----------------|------------|
| Platform | Windows (.NET) | Linux / macOS / Windows / Wasm | Any modern browser | Anywhere with Python 3 |
| Install | One binary | cargo install or release binary | None | pip install |
| Output | CSV (Timeline Explorer schema) | CSV / JSONL | Interactive table + CSV export | CSV |
| $UsnJrnl:$J | Yes | No (separate omerbenamram/usn crate) | Browser parser links to a $J view | No |
| $LogFile | Yes | No | No | No |
| Scriptable | CLI only | Library + CLI | UI-driven | Library + CLI |
| Speed (1 GB MFT) | ~30 s | ~20 s | ~60 s (UI overhead) | 10-20 min |
| Privacy | Local | Local | Local (verifiable by network isolation) | Local |
Picking one
For a routine IR engagement on a Windows workstation: MFTECmd. It slots into KAPE and Timeline Explorer. It is the path of least surprise.
For a pipeline that ingests many disks, runs on Linux, or wants JSON: omerbenamram/mft. The CLI is fast, the library is clean.
For a one-off triage, a hostile-network situation, a classroom, or a colleague without a forensics machine: the browser parser.
For a full image investigation where MFT is one filesystem of several, or where court-admissibility lineage matters more than convenience: Sleuth Kit.
These are complementary. Most experienced examiners reach for whichever fits the moment. There is no single right answer.
Further reading
- Eric Zimmerman's tool index: ericzimmerman.github.io. MFTECmd is one of many; the ecosystem around it (RECmd, EZViewer, KAPE) is what makes it the IR default.
- The Sleuth Kit Wiki.
fls,istat,icatdocumentation plus the conceptual NTFS notes. omerbenamram/mftREADME and test corpus. Worth reading if you want to understand exactly what the parser does and does not handle.