安卓取证教程（三）

原文：zh.annas-archive.org/md5/CEAE4A4C2A963DFCD507E6E1C793EDA6

译者：飞龙

协议：CC BY-NC-SA 4.0

第七章

安卓应用程序与法医分析

本章信息

• 分析技术

• FAT 法医分析

• YAFFS2 法医分析

• 安卓应用分析与参考

引言

到目前为止，本书已经讨论了大量材料，不仅涵盖了安卓设备的历史和架构，还提供了关于文件系统、设备安全方法和数据获取方法的完整详细信息。但缺乏上下文和分析的数据只是噪音。许多传统法医调查中使用的技术适用于安卓法医分析。

分析技术

本节将提供分析技术概述，随后是展示特定文件系统程序的章节。

时间线分析

时间线分析应成为任何调查的关键组成部分，因为事件的时间几乎总是相关的。构建法医时间线的方法有很多。然而，除非使用专门软件创建，否则这个过程可能非常繁琐。本章后面将详细介绍几种软件技术，包括来自 The Sleuth Kit 和 log2timline 的自由开源法医工具。其他法医工具也可以创建时间线。

对于支持的文件系统（例如，在 SD 卡和嵌入式多媒体卡[eMMC]上发现的 FAT16/FAT32 文件系统），有许多工具可以创建时间线。然而，目前没有分析工具支持 YAFFS2，因此创建时间线需要大量的手动分析。

时间线信息的主要来源是文件系统元数据，包括修改（文件元数据）、访问、更改（文件内容）和创建时间。这些元数据通常被称为 MAC 时间，有时也被称为 MACB（其中“B”代表文件创建时间）。在进行法医分析时，必须考虑文件系统跟踪不同时间戳并具有细微差别。

例如，微软的 FAT 文件系统已经成为了许多法医调查和分析的主题。微软开发者网络（MSDN）提供了关于 FAT 和 NTFS 文件系统中的文件时间的详细信息，并指出：

并非所有文件系统都能记录创建和最后访问时间，而且不是所有文件系统都以相同方式记录它们。例如，FAT 上的创建时间分辨率为 10 毫秒，而写入时间分辨率为 2 秒，访问时间分辨率为 1 天，因此实际上它是访问日期。NTFS 文件系统会将文件最后访问时间更新延迟最多 1 小时。

（文件时间，未标明日期）

Andre Ross 在他的 digfor（数字法医）博客上创建了一个有用的图形表示(digfor.blogspot.com/2008/10/time-and-timestamps.html)，如图 7.1 所示（Ross, A., 未标明日期）。

图 7.1 FAT 和 NTFS 时间及时间戳。

为了进一步说明 FAT 时间戳的工作原理，数字取证和事件响应公司 cmdLab 发布了一篇名为“文件系统时间戳的误解”的博客（Casey, E., n.d.），其中提供了关于 FAT 时间戳的完整详细信息。

之所以出现混淆，是因为 FAT 文件系统对创建时间和最后写入时间戳的表示略有不同。最后写入时间戳是 32 位小端值，解释如下：

以以下 FAT 文件夹条目为例，其中最后写入日期以粗体突出显示：

转换为大端表示为 3a 75 b9 78，其二进制表示如下：

00111010 01110101 10111001 01111000

这对应于以下时间戳：2009.03.21 23:11:48：

• 7 位 = 0011101 = 1980 年以来 29 年

• 4 位 = 0011 = 3 个月

• 5 位 = 10101 = 21 天

• 5 位 = 10111 = 23 h

• 6 位 = 001011 = 11 min

• 5 位 = 11000 = 24 = 48 s

请注意，5 位无法存储所有的 60 秒，因此最后写入时间戳必须以 2 秒的间隔递增，并且总是偶数秒。

尽管创建时间遵循类似的通用计算方法，但它使用额外的 8 位来表示百分之一秒。在上面的同一目录列表中，创建时间戳与最后修改时间戳相同，除了多出一个字节（75 78 b9 75 3a）。这个额外的字节等于 117 百分之一秒，这使得创建时间变为 2009.03.21 23:11:49.17。因此，创建时间可以有奇数秒，并且具有 10 毫秒的分辨率。

本书用于时间线分析的一个工具是 The Sleuth Kit（TSK），它支持多种文件系统。TSK 维基提供了表 7.1 中的信息，以定义支持的文件系统 MACB 时间戳的含义（Carrier, B., n.d.）。

表 7.1 文件系统 MAC 含义

不幸的是，截至版本 3.2.1，TSK 并不完全支持 YAFFS2。然而，有一些努力提供这些信息。对于 Android，TSK 在分析 FAT 文件系统以及某些设备上发现的 EXT3 方面是有效的。TSK 尚未完全支持 EXT4，但软件更新频繁，检查员应访问www.sleuthkit.org/以获取最近的更改。

文件系统分析

正如本书所讨论的，Android 文件系统中的目录和文件显然是法医调查的主要关注点。本章和本书的最后一节“Android 应用分析与参考”将提供对 Android 应用的详细分析。将此信息与第四章中展示的技术相结合，将为调查提供最重要的结果。

调查中需要检查许多目录。随着时间的推移，检查员需要扩展目录和文件列表，因为 Android 设备变化迅速。解决这个问题最好的方法是首先运行以下命令，以确定系统上挂载了哪些文件系统，它们挂载在哪里，以及它们的类型是什么。为了说明，让我们看看四款不同的 Android 手机，包括 T-Mobile/HTC G1，谷歌 Nexus One，摩托罗拉 Droid 和 HTC Incredible。

首先，让我们检查一下运行 Android 1.5 的 G1 上的 mount 命令输出：

这款特定的 G1 运行的是原厂固件，没有插入 SD 卡，所以我们只剩下四个用强调标记的文件系统需要检查。

同样，我们检查一下运行 Android 2.1-update1 的 Nexus One 上的 mount 输出：

在这个案例中，Nexus One 上有五个文件系统，我们用强调的方式标记出来，这应该是检查的初步关注点。新增的文件系统是挂载的 SD 卡。

接下来，我们看看运行 Android 2.2.1 系统的摩托罗拉 Droid 的挂载文件系统：

摩托罗拉 Droid 也有七个值得关注的文件系统。然而，它们与 Nexus One 略有不同。

最后，让我们看看之前讨论的运行 Android 2.2 的 HTC Incredible 的输出：

HTC Incredible 以九个值得关注的文件系统位居榜首。如您所见，不同的 Android 设备和不同的 Android 版本，关注的文件系统会有所变化。然而，从上述检查中，我们创建了表 7.2，这为文件系统检查提供了一个强有力的起点。

表 7.2 调查中应包含的文件系统

挂载点	文件系统类型	相关性
/proc	proc	使用“cat”命令在手机上检查。寻找关于系统的相关元数据，如文件系统统计信息
/data/data（在旧系统上，整个/data 是 1 个分区/文件系统）	YAFFS2	几乎所有的应用数据
/data（在新手机上/data 可以进一步细分）	EXT3/EXT4/YAFFS2	应用和系统数据，不包括/data/data 中的应用数据存储
/cache	YAFFS2/EXT3	一些应用和系统使用的缓存文件系统
/mnt/asec	tmpfs	未加密的应用 .apk 文件，它存储在 SD 卡上并加密，但在这里解密以便运行系统访问和使用
/app-cache	tmpfs	临时文件系统，HTC Incredible 上的 com.android.browser 存储缓存。随着时间的推移，其他应用也可能使用这个目录
/mnt/sdcard	vfat	可移动 SD 卡上的 FAT32 文件系统
/mnt/emmc	vfat	嵌入式 MultiMediaCard (eMMC) 上的 FAT32 文件系统

值得注意的是，由于这些文件已被分配，即使是不受支持的文件系统（如 YAFFS2），这些文件也可以被复制到另一个介质上，并使用现有的取证工具和技术进行检验。例如，可以从 Android 设备将“/data/data”的内容复制到你的取证工作站上，然后直接检查内容。

文件雕刻

文件雕刻是一个过程，通过这个过程，在二进制数据中搜索并提取特定的文件类型，通常会导致整个磁盘或分区的取证镜像。文件雕刻通过检查二进制数据并基于已知的文件头来识别文件。如果文件格式有一个已知的文件尾，它将从头部扫描直到找到尾部（或达到配置文件设置的最大文件长度），然后将雕刻的文件保存到磁盘以供进一步检查。

传统的文件雕刻技术要求数据在镜像中是连续的，如果文件被碎片化，这无法产生完整的文件。文件碎片化的原因有很多，因为将文件保存到非易失性存储的过程因文件系统类型而异，并且受到内存类型（如 NAND 闪存）的强烈影响。这也意味着，非常大的文件（如视频）将更难以恢复。

新的文件雕刻技术正在被研究和开发，以解决文件碎片化带来的限制。纽约的一家数字取证解决方案公司——数字装配（Digital Assembly）开发了一种这样的技术，称为 SmartCarving。该技术分析了多种流行文件系统（不幸的是，不包括 YAFFS2）的碎片化特性，并利用这些信息来雕刻碎片化的照片。他们的产品 Adroit Photo Forensics 还可以从未知文件系统中雕刻图像（数字装配，未标明日期）。

用于雕刻数据文件的一种流行工具是 scalpel，这是一个由 Golden G. Richard III 编写的开源高性能文件雕刻工具（Scalpel，未标明日期）。Scalpel 读取一个配置文件，其中包含所需的文件头和尾定义，以便从原始镜像中提取文件。它是独立于文件系统的，可以在 FATx、NTFS、EXT2/3、HFS 或原始分区上工作。Scalpel 是用 C 语言编写的，可以在 Linux、Windows、OS X 和其他可以编译 C 代码的操作系统上运行（Scalpel，未标明日期）。

获取 scalpel 有两种方法。首先，在取证工作站上，你可以通过 apt-get 安装：

这将安装最新版本。另外，你也可以从源代码编译，这将允许你在 Linux 或其他平台上安装最新版本，而无需等待特定平台维护者更新预打包版本。

现在 scalpel 可执行文件位于“~/scalpel-1.60”目录下，简单地称为 scalpel。此外，在同一目录中还有一个样本 scalpel.conf 文件，scalpel 需要它来运行并扩展支持的文件定义。以下是针对 Android 设备的起始 scalpel.conf 文件：

