1

While trying to data-recovery of a flash-drive, I am trying to write a tool that can search for FAT directory entries. Since I cannot rely on the FAT to tell me where to look, I am doing a simple scan of the drive sectors (actually an image dump of the drive).

The problem is that I cannot find any information about how to detect if a sector/cluster contains FAT directory entries. I know the structure of a directory entry, but not how to detect if a bunch of given bytes actually comprise one.

Finding the start of a sub-directory is simple enough since you can just search for . at byte 0x00 and .. at byte 0x20, but this only helps with the first sector of a sub-directory, not subsequent sectors, nor the root directory or sub-directory fragments in other locations.

I tried using date ranges, file sizes, cluster ranges, invalid filename characters as rough guides, but of course, that’s not too reliable.

If I open the image in a disk-editor and hold down the PgDn key, my brain can detect when a sector containing valid directory entries passes through my field of vision, but how can this be implemented in a program? Is there any way to detect FAT directory entries?

Synetech
  • 9,643
  • 9
  • 64
  • 96
  • Have you looked into this? http://en.wikipedia.org/wiki/Design_of_the_FAT_file_system and this http://www.win.tue.nl/~aeb/linux/fs/fat/fat-1.html – Joao Nov 19 '14 at 04:06
  • Yes, I’ve seen both (in fact, the only link my question is to the Wikipedia page you linked to). Neither say anything about identifying markers, just the layout. There is no reason that a random bunch of bytes couldn’t be *interpreted* as a directory entry. I’m trying to determine if there’s a way to figure out if it’s a *valid* directory entry. – Synetech Nov 19 '14 at 20:25
  • Take a look at http://www.tavi.co.uk/phobos/fat.html , namely the 'The File Attributes' section, where it says that 0x10 'The entry describes a subdirectory.' – Joao Nov 20 '14 at 02:21
  • That indicates that that specific entry being pointed to is a subdirectory, but it says nothing about the entry itself. It could be `0x10` by chance and completely invalid as a FAT directory entry. – Synetech Nov 21 '14 at 02:44

1 Answers1

0

It's unlikely that you can do a perfect job of identifying the directory entries, but you should be able to get reasonable results by using some simple heuristics.

As you said, you can start by looking for a . character at offset 0x00. If it's not there, then the entry is definitely not a directory.

Bit 4 of the file attributes (offset 0x0B) is set if it's a directory entry. If that bit is not set, then it's definitely not a directory. Also, the documentation says that bit 6 will never be set for a disk device. So if bit 6 is set, then it's almost certainly not a valid FAT entry. Although be careful, because a value of 0x0F designates a VFAT long file name entry.

The two bytes at 0x0E are the creation time. If the decoded hours are > 23, or decoded minutes > 59, or decoded seconds > 29, then you can view it as suspicious. It could be a directory entry that somebody mucked with or was somehow corrupted, but it's unlikely.

The access rights at 0x14 says that bits 12-15 must be set to 0. If any of those bits are set, consider it suspicious.

The four bytes at 0x1C give the file size. Those are supposed to be 0 for a directory entry. If they aren't, consider it suspicious.

It appears that there are other such indications in that structure. What you'll have to do is have your code identify the ones that it can, and then make a decision based on the evidence. It won't be 100% correct (i.e. you can probably fool it), but I suspect it would be quite good.

Jim Mischel
  • 131,090
  • 20
  • 188
  • 351
  • `If it's not there, then the entry is definitely not a directory.` Like I said, that only identifies the **start** of a directory. Directories can be fragmented, and subsequent fragments would not contain that at the start of the sector. (For that matter, even unfragmented directories would not contain that past the directory’s first sector.) – Synetech Jul 13 '15 at 04:37