Hi,
I have implemented NTFS parsing the last 9 days and I have a nice working version now despite the horror of finding information on topic.
However, on my system, I still run into a few issues that seem to do with marginal behaviour. I found and tried other tools such as spiff NTFS explorer to check on the issues but they don't do better (or worse) than my app.
I can formulate several questions backed up with some data where possible but before I do I was wondering if this is the right place for it ?
Are there people reading this forum that know NTFS well (enough) to go deep with me and try to figure things out ?
In short;
- trouble finding second (/third, …) MFT entries for files that span multiple MFT entries. I think I have a few of those on my system
- File MFT entries without a DATA attribute (probably related to previous, ie spanned MFT entries)
- Issues with a few data runs. This works well for most files but there are some issues with some files. E.g. 10 bytes for an offset yet the 64 bit offset is (obviously) only 8 bytes long etc. So does the Header byte need to be filtered first with a value ? Header &= 0x77 ?
- And a few more questions, but above info to illustrate the issues I'm dealing with.
Cheers,
Peter
Peter
Have you searched the forum? What about this topic, is it any help?
http//www.forensicfocus.com/index.php?name=Forums&file=viewtopic&t=8010
H
Try Carrier's book.
Carrier - http//
H
Hi Peter,
I spent some time, a while back now, implementing some NTFs parsing in C#. I can't recall how far I got with it, but I can thoroughly recommend Brian Carrier's "File System Forensic Analysis" (as already recommended by others in this thread) - I used it almost exclusively whilst writing my software )
Phil H
What is your application suposed to do exactly? Yeah, the fixups may turn out to be something different than you initially thought (as for me).. The ntfs driver handles this for you if target volume is ntfs, but probably the point is to not rely on that.
Regarding runs (which you probably have issues with), don't forget there may be negative relative moves too, and also that $MFT itself may be fragmented as well.
Btw, what language are you coding in?
Hi,
I code in C++ (Builder)
The app is data recovery software and I'm quickly implementing NTFS (basic for now) since I promissed it to my users (and the hired help let me down with nothing to show for it after 10 months). It's right up my alley however, I have written all code so far myself (UDF, FAT, ISO9660, HFS(+) etc.)
NTFS
I have code in place for negative runs (not tested properly yet) and a fragmented MFT is no problem either.
Finding the runs is not a problem for 99% of the files yet there are a few that create issues. For instance an offset nibble that contains 0xA … which is funky because I can only fit 8 offset bytes in a 64bit variable (duh).
This sort of weird behaviour is keeping me from releasing a beta version. I want it to at least work properly on my system. Windows itself has no issues with these files so I'm missing something … but what ?
What does NTFS do with a 0xA nibble ? AND with 0x7 ?
Unless .. unless unless …. Windows treats >8 nibbles as 0 nibbles ? A zero offset means a sparse run … something to check tomorrow.
This runs thing is one thing but I also have no clue how to find MFT records that belong to a base MFT for files spanning more MFT records.
Anybody an idea about that ?
Yes the runs must be interpreted differently when file is compressed/sparse. Post one of those tricky records so we can have a look.
Finding the runs is not a problem for 99% of the files yet there are a few that create issues. For instance an offset nibble that contains 0xA … which is funky because I can only fit 8 offset bytes in a 64bit variable (duh).
Try mounting the volume on Linux, and see if it's NTFS implementation gets it right. If it does, enter the code and see what it does. Or ask on the apporpriate developer's list.
Or try the NTFS.com forum which seems to have a number of NTFS experts around.