本来的需求是XEN下的镜像取证，但这篇仅包括他支持的一种格式，就是VHD，此项目从头开始大概用了两周时间，中间遇到了很多让人头大的问题，光是思考的笔记就写了十几页纸，不过实际上并没有那么难，主要是很久没编码了，还有很多概念没搞清楚。好吧，搬家过来的第一个博客就从这个项目开始吧。
要求：
1、解析vhd格式文件，判断合法性
2、该vhd装的文件系统是NTFS格式
3、拿到该格式下的目录结构，即包含哪些文件和目录。
4、跨平台
思路：
一、vhd格式解析
解析首先要弄懂数据结构，网上关于他的官方格式说明是找不到的，但是XEN竟然能支持vhd格式肯定能有相应的数据结构，所以去搜索，xen的源码，果然里面就含有一个vhd.h，格式旁边还有注释，非常完美。此外，网上还找到了一篇《storage_layout系列之VHD结构详解》，是北亚数据的创始人写的，也很详细。
这个格式主要就是一个位于文件尾部512字节的数据结构：
// VHD Footer structure
typedef struct {
u_char cookie[MT_CKS]; // Cookie
u_int32_t features; // Features
u_int32_t ffversion; // File format version
u_int64_t dataoffset; // Data offset
u_int32_t timestamp; // Timestamp
u_int32_t creatorapp; // Creator application
u_int32_t creatorver; // Creator version
u_int32_t creatorhos; // Creator host OS
u_int64_t origsize; // Original size
u_int64_t currsize; // Current size
u_int32_t diskgeom; // Disk geometry
u_int32_t disktype; // Disk type
u_int32_t checksum; // Checksum
u_char uniqueid[16]; // Unique ID
u_char savedst; // Saved state
u_char reserved[427]; // Reserved
}__attribute__((__packed__)) vhd_footer_t;
【lseek可能遇到的问题 】
由于vhd若装的是windows 7那么很可能就是5G以上，我测试的是一个11G的，但是lseek参数是ULONG只能支持到32位即4GB空间，超过4GB会报错，所以定位取尾部一个扇区的数据结构时，要用SEEK_END。当然之后还会出现类似的指针地址太大问题，解决方法有俩：
1、posix标准下，可以用在Makefile里面写上
CFLAGS += -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES
CXXFLAGS += -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES
别的不用动就能支持了。
2、一个比较生硬的转换法：
int count= 要lseek的数字/(65535*65535);
for( int i = 0;i<count;i++ )
lseek( 65535*65535 );
lseek( 要lseek的数字%(65535*65535) )
未测试成功性。
通过disktype能判断是静态vhd磁盘还是动态vhd磁盘，这里只考虑动态vhd磁盘，通过dataoffset就能跳到动态磁盘头部，动态vhd磁盘数据结构如下：
// VHD Dynamic Disk Header structure
typedef struct {
u_char cookie[MT_CKS]; // Cookie
u_int64_t dataoffset; // Data offset
u_int64_t tableoffset; // Table offset
u_int32_t headerversion; // Header version
u_int32_t maxtabentries; // Max table entries
u_int32_t blocksize; // Block size
u_int32_t checksum; // Checksum
u_char parentuuid[16]; // Parent Unique ID
u_int32_t parentts; // Parent Timestamp
u_char reserved1[4]; // Reserved
u_char parentname[512];// Parent Unicode Name
u_char parentloc1[24]; // Parent Locator Entry 1
u_char parentloc2[24]; // Parent Locator Entry 2
u_char parentloc3[24]; // Parent Locator Entry 3
u_char parentloc4[24]; // Parent Locator Entry 4
u_char parentloc5[24]; // Parent Locator Entry 5
u_char parentloc6[24]; // Parent Locator Entry 6
u_char parentloc7[24]; // Parent Locator Entry 7
u_char parentloc8[24]; // Parent Locator Entry 8
u_char reserved2[256]; // Reserved
}__attribute__((__packed__)) vhd_ddhdr_t;
动态vhd格式的整体布局如下：
刚才拿到了尾部扇区，头部的0扇区是对他的备份，接着利用头部扇区再定位到BAT。BAT就是块地址表，他的数组中的每个值对应一个块地址：
定位方法就是batmap[i]*扇区大小
取数据我们只需要关注块数据的位置即可，上图的BAT的y0 y1……代表的就是块的首地址，跳到y0首地址，这里是一个512B+2MB的结构，前512字节（4096位）说明后面4096个扇区（2MB）的数据的分配情况，我们不需要管分配情况，只需要定位即可，所以我们每次定位要跳过512字节。
定位思路就是先算出块的位置，再算出块内扇区位置，非常简单，最终得出的地址转换函数如下：
/*
* 功能：将磁盘地址转到vhd地址位置获取到对应扇区信息
* offset偏移扇区数,size读取长度
*/
u_char * Address2VHD(u_int64_t offset,int size)
{
int blk_index = offset/(blk_size / MT_SECS);
int sc_index = offset % (blk_size / MT_SECS);
u_char sc[MT_SECS*size];
int lk = lseek(vhdfd,SwapInt32(batmap[blk_index])*(u_int32_t)MT_SECS + 512 + sc_index*(u_int32_t)MT_SECS,SEEK_SET);
if(lk < 0 )
{
perror("lseek");
}
else
{
read(vhdfd,sc,MT_SECS*size);
return sc;
}
}
【块设备的问题】
I/O设备分为块设备与字符设备，磁盘是块设备，他与内存交互的单位就是块，块都有自己地址，一个块一般含1到64个扇区，但是虚拟磁盘的块有2MB这么大，也就是4096个扇区，而且每块前面都有一个位图，形式不太一样，不能当一般磁盘设备来看待，毕竟是虚拟的磁盘，不必大惊小怪。
此外簇是文件系统存储的最小单位，再高级格式化时能设置，与块没什么直接关系，不要搞乱了。
二、找到第一个扇区MBR并解析
有了地址转换函数再找MBR主引导扇区就容易多了，但首先要做的是定义MBR的格式。MBR的数据结构网上非常容易找，我这里主要参考的《数据重现 文件系统原理精解与数据恢复最佳实践》这本书，讲解得非常详细。
MBR的数据结构如下：
#pragma pack(1)
/*一个分区表的表头信息*/
typedef struct DPT_Header
{
u_char State; //分区状态, 0 = 未激活,0x80 = 激活
u_char StartHead; //分区起始磁头号
u_int16_t StartSC; //分区起始扇区和柱面号,低字节（低6位为扇区号,高2位为柱面号的第9,10位）,高字节（柱面号的低8位）,考虑到字节序问题可能不一样
u_char Type; //分区类型,00 表示此项未用,其他标号代表各种系统
u_char EndHead; //分区结束磁头号
u_int16_t EndSC; //分区结束扇区和柱面号,定义同前
u_int32_t Relative; //在线性寻址方式下的分区相对扇区地址(对于基本分区即为绝对地址),从0开始的扇区数
u_int32_t Sectors; //分区大小 (总扇区数)
} DPT_Header;
//引导区512u_char结构
typedef struct _MBR_SECTOR
{
u_char BootCode[440];//启动记录440 u_char
u_int32_t DiskSignature;//磁盘签名 4字节
//u_int16_t blank1;
u_int16_t NoneDisk;//二个字节
DPT_Header Partition[4];//分区表结构64 u_char
u_int16_t Signature;//结束标志2 u_char 55 AA
//u_int16_t blank2;
} MBR_SECTOR, *PMBR_SECTOR;
#pragma pack()
分区中的Type类型可以定义各种操作系统，对应编码表：
【字节对齐问题】
由于读取的时候我们会是一个个字节读进来，结构体默认的字节对齐（一般是4字节对齐，也就每个类型总在4字节内，或者恰好是4的整数倍，否则就填充）并且sizeof()函数会按字节对齐后所消耗的真正空间。这样在后期运算会带来很大麻烦，所以这里加上#pragma pack(1) #pragma pack()规定就使用1字节对齐，就不会出现问题了。
取到了MBR，其中有4个分区表结构DPT_Header（因为NTFS最多支持4个主分区，但是动态磁盘支持更多，这里暂时不考虑动态磁盘），DPT_Header中有个起始扇区号，这就是每个扇区的起始扇区，那么就一个一个跳过去查看。
【显示空间大小问题】
由于空间时不时是上百G，那么在将扇区数转成GB或MB显示的时候要十分小心，例如一般是939393*每扇区字节数/1024/1024，若是int，那么第一个乘法就溢出了，所以应该把乘法放后面。
【malloc及传参问题】
这是基础内容了，传参的时候func(uchar**)必须是双重指针，否则在内部malloc后只是值改变，而指针本身没有变化。
三、找到MFT表的具体位置
在ntfs中，MFT表记录了整个文件系统的布局，每个mft都会记录一个文件的详细信息，包括创建时间、修改时间、作者、文件名、目录名等等。整个表一般占全系统的12.5%，当然他还可以往上配置得更大一点，一个文件被删除，也只是更改里面的属性而已，若不被重新分配，通过mft表就能很快恢复过来，他一般集中在文件系统的某个特定位置，现在我们的目标就是找到他。
《数据重现 文件系统原理精解与数据恢复最佳实践》这本书详细介绍了mft表的内容这里不再赘述。
这里开始就要引入ntfs.h了，里头有一个PACKED_BOOT_SECTOR结构，在分区表的其实扇区偏移地址就是指向这里，所以第一步就是跳到这里。
typedef struct _PACKED_BOOT_SECTOR {
UCHAR Jump[3]; // offset = 0x000
UCHAR Oem[8]; // offset = 0x003
BIOS_PARAMETER_BLOCK PackedBpb; // offset = 0x00B
UCHAR Unused[4]; // offset = 0x024
LONGLONG NumberSectors; // offset = 0x028
LCN MftStartLcn; // offset = 0x030
LCN Mft2StartLcn; // offset = 0x038
CHAR ClustersPerFileRecordSegment; // offset = 0x040
UCHAR Reserved0[3];
CHAR DefaultClustersPerIndexAllocationBuffer; // offset = 0x044
UCHAR Reserved1[3];
LONGLONG SerialNumber; // offset = 0x048
ULONG Checksum; // offset = 0x050
UCHAR BootStrap[0x200-0x044]; // offset = 0x054
} PACKED_BOOT_SECTOR;
拿到这个数据结构，里面又有很多的内容，其中有一个是MftStartLcn，这就是Mft表的起始簇。一个簇有多大呢？这里有个数据结构BIOS_PARAMETER_BLOCK，就是上面的0x00B，他的定义如下：
typedef struct BIOS_PARAMETER_BLOCK {
USHORT BytesPerSector;
UCHAR SectorsPerCluster;
USHORT ReservedSectors;
UCHAR Fats;
USHORT RootEntries;
USHORT Sectors;
UCHAR Media;
USHORT SectorsPerFat;
USHORT SectorsPerTrack;
USHORT Heads;
ULONG HiddenSectors;
ULONG LargeSectors;
} BIOS_PARAMETER_BLOCK;
显然这个结构里包含了，每个簇的扇区数，每个扇区的字节数等，通过这些指标我们就能定位mft里了。
实际上，网上能搜到一个toysntfs的程序，他采用符号链接和MBR的两种方法对MFT的表解析并读取根目录内容（只针对本地磁盘而不是针对虚拟机的），但是下下来后竟然发现后一种方法是不成功的，虽然传入的参数完全一样，但是最终read得到的结果却不同，再苦闷中分析了两天，才发现，原来是对WINAPI的操作理解不太到位。这个起始簇是相对于分区的，也就是说这个分区的第一个簇是0，下一个分区的第一个簇也是0，所以绝对的地址必须在前面加上一个起始扇区的偏移量，否则定位错误，经修改，运行正常。
定位到MFT就用下面的公式：
NtfsData.MftStartLcn.QuadPart * NtfsData.SectorsPerCluster四、MFT的解析及遍历
MFT（主文件表也可以称为文件记录块）本身也是一个文件，他占2个扇区，文件系统的前16个MFT是元文件，包括用于文件定位和恢复的数据结构、引导程序数据以及整个卷的分配位图等信息，用户是不能访问的，这里列出前5个：
0 $MFT //mft本身
1 $MftMirr //mft 元数据文件的镜像，用于备份恢复
2 $LogFile //文件操作历史记录文件
3 $Volume //文件卷信息文件
4 $AttrDef //属性定义文件
5 $Root(\) //根目录文件取根目录的扇区位置即：
ulStartSector.QuadPart = NtfsData.MftStartLcn.QuadPart * NtfsData.SectorsPerCluster + ulStartMft.QuadPart*2;
获取目录结构的方法有两个：
1、从$root开始递归遍历，首先查看0x16~17偏移看是否是目录，是的话通过文件记录号跳转递归查询：
mft记录头的结构如下：
后面紧跟着各种属性：
属性分析的框架：
ReadSector( MFT索引号, 长度)
{
解析MFT记录头；（大小0x38字节）
解析属性部分
{
Switch(属性类型)
{
Case: 对不同的属性做处处理，读取或修改,break;
Default:
}
}我们要的主要是文件名
2、遍历所有的MFT，一般来说MFT是连续的，但也有不连续的可能，主要是$data属性超出的情况，但是不是做文件恢复这里影响不大，只要读取filename即可，另一种说法是遍历MFT在磁盘上分布的区域大小，计算出总的MFT记录数量，然后发送控制码FSCTL_GET_NTFS_FILE_RECORD来获取文件引用号。这个方法不知道对虚拟机镜像可不可行，未测试。
下面这篇文章对解析有较多内容的阐述：
主要参考：
《storage_layout系列之VHD结构详解》
《XEN虚拟机分析》 薛海峰，卿斯汉，张焕国
《数据重现 文件系统原理精解与数据恢复最佳实践》
《数据恢复技术》
