填坑第三集，Katze kit

开始之前……

第一集、第二集和第零集呢？！

嘛……

想法

关于这个坑之前有过一些尝试，但是由于坑太多了于是就搁置了，只有一些博客作为技术储备留了下来，这次填上。电子数据取证软件是个大坑，需要很多的技术积累和经验积累，也注定这个坑会填很久。在设计架构的时候，我希望能够尽量用可扩展、可复用的方式设计一套优秀的方案出来，这样就能先投入生产环境，然后根据具体的需求慢慢进行扩展。这篇博客作为开端，主要是做一下初步的架构设想，然后确定一下最初开发的方向和技术栈。

数据取证软件？文件浏览器！（？）

其实电子取证软件就是一个大号浏览器，然后搭载了所谓自动取证分析等等功能，实际上就是 walk dir 并按照事先设置好的规则进行证据提取。所以软件的架构设计应该围绕着最核心的功能进行，也就是对于各种镜像/设备格式的访问和提取。

如果调研一下市面上已经有的镜像/取证包格式，就会发现这个 “访问” 其实并不是那么好做。现代计算机的存储架构是很复杂的，就拿一个普通的个人PC来说，我们先把磁盘看作是一整个数据空间，那么在这个空间之上进行数据分配的就是分区表（Partition Table）。然后分区表会决定磁盘上的分区情况，固定了起始地址等等。按照分区表的指引找到某个分区之后，**文件系统（File System）**在等着我们做解析工作。磁盘和分区表在软件层面种类尚且有限，文件系统就是个百鬼夜行百花齐放的东西了。每种文件系统实现都有其特殊的用途，例如ZFS、BtrFS等等，每种分区的解析工作都比较复杂。进入文件系统之后，剩下的路就比较好走了，都是标准的文件访问模型，有文件夹、文件、链接等等。不同文件系统在这里可能会有特性上的区别，例如ext4的inode、NTFS的额外文件属性等，这些对于取证软件而言倒不是特别重要。

但是这样就完了吗？当然不是！笔者曾经见过有人直接在服务器上把某个硬盘直接格式化成单独分区使用的，这里就绕过了分区表一层（关于这件事，笔者差点删掉了学姐的毕业论文数据，还好损失的都是些机器学习的原始训练集，不太打紧，有空的话单独写一篇博客讲讲）；而且现在分布式存储也很流行，一块数据可能以各种形式分块存在不同的磁盘中；为了增加数据存储的稳定性，多块硬盘还可以组成磁盘阵列…… 总之都是我们需要解决的麻烦事，并不是只要按照层级去分别设计访问模型就可以的。

根据上面的各种棘手情况，访问模型要有以下的设计结构：

• 访问类型：这里主要指 文件/文件夹 的区别。但又不完全是，比如说，一个原始的磁盘镜像他可以只是个文件，也可以是个文件夹，毕竟里面有可访问数据。所以在设计访问类型的时候，应当把内部文件访问作为一种特性来提供，而不是一刀切的将数据直接分类为文件或文件夹。
• 统一访问路径：在使用时，用户会将现实的文件（镜像、压缩包、取证包等等）拖进软件进行分析，在这些取证材料中可能还会内嵌其他的拥有内部文件访问特性的文件。因此在设计访问模型的时候，应当有一个面向全局的访问路径，取证软件可以通过这个路径在不区分实际/虚拟文件的情况下准确定位到某个文件。
• 数据属性：文件和文件夹都有属性这个说法，根据文件系统的不同属性也不同。按照统一访问模型的设计，文件系统本身也是设计的一环，所以文件系统和其他各种各样层级设备的属性也应当呈现出来。但属性并不等同于内容，我们需要设计一个能够扩展的属性模型出来，不能把文件属性的列表直接钉死。
• 原始数据访问：这个算是核心内容，毕竟电子数据取证的目的就是查找原始文件证据。但是数据访问可能会遇到一些难题，如何呈现某些特殊的文件？例如图片、doc文档、ppt、PSD什么的，每种文件都有不同的呈现方式。一种方案是利用FUSE或者类似的技术将文件挂载到宿主系统上，然后通过用户自己安装的软件打开，这种方式工作量最小，但是会有一些安全隐患。挂载为FUSE之后，原本证据内容会向整个操作系统暴露，杀毒软件等等监控软件可能就会在不知情的情况下访问证据数据并进行处理；如果被分析的证据中存在病毒文件，那么只读文件系统也可能会有执行权限，会有感染宿主机的风险。另一种方案是实现尽可能多的文件类型预览工具，提供一个最基本的预览，然后再告知用户要不要将这个文件导出到宿主系统里，用更专业的软件进行处理。除了文件预览的问题之外，超大型文件的处理也是个问题。某些格式可能本身就有流处理功能，例如视频等等，而另一些文件本身巨大，而且并不是为了让用户打开/执行而设计的，例如原始取证镜像。所以数据读取也是一个要解决的核心问题。我们需要在性能尽可能高的情况下将原始数据串流给预览工具，从而实现比较低的内存占用。
• 组合模型：有时候模型本身是一个纯粹的数据块，但是多个模型组合之后可以变成一个具有内部文件访问特性的新模型，例如RAID阵列的不同磁盘镜像、ZIP、RAR等压缩包格式的分块压缩等等。因此模型之间应该是可以选择合并的，并且能够建立某种逻辑联系，使得取证软件处理的时候能够正确访问其中的内容。

暂时想到的就这些，有的话等写着写着发现了再补充。

访问架构

之前博客里写过的，大致如下：

    组件层：文件浏览、自动化证据提取、证据笔记……
 ====================================================================
    虚拟数据访问平台：提供抽象文件访问服务
 ====================================================================
    访问器：负责按照层级与具体的规则访问镜像文件等，并向上级返回数据

访问器将所有的细节都封装了起来，虚拟数据访问平台向组件层提供与环境无关的、统一的数据访问接口，而组件层负责进行二进制/文本数据的抽象分析。而访问器的统一API可以导出为Python API，然后平台附带一个Python环境，给用户足够高的扩展能力。

架构集成

有了上述访问器的架构描述，感觉我们可以往更有趣的方向探索一下。如果我们能把这种文件访问能力抽象成一个完整的磁盘/文件系统API呢？这样一来，就可以直接对虚拟机提供磁盘服务了！如果能够集成QEMU之类的虚拟机软件，我们甚至可以通过几次点击，直接以取证软件本身为载体，复原出案发时的机器架构！这样一来就可以省下一部分用来重构网站的精力了（当然，运维该做的事情还是要做）。

接下来的事情

进入实现之后可能还会有各种有趣的事情和挑战，希望能做为一个系列给我的博客多添几篇水货。