如你所见，这个配置文件的头部定义了扩展名或文件类型（如果区分大小写），要雕刻的最大大小，头部定义（以 ASCII、十六进制和其他支持的表示法），以及尾部（如果存在）。针对雕刻的目标文件类型不需要定义每个设置。有关更多信息，请参见下载源文件中的示例配置文件，因为还有许多其他非常强大的选项。现在你的 Ubuntu 工作站已经具备了进行文件雕刻所需的软件，这将在 FAT32 和 YAFFS2 部分进行介绍。

值得一提的是，大量的文件签名已经被汇编好了。Gary Kessler，一位独立的咨询数字取证实践者，在他的网站上积极维护文件签名表(Kessler, G., n.d.)。他引用了“magic file”，在大多数 Unix 系统中都可以找到，位于 Ubuntu 工作站上的“/usr/share/file/magic”。在工作站上，您可以运行“file”命令，它接受一个文件作为参数，并尝试根据 magic 文件中的签名确定文件类型。

一个简单的例子是查看“/mnt/emmc/.Trashes”中的未知文件，名为“._501”，通过文件名无法轻易识别它（当然，有些人可能会通过更改扩展名来隐藏文件类型；然而，通过检查文件签名，很容易发现这一点）：

因此，eMMC 中有一个 OS X 文件在垃圾箱里，这可能表明有人将 Android 设备连接到了 Mac 电脑。

字符串

Ubuntu 工作站上的 strings 命令默认会从任何文件（文本或二进制）中提取至少四个字符长的 ASCII 可打印字符串。虽然这种技术不是特别优雅或复杂，但它非常有效，可以快速检查二进制数据，以确定文件中是否可能包含感兴趣的信息。

有几个选项对字符串输出有很大影响。首先，让我们看一下命令手册页面的概要部分：

在执行 strings 命令时，有几个选项你应当始终考虑使用。首先，“—all”选项告诉 strings 检查整个文件（对于某些文件，它只检查文件的某些部分）。其次，“–radix=”选项指示 strings 打印在文件中找到字符串的偏移量。当你将 strings 命令和十六进制编辑器结合使用，以检查文件中可能找到的证据时，这个选项非常有帮助。radix 选项可以以八进制(–radix=o)、十六进制(–radix=x)或十进制(–radix=d)打印偏移量。对于大多数十六进制编辑器，你应该考虑使用十六进制或十进制偏移量。

另一个极其重要的选项控制字符串的字符编码，它支持大端和小端格式下的 Unicode 字符：

这一点很重要，因为 Android 不仅原生支持 Unicode，而且它还允许调查者探究那些默认语言需要 Unicode 的手机。以下是之前 dd 镜像中的一些例子：

在这个例子中，结果的最初几行被省略了。但是，你可以看到 dd 镜像在偏移量 0x880A 处引用了 htcchirp.db，紧接着我们看到了未链接(0x900A)、已删除(0x980A)，最后是 htcchirp.db-journal (0xA00A)。那么这一切意味着什么？看起来 htcchirp.db 数据库被修改了。在那段时间里，它创建了一个特殊文件（htcchirp.db-journal，一个日志文件），该文件管理更新并允许在更新不成功时回滚更改。当不再需要日志文件时，它被删除了。这对于理解发生的情况以及可能存在已删除数据的位置（日志文件对正在更新的 SQLite 页面进行了完整快照，因此，以前的值存储在 NAND 闪存上）是重要的信息。

现在，让我们更改编码参数并查找以下内容：

在这个例子中，我们正在寻找 16 位大端字符。在这个案例中，从结果中提取了两个示例。在一个示例中，偏移量 0xC42404 处清楚显示了一些与芝加哥相关的活动。调查者可以简单地打开一个十六进制编辑器，跳转到偏移量 0xC42404，查看这个条目周围的数据，试图理解这一活动。

同样有趣的是，偏移量 0x1943020 处的下一个条目引用了bearshare.com网站，并且似乎有一个时间戳。如果我们把数字 1295219345 转换成基于 Unix Epoch 的日期/时间，我们得到的是 2011 年 1 月 16 日星期日 23:09:05 GMT。同样，调查者需要更仔细地检查数据以验证任何发现，但一个好的假设是，在那时 Android 设备上发生了一些基于网络的活动。

最后一个例子（其他编码留给读者作为练习）揭示了以下内容：

这是一个很好的例子，因为它不仅包含了一个（有效的）经度和纬度，还包含了一个时间戳（以毫秒为单位，自 1970 年以来，不是秒），它转换为 GMT 时间：Sat, 30 Oct 2010 20:20:18 GMT。

Strings 是一个非常强大的命令，当与搜索和过滤器结合使用时，可以快速确定数据文件中是否容易提取电话号码、姓名、位置、GPS 坐标、日期以及更多信息。

十六进制：法医分析师的好朋友

在许多法医调查中，从物理获取的逻辑获取或逻辑文件系统分析将提供足够的数据。然而，某些案件需要深入分析以找到已删除的数据或未知文件结构。当文件系统在标准法医工具中几乎没有或没有支持时，这也同样必要，例如 YAFFS2。

可以理解，许多法医分析师宁愿不对数据进行深入分析，因为这需要大量的时间，非常繁琐，并且需要对数据结构有相当深入的理解和好奇心。然而，这种分析得出的结果常常非常惊人。可以了解到有关该案件的重要信息，而且这些知识通常可以应用于未来的许多案件。

由于这些原因，每个法医分析师都应该熟练使用十六进制编辑器，以备不时之需。这使分析师能够确切地看到正在存储哪些数据，寻找模式，并可能识别已删除或以前未理解的数据结构。

当然，让我们用一个例子来更好地解释这一点。首先，确保在你的 Ubuntu 工作站上安装以下软件包：

这是一个非常快速的基于 curses（终端）的十六进制编辑器。当然，你可以使用任何你觉得舒适的十六进制编辑器。接下来，让我们使用 strings 命令查看位于/data/data/com.android.providers.telephony/databases 目录下的 mmssms.db 文件，看看我们是否能找到一些已删除的短信。在这个示例案例中，已知设备上删除了发送到 3128781100 的短信。首先，让我们使用 strings 命令看看是否能在这个 SQLite 文件中找到那个电话号码：

在这个命令中，我们使用了管道（“|”）操作符，它将一个命令的输出传递给下一个命令。通过这种方式，我们可以将许多命令连接在一起，即时获得非常强大的分析方法。因此，上述命令执行了以下操作：

1. 在 SQLite 数据库上运行 strings 命令。

2. 将 strings 命令的输出通过 grep 程序运行，该程序基于提供的模式过滤输出。在这种情况下，我们提供了有疑问的电话号码。然而，你可以为 grep 创建非常强大的搜索字符串，包括正则表达式。

3. 将 grep 命令的输出传递给单词计数程序（“wc”），并指示它按行而不是按单词计数，以查看返回了多少行。

结果是，找到了针对该电话号码的 417 条记录；显然表明确实与该设备上的电话号码进行了通信。接下来，我们想仔细查看这些消息，因此不是将输出传递给 wc 程序，而是直接查看结果，并在电话号码后添加“-A 1”选项来包含一行文本（另外，我们将输出传递给“less”命令，以一次显示一页）：

因此，我们知道有一个 SQLite 数据库，其中包含目标号码和消息。让我们使用 SQLite3 来更好地了解数据库。这里我们将使用命令行（第四章介绍）进行操作，但如果你愿意，也可以使用带有图形界面的 SQLite 查看器。

提示

SQLite 语言参考

尽管本书中提到了多个 SQLite 工具，但您可能会发现www.sqlite.org/lang.html的 SQLite 语言参考是一个极佳的资源。对于不熟悉 SQL 的人来说，它提供了全面的概述。如果您已经了解 SQL，这个语言参考将有助于解释，正如页面标题所说，“SQLite 理解的 SQL”。

在上述 SQLite3 会话中，运行了以下命令以更好地理解数据：

1. SQLite3 mmssms.db: 打开数据库以进行查询。

2. .tables: 列出数据库中的表。

3. .schema sms: 关注 sms 表，请求数据库提供表的结构（架构）。架构相当长，因此被截断了。

4. .mode line: 将显示模式设置为行，以便更容易查看。

5. “select ∗ from sms limit 1;”: 指示 SQLite3 从 sms 表显示一条记录到屏幕上（限制一条），显示所有列。

6. .quit: 退出程序

因此，我们现在可以看到 sms 表中有很多字段，但在电话号码之后是一个个人 ID，然后是时间戳。使用十六进制编辑器，让我们确定一下从关于电话激活的消息中是否能确定日期/时间戳。首先，让我们在刚才安装的十六进制编辑器中打开 mmssms.db：

这将显示文件开头的框状十六进制以及右侧的可打印 ASCII 字符串：

我们可以按 Ctrl-T (^T)跳转到文件中的偏移量。在这种情况下，前面的 strings 命令包括了“–radix=x”，因此我们有十六进制的偏移量（0x12108），是时候搜索了：

十六进制编辑器非常响应迅速，跳转到偏移量：

从上面的十六进制数据中，我们可以看到电话号码，并在 0x12111 结束。在那之后，我们应该看到一个 person 字段，因为它是表设计中指定的下一个列（也称为表架构）。如果设置了 person 字段，它会链接到联系人表，以提供涉及人员详细信息。在这种情况下，没有设置 person，所以 SQLite 没有记录任何内容。最后，我们查看接下来的六个字节，得到 0x012AFC97C52C。转换为十进制后，得到的数字是 1284138059052。最后，我们可以使用多种技术将这个时间（以毫秒为单位的 Unix 纪元时间）转换为更易于阅读的日期/时间。对于这种情况，一个快速的技术是使用内置的 date 命令。然而，它只能处理以秒为单位的 Unix 纪元时间，而不是毫秒，所以你可以简单地将数字除以 1000（即省略最后三位数字）：

date 命令会自动以当前系统时区显示日期。另一种快速转换时间的方法是使用设计用于转换 Unix 纪元时间的网站www.epochconverter.com/，它支持以秒和毫秒为单位的 Unix 纪元时间（Epoch Converter, n.d.）。要转换，将整个时间戳（无需除以 1000）复制到网站文本框中，然后点击“Timestamp to Human date”，如图 7.2 所示。

图 7.2 在www.epochconverter.com/上的时间转换。

