本篇主要面向受众是取证行业所有人员，因为讲的是介质基础。本文充满干货，没有一句瞎bb。
0x01 镜像与文件集合
从大方向上讲，取证中取只有两种：一种是二进制的数据流，还有一种是逻辑文件集合。
二进制数据流是一种最大可能保留原始数据的格式，其代表作是硬盘镜像。在有了硬盘镜像的基础上，取证人员就可以对证据进行动态分析和静态分析。动态分析是指通过仿真还原用户场景，并且提供了与原始证据的交互能力。通过动态分析可以做网站重构，恶意软件分析等诸多静态分析不容易做到的事情。动态分析明显的弊端是受限于取证人员自身技术水准。静态分析则通过各种分析软件，从二进制的角度对部分信息做提取并展示。这个过程中有效降低对取证人员的技术要求，但是考虑到静态分析受限于分析软件，那么就存在软件本身bug导致信息可能不准确的问题，或者首先软件功能导致部分无法分析的问题。
逻辑文件集合是一种退而求其次的做法。现在手机取证中，部分手机不能做出硬盘镜像则只能使用类似于自备份或者文件提取方案制作逻辑文件集合。通过这种方案可以做应用解析，文件内的数据恢复。
文件集合的核心信息表达有文件路径信息，时间信息，权限信息，文件内容等。硬盘镜像在此基础上还会提供分区表，文件系统信息(文件系统日志，最后挂载点，创建时间)，未使用空间，未分配簇等。
0x02 十六进制查看工具
文件图标和扩展名都是不可信的，两者都只是欺骗小白的一种低级手段。jpg病毒喜欢带着一个假图标和美女.jpg.exe文件名欺骗用户，因为windows系统默认隐藏常见文件类型扩展名，所以用户会看到美女.jpg这个名称，双击时其实运行的是恶意程序。扩展名只是用来提示系统应该采用什么样的关联应用程序去打开。
由于文件图标和扩展名都是不可信的，所以我们需要一个十六进制查看器通过文件内容层面对文件真正的类型进行解读。作为IT从业人员，手里都需要至少备用一个用的顺手的十六进制工具。比如winhex和010 Editor这样的。本文不提供工具的具体下载地址。
0x03 常见镜像类型签名
DD镜像： 这个没啥说的，不带任何压缩的二进制存储数据结构，扩展名可能是dd,001,raw等。
E01：隶属于EWF(Expert Witness Compression Format)。E01是EWF中最为知名的一种镜像格式，致力于以压缩的形式存储二进制数据流，其标准也贴心的考虑到了用于存储原始镜像hash的字段。除了E01以外，EWF标准还提供了E01的升级版Ex01，还有用于存储逻辑文件集合的L01格式，E01人尽皆知，L01很可惜的没火起来。E01文件签名是 EVF\x09\x0d\x0a\xff\x00, 如下图所示：
VMDK(Virtual Machine Disk)：它描述了虚拟磁盘在VMware Workstation 和 VirtualBox等虚拟机中使用的容器。该格式最初是由 VMware 为其虚拟设备产品开发的，在VMDK 5.0版发布之后成为一种开放格式，是开放虚拟机格式文件中用于虚拟设备的磁盘格式之一。当然其他虚拟机软件也支持这种格式，比如QEMU，VirtualBox，Parallels。VMDK的文件签名是 KDMV, 如下图所示：
VHD(Virtual Hard Disk)：最早由Conectix公司发明用于Virtual PC产品，在2013年微软收购了Connectix，这种格式就被微软接受。win7本身支持vhd文件的(只读/读写)挂载。在Windows Server 2012版本中带来了vhd的升级版vhdx，支持更大的容量，提升访问性能。VHD的文件签名是conectix， 如下图所示：
QCOW(QEMU Copy-On-Write)：QCOW是QEMU使用的磁盘格式，支持AES-CBC加密，目前已经发展到第三个版本，但只使用qcow和qcow2这两个扩展名。QCOW因为其延迟分配空间来优化性能而出名，就如名字写的Copy-On-Write。三个版本的qcow都使用QFI\xfb作为文件签名，紧接着4个字节表明当前版本号，以下图为例(注意图中的00 00 00 03代表qcow3)：
0x04 常见文件集合特征
tar：tar包在linux系统中实在是太常用了，提供了文件打包功能。本身不具备压缩能力，会存储文件的路径，文件名，权限，不压缩的文件内容。但有个很明显缺陷是只会记录文件的最后修改时间，创建时间和访问时间是不存储的。但因为其数据结构简单，受到广大手机备份的喜欢。
其头部部分字节数据结构如下：
| Field offset | Field size | Field |
|---|---|---|
| 0 | 100 | File name |
| 100 | 8 | File mode |
| 108 | 8 | Owner's numeric user ID |
| 116 | 8 | Group's numeric user ID |
| 124 | 12 | File size in bytes (octal base) |
| 136 | 12 | Last modification time in numeric Unix time format (octal) |
| 148 | 8 | Checksum for header record |
| 156 | 1 | Link indicator (file type) |
| 157 | 100 | Name of linked file |
放图给大家感受一下（开头就是一段路径，后面是文件信息，会发现大量0字节，后面就是不压缩的文件内容）：
zip: 数据结构比tar更复杂，tar是将文件按顺序一个一个排下去。zip则有一个区域专门存储文件条目，而且由于数据是经过压缩的，导致单文件内不能随机访问，只能先将数据解压到临时文件或者内存再随机读取。zip的定位也是用于存储逻辑文件，存储文件时也只会保存文件的最后修改时间。相比与tar，zip中每个文件都有扩展字段(Extra)，这一点上比tar的灵活性会更高。当扩展字段的类型为0x000a(NTFS)时，则会为三个时间分别分配8个字节。言归正传，zip的文件签名是0x04034b50 ,如下图所示：
其实后面还有MBR和GPT，各种常见文件系统特征头。作为文件系统方向的开发者，这些东西看的次数多自然就敏感了，不需要刻意的记，毕竟熟能生巧。
