HMFT – Yet Another $MFT extractor

HMFT is a simple tool that extracts $MFT from a given drive or a disk image to a file in any location (including removable drive).

Extracting $MFT directly from a live system or even from an image is always a pain. Most of the tools available on the internet are GUI-driven, and GUI option is not always available (e.g. to remote users); such GUI-driven tools are also often not very ‘portable’ as they are bundled with other components and are written in a high-level language so the file size often goes to a few hundred KiBs, if not MiBs . As such, getting them on a target system may be annoying to say the least. There are of course good command line tools available as well, but they are often private, paid-only, or offering a limited functionality in its free version (not to mention the file size).

Now, don’t get me wrong – this is not to boo at other tools – they are often excellent and very useful. Also, apart from extracting $MFT they often offer a lot of other functionality e.g. parsing various file systems, extracting files by name, etc. They are just written for a different purpose.

Interestingly, the MFT extraction can be easily achieved within less than 1KB of code; HMFT is still far from an optimal size, but since it is written in X86 assembly and packed with UPX it ‘weights’ only 4KiB and I have no plans on optimizing it further. It is also quite fast and if you are lucky, extracting $MFT file should be a matter of seconds up to few minutes (it will take longer if for $MFT extracted from removable drives or if systems is under performing during the operation). HMFT reads NTFS directly and tries its best to parse its structure. It doesn’t rely on any 3rd party library, and doesn’t use commonly used FSCTL_* commands to retrieve data – it’s all plain Read/Write from the list of clusters that $MFT occupies.

Once extracted, $MFT can be parsed with analyzeMFT, mft.pl, or other scripts.

Note:

  • For images, only images of volumes (logical drives) are supported at the moment.
  • As mentioned, while parsing NTFS is a major pain in general, extracting $MFT alone is relative simple, so I hope it will work OK. Still,  if you try it and for some reason something doesn’t work, please let me know and I will try to fix it.

Usage:

hmft.exe [drive] [output filename]

f.ex.:

Download HMFT here.

Update

It’s been a while since I wrote anything here. This is due to me being on holidays and moving to a new place right after coming back. I finally settled down in a new apartment and looking forward to play with some new ideas.

So, here is a short update:

  • I fixed a silly bug in HAPI – I mixed up CR & LF characters in the output and it looked awkward to say the least, not to mention potential parsing issues; Thx to Pedro L. for spotting this and notifying me
  • HAPI may occasionally print some strings that look like non-API, e.g. ‘version’; this is not a bug, but a feature 😉 it turns out that there is such an API exported by one of the Microsoft DLLs ; since I don’t want to miss any API, I made a trade off and include all of them; still… I use some little heuristics to prevent printing many of them, but some of them will sometimes go through; so, please always verify the output manually; and for the curious – some Microsoft programmers decided to name certain APIs using one, or two characters; I dunno why do you do stuff like this, but there are legitimate system DLLs exporting functions named ‘u’, ‘vo’, etc.
  • Discovered recently that Symantec’s VBN files can be encrypted not only with 0x5A, but also 0xA5; these files are still handled by DeXRAY since it relies on a XRAYS technique that searches and extracts encrypted executables without needing to know a specific key; but if you parse VBN files yourself, knowing that 0xA5 is being used may help you to save some time