最后一个要提及的时间戳转换技术是由英国数字取证软件公司 Digital Detective 提供的免费工具 DCode。DCode 支持许多格式（Digital Detective, n.d.）并且如图 7.3 所示，可以转换毫秒。

图 7.3 Digital Detective 的 DCode 时间转换工具。

这个例子仅仅是为了说明如果取证分析师超越他们使用的取证软件，直接检查数据，那么可能只有这样才能访问到数据的重要性。对于知名的文件系统和“标准”案例，通常并不需要这样做。然而，移动取证，尤其是 Android 取证是一个具有挑战性的领域，因为许多文件格式、文件系统、硬件和软件不仅非常新（支持不佳），而且变化速度惊人。深入十六进制的取证分析师会发现，他们揭露的数据远比仅仅依赖现有取证软件要多。

Android 目录结构

对 Android 目录结构有一个广泛的理解对于设备的取证分析非常有帮助。为了进行这项分析，从 HTC Incredible 复制了五个重要的根级目录，然后在本地工作站上使用 tree 命令显示。按照层次结构布局，提供了许多目录的解释。

第 1 行：顶部是根目录，它创建了其他文件系统的结构和挂载点，这些文件系统之前已经探讨过。

第 2 行：如前所述，HTC Incredible 创建了一个类型为 tmpfs 的“/app-cache”目录。你可以看到浏览器缓存的结构。据推测，随着时间的推移，其他应用可能会利用这个目录。

第 6-8 行：从一开始，Android 设备就有一个专门的“/cache”目录，最初看似未被使用。然而，实际情况并非如此，应该对“/cache”分区进行完整分析。这里可以找到包括 Gmail 附件预览、浏览器 DRM、一些下载（市场和其它）以及来自无线运营商的 OTA 更新文件。

第 9 行：根级别的“/data”目录有许多重要的子目录，将在下一步介绍。请注意，一些手机（如 HTC Incredible）为“/data/data”子目录分配了一个专用的分区。

第 10 行：" /data/anr"目录包含了来自系统的堆栈跟踪（调试信息），通常对 shell 用户不可访问。然而，一些 adb 调试命令似乎可以读取这些数据。

第 11 行：" /data/app"目录包含了来自 Android 市场的.apk 文件。

第 12 行：" /data/app-private"目录用于存储来自 Android 市场的受保护应用。

第 13 行：较新版本的 Android 有一个安全的云备份 API，开发者可以将其集成到他们的应用中。" /data/backup"目录用于排队和管理这些备份。然而，到目前为止，还没有从该目录恢复有意义的数据。

第 14 行：" /data/btips"（德州仪器的蓝牙协议栈）目录存储了相关应用（com.ti.btips）崩溃时的日志文件。

第 15 行：" /data/davlik-cache"目录包含了 Davlik VM 用于运行应用的缓存 dex 文件。

第 16 行：" /data/data"目录包含了应用特定的数据，这无疑是调查中需要重点关注的最重要的区域。

第 17-23 行：出于演示目的，在目录层次结构中保留了一个应用。该目录根据包名命名，通常可以清晰地识别开发者（在本例中是 Facebook）。

第 24 行：对于《银河系漫游指南》（The Hitchhiker’s Guide to the Galaxy）的粉丝（这部经典小说给星际旅行者的著名建议是：不要恐慌），有一个名为“/data/dontpanic”的目录非常有趣，它只是用来存储系统的一些错误日志文件的地方。再次，开放系统的优点是可以检查代码。如果不是这样，我们就只能猜测其用途或进行大量的测试。以下是 AOSP 的内容：

第 25 行：/data/local目录非常重要，因为它允许 shell（非 root 手机运行 adbd 的用户账户）具有读写权限。安装应用时，首先将其复制到/data/local目录。此外，一些取证技术依赖此目录上传重要文件，通常是二进制文件。

第 26 行：/data/lost+found目录在 YAFFS2 文件系统的多个位置出现。再次，快速搜索（尝试从我们下载的 YAFFS2 源代码目录中使用“grep -R lost+found ∗.c”）将解释任何没有到根目录路径的文件或目录都将被放置在此文件夹中。

第 27-35 行：/data/misc目录包含与蓝牙、dhcp、vpn、Wi-Fi 等相关的文件。其中一个重要的文件是/data/misc/wifi/wpa_supplicant.conf，其中包含设备连接过的Wi-Fi.com网络的列表。如果无线接入点需要密码，该文件将以明文形式存储密码（渗透测试人员可以好好利用）。以下是部分列表：

第 36 行：/data/property目录包含各种系统属性，如时区、国家和语言。

第 37 行：除了子目录，你可以看到/data/system包含几个关键文件。首先，accounts.db 包含需要身份验证的账户列表，并提供名称、类型、密码（加密）和认证令牌（以及其他数据）。还有两个与设备密码或 PIN 码相关的非常重要的文件。这些文件是 gesture.key 和 password.key，它们包含密码的编码/加密十六进制值。

第 43 行：当进程崩溃时，会创建一个特殊的墓碑文件。该文件为 ASCII 格式，因此可读。更多信息可以在网上找到，例如Crazydaks.com上的一篇有信息性的帖子（在 Android 中调试，n.d.）。

第 44 行：/mnt目录是系统挂载各种文件系统的地方，包括 SD 卡、eMMC 等。

第 45 行：/mnt/asec目录包含存储在 SD 卡上的未加密应用。当 Android 引入在 SD 卡上存储应用的功能时，出于安全原因对内容进行了加密。然而，当系统运行并需要访问未加密的文件时，这些文件将在/mnt/asec中被解密并挂载。

第 46 行：/mnt/emmc包含一些设备上的 NAND 闪存上的 FAT32 文件系统。第 47 至 55 行是几个 eMMC 子目录的示例。

第 51 行：/mnt/emmc/DCIM目录，相册缩略图存储在这里。

第 52 行：/mnt/emmc/DCIM/100MEDIA目录包含由 HTC Incredible 拍摄的照片或视频。

行 53：在 FAT32 分区上可以找到"/mnt/emmc/LOST.DIR"目录，其中可能包含文件系统失去追踪的文件或片段（类似于 YAFFS2 的 lost+found 目录）。应该检查这个目录。

行 56：如果存在物理 SD 卡，它将被挂载在"/mnt/sdcard"。

行 66：与 eMMC 类似，“/mnt/sdcard/dcim"目录用于存储设备中的图片和视频。在 HTC Incredible 上，它们存储在”/mnt/emmc/DCIM"中，因此并不在物理 SD 卡上。

行 67-68：“/mnt/sdcard/download"和”/mnt/sdcard/Downloads"目录包含浏览器、电子邮件客户端等下载的文件。

行 72：如前所述，"/mnt/sdcard/secure/asec"目录是加密的，那些位于 SD 卡上（而不是 NAND 闪存）的应用程序会在此存储数据。

行 75："/system/app"目录包含与系统一起提供的.apk 应用文件。这包括由 Google/Android、制造商（在本例中为 HTC）和无线运营商（在本例中为 Verizon）捆绑的应用。在 HTC Incredible 的情况下，该目录包含一个重要的 152 个.apk 文件。在需要对案件进行应用分析时（这意味着你需要访问 apk 文件），了解这个位置很重要。参考 HTC Incredible 上存在的.apk 文件包括：

行 76 和 117：“/system/bin"和”/system/xbin"目录包含系统上使用的 Android 二进制文件。法医分析师和网络安全工程师（以及无疑的 Android 研究人员）可以通过实验这些目录中的文件，找到许多有用且未记录的命令。

行 77-80："/system/customize"目录包含针对手机的运营商特定定制，尤其是 UI。

行 81："/system/etc"目录是 Android 存储典型的 Linux/Unix 配置(/etc)目录的地方。它包含许多值得检查的配置文件——本书中无法一一讨论——但会因设备而异。

有更多目录和文件等待探索，但上述概览提供了一个很好的起点。

FAT 法医分析

SD 卡对法医调查人员来说可能是一座金矿。所有与手机同步的多媒体，或者用手机相机拍摄的内容，都存储在这里。可以恢复的项目包括图片、视频、语音录音、应用数据、音乐、Google 地图数据，以及可能使用 SD 卡存储的备份应用生成的完整备份文件。此外，调查人员还可以找到缓存的彩信图片缩略图、与已删除对象相关的垃圾信息，以及下载的应用 APK 文件。

例如，一个典型的用户可能会使用 Google 地图获取到当地购物中心的驾车指南。通过在 SD 卡上对“com.google.android.apps.maps/cache”目录进行取证检查，我们能够恢复地图图像块和导航语音提示。这些语音提示也带有日期和时间戳，因此取证调查员可以字面上根据给定的日期和时间追溯设备的位置。

在芝加哥郊区短暂旅行后，它看起来像这样：

还需要记住，SD 卡可以通过 Android 作为外部大容量存储设备挂载。这使得用户可以在 SD 卡和个人电脑之间传输任何文件。

在第六章中，我们演示了如何获取包含数据的 Android 设备上的两个当前 FAT32 分区。有许多书籍和文章涵盖了 FAT32 文件系统的分析，本节将不再详细重复这些内容。但是，本节将展示一些使用 Ubuntu 工作站对 Android 设备上发现的 FAT32 分区进行检查的技术。

FAT 时间线分析

为了构建一个 FAT32 映像的文件系统时间线，我们同时使用 The Sleuth Kit（TSK）和另一个名为 log2timeline 的优秀开源取证工具。由 Kristinn Gudjonsson 编写的 log2timeline 工具是一个自动创建时间线的框架，包括系统上各种日志文件和发现的工件。log2timeline 可在许多系统上使用，并且在提取多种文件格式的的时间戳信息以进行分析方面做得非常出色。

由于我们已经设置了 TSK，我们需要采取几个步骤来安装 log2timeline。首先，自从你第一次构建 Ubuntu 工作站以来可能已经有一段时间了，因此更新任何有新版本并且通常包含安全补丁或错误修复的软件包是一个好主意。

第一步更新了你的软件列表，第二步将实际执行升级。接下来，我们将安装 log2timeline，Kristinn 通过为他的软件创建了一个 Ubuntu 软件包，极大地简化了这一过程。

这四个命令执行以下操作：

1. 将 log2timeline 自定义软件仓库添加到 Ubuntu 工作站的总体列表中。

2. 下载用于验证软件的公钥并将其添加到接受密钥列表中。

3. 更新软件包列表。

4. 安装 log2timeline。

