analyzeMFT: parsing the NTFS Master File Table into forensic output

What the tool does and where it stops

AnalyzeMFT is described as a Python-based tool designed for parsing and analyzing the NTFS Master File Table, and the repository description says it is designed to fully parse the MFT file from an NTFS filesystem and present the results as accurately as possible in multiple formats.

The scope is important to state precisely, because the name invites a broader reading. The tool transforms raw binary MFT data into structured, human-readable output suitable for digital forensics, incident response, and file system analysis. It does not mount a filesystem, it does not read file contents, and it does not acquire anything. The input is an MFT file that has already been obtained.

What it does with that file is the useful part. The primary purpose is to assist forensic analysts in reconstructing file system activity by decoding MFT records, and each record contains critical information such as file names, creation and modification times, file sizes, and directory relationships. The tool handles both active and deleted entries, which is the point of the exercise, since a deleted file's MFT record is often the only surviving evidence that it existed. The README says this allows comprehensive timeline analysis and artifact recovery, and that it includes error handling to manage corrupted or incomplete MFT entries, ensuring reliable processing even on damaged file systems.

That last claim is the one to test for yourself. MFT records on a live system are not contiguous, and an extracted MFT is often a reconstruction from $MFT itself, so gaps and short reads are the normal case rather than the exception.

The project is written in Python, licensed MIT, and the default branch is master with the last push on 2026-07-06. The recent releases are v3.1.1.0 from 2025-08-13, v3.1.1 from 2025-08-12, and v3.1.0 from 2025-07-21, which the release name describes as input validation and a better testing framework.

The output formats, and why so many of them

The output section is the strongest part of the README, because it shows the tool was built around the receiving end of a forensic workflow rather than around its own preferences.

Multiple output formats are supported to integrate with common forensic workflows, and users can export results as CSV, JSON, XML, or Excel files for review and reporting. For timeline analysis, the body file format compatible with mactime and other tools is available. SQLite export creates a relational database structure for querying and long-term storage. And the TSK timeline and log2timeline CSV formats allow direct ingestion into established forensic platforms.

The list covers three distinct destinations. There is the human and reporting layer, with CSV, JSON, XML and Excel. There is the timeline layer, with body file, TSK timeline and log2timeline CSV, which is what gets loaded into Plaso, log2timeline and the Autopsy ecosystem. And there is the storage layer, with SQLite, which is the one that scales to a full volume where a timeline tool would be the wrong shape.

The body file format deserves a note because it is the least obvious of the choices. It is a plain text format, one line per event, and it was the original interchange format for Plaso. Exporting to it is a decision to hand your data to a tool built for large-scale timeline analysis, and it means the output is no longer a record of what the tool believes but a stream of events another tool will interpret.

SQLite is the opposite decision. If the analyst's question is about relationships between files rather than about a sequence of events, then a relational database with the directory structure preserved is the right container, and the tool creates that structure rather than leaving the analyst to import a flat file.

The choice of output format is driven by the file extension or by explicit export flags, and the README documents the rules. The -o option sets the output destination, the --sqlite flag must be used when exporting to SQLite, and for CSV output no additional flag is required if the output file ends in .csv.

Profiles, and the difference between the default and the forensic setting

The tool supports configurable analysis profiles to suit different operational needs, and there are four built in.

The default profile provides balanced processing for general use. The quick profile minimizes processing overhead for rapid triage, which is the one to use when you are triaging a queue of images and only need to know whether a file was there. The forensic profile enables maximum data extraction, including all timestamp variants and extended attributes. And the performance profile adjusts internal settings to prioritize speed and resource efficiency on large datasets.

The forensic profile is the one to understand, because all timestamp variants is a specific and important claim. NTFS stores several timestamps per file, and the set of timestamps a tool reports is a decision that changes what a timeline shows. A profile that reports only the modified time and a profile that reports created, accessed, modified and changed times will produce different events from the same MFT, and the second is what an examiner needs when the question is when a file was created versus when it was last touched.

The profiles are listed with --list-profiles, which displays all available built-in profiles and their descriptions, and configuration is managed through command-line options or external files in JSON or YAML format. A configuration file can define output settings, analysis profiles, hash options, and filtering criteria, and sample configuration files can be generated using the --create-config option. The repository ships a sample_config.json at the root to show the shape.

Two other option families are worth noting. Verbosity is controlled with -v for increased output and -d for debug-level logging, which help diagnose issues during processing, and the export options allow selection of format without relying on file extensions, so a caller can write a CSV to a path with no extension.

Hashing, and the multiprocessing trade-off

Hash computation is available for file record attributes that include data runs, which is a precise limitation worth understanding. A file record's data runs describe where the file's data lives on the volume, and a resident file keeps its data inside the MFT record itself, while a non-resident file's data must be read from elsewhere. The tool hashes what the record makes available.

The algorithms offered are MD5, SHA256, SHA512, and CRC32, and they can be generated for resident and non-resident data. The stated purpose is file identification and integrity verification, and the practical use is comparing a known file against a hash set during triage, or checking whether a file found on the volume matches one the analyst already has.

