Crates.io | mft2bodyfile |
lib.rs | mft2bodyfile |
version | 0.8.0 |
source | src |
created_at | 2021-04-22 16:32:47.144345 |
updated_at | 2023-05-08 14:41:24.088633 |
description | parses an $MFT file to bodyfile (stdout) |
homepage | https://www.github.com/janstarke/mft2bodyfile |
repository | |
max_upload_size | |
id | 388194 |
size | 172,958 |
parses an $MFT file (and optionally the corresponding $UsnJrnl
) to bodyfile
cargo install mft2bodyfile
USAGE:
mft2bodyfile [FLAGS] [OPTIONS] <MFT_FILE>
FLAGS:
-h, --help Prints help information
--journal-long-flags don't remove the USN_REASON_ prefix from the $UsnJrnl reason output
-V, --version Prints version information
OPTIONS:
-J, --journal <journal> path to $UsnJrnl $J file (optional)
-O, --output <output> name of destination file (or '-' to write to stdout)
ARGS:
<MFT_FILE> path to $MFT
mft2bodyfile '$MFT' -J '$UsnJrnl_$J' >mft.bodyfile
mactime -b mft.bodyfile -d >mft.csv
Until now, me and my team used analyze_mft.py
to extract data from the $MFT
, when we got triage data from a customer. Unfortunately, analyze_mft.py
has some disadvantages:
$STANDARD_INFORMATION
or the $FILE_NAME
attribute used to generate the timestamps, bot not both of them at the same time. This always required us to merge both outputs, which is a little bit messy$MFT
So, at first we started to work on analyze_mft.py
to fix our complaints, but we soon got stuck when we discovered one additional disadvantage:
$FILE_NAME
attribute not stored in its base entry, but in some nonbase entry which is refered by an $ATTRIBUTE_LIST
attribute, then this file is not shown in the bodyfile.You might think that "non-base MFT entries do not have the $FILE_NAME
and $STANDARD_INFORMATION
attributes in them", as Brian Carrier has stated in his great book. But we found that this does happen. Further investigation showed us that nearly all fast and simple tools have the same problem. So this was the last bit that led us write a tool for our own.
analyze_mft.py
$ATTRIBUTE_LIST
entries.$MFT
and $UsnJrnl
data$UsnJrnl
RecordsThe file $UsnJrnl
(abbreviation for Update Sequence Number Journal) contains a list of entries, where every entry documents changes of metadata for a file.
The following data are shown:
Field | Description |
---|---|
$UsnJrnl |
shown if for every entry extracted from the $UsnJrnl file |
filename |
shown if the filename found in the $MFT is different from the filename found in $UsnJrnl or if the $MFT does not contain a $FILENAME attribute for this file |
parent |
shown if the parent reference in the $MFT is different from the parent reference in the $FILENAME attribute or if the $MFT does not contain a $FILENAME attribute for this file |
reason |
The flags that identify reasons for changes that have accumulated in this file or directory journal record since the file or directory opened. (https://docs.microsoft.com/de-de/windows/win32/api/winioctl/ns-winioctl-usn_record_v2) |
Tue Aug 31 2021 10:48:42,16,macb,0,0,0,335695,"/Users/tmpadmin/AppData/Local/Microsoft/Edge/User Data/Default/Local Storage/leveldb/CURRENT ($UsnJrnl filename=000001.dbtmp reason=RENAME_OLD_NAME)"
Tue Aug 31 2021 10:49:50,0,macb,0,0,0,336826,"/Users/tmpadmin/AppData/Local/Microsoft/Edge/User Data/CertificateRevocation/6498.2021.5.1 ($UsnJrnl filename=8244_1963452067 parent='/Users/tmpadmin/AppData/Local/Temp' reason=CLOSE+FILE_CREATE)"
Tue Aug 31 2021 10:49:50,0,macb,0,0,0,336826,"/Users/tmpadmin/AppData/Local/Microsoft/Edge/User Data/CertificateRevocation/6498.2021.5.1 ($UsnJrnl filename=8244_1963452067 parent='/Users/tmpadmin/AppData/Local/Temp' reason=FILE_CREATE)"
Tue Aug 31 2021 10:49:51,0,macb,0,0,0,336826,"/Users/tmpadmin/AppData/Local/Microsoft/Edge/User Data/CertificateRevocation/6498.2021.5.1 ($UsnJrnl filename=8244_1963452067 parent='/Users/tmpadmin/AppData/Local/Temp' reason=RENAME_OLD_NAME)"
Consider the following situation: You have a file, which has a list of attributes which is so long that not all attributes can be stored in the base entry. Then, one or more additional entries are used. If such a file is deleted and the base entry is reused for another file, we can only see that there once a file has existed (using the nonbase entry), but we cannot see the original filename. In addition, if we cannot see the $FILENAME
attribute, we also cannot see the $STANDARD_INFORMATION
attribute, which has a lower attribute id. So, we see traces that some files once existed, but we neither see its name nor any timestamps.
If you provide a $UsnJrnl:$J
file, chances are good that mft2bodyfile
can find a filename and some timestamps even from deleted files.