为了进行分析，我们将使用在第六章中成像的 2 GB SD 卡的取证映像。首先，检查员应始终确保映像的哈希签名与取证成像期间获取的哈希相匹配，以确保映像是有效的。

如果你记得，输入设备（在本例中为/dev/sdc）的哈希值是 e5dcc0af1d8a09c9af4d2db98f5f684d20a561666b9ff8df7c8b90a0b9d78770。取证镜像现在已验证。接下来，让我们先用 file 命令快速查看文件：

因此，我们实际上是在处理一个带有有效分区的磁盘镜像。接下来，我们可以使用 TSK 的 mmls 进一步检查磁盘镜像：

最后是 TSK 的 fsstat，但请注意，你必须提供一个扇区偏移量 129，因为 FAT 分区从那里开始：

在此例中，分区是一个带有数据的 FAT16 分区。因此，我们首先要使用 TSK 的 fls 命令构建时间线：

设置的选项具有以下含义：

• -z CST6CDT—将时区设置为美国中部时间的 CST6CDT

• -s 0—如果已知时间偏移，则设置时间偏移

• -m /mnt/sdcard—在写入 body 文件时用这个值作为路径前缀

• -f fat16—将文件系统设置为 FAT16

• -r—递归遍历所有目录以构建时间线

• -o 129—将偏移量设置为 129（假定一个扇区大小为 512 字节，但可以使用-b 选项更改）

• -i raw—设置镜像类型，在本例中为原始镜像，而不是其他取证镜像格式

• ~/sd-emmc/viaforensics/af-book/sdcard2-113serialno/sdcard2-113serialno.dc3dd—镜像文件

• > ~/sdcard.body—将命令的输出重定向到文件，而不是在屏幕上显示

通常了解命令需要多长时间很有帮助（如果没有什么，随着时间的推移，你会知道什么时候去拿咖啡加热器最好）。因此，我们在 fls 前加上 time 命令，它会告诉我们程序运行了多长时间（实际）以及各种系统时间（用户，系统）。你可以查看 body 文件的内容，但在后续步骤中，我们将把它转换成更易读的格式。如果你想验证 fls 返回的结果，你总是可以确定文件中的总行数：

因此，我们刚刚超过了 24,000 个条目。接下来，我们需要以只读方式挂载文件系统，然后我们可以对其运行 log2timeline。要使用 dd 镜像挂载文件系统，请使用 mount 命令和一个名为 loopback 的特殊设备。完整的命令如下：

再次，让我们看看设置的每个选项。首先，此命令需要管理员权限，所以我们用 sudo 运行。选项如下：

• -t vfat

• -o loop,ro,offset=66068—这告诉 mount 使用 loopback 设备，因为我们使用的是物理文件而不是实际的设备。ro 以只读方式挂载电子邮件。最后，我们必须告诉 mount 在哪里找到分区。从 mmls 命令中，你记得偏移量是扇区 129。Mount 不知道扇区大小，所以我们计算 129×512，等于 66,048

• ~/sd-emmc/viaforensics/af-book/sdcard2-113serialno/sdcard2-113serialno.dc3dd—dd 镜像文件

• ~/mnt/sdcard—挂载镜像的位置

我们可以通过执行不带选项的 mount 命令来验证文件系统是否已挂载，这将返回所有已挂载文件系统的列表。我们通过 grep 管道来隔离我们要查找的文件系统：

因此，我们可以看到 vfat 文件系统通过环回设备“/dev/loop0”以只读方式挂载在“/home/ahoog/mnt/sdcard”位置。你可以使用 df 命令查看总大小：

因此，在可用的 1.7G 中，只有 244M 被使用。现在我们准备使用与 log2timeline 一起提供的 timescanner 程序，从文件中提取额外的时间线信息。我们将把命令输出追加到与 fls 相同的正文文件中：

timescanner 的选项如下：

• -d /home/ahoog/mnt/sdcard—指定要扫描时间戳工件的目录

• -z CST6CDT—再次将时区设置为美国中部时间

• >> sdcard.body—将输出追加到现有的 sdcard.body。请注意双大于号（“>>”），它会指示 shell 将内容追加到文件中（如果文件不存在，则创建它）。如果你忘记并使用了单“>”，那么你会覆盖 fls 的输出。

Timescanner 只提取了 410 个工件，这比扫描整个硬盘所提取的数量要少得多。但是，这 410 个工件肯定有助于构建设备的整体时间线。

最后，我们可以使用 TSK 的 mactime 命令创建一个易于阅读（且易于分享）的时间线 csv 文件：

传递给 mactime 的选项如下：

• -b sdcard.body—指定要转换的正文文件

• -z CST6CDT—时区

• -d—以 csv 格式输出文件

这只需几秒钟，对于不到 25,000 个条目，但在 csv 文件中产生了超过 73,000 行。

你现在可以轻松地在电子表格程序中浏览时间线，甚至可以将其导入数据库进行进一步分析。有几个有趣的项目需要指出。

首先，你可能会看到很多接近 1970 年 1 月 1 日的日期。这是由于时间戳被设置为 0 或根本没有设置。由于 Unix 纪元是基于自 1970 年 1 月 1 日 00:00:00 UTC 以来的秒数，那么偏移量将是那个确切的时间。在上面的例子中，我们将时区设置为 CST6CDT，一月份这是 GMT -6 小时。因此，有很多带有“Wed Dec 31 1969 18:00:00”时间戳的工件。虽然我们无法从这些工件中提取具体的时间线数据，但它们可能仍然包含重要信息。

如果你从 Ubuntu 工作站双击 sdcard-timeline.csv 文件，Open Office 的 Calc 程序将显示如图图 7.4 所示的文本导入屏幕。确保“分隔符”设置为逗号，然后按确定。

图 7.4 将 sdcard-timeline.csv 文本导入到 OO Calc 中。

然后 Calc 程序将打开，你可以浏览时间线，如图图 7.5 所示。

图 7.5 在 OO Calc 中查看时间线。

如你所见，大多数文件都被删除了。然而，TSK 和其他程序仍然可以恢复它们。一个有趣的事件是检查一个应用程序出于测试目的被移动到 SD 卡上。该应用程序，愤怒的小鸟，支持从 SD 卡运行，在 2011 年 2 月 15 日 06:17:28 进行了测试，如图图 7.6 所示。

图 7.6 应用程序移动到 SD 卡的时间线。

时间线清楚地显示在“/mnt/sdcard/.android_secure”中在 06:17:28 创建并修改了一个新文件。

最后一个要指出的是来自 log2timeline 的条目。当它遇到一个 PDF 时，提取了元数据。我们可以看到以下内容：

• 2010 年 11 月 29 日星期一 04:44:47

• 23,159 字节

• 文件已修改

• 标题：（扫描文档）

• 作者：[michelle]

• 创建者：[HardCopy]

• 制作者：[Lexmark X543]

• 文件：/mnt/sdcard/.easc/Attachment/ATT_1291219677612.pdf

时间线分析非常强大，特别是如果法医分析师结合了 Kristinn Gudjonsson 的传统文件系统时间戳工件 log2timeline。

FAT 附加分析

对于 FAT 分区的进一步分析有许多不同的方法。首先，市场上大多数法医软件都支持 FAT 文件系统，许多检查员都有他们感到舒适的工具集。除了法医软件，我们在第一部分中介绍了一些额外的技术，包括：

• 文件系统分析

• 文件雕刻

• 字符串

• 十六进制分析

即使文件系统类型不同，这些技术也是相似的，因此我们将在接下来的 YAFFS2 部分提供详细的内容。但是，下面突出了一些简要概念。

首先，SD 卡显然有大量被删除的文件。建议使用法医工具来恢复数据。TSK 可以恢复数据，以及其他许多法医软件包。此外，应使用文件雕刻技术来恢复分区文件分配表中未引用的文件。字符串和十六进制分析再次成为快速定位感兴趣数据的好方法。

如果使用 Ubuntu 工作站进行文件系统分析，还有一项快速技术要提及。使用 find 和 file 命令，你可以按名称、路径和文件类型列出所有已分配的文件。你可以轻松地即时排序，或者将它们导入电子表格或数据库进行进一步分析。这项技术只列出已分配（未删除）的文件，但非常有效。

命令如下：

总的来说，这个命令在 SD 卡上找到了并分类了 4352 个已分配的文件。以下是命令每一部分完成的工作：

• find ~/mnt/sdcard—在挂载 SD 卡镜像的目录中查找文件，即~/mnt/sdcard

• -type f—只检查普通文件（即，不列出目录）

• -print0—使用 NULL 字符结束每个文件名，而不是默认换行符，当文件名包含空格时会导致问题

• “|”—将 find 的输出传递给下一个程序

• xargs—这个程序使用标准输入（例如，其他程序的输出）构建并执行命令行

• -0—告诉 xargs，通过管道传输的数据由 NULL 字符结束（与 find 的-print0 匹配）

• file—这是 xargs 针对 find 命令返回的每一行执行的命令

find 和 xargs 命令是检查、交互或以其他方式处理大量文件非常强大的方法。通过结合时间线分析和文件系统分析、文件雕刻、字符串和十六进制分析，调查员装备了强大的工具，以揭示对案件至关重要信息。

FAT 分析笔记

关于 Android 上的 FAT 文件系统还有几点剩余的说明。

SD 卡上的应用

首先，如第六章所述，从 Android 2.2 开始，用户可以将支持的应用移动到 SD 卡，以节省"/data/data"目录中的空间，该目录用于存储用户数据。应用必须明确支持此功能，典型的候选者是使用大量存储空间的应用，如游戏。为了测试这个功能，在参考 HTC Incredible 上安装了 Rovio Mobile 公司流行的 Angry Birds 游戏（Rovio - Angry Birds, n.d.）。运行了该应用，然后关闭。要将应用移动到 SD 卡，你从主屏幕选择设置，然后是应用程序，最后是管理应用程序，如图 7.7 所示。

图 7.7 管理应用程序屏幕。

如你所见，“Angry Birds"在”/data/data"目录下占用了 18.40 MB 的空间，这是非常宝贵的空间。因此，应用开发者包含了必要的支持，将.apk 移动到 SD 卡。然后用户可以选择应用（在这个例子中是 Angry Birds），并会看到一个包含有关应用信息及选项的屏幕，包括“移动到 SD 卡”选项，如图 7.8 所示。

图 7.8 移动到 SD 卡。

