在尝试对闪存驱动器进行数据恢复时，我正在尝试编写一个可以搜索 FAT 目录条目的工具。由于我不能依靠 FAT 告诉我去哪里看，我正在对驱动器扇区进行简单的扫描（实际上是驱动器的图像转储）。
问题是我找不到有关如何检测扇区/群集是否包含 FAT 目录条目的任何信息。我知道目录条目的结构，但不知道如何检测一堆给定字节是否实际上包含一个。
查找子目录的开头.很简单，因为您可以只搜索字节 0x00 和..字节 0x20，但这仅有助于子目录的第一个扇区，而不是后续扇区，也不是根目录或子目录其他位置的目录碎片。
我尝试使用日期范围、文件大小、群集范围、无效文件名字符作为粗略的指导，但当然，这不太可靠。
如果我在磁盘编辑器中打开图像并按住PgDn键，我的大脑可以检测到包含有效目录条目的扇区何时通过我的视野，但是如何在程序中实现呢？有什么方法可以检测 FAT 目录条目吗？
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.