FAT32学习笔记（一）

从最简单的开始，如何在FAT32格式的U盘里找到一个文件？

如果有U盘，那么可以拿实际的U盘做试验，这里可以使用一个image文件来做试验，效果一样。

在整个实验过程当中，会不停的用到如下几条命令：

mount test.img /mnt/

umount /mnt

hexdump -C -s xxxx -n xxxx test.img

具体含义请自行man。

1 首先，创建一个FAT32格式的image文件。分作如下几步：（环境为ubuntu 14.04）

a cd /tmp

b sudo dd if=/dev/zero of=test.img bs=512 count=80000

在这一步中，要保证最终的size(bs*count)达到一定数目，具体是多少，目前还没研究，到后面细节的时候再来研究。

这个时候用hexdump来看，将会看到整个文件里全部是0.

c sudo mkfs.vfat -F 32 test.img

这里就会在这个image文件中安装FAT32的文件系统，或者，把这个文件用FAT32的方式进行格式化。

注意，这里可以用hexdump命令查看一下目前这个文件里的内容，此时已经可以看到FAT32的BPB，FsInfo，FAT表。

2 把第一步中做好的image挂载起来。

sudo mount test.img /mnt

可以通过mount指令来查看是否挂载成功，一般会是在最后一项显示该挂载项。如果成功，则会找到“/tmp/test.img on /mnt type vfat (rw)”

3 在/temp/目录下创建一个文件，为了简化，用下面的命令

touch 123.txt

4 把这个文件复制到/mnt目录，此时可能需要用到sudo，如下

sudo cp 123.txt /mnt/

5 把挂载到/mnt的test.img卸载掉

sudo umount /mnt

此时，用hexdump命令来查看test.img里的内容，就可以开始最简单的FAT32的学习了。

下图是此时我的截图，这里只截取了前面512 Bytes的内容，先分析这512 Bytes。

在FAT32的官方文档里，最前面512 Bytes称作BIOS Parameters Block。它叫什么名字意义不大，重要的是它能提供给我们什么信息。

BytesPerSector，offset 0xB，2 Bytes，这里是0x200，表示一个sector是512 Bytes。

SecPerCluster，offset 0xD，1 Bytes，这里是0x01，表示一个cluster包含1个sector。

RsvdSecCnt，offset 0xE，2 Bytes，这里是0x0020，表示reserved sector的数目是32个。

NumFATs，offset 0x10，1 Bytes，这里是0x02，表示FAT表的数目是2个。

TotSec32，offset 0x20， 4 Bytes，这里是0x00013880，表示该FAT32表一共管理了0x13880个sector。

FATSz32，offset 0x24，4 Bytes，这里是0x00000268，表示一个FAT32表占用0x268个sector。

注意，不要用这个格式往FAT12或者FAT16上套，它们的含义并不一样。

到这里，大致可以知道在该文件的内容分部情况如下：

要找的123.txt只在Data区域，因此，需要知道Data区域的起始地址，从BPB刚才所提供的信息可以计算出Data区域的起始地址。计算方法如下：

RsvdSecCnt里已经包括了BPB和FsInfo各占用的一个sector，所以，FAT1 offset = RsvdSecCnt * BytesPerSector = 0x20 * 0x200 = 0x4000

FAT2 offset = FAT1 offset + FATSz32 = 0x4000 + 0x268 * 0x200 = 0x4000 + 0x4D000 = 0x51000

Data offset = FAT2 offset + FATSz32 = 0x51000 + 0x4D000 = 0x9E000

或者，直接就有

Data offset = RsvdSecCnt * BytesPerSector + NumFATs*FATSz32*BytesPerSector = 0x20 * 0x200 + 0x2 * 0x268 * 0x200 = 0x9E000

这时，再用hexdump命令来查看在offset 0x9E000的地方是否放着123.txt

hexdump -C -s 0x9E000 test.img

附上截图如下：

由此可以看到，123.txt确实在这里，虽然位置有点偏差（为什么不是在offset 0x9E000，而是0x9E020），这个涉及到FAT32对长文件名的支持，稍微复杂，后续文章再说。

好了，一次简单的在FAT32格式中寻找文件的过程就是这样，更多的问题留待后续的文章。