从这个屏幕上，你可以看到应用程序本身使用了 18.39 MB，而用户数据只有 12.00 KB，显然是移动.apk 文件到 SD 卡的理想候选者。正如图 7.9 所展示的，只需点击“移动到 SD 卡”按钮，然后等待任务完成即可。

图 7.9 应用程序移动到 SD 卡完成。

这对于用户来说是非常好的。但对于取证检查员或安全分析师来说这意味着什么呢？接下来描述了一些步骤，并在代码列表中突出显示。

1. .apk 文件从“/data/app”（或“/data/app-private”）移动到 SD 卡上加密分区中的/mnt/secure/asec（见下一个列表中突出显示的部分），只能通过根目录访问。

2. 一个新的设备映射文件系统被只读挂载，来自“/mnt/secure/asec”的应用程序被解密，并且可以在“/mnt/asec/com.rovio.angrybirds-1”处被系统访问。系统必须能够访问未加密的.apk 文件才能运行该应用程序。

3. 用户数据保留在“/data/data”中（在本例中为“/data/data/com.rovio.angrybirds”）。

4. 如果 SD 卡无法访问（无论是被移除、损坏，还是仅仅在主机计算机上挂载用于文件共享），未加密的卷会被卸载，并且不再能被系统访问。这就是为什么核心应用程序目前无法从 SD 卡运行的原因。

.apk 文件在 SD 卡上被加密，以确保其他应用程序（或进程）不能损坏或恶意修改应用程序。然而，应用程序开发者不应依赖加密来防止人们访问.apk 文件，因为它只是从未加密的“/mnt/asec/”中复制的问题。以下代码中的 mount 和 ls 命令说明了这个结构。

如果你需要.apk 文件进行分析（例如，调查恶意软件），那么在获取过程中，当 SD 卡插入并激活在 Android 设备上时（即没有在取证工作站上进行物理获取的挂载），复制“/mnt/asec”子目录是至关重要的。

nomedia

在 SD 卡和 eMMC 分区上常见的另一个项目是一个名为.nomedia 的空文件，它会指示 Android 的媒体扫描器跳过该目录，这样在诸如图库或音乐等应用程序中就不会包含任何媒体文件。如果一个目录不包含这个文件，那么很可能之前删除的图片仍然有缩略图存在于媒体扫描器的目录中。关于 Android 应用程序分析和参考的部分将进一步讨论这个问题。

YAFFS2 取证分析

正如在第四章所讨论的，YAFFS2 是一个开源的、针对 NAND 闪存设计的日志结构文件系统，支持磨损均衡和错误校正码算法。这对于手机用户来说是个好消息，因为 YAFFS2 在 Android 上运行良好；对于法医分析师来说也是个好消息，因为大量的旧数据（已删除或更新的）是可以恢复的。但好消息仅此而已。由于 YAFFS2 是一个相对较新的文件系统，目前还没有商业法医软件解决方案支持它。

然而，一切并未丢失。利用 Linux 的强大功能，YAFFS2 的开放性，有效的获取策略，以及已经讨论过的技术，包括文件系统分析、文件雕刻、字符串和十六进制分析，法医检查员可以从文件系统中提取大量相关信息。

当我们深入分析 YAFFS2 时，记住它的结构方式非常有帮助。需要回忆的一个重要概念是数据是如何通过 MTD 在 NAND 闪存上物理结构化的。通常，YAFFS2 和 MTD 将 NAND 闪存组织成 128 KB 的块，每个块由 2048 KB 的数据块和 64 字节的带外数据（OOB）组成（使得 NAND 闪存上的总大小为 132 KB），用于存储磁盘和某些文件系统元数据，如图图 7.10 所示。

图 7.10 块（128 KB = 64 × 2k 块 + OOB）。

当然，Android 设备并不需要以这种方式构建 NAND 闪存和 MTD，最好的验证方法是检查“/proc/mtd”文件的内容，该文件包含配置信息。以下是来自参考 HTC Incredible 的文件内容。

虽然如果我们想在 Ubuntu 工作站上尝试挂载 YAFFS2 nanddump，我们需要 OOB 数据，但 64 字节的 OOB 数据肯定会对大多数法医技术，尤其是文件雕刻造成问题。为了减轻这个问题，你可以使用一个简单的程序简单地移除 OOB。该程序是用 Python 编写的，可以轻松地适应不同的块和 OOB 配置。

首先，让我们使用 sudo 权限打开一个新文件进行编辑，这样我们就可以将程序放在“/usr/local/bin”中，这是保存自定义脚本和程序的最佳位置。

接下来，将以下内容复制到编辑器中：

然后使用 Ctrl-O 保存并使用 Ctrl-X 退出。接下来，你需要使 Python 文件可执行，所以输入以下内容：

最后，我们可以对 nanddump 文件运行程序：

让我们确保 removeOOB.py 的结果符合我们的预期。根据“/proc/mtd”的信息，分区“/dev/mtd/mtd6”的大小为 0x9500000 字节，擦除大小（块大小）为 0x20000。总字节大小为 156,237,824（将十六进制的大小转换为十进制），大约为 154 MB。同样，擦除大小为 2048 字节，因此如果我们用 156,237,824 除以 2048，我们得到数据中的 76,288 个块。这与 removeOOB.py 的结果相符合。但还有一件事我们可以检查。由于我们知道 nanddump 在每个 2k 数据块后都有 64 字节的 OOB 数据，因此磁盘上的 nanddump 总大小应为 (76,288 × 64) + 156,237,824。然后总数应为 161,120,256，这代表了数据块及其相应的 OOB。我们可以通过简单的“ls –l”命令查看磁盘上的大小：

如您所见，完整的 nanddump 和 .dd 映像（移除了 OOB 的 nanddump）都与预期的大小相符。

既然我们已经有了 YAFFS2 nanddump 文件、dd 映像以及逻辑文件（通过 tar、adb pull 或挂载 YAFFS2 分区获得），我们可以对数据执行各种技术。

YAFFS2 时间线分析

理想情况下，这一节将详细说明已经构建的取证软件的使用，该软件可以构建 YAFFS2 时间线。不幸的是，目前还没有任何取证时间线工具支持 YAFFS2，因此需要这些信息的检查员必须走一条更艰难的道路。

在未来几年中，取证行业需要针对 YAFFS2 进行更多的研究。然而，随着 Android 向 EXT4 迁移，可能大部分 YAFFS2 研究不会发生。希望情况不会是这样。

在这里，我们将介绍一些旨在为 YAFFS2 研究提供一个基本框架的研究。这项研究是在第四章中首次介绍的模拟 NAND 闪存上进行的。尽管这种方法为研究者提供了进行有效研究所需的控制和权限，但它并不一定能模仿生产环境。

如第四章所述，YAFFS2 和 MTD 都涉及将数据写入 NAND 闪存。YAFFS2 模块负责文件系统的所有方面。然而，将数据写入 NAND 闪存是由 MTD 管理的。不幸的是，这增加了分析的复杂性，因为 MTD 可以接受来自 YAFFS2 的数据，这些数据需要写入 NAND 闪存，然后它有自主权，不仅可以写入 YAFFS2 数据，还可以按照它认为合适的方式写入额外的 MTD 数据。对持久数据的研究必须考虑到不仅是 YAFFS2 代码，还有 MTD 代码。此外，不同 Android 设备上使用的 YAFFS2 和 MTD 模块之间可能存在细微差异，这又增加了一层复杂性。

这并不意味着理解 nanddump 中找到的 YAFFS2 数据是不可能的。为了开始，我们将在 Ubuntu 工作站上设置一个 64 MB 的模拟 NAND 闪存设备。

你可以验证 nandsim 是否正确设置：

在挂载 YAFFS2 文件系统之前，我们将启用 YAFFS2 内置的各种调试功能。YAFFS2 支持许多调试选项（YAFFS Debugging, n.d.），但我们只启用其中的三个。为此，我们首先需要拥有完整的 root 权限，然后将调试标志输入到“/proc/yaffs”：

echo 命令后的值首先移除所有现有的调试（无），然后启用 os、write 和 mtd 调试选项。你可以在位于“/var/log/syslog”的系统日志中查看调试的结果。理想情况下，打开第二个终端窗口或 ssh 会话，并使用 tail 命令持续输出 syslog 的末尾部分：

接下来，我们创建挂载点并挂载 YAFFS2 文件系统：

在这一点上，检查员应该创建一系列测试用例，以便在模拟 NAND 闪存上检查预期的受控数据，最终确定其结构。对于这个测试，采取了以下步骤：

1. 在“~/mnt/yaffs2”中创建一个名为 test 的目录（mkdir ~/mnt/yaffs2/test）

2. 创建包含“viaforensics”内容的“~/mnt/yaffs2/test/file1.txt”文件（nano -w ~/mnt/yaffs2/test/file1.txt）

3. 更新“~/mnt/yaffs2/test”并将“updated”内容追加到文件（echo “updated” >> ~/mnt/yaffs2/test/file1.txt）

4. 读取“~/mnt/yaffs2/test/file1.txt”（cat ~/mnt/yaffs2/test/file1.txt）

5. 更改目录和文件的用户和组所有者（chown -R pulse.rtkit ~/mnt/yaffs2/test）

6. 更改目录和文件的权限（chmod -R 777 ~/mnt/yaffs2/test）

在执行这些测试时，不仅文件系统被更新，而且调试信息被写入 syslog。调试信息非常详细（我们只启用了三个调试选项），因此这里只提供了两个示例，分别对应以下内容：

1. 创建“~/mnt/yafs2/test”目录

2. 更改 file1.txt 的权限（chmod -R 777 ~/mnt/yaffs2/test）

调试提供了有价值的信息，包括对象 id、序列号、块 id 以及 YAFFS2 创建文件所遵循的详细过程。如果你启用了额外的调试功能，你将拥有更多的数据来关联和使用，以便更好地理解 YAFFS2。

在我们检查实际的 nanddump 之前，还有另一个有用的命令值得一提。stat 命令将提供关于文件、目录或其他文件系统对象的详细信息。例如，我们可以对“_{/mnt/yaffs2/test”和“}/mnt/yaffs2/test/file1.txt”运行 stat 命令，并将信息用于我们的研究：

现在我们已经获得了文件和目录的修改、访问和更改属性，结合我们创建数据的操作，我们有足够的信息开始我们的研究。