The performance model is where the engineering shows. Hashing runs in parallel by default, with the number of processes configurable, and the number of hashing threads is set with --hash-processes. Users can disable multiprocessing if running in constrained environments, and that option exists because a forensic workstation is not always the machine you want spawning processes on, particularly when the analysis is running inside a container with a restricted process budget.

The rest of the performance work is about memory rather than time. Processing occurs in configurable chunks to manage memory usage, particularly important when analyzing MFTs that are hundreds of megabytes in size, and --chunk-size sets the record batch size. Progress indicators provide real-time feedback during long-running operations.

That combination, chunked reading plus parallel hashing, is what makes a full volume's MFT tractable on a laptop. A large MFT is hundreds of megabytes, and parsing it as one object would be a memory problem before it was a CPU problem.

Installing, and the synthetic MFT you should generate first

Installation is a pip install, and the quick start shows the three things you will do.

# Install
pip install analyzeMFT

# Basic usage
python analyzeMFT.py -f MFT_FILE -o output.csv --csv

# Generate test MFT for testing
python -c "from src.analyzeMFT.test_generator import create_test_mft; create_test_mft('test.mft', 100)"

# Analyze with multiple outputs
python analyzeMFT.py -f test.mft -o output.json --json --hash

The third command is the one to run first, and the README says why. A test MFT generator is included for development and training purposes, and using the --generate-test-mft option you can create synthetic MFT files with a specified number of records. The stated uses are validating tool functionality, testing parsers, and creating demonstration data.

That ordering is the correct one for a forensic tool, and it is not an accident of how the README was written. Running the parser against a known-synthetic MFT first tells you whether the tool works on your machine before you point it at evidence, and the training use is a real one, since a synthetic file with a known record count and a known structure is a far better teaching artefact than a real volume with thousands of records of unknown provenance.

The last command shows the export flags in use, with --json and --hash together, and the input is the generated test file rather than a real one.

The input is specified with -f followed by the path to the MFT file. The tool also has a structured help system: running the script with --help displays all available options and their descriptions, the usage summary shows required and optional arguments, and detailed explanations are provided for each category of options, including export, performance, configuration, and debugging settings.

The package installs a console script named analyzemft pointing at analyzeMFT:main, so the tool is available as a command as well as through the script. The runtime dependencies are openpyxl for the Excel output, pyyaml for the YAML configuration files, and pywin32 on Windows, which is the conditional dependency in setup.py for the platform, and the Python floor is 3.8.

Where analyzeMFT is the wrong tool

Three cases point elsewhere. The first is an examiner who needs the MFT acquired from a disk image or a live machine. The tool takes an MFT file as input and does not read $MFT out of a volume, so the acquisition step, which usually means a forensic image, a carved $MFT, or a mounted read-only export, is on you. That is a defensible division, and it is also the part of the workflow where a mistake has consequences, so a tool that did both would not obviously be safer.

The second is a project that needs file contents. The tool reconstructs metadata: names, timestamps, sizes, directory relationships, and optionally hashes. It does not extract or decrypt file data, and the description says it transforms raw binary MFT data into structured output. If your question is what was in the file, this is the wrong tool and you need something that works at the data run level.

The third is a team that needs the tool to be production hardened. The setup.py classifiers list the development status as 3 - Alpha, the documentation ends with a disclaimer that the tool is provided as-is for legitimate forensic and security analysis purposes with users responsible for ensuring they have (the text is cut off there), and the roadmap lists features that are not in the tool: STIX and TAXII export, Elasticsearch and Splunk integration, Neo4j graph export, filtering by date range, file type and size inside the tool, and possibly an interactive mode.

The alternative worth weighing is libewf and the Sleuth Kit tooling chain, or Plaso with log2timeline directly, and the difference in approach is about who interprets the data. A dedicated forensic suite reads the MFT and produces a timeline with its own event model, its own timezone handling and its own artefact definitions, and it is the tool an examiner presents in a report. analyzeMFT is a parser and converter, and its value is the range of output shapes including the body file and log2timeline CSV formats that let you pipe into those suites while keeping control of the parsing, the profiles and the configuration.

The project also earns credit on the engineering side. The test suite includes 224 tests covering all major components, GitHub Actions pipelines run across Python 3.8 to 3.12 on Linux, Windows and macOS, Bandit security scanning and Safety dependency checking are integrated into the build, and coverage is tracked through Codecov. The contribution rules are explicit as well: type hints and unit tests on all new code, coverage above 80 percent, PEP 8, and cross-platform compatibility.

Editorial conclusion

analyzeMFT fits a forensic analyst who already has an MFT file and needs it in a format their timeline tooling ingests, and who wants the parsing decisions to be configurable through profiles rather than hard coded. It does not fit an examiner who needs to acquire the MFT from a live or imaged disk, since the tool takes an MFT file as input, and it does not fit a project that needs a formatted, decrypted output of file contents. Before you run it, check the profile you are using against what you actually need, since the default is described as balanced and the forensic profile is the one that enables all timestamp variants and extended attributes, and generate a test MFT with --generate-test-mft before pointing the tool at real evidence.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. rowingdude/analyzeMFT on GitHub