是时候查看 NAND 闪存了，这需要 root 权限。以下命令将跳过 NAND 闪存的行，这些行都是 0xFF 和 0x00，使其更容易看出趋势。此外，出于空间原因，这里只显示了 NAND 闪存的一小部分，以十六进制表示：

包括的 NAND 闪存部分涵盖以下内容：

1. 创建“~/mnt/yaffs2/test”目录

2. 对 file1.txt 文件权限更改（chmod -R 777 ~/mnt/yaffs2/test）

显示的数据是 YAFFS2 ObjectHeaders 的一部分，包含文件系统的元数据。文件名清晰可见，64 字节的 OOB 区域也是如此。此数据的一个关键特点是表示 Unix 纪元时间戳的整数以小端序排列，这意味着您必须从右到左读取数据。

• 写入 NAND 闪存的数字：63 99 d5 d4（0x6399d5d4）

• 从 little endian 转换为 big endian：4d 5d 99 36（0x4d5d9936，这是从右到左读取的十六进制数）

• 将 0x4d5d9936（十六进制）转换为十进制是 1297979702

• Unix 时间戳 1297979702 以人类可读的日期/时间格式是 2011 年 2 月 17 日星期四 15:55:02 CST（date -d @1297979702）

使用这些信息，我们可以在 nanddump 中隔离出许多重要的工件，如表 7.3 所示。

表 7.3 来自 YAFFS2 Nanddump 的工件

令人满意的是，调试日志、stat 命令以及模拟 NAND 闪存设备的 nanddump 数据均相互对应。通过进一步分析，完全有可能为 NAND 闪存上的每个文件和目录创建 MAC 时间，这将为审查员提供明显的好处。也有可能从 NAND 闪存上仍然存在的 ObjectHeaders 中收集完整的元数据信息，并且如果在块上没有发生垃圾回收，还可以获取每个时间点的全部内容。

值得指出的是，在本文展示的非常有限测试和分析中，似乎文件的atime（访问时间）并不是每次访问文件时都会更新。这并不奇怪，因为这意味着每次程序访问文件时，都必须将新的 ObjectHeader 写入 NAND 闪存。这将导致对 NAND 闪存的写入次数大大增加，不仅会消耗宝贵的电池电量，而且还会因大多数用户并不真正关心的元数据更新而耗尽 NAND 闪存。这种做法并不特别不寻常，因为微软在默认情况下，在 Microsoft Windows Vista 和 Windows 7 中禁用了atime更新。

需要指出的是，这种分析并不是微不足道的。它能提供有价值的信息，并为对 YAFFS2 文件系统进行法医研究提供基础。

YAFFS2 文件系统分析

对 YAFFS2 文件系统进行十六进制分析非常耗时，因此让我们继续分析分配的文件的技术。不幸的是，这里又遇到了挑战，因为从 Android 设备提取后，挂载 YAFFS2 nanddump 可能会相当困难。

因此，如第六章所述，如果你在 Android 设备上有 root 权限，最好不仅要获取适当的 YAFFS2 nanddump 文件，还要使用 adb pull、tar 或其他方法从系统中逻辑地复制重要目录。这样，如果你无法挂载 YAFFS2 nanddump，你仍然有一个逻辑上的文件副本。然后可以使用 nanddump 来创建时间线、进行其他十六进制分析以及文件雕刻。

然而，在 Linux 中可能挂载一些 YAFFS2 nanddumps，随着时间的推移，预计会有更多的 nanddump 文件成功挂载。但是，在本节中，我们将关注来自摩托罗拉 Droid 的 nanddump，因为它们可以通过 nandsim 和 YAFFS2 内核模块在 Linux 中成功挂载。

首先，我们需要加载合适的内核模块并创建一个 1 GB 的 nandsim 设备。

现在我们有一个 1 GB 的 nandsim 设备，可以容纳 Droid 的“/data”分区。下一步是使用 nandwrite 将数据和 OOB 都复制到模拟的 NAND 闪存中。

这些参数指示 nandwrite 执行以下操作：

• sudo nandwrite—nandwrite 需要 root 权限

• --autoplace—使用自动 oob 布局

• --oob—图像包含 oob 数据

• /dev/mtd0—写入 nanddump 的 mtd 设备

• droid_userdata.nanddump—nanddump 文件的名称

如果一切按照预期进行，我们现在应该能够使用以下命令挂载文件系统：

在这个过程中，你可能会遇到两个主要问题。首先，YAFFS2 和 MTD 可能无法成功挂载文件系统，并会显示以下信息：

导致这种情况的原因可能有：

• 设备的 YAFFS2 和 MTD 实现与你的工作站之间的差异

• 损坏或无效的 nanddump

• 文件系统问题

第二个最常见的问题是文件系统挂载了，但是没有文件：

这很可能是由于设备的 YAFFS2 和 MTD 实现与你的工作站之间的差异造成的，并且可能很难调试。你可以尝试一些方法来解决问题。首先，如果你有大于 20090606-1 版本的 mtu-utils，尝试安装旧版本。以下是检查你当前版本并选择安装的方法：

既然我们已经降低了 MTD 的版本，你可以尝试再次执行挂载 YAFFS2 nanddump 的步骤。

另一个可能的情况是，你的 YAFFS2 版本与 Android 设备上使用的版本不够一致。为了获得不同版本的 YAFFS2，你需要使用 YAFFS2 或 Android 开源项目的源代码控制系统。然后，你可以编译该源代码，移除现有的 YAFFS2 内核模块，插入新的模块，并再次尝试。

如果这些步骤有效，以下是你会看到的情况：

目前，我们已经可以在 Ubuntu 工作站上访问到一个摩托罗拉 Droid 手机的完整“/data”文件系统，你可以使用你选择的取证工具进行探索和分析。最终，如果你无法在 Ubuntu 工作站上挂载 nanddump，你仍然应该拥有获取过程中完整的逻辑文件集，因此它不应该妨碍对设备进行分析。

YAFFS2 文件雕刻

下一个用于分析 YAFFS2 文件系统的技术是文件雕刻。在本章前面，我们在 Ubuntu 工作站上安装并配置了 scalpel。对于这个例子，假设 Ubuntu 虚拟机上登录用户的主目录中有一个名为 htc-datadata.dd 的文件。在同一个目录（你可以在命令中使用 ~ 来引用它），有一个包含 1.3 节条目的名为 scalpel-android.conf 的 scalpel 配置文件。

请注意，我们在这里使用的是 dd 映像 进行文件雕刻，而不是 nanddump。这是必要的，因为每个 2k 块 YAFFS2 数据后面的 OOB 数据将严重影响 scalpel 雕刻有效文件的能力。以下命令将在 dd 映像上运行 scalpel，并将文件输出到名为 htc-scalpel-test 的文件夹中，该文件夹位于你的主目录中：

在这种情况下，scalpel 能够恢复 11,370 个文件，并且输出提供了有关恢复的文件类型和数量的详细信息。图 7.11 是在 Ubuntu 工作站上查看其中一个 JPG 目录的屏幕截图。

图 7.11 使用 scalpel 恢复的图像查看。

图片的分辨率并不高，但特别是在工作站上直接查看时，你可以分辨出内容。以下是这部分图片显示的一些内容：

• 前三张图片是 YouTube 视频的开头帧，在这个例子中是龙卡通。

• 接下来的图片是 Facebook 消息的一部分，询问午餐并推荐寿司。

• 剩余的图片似乎来自不同的新闻文章。

正如所示，文件雕刻可以从 YAFFS2 恢复重要的工件，对于法医分析来说是一个有价值的工具。

YAFFS2 字符串分析

我们已经展示了一个在 Android 设备上使用 strings 查找数据的例子。但是，让我们通过另一个练习来演示这项技术以及这种分析类型的强大功能。

在这个例子中，检查员需要在 Android 设备上找到位置信息。特别是在 Android 设备上，一个需要搜索的关键词是maps.google.com，因为 Google 地图服务与操作系统紧密集成。一个非常强大的搜索工具叫做 grep，它被广泛使用，现在在技术术语中已经变成了一个动词（“你有没有用 grep 搜索设备上的地图引用？”）。它不仅内置在 Ubuntu 虚拟机中，而且支持非常强大的正则表达式（通常简称为 regex 或 regexp），这允许进行复杂的模式匹配。有许多在线资源介绍了 grep 和 regex，并附有很好的示例。

在我们的例子中，我们将使用 grep 的最基本功能，我们只需搜索一个字符串：

查询返回了 775 个示例——出于简洁和隐私原因，这里只显示了一些。然而，很容易确定设备上发生的一些活动。具体来说：

• 对 Naperville 犯罪预防的搜索（URL 中的 q=代表查询）已经进行，URL 是有效的，包括地址、电话号码、图片、方向等。

• 对肯尼迪航天中心游客综合体的搜索也已完成。

• 肯尼迪航天中心的查询随后被移动地图应用程序查看，我们甚至可以看到 IP 地址。

如果我们查看 IP 地址，它是最后一个查询的一部分（174.253.2.53），我们可以使用命令行工具或在线 IP 查找服务（What Is My IP Address, n.d.）来获取更多信息。结果在图 7.12 中显示。

图 7.12 IP 地址查找结果。

IP 查找服务的信息揭示了几个重要的信息片段：

1. 设备正在使用威瑞森无线网络。

2. 设备位于伊利诺伊州芝加哥地区（可以伪造和欺骗 IP 地址，但在大多数情况下这并不简单且不太可能）。

由于我们已恢复字符串的十六进制偏移量，我们可以查看此搜索周围的数据以确定搜索发生的大致时间范围。

YAFFS2 分析师笔记

对于 YAFFS2 取证的大部分手动分析确实很耗时且有些令人畏惧，这导致进入这一领域的门槛比分析那些理解深入、支持充分的文件系统要高。然而，有许多易于获取的资源可以协助刚接触这种方法的分析师。

首先，希望这本书为取证分析中使用 Linux 提供了一个良好的介绍（请推荐给你的所有朋友和同事，让他们也都在书架上放一本）。

也许更有帮助的是，简单的 Google 搜索常常会带来许多博客、讨论板、邮件列表等资源上的有用帖子。尽管互联网上确实存在不准确的信息，但许多在这些领域工作的技术人员发布的信息相当准确和精确。而且，作为额外的好处，许多作者对询问和澄清非常响应。

接下来，有一个针对执法和取证分析师的 Linux 优秀入门介绍，该资源在线免费提供。网站“Linux LEO：执法和取证检验员的 Linux 入门”提供了 PDF 格式的指南，并介绍了使用操作系统作为取证工具所需的 Linux 概念（Grundy, B., n.d.）。

随着你进一步使用 Linux，你会发现自动化许多手动任务其实相当简单。这不仅让你对系统如何工作有很好的控制，而且自动化可以节省大量时间。这对于忙碌的分析师来说是一个很好的组合，他们可以使用前沿工具处理更多取证数据，同时还能准确解释系统做了什么，而不仅仅是说点击了一个按钮并生成了一份报告。

开始自动化常见 Linux 任务的最简单方法就是编写一个 shell 脚本，这非常容易实现，本质上就是模仿你在终端会话中输入的命令。

例如，假设你有一系列.csv 文件，这些文件包含了在 Android 设备上运行 AFLogical 取证技术得到的结果。你需要将每个文件的第一行发送给某人，但不应包含任何设备数据。你可以手动打开每个文件，删除数据行，将更新后的文件保存到新目录，然后发送信息。但这可能需要相当长的时间。相反，你可以编写一个简单的 shell 脚本。

首先，我们打开一个新文件进行编辑：

然后将以下内容放入文件中：

然后通过按 Ctrl-O 保存文件，并通过 Ctrl-X 退出。接下来，我们必须使脚本可执行：

我们需要清理的文件位于用户主目录下的一个名为 AFLogical 的目录中，如您所见，手动处理这些文件会非常耗时：

我们现在可以轻松处理这些文件：

现在，AFLogical 目录不仅有一个名为 sanitized 的新子目录，其中包含了每个更新的文件，而且还有一个包含数据的单一文件：

这些数据可以轻松地通过电子邮件发送或复制到另一个驱动器。

下面是一个更复杂的例子，它将创建一个 nandsim 设备，挂载一个空白的 YAFFS2 文件系统，生成几个文件，然后允许用户卸载文件系统。这是自动化测试 YAFFS2 涉及的步骤的快速方法。

希望检查员不要认为由于缺乏支持 YAFFS2 文件系统的商业工具，就无法恢复额外的数据。使用 Ubuntu 工作站上可用的免费开源工具，显然可以提供进一步调查的强大手段。将这些技术与本章概述的十六进制分析相结合，检查员应发现他们已经很好地准备好从安卓设备上的 YAFFS2 分区提取证据。当一个涉及运行嵌入式 Linux 和 YAFFS2 文件系统的医疗设备的案例放在您的桌子上时，您可以自信地深入研究并解决问题。

安卓应用分析与参考

尽管本章描述了许多对安卓设备进行取证和安全调查有用的技术，但了解关键应用数据存储位置的信息很有帮助。当然，由于应用程序数量庞大，以及特定设备和安卓版本之间的差异，要维护一个完整的参考资料几乎是不可能的。

在以下各节中，我们将分析本书中使用的参考手机上的 10 个重要应用，并提供以下数据：

1. 应用信息

2. 文件和目录（包括 /data/data，SD 卡和 eMMC）

3. 重要的数据库表

4. 分析师笔记

通过应用分析，所有时间戳都是 Unix 纪元毫秒，即自 1970 年 1 月 1 日以来的毫秒数，除非特别说明。

测试的应用是在设备上安装并使用后，再通过一个自定义的 Python 程序进行分析，以自动化本章前面描述的一些技术。虽然提供了大量信息，但请注意，这只是一个参考，可能不完整。分析人员应该使用本章描述的取证和安全工具以及技术，对正在检查的设备进行全面分析。

短信（sms 和 mms）

应用信息

这是安卓系统默认的短信和彩信处理应用。

• 应用名称：短信

• 软件包名称：com.android.providers.telephony

• 版本：2.2

• 设备：HTC Incredible

• 应用开发者：Android

目录、文件和文件类型

在 /data/data/com.android.providers.telephony 目录下：

重要的数据库表和文件

MMS 和 SMS 的重要数据库表和文件显示在表 7.4 中。

表 7.4 来自 /data/data/com.android.providers.telephony/databases/mmssms.db 的重要数据库表和文件

数据库表/文件	描述
words_content	消息内容
part	MMS 附件详情，包括类型、名称、如果为二进制文件（例如图像）在文件系统中的位置以及如果为纯文本的附件内容
sms	完整的 SMS 消息，包括收件人、发件人、联系人、时间戳、阅读状态、发送/接收状态和消息内容

分析笔记

对于 /data/data/com.android.providers.telephony 的分析笔记：

• app_parts 文件夹将包含 MMS 附件，可以包括图像、视频或任何其他支持的数据。文件类型没有维护，因此请使用 file 命令或其他文件签名分析工具来识别。

• telephony 数据库通常没什么兴趣，因为它只包含无线运营商的服务信息。

• sms 表包含所有消息，应该是主要关注点。

• 其他几个表似乎复制了 sms 表内容的部分，因此查看 words_content 和其他表以帮助分析。

• 另请参阅：com.android.mms。

MMS 辅助应用

应用信息

该应用存储一些 MMS 数据，似乎是主 Messaging 应用的辅助应用。

• 应用名称：com.android.mm

• 软件包名称：com.android.mms

• 版本：2.2

• 设备：HTC Incredible

• 应用开发者：Android

目录、文件和文件类型

在 /data/data/com.android.mms 目录下：

重要的数据库表和文件

• 在 /data/data/com.android.mms/cache 目录下的 PART 文件

分析笔记

对于 /data/data/com.android.mms 的分析笔记：

• 文件“bufferFileForMms”在发送时可能包含缓冲数据。但它通常只包含 0x00。

• 缓存中的 PART 文件是 Messaging 应用中找到的位于 /data/data/com.android.providers.telephony/app_parts 的图像的小 PNG 版本。

浏览器

应用信息

这是基于开源 WebKit 项目的 Android 内置 Web 浏览器。

• 应用名称：Internet

• 软件包名称：com.android.browser

• 版本：2.2

• 设备：HTC Incredible

• 应用开发者：Android

目录、文件和文件类型

在 /data/data/com.android.browser 目录下：

在 /app-cache/com.android.browser/cache 目录下：

重要的数据库表和文件

支持的 Web 应用的本地存储显示在表 7.5 中。

表 7.5 来自 /data/data/com.android.browser/app_databases/http_www.google.com_0.localstorage 的重要数据库表和文件

数据库表格/文件	描述
项目表格	这个表格是一个简单的键/值对列表；然而，可能包含有关访问过的网站的实用信息，并利用了 localStorage 功能。

缓存的地理位置数据显示在表 7.6 中。

表 7.6 来自/data/data/com.android.browser/app_geolocation/CachedGeoposition.db 的重要数据库表格和文件

地理位置权限数据库显示在表 7.7 中。

表 7.7 来自/data/data/com.android.browser/app_geolocation/GeolocationPermissions.db 的重要数据库表格和文件

数据库表格/文件	描述
权限	这个表格是源（网站）及其每个权限（允许）的列表。例如，www.google.com 和值 1 意味着 Google 网站有权限访问地理位置

表 7.8 显示了浏览器数据库。

表 7.8 来自/data/data/com.android.browser/databases/browser.db 的重要数据库表格和文件

表 7.9 显示了网页视图数据库。

表 7.9 来自/data/data/com.android.browser/databases/webview.db 的重要数据库表格和文件

网页视图缓存数据库显示在表 7.10 中。

表 7.10 来自/data/data/com.android.browser/databases/webviewCache.db 的重要数据库表格和文件

分析师笔记

关于/data/data/com.android.browser 的分析师笔记：

• 如果需要查找特定网站并且该网站有 favicon，请检查 app_icons 中的 WebpageIcons.db。

• 特定的应用数据库可能包含非常有用的信息。例如，Google 应用数据库包含先前的搜索词，许多带有时间戳的“lon/lat/acc”缓存版本等。

• com.adobe.flashplayer 目录不仅包含以.sol 扩展名结尾的“Flash cookies”，可以通过 log2timeline 解析，还包含一些 Flash .swf 文件。

浏览器数据库（databases/browser.db）包含一个名为 bookmarks 的表格，该表格通常预先填充了来自无线运营商的书签。这个表格还包含了网页浏览器历史记录。还有一个名为 Searches 的表格，其中包含了从浏览器进行的 Google 搜索。

• 网页视图数据库（databases/webview.db）包含大量信息，不仅对法医检查员有用，对安全工程师也有用。Cookies 是可见的，而且大多数都不安全，这意味着它们可能容易受到像 Firesheep 这样的工具的 cookie 劫持攻击。表单 URL 和数据通常包含敏感信息，httpauth 和密码也是如此。

• 网页视图缓存数据库（databases/webviewCache.db）提供了有关存储在缓存目录中的缓存文件的元数据。

• 大多数设备将网页视图缓存数据作为/data/data/com.android.browser 的子目录保存。然而，HTC Incredible 将此目录移动到了 tmpfs（RAM 磁盘）目录。

联系人

应用信息

该应用是 Android 提供的主要联系人应用。尽管有许多其他应用可用，但此应用提供了核心的联系人功能。

• 应用名称：联系人

• 包名：com.android.providers.contacts

• 版本：2.2

• 设备：HTC Incredible

• 应用开发者：Android

目录、文件和文件类型

在/data/data/com.android.providers.contacts：

重要的数据库表和文件

只有一个数据库，即 contacts2.db，它有超过 30 个表。一些关键表在表 7.11 中列出。

表 7.11 来自/data/data/com.android.providers.contacts/databases/contacts2.db 的重要数据库表和文件

分析师笔记

关于/data/data/com.android.providers.contacts 的分析师笔记：

• 该应用在 calls 表中存储设备的通话记录。

• contacts2.db 中超过 30 个表，可能需要进一步检查。数据表包含有关联系人的额外值，而 raw_contacts 包含有关某些联系人的额外数据。

• 该应用能够存储来自许多不同账户的联系人信息，包括 Gmail、Exchange、Facebook、Twitter 等。存储的一些数据包括来自这些其他应用的信息，如 Facebook 状态消息。

• 如果联系人的图片可用，它们将存储在 files 目录中，并命名为 thumbnail_photo_[NNNNN].jpg。在参考 HTC Incredible 中，发现超过 200 张图片，但有重复。

媒体扫描器

应用信息

该应用扫描并存储内部和外部存储介质上媒体文件的元数据。

• 应用名称：媒体商店

• 包名：com.android.providers.media

• 版本：2.2

• 设备：HTC Incredible

• 应用开发者：Android

目录、文件和文件类型

在/data/data/com.android.providers.media：

重要的数据库表和文件

每个数据库的结构相似，如表 7.12 所示。

表 7.12 来自/data/data/com.android.providers.media/databases/的重要数据库表和文件

分析师笔记

关于/data/data/com.android.providers.media 的分析师笔记：

• 数据库名称包含卷 ID（如果有）。例如，在参考 HTC Incredible 设备上，eMMC FAT32 文件系统有一个卷 ID 为 0xc7f80810。

• 如果一个目录中有一个名为.nomedia 的文件，那么媒体商店将不会扫描并记录该目录中文件的元数据。

• 如果删除了一张图片，缩略图可能仍然存在。此外，即使删除了元数据记录，由于 YAFFS2 文件系统，它很可能可以被恢复。

• 还会扫描音频文件、专辑等。

• 存在其他媒体扫描器和应用，因此需要检查这些内容。其中一个在 SD 卡上存储缩略图，这可以提供被删除图片和视频的洞察。

YouTube

应用信息

YouTube 是一个视频观看网站，现在由 Google 拥有，为此他们为 Android 开发了一个原生应用。

• 应用名称：YouTube

• 包名：com.google.android.youtube

• 版本：1.6.21

• 设备：HTC Incredible

• 应用开发者：Google

目录、文件和文件类型

在/data/data/com.google.android.youtube中：

重要的数据库表和文件

YouTube 偏好设置，包括在/data/data/com.google.android.youtube/shared_prefs/youtube.xml中的设备密钥和已观看视频。

在/data/data/com.google.android.youtube/cache的 XML 文件中保存的关于特定已观看电影的信息：

分析师笔记

关于/data/data/com.google.android.youtube的分析师笔记：

• 检查缓存目录和 shared_prefs 目录中的 XML 文件，了解已观看视频的信息。

• 通常可以通过文件雕刻或其他技术在设备上找到视频开场图像的快照。

Cooliris Media Gallery

应用信息

这个应用是为 Google Nexus One 开发的，提供了一个媒体库和扫描器。

• 应用名称：Cooliris Media Gallery

• 包名：com.cooliris.media

• 版本：1.1.30682

• 设备：Google Nexus One

• 应用开发者：Cooliris

目录、文件和文件类型

在/data/data/com.cooliris.media中：

更重要的是，缩略图存储在 SD 卡上：

重要的数据库表和文件

对于这个设备，picasa.db 是空的，但数据库可能包含有用的信息。

分析师笔记

关于/data/data/com.cooliris.media的分析师笔记：

• 这个应用真正的价值在于，在设备上发现的媒体会在 SD 卡上的“/mnt/sdcard/Android/data/com.cooliris.media/cache”目录中被缓存，应该仔细检查。

Google Maps

应用信息

这是内置的 Google Maps 应用，用于查看地图、搜索终点，甚至提供导航。

• 应用名称：Google Maps

• 包名：com.google.android.apps.maps

• 版本：4.4.0

• 设备：HTC Incredible

• 应用开发者：Google

目录、文件和文件类型

在/data/data/com.google.android.apps.maps中：

这个应用还在 SD 卡上存储数据：

重要的数据库表和文件

尽管每个数据库都应该被检查，但在 HTC Incredible 上，有两个数据库包含非常有用的信息。第一个是在表 7.13 中显示的 da_destination_history 数据库，以及表 7.14 中显示的 search_history 数据库。

表 7.13 /data/data/com.google.android.apps.maps/databases/da_destination_history 的重要数据库表和文件

表 7.14 /data/data/com.google.android.apps.maps/databases/search_history.db 的重要数据库表和文件

files 目录也包含大量信息。例如，DATA_LAYER_24 文件的第一部分包含以下字符串：

存储在 SD 卡上的数据用于谷歌地图导航的逐向指引，且逐向指引都带有时间戳：

分析师笔记

关于/data/data/com.google.android.apps.maps 的分析师笔记：

• 该应用在 files 目录中存储了大量关于地图、瓦片、搜索等信息，应仔细检查。

• 尽管每个数据库可能不包含信息，但应仔细检查 search_history.db 和 da_destination_history。

• 尽管 shared_prefs 目录包含一些信息，但大多数对法医检查来说并不有用。然而，可以恢复认证令牌，这在进行安全审查时可能是有趣的。

• 导航功能在 SD 卡上缓存地图数据，以及实际指引的.wav 文件。如果你查看文件的时间戳，它们以“._speech_nav”为前缀，你可以确定指引是在何时提供的，并且可以听到实际的语音指引。

Gmail

应用信息

谷歌为他们的 Gmail 服务提供了一个本地客户端：

• 应用名称：Gmail（Google Mail）

• 包名称：com.google.android.gm

• 版本：2.2

• 设备：HTC Incredible

• 应用开发者：Google

目录、文件和文件类型

在/mnt/sdcard/Android/data/com.google.android.apps.maps/：

重要的数据库表和文件

Gmail 应用在 SQLite 数据库中存储了大量信息，关键表的一个示例显示在表 7.15 中。

表 7.15 /data/data/com.google.android.gm/databases/mailstore.book@viaforensics.com.db 的重要数据库表和文件

分析师笔记

关于/data/data/com.google.android.gm 的分析师笔记：

• 每个配置的 Gmail 账户将有自己的 SQLite 数据库，其中将包含全部电子邮件内容。

• 其他数据库如 downloads.db、suggestions.db 和 gmail.db 包含附加信息。

• 一些 SQLite 日志文件可能可恢复。

• 缓存/下载目录存储下载内容。

• 同步的 Gmail 账户也在 shared_prefs 中的 Gmail.xml 中引用。

Facebook

应用信息

这是官方的 Facebook 应用。

• 应用名称：Facebook

• 包名称：com.facebook.katana

• 版本：1.2

• 设备：HTC Incredible

• 应用开发者：Facebook

目录、文件和文件类型

在/data/data/com.facebook.katana 中：

重要的数据库表和文件

如表 7.16 所示，有一个主数据库。

表 7.16 来自/data/data/com.facebook.katana/databases/fb.db 的重要数据库表和文件

分析师笔记

对于/data/data/com.facebook.katana 的分析师笔记：

• fb.db 几乎包含了所有信息，上面只分析了三个表。完整的表单列表包括以下内容：

• albums

• info_contacts

• notifications

• android_metadata

• key_value

• perf_sessions

• chatconversations

• mailbox_messages

• photos

• chatmessages

• mailbox_messages_display

• search_results

• default_user_images

• mailbox_profiles

• stream_photos

• events

• mailbox_threads

• user_statuses

• friends

• mailbox_users

• user_values

• 文件目录包含了来自 Facebook 应用的大量图片。

Adobe Reader

应用信息

这是官方的 Adobe PDF 文件阅读器

• 应用名称：Adobe Reader

• 包名称：com.adobe.reader

• 版本：9.0.1

• 设备：HTC Incredible

• 应用开发者：Adobe

目录、文件和文件类型

在/data/data/com.adobe.reader 中：

重要的数据库表和文件

com.adobe.reader.preferences.xml 偏好文件：

分析师笔记

对于/data/data/com.adobe.reader 的分析师笔记：

• 缓存的 PDF 文件存储在缓存目录中。

• 最近文件列表存储在 cache/com.adobe.reader.preferences.xml 中。

摘要

尽管获取 Android 设备是研究、开发和讨论的重点，但这实际上只是 Android 取证挑战的一半。需要使用逻辑和物理技术进行分析。然而，物理获取后所需的分析量要大得多。本章的目标是提供技术，使法医分析师或安全工程师能够检查并从获取的数据中提取信息，即使文件系统不受取证工具支持。通过利用现有的取证工具、Linux 命令，有时还有十六进制分析，可以获取调查所需的大部分数据。

参考文献

1. 文件时间（Windows）。（未确定日期）。2011 年 2 月 13 日检索自msdn.microsoft.com/en-us/library/ms724290%28VS.85%29.aspx。

2. Carrier, B. （未确定日期）。Mactime 输出—SleuthKitWiki。2011 年 2 月 13 日检索自wiki.sleuthkit.org/index.php?title=Mactime_output。

3. Casey, E. （未确定日期）。文件系统时间戳的误解。2011 年 2 月 13 日检索自blog.cmdlabs.com/2009/05/08/misinterpretation-of-file-system-timestamps/。

4. 《使用墓碑在 Android 中进行调试》. (未标明日期). 从 crazydaks.com/debugging-in-android-with-tombstones.html 检索于 2011 年 3 月 14 日。

5. 《数字装配：Adroit 照片取证—SmartCarving™》. (未标明日期). 从 digital-assembly.com/products/adroit-photo-forensics/features/smartcarving.html 检索于 2011 年 2 月 13 日。

6. 《数字侦探—DCode》. (未标明日期). 从 www.digital-detective.co.uk/freetools/decode.asp 检索于 2011 年 2 月 14 日。

7. 《Epoch 转换器—Epoch 与 Unix 时间戳转换工具》. (未标明日期). 从 www.epochconverter.com/ 检索于 2011 年 2 月 14 日。

8. Grundy, B. (未标明日期). Linux LEO. 从 www.linuxleo.com 检索于 2011 年 2 月 19 日。

9. Kessler, G. (未标明日期). 文件签名表. 从 www.garykessler.net/library/file_sigs.html 检索于 2011 年 2 月 13 日。

10. Ross, A. (未标明日期). digfor: 时间和时间戳. 从 digfor.blogspot.com/2008/10/time-and-timestamps.html 检索于 2011 年 2 月 13 日。

11. 《愤怒的小鸟—Rovio》. (未标明日期). 从 www.rovio.com/index.php?page=angry-birds 检索于 2011 年 2 月 15 日。

12. 《Scalpel：一个节俭、高性能的文件雕刻器》. (未标明日期). 从 www.digitalforensicssolutions.com/Scalpel/ 检索于 2011 年 2 月 13 日。

13. 《我的 IP 地址是什么》. (未标明日期). 从 www.whatismyip.com/ 检索于 2011 年 2 月 19 日。

14. 《YAFFS 调试》. (未标明日期). 从 www.yaffs.net/yaffs-debugging 检索于 2011 年 2 月 17 日。