安卓取证学习手册-全-

安卓取证学习手册（全）

原文：zh.annas-archive.org/md5/2056B6A0FCF4F0573C8075022809CB01

译者：飞龙

协议：CC BY-NC-SA 4.0

前言

《学习 Android 取证》使用免费开源工具向您展示如何从 Android 设备中取证恢复数据。鼓励从初学者到专家的所有人都按照逐步说明进行学习，以了解如何获取和检查证据，并深入了解 Android 取证过程。商业取证工具通常会给取证人员一个按钮要按（通常称为“查找证据”按钮）。本书揭示了这些工具实际上在做什么，让您更深入地了解它们的工作原理。商业取证工具还经常无法从第三方应用程序中恢复数据；有太多的应用程序可用，无法编写一个覆盖所有应用程序的工具。本书向您展示如何手动分析十多个流行应用程序。它教授了理解数据的技术和程序，这些可以应用于几乎任何其他应用程序的分析。

本书涵盖的内容

第一章，“介绍 Android 取证”，介绍了移动取证，一般方法和面临的挑战。本章还概述了 Android 架构，安全功能，引导过程等。

第二章，“建立 Android 取证环境”，涵盖了建立取证设置以检查 Android 设备的步骤。本章还解释了在 Android 设备上使用 ADB 命令。

第三章，“了解 Android 设备上的数据存储”，详细解释了设备中存储的数据类型，存储位置，存储方式以及存储在其中的文件系统的详细信息。

第四章，“从 Android 设备逻辑提取数据”，涵盖了使用免费和开源工具的各种逻辑数据提取技术。涵盖的逻辑方法包括 ADB pull，ADB 备份，ADB dumpsys 信息和 SIM 卡提取。还涵盖了绕过设备锁屏的方法。

第五章，“从 Android 设备中物理提取数据”，演示了各种物理数据提取技术。物理方法包括 dd 和 nanddump，以及使用 netcat 将数据写入取证人员的计算机。还涵盖了 RAM 和 SD 卡镜像。

第六章，“从 Android 设备中恢复已删除数据”，概述了从 Android 设备中恢复已删除数据的过程。本章解释了从 SD 卡和手机内部存储中恢复已删除数据的程序。

第七章，“Android 应用程序取证分析”，涵盖了 Android 应用程序的取证分析，流行应用程序使用的数据混淆方法，Android 应用程序的逆向工程以及所需的方法。

第八章，“Android 取证工具概述”，介绍了在取证分析 Android 设备过程中有用的各种开源和商业工具。

本书所需内容

本书涵盖了 Android 设备上的各种取证方法和技术。内容组织得让任何用户都能够检查 Android 设备并进行取证调查。不需要先修知识，因为所有主题都有详细解释，从基础到深入。对移动平台，尤其是 Android 的了解肯定会是一个优势。在可能的情况下，详细解释了使用工具执行各种取证活动所需的步骤。

本书的受众

本书适用于在 Android 平台上进行移动取证的初学者或基础经验的取证员。对于计算机安全专业人士、研究人员以及希望更深入了解 Android 移动内部的任何人来说，本书也将非常有用。最后，对于那些试图从 Android 设备中恢复意外删除的数据（照片、联系人、短信等）的人来说，本书也会派上用场。

约定

在本书中，您将找到一些区分不同信息类型的文本样式。以下是一些样式的示例及其含义的解释。

文本中的代码词、数据库表名、文件夹名、文件名、文件扩展名、路径名、虚拟 URL、用户输入和 Twitter 句柄显示如下："在 Android 4.4 之前，/system 下的所有应用程序都被平等对待。"

代码块设置如下：

<manifest  package="com.example.rohit">

  <uses-permission android:name="android.permission.INTERNET" />

</manifest>

任何命令行输入或输出都以以下方式编写：

shell@android:/ $ cat default.prop
cat default.prop
#
# ADDITIONAL_DEFAULT_PROPERTIES
#
ro.secure=1
ro.allow.mock.location=0
ro.debuggable=0
persist.sys.usb.config=mtp

新术语 和 重要单词 以粗体显示。您在屏幕上看到的单词，例如菜单或对话框中的单词，会以这种方式出现在文本中："在 Android 设备中，通过导航到 设置 | 开发者选项 通常可以找到此选项。"

注

警告或重要说明会出现在这样的框中。

提示

提示和技巧会以这种方式出现。

第一章：介绍 Android 取证

移动取证是数字取证的一个分支，在当今数字时代正在发展。Android 取证涉及通过各种技术从 Android 设备中提取、恢复和分析数据。然而，在我们深入了解如何提取数据之前，有必要对平台和其他基本知识有清晰的理解。在本章中，我们将涵盖以下主题：

• 移动取证

• 移动取证方法

• Android 架构

• Android 安全

• Android 硬件组件

• Android 启动过程

今天的世界正经历着前所未有的技术创新。在移动设备领域，这种增长几乎是指数级的。技术研究和咨询公司 Gartner 在 2014 年 6 月发布的预测中预测，手机出货量很快将突破 24 亿部。这一统计数据反映了移动设备的空前增长。手机不仅数量增加，而且在功能上也变得更加复杂。

以下截图引用自en.wikipedia.org/wiki/File:Mobile_phone_subscribers_1997-2014_ITU.svg显示了 1997 年至 2014 年每 100 名居民的移动电话用户数量的增长图：

1997-2014 年每 100 名居民的移动电话用户

在移动电话中，智能手机已经成为常态。这些设备的计算能力和数据存储的改进使我们能够执行各种活动。我们越来越依赖这些移动设备来进行大部分活动。除了执行常规任务，如打电话，发送短信等，这些设备还支持其他活动，如发送电子邮件，上网，录制视频，创建和存储文件，使用全球定位系统（GPS）服务识别位置，管理业务任务等等。换句话说，移动设备现在是敏感个人信息的存储库，包含大量用户数据。很多时候，设备上的数据比设备本身更有价值。例如，从设备上拨打的电话可能对执法机构来说是有价值的信息。移动取证在解决高调案件中发挥了关键作用，例如 2010 年时代广场汽车爆炸未遂和波士顿马拉松爆炸案，这再次证实了移动取证在许多政府和执法案件中的日益重要的作用。

移动取证

移动设备取证是数字取证的一个分支，涉及在取证上的可靠条件下从移动设备中提取、恢复和分析数字证据或数据。简而言之，它涉及访问存储在设备上的数据，包括短信、联系人、通话记录、照片、视频、文件、应用程序文件、浏览历史等，并使用各种取证技术恢复从设备中删除的数据。如果要在法庭上承认证据并保持证据的完整性，从设备中恢复或访问详细信息必须是取证上的可靠。如果证据必须在法庭上承认，原始设备不被篡改是很重要的。

注

“取证上的可靠性”这个术语经常在数字取证社区中使用，以澄清特定取证技术或方法的正确使用。移动取证，尤其是 Android 取证，正在快速发展，因为它在市场研究公司 IDC 的市场份额达到了 84%。

正如 Eoghan Casey 在他的书《数字取证与调查》中所解释的那样，取证的可靠性不仅仅是保持原始证据不变。甚至使用硬件写保护器从硬盘获取数据的例行任务也可能会导致改变（例如，使硬盘的隐藏区域可访问）。取证的可靠性的关键之一是文档记录。记录设备从一开始的处理方式非常重要。因此，如果获取过程保留了原始数据并且其真实性和完整性可以得到验证，那么调查可以被认为是取证上可靠的。证据完整性检查确保证据在收集时没有被篡改。完整性检查是通过比较收集时证据的数字指纹与当前状态下证据的数字指纹来进行的。

由于几个原因，移动取证的需求正在增长。一些突出的原因包括：

• 使用手机存储个人信息

• 增加使用手机进行在线活动

• 手机在多起犯罪中的使用

特定设备上的移动取证主要取决于底层操作系统。因此，我们有不同的领域，如 Android 取证、iOS 取证、Blackberry 取证等。

移动取证的方法

一旦从设备中提取数据，根据底层案例使用不同的分析方法。由于每个调查都是独特的，不可能为所有案例制定一个单一的明确程序。然而，整个过程可以分为以下图表中显示的五个阶段：

移动取证的阶段

以下部分详细讨论了每个阶段：

调查准备

当收到检查请求时，这个阶段开始。它涉及准备所有需要记录保管链、所有权信息、设备型号、用途、请求者寻求的信息等的文件和表格。保管链是指按时间顺序记录或纸质追踪，显示物理或电子证据的扣押、保管、控制、转移、分析和处置。根据请求者提交的细节，对每次检查的目标有清晰的理解是很重要的。

扣押和隔离

在进行取证分析时，处理设备的方式是重要的一步。通常使用防静电袋来运输证据，这些袋子设计用来保护电子元件免受静电产生的损坏。一旦设备被扣押，就应该注意确保我们的行动不会导致设备上的任何数据修改。同时，也不应错过任何可以帮助调查的机会。

在处理 Android 设备时需要考虑的一些要点如下：

• 随着用户对安全和隐私意识的增强，大多数设备现在都启用了屏幕锁定。在扣押时，如果有机会这样做，禁用密码。有些设备在禁用锁屏选项时不要求用户重新输入密码。

• 如果设备已解锁，尝试更改设备的设置以允许更大的访问权限。可以考虑以下设置来实现这一点：

• 启用 USB 调试：启用此选项通过Android 调试桥（adb）连接为设备提供更大的访问权限。我们将在第二章设置 Android 取证环境中详细介绍 adb 连接。这将极大地帮助取证调查员在数据提取过程中。在 Android 设备中，此选项通常位于设置 | 开发者选项下，如下面的截图所示。从 4.2 开始的较新的 Android 版本中，开发者选项默认是隐藏的。要启用它们，转到设置 | 关于手机，然后点击版本号7 次。

• 启用保持唤醒设置：启用此选项并充电将使设备保持唤醒，这意味着它不会被锁定。在 Android 设备中，此选项通常位于设置 | 开发者选项下，如下面的截图所示：

保持唤醒和 USB 调试选项

• 增加屏幕超时：这是设备解锁后保持活动的时间。根据设备型号，这个时间可以设置为最长 30 分钟。在大多数设备中，它可以在设置 | 显示 | 屏幕超时下找到，如下面的截图所示：

注意

请注意，访问此项目的位置在不同版本和型号的 Android 手机上会有所变化。

Android 设备上的屏幕超时选项

在移动取证中，保护扣押的设备非常重要，以便我们与证据的互动（或攻击者试图远程与设备互动）不会改变证据。在计算机取证中，我们有软件和硬件写入阻断器可以执行此功能。但是在移动取证中，由于我们需要与设备互动以提取数据，这些写入阻断器就没有任何用处。另一个重要方面是我们还需要防止设备与无线电网络互动。如前所述，攻击者很有可能发出远程擦除命令，删除设备上的所有数据，包括电子邮件、应用程序、照片、联系人和其他文件。

Android 设备管理器（ADM）和其他几个第三方应用程序允许远程擦除或锁定手机。这可以通过登录配置在移动设备上的 Google 帐户来完成。使用这个软件，攻击者也可以定位设备，这可能构成安全风险。出于所有这些原因，将设备与所有通信来源隔离开非常重要。

提示

您是否考虑过不需要互联网访问的远程擦除选项？移动设备管理（MDM）软件通过发送短信提供了远程擦除功能。将设备与所有通信选项隔离开非常重要。

将设备与网络隔离，如果可以访问设备，我们可以将设备置于飞行模式。飞行模式会禁用设备的无线传输功能，如蜂窝无线电、Wi-Fi 和蓝牙。然而，这并不总是可能，因为大多数设备都被锁定屏幕。另外，由于现在飞机上有 Wi-Fi，一些设备现在允许在飞行模式下使用 Wi-Fi。因此，另一个解决方案是使用法拉第袋或射频隔离盒，因为两者都可以有效地阻断手机的信号。但是，这些隔离方法的一个问题是一旦它们被使用，就很难使用手机，因为你无法透过它们来使用触摸屏或键盘。因此，法拉第帐篷和房间存在，如下面的截图所示（摘自www.technicalprotection.co.uk/），但价格昂贵。

金字塔形法拉第帐篷

即使采取了所有这些预防措施，某些自动功能，如闹钟可能会触发。如果遇到这种情况，必须妥善记录。

获取

获取阶段指的是从设备中提取数据。由于移动设备固有的安全功能，提取数据并不总是直截了当的。根据设备的操作系统、制造商和型号，决定提取方法。以下类型的获取方法可用于从设备中提取数据：

• 手动获取：这是所有获取方法中最简单的。检查员使用手机的用户界面进行浏览和调查。这里不需要特殊工具或技术，但限制在于只能提取通过正常用户界面可见的文件和数据。通过其他方法提取的数据也可以使用这种方法进行验证。

• 逻辑获取：这也被称为逻辑提取。这通常指的是从逻辑存储器（如文件系统分区）中提取文件。这包括从手机中获取文本消息、通话记录、图片等数据类型。逻辑提取技术是通过使用原始设备制造商的 API 来将手机内容与计算机同步。这种技术通常涉及提取以下证据：

• 通话记录

• 短信

• MMS

• 浏览器历史记录

• 人员

• 联系人方式

• 联系人扩展

• 联系人分组

• 联系人电话

• 联系人设置

• 外部图像媒体（元数据）

• 外部图像缩略图媒体（元数据）

• 外部媒体、音频和其他（元数据）

• 外部视频（元数据）

• MMSParts（包括通过 MMS 发送的完整图像）

• 位置详细信息（GPS 数据）

• 互联网活动

• 组织

• 安装的所有应用程序列表，以及它们的版本

• 社交网络应用程序的数据，如 WhatsApp、Skype、Facebook 等。

• 文件系统获取：这是一个逻辑过程，通常指的是从移动设备中提取完整的文件系统。文件系统获取有时可以帮助恢复从设备中删除的内容（存储在 SQLite 文件中）。

• 物理获取：这涉及制作整个闪存的逐位拷贝。使用这种方法提取的数据通常是原始数据（十六进制转储），然后可以进一步解析以获取文件系统信息或人类可读数据。由于所有调查都是在这个镜像上进行的，这个过程还确保原始证据没有被改变。

检查和分析

在这个阶段，使用不同的软件工具从内存镜像中提取数据。除了这些工具，调查员还需要使用十六进制编辑器的帮助，因为工具并不总是能提取所有数据。没有单一的工具可以在所有情况下使用。因此，检查和分析需要对各种文件系统、文件头等有扎实的知识。

报告

在整个过程中应该记录检查的文档，记录每个阶段所做的工作。检查员可能记录以下几点：

• 检查开始的日期和时间

• 手机的物理状态

• 收到手机时的状态（开/关）

• 手机的制造商、型号和操作系统

• 手机和各个组件的图片

• 调查中使用的工具

• 检查期间记录的数据

从移动设备提取的数据应清晰地呈现给接收方，以便可以将其导入其他软件进行进一步分析。在民事或刑事案件中，尽可能收集数据的图片，因为它们对陪审团有视觉上的吸引力。

移动取证中的挑战

随着 Android 设备的使用增加以及它们支持的通信平台的广泛，对取证检查的需求自然增长。在处理移动设备时，取证分析师面临着许多挑战。以下几点阐明了当今移动取证所面临的一些挑战：

• 防止设备上的数据被更改：取证中要记住的基本规则之一是不要修改证据。换句话说，应用于设备的取证技术不应更改设备上的数据。但是，对于移动取证来说，这是不切实际的，因为简单地打开设备可能也会更改设备上存在的某些状态变量。移动设备上始终运行着后台进程，突然从一种状态转换到另一种状态可能导致数据的丢失或修改。因此，取证分析师有可能故意或无意地更改数据。除此之外，攻击者有可能远程更改或删除设备上的内容。由于手机使用不同的通信渠道（蜂窝、Wi-Fi、蓝牙、红外线等），通过它们进行通信的可能性应该被消除。远程数据擦除等功能会使攻击者能够通过发送短信或简单地按下一个发送擦除请求的按钮来远程擦除整个设备。与计算机取证不同，移动设备取证需要更多的工作，不仅仅是将设备与网络隔离。

• 操作系统和设备型号的广泛范围：市场上提供的广泛移动操作系统使得取证分析师的工作变得更加困难。尽管 Android 是移动世界中最主要的操作系统，但在调查中经常会遇到运行其他操作系统的移动设备，包括 iOS、Blackberry、Windows 等。此外，对于给定的操作系统，有数百万种不同的移动设备，它们在操作系统版本、硬件和其他各种功能上都有所不同。例如，在 Android 操作系统中，大约有 10 个版本，而对于每个版本，不同制造商都进行了不同的定制。根据制造商，获取取证证据的方法也会改变。为了保持竞争力，制造商们发布新型号和更新如此迅速，以至于很难跟踪所有这些变化。有时在同一操作系统中，数据存储选项和文件结构也会发生变化，使情况变得更加困难。没有单一工具可以在所有可用类型的移动操作系统上运行。因此，取证分析师必须及时了解所有最新的变化和技术。

• 固有的安全功能：随着“隐私”概念日益重要，移动制造商正朝着在设备上实施强大的安全控制的方向发展，这使得获取数据的过程变得更加复杂。例如，如果设备受到密码保护，取证调查员必须首先找到一种绕过密码的方法。同样，一些最新设备上实施的全盘加密机制阻止执法机构和取证分析师访问设备上的信息。苹果的 iPhone 默认使用设备内置的硬件密钥对设备上的所有数据进行加密。取证人员很难使用暴力破解等技术来破解这些加密机制。

• 法律问题：移动设备可能涉及跨越全球并跨越地理边界的犯罪。为了解决这些跨司法管辖范围的问题，取证人员需要了解犯罪的性质以及地区法律。

Android 架构

在我们继续讨论 Android 取证的内部之前，本部分将向您介绍 Android 作为操作系统的基本概念，并涵盖需要理解的各种基本概念，以便在取证领域获得经验。

任何操作系统（桌面或移动）都负责管理系统资源，并提供一种让应用程序与硬件或物理组件进行通信以完成某些任务的方式。Android 操作系统也不例外。它为移动电话提供动力，管理内存和进程，执行安全性，处理网络问题等。Android 是开源的，大部分代码都是根据 Apache 2.0 许可发布的。实际上，这意味着手机设备制造商可以自由访问它，修改它，并根据任何设备的要求使用该软件。这是其受欢迎的主要原因之一。

Android 操作系统由一系列层次堆叠而成。通过查看这些层次是什么以及它们的作用，可以更好地理解 Android 架构。以下图表引用自elinux.org/images/c/c2/Android-system-architecture.jpg，显示了 Android 软件堆栈中涉及的各个层次：

Android 架构

Android 架构以软件堆栈的形式存在，包括内核、库、运行环境、应用程序、中间件和服务。堆栈的每一层（以及每一层内的元素）都以一种集成的方式存在，为移动设备提供了最佳的执行环境。接下来的部分将重点介绍 Android 堆栈的不同层次，从底层的 Linux 内核开始。

Linux 内核

Android 操作系统是建立在 Linux 内核之上的，谷歌对其进行了一些架构上的改变。选择 Linux 是因为它是一个可移植的平台，可以在不同的硬件上轻松编译。Linux 内核位于软件堆栈的底部，并在设备硬件和上层之间提供了一定程度的抽象。它还充当了设备上软件和硬件之间的抽象层。为了更好地理解这一点，可以考虑一下使用相机按钮拍照的情况。当您在移动设备上按下相机按钮拍照时，实际上会发生什么？在某个时刻，硬件指令，比如按下按钮，必须转换为软件指令，比如拍照并将其存储在相册中。内核包含可以促进这一过程的驱动程序。当检测到相机按钮点击时，指令会传递到内核中相应的驱动程序，该驱动程序向相机硬件发送必要的命令，类似于在键盘上按键时发生的情况。简而言之，内核中的驱动程序控制着底层硬件。如前图所示，内核包含与 Wi-Fi、蓝牙、USB、音频、显示等相关的驱动程序。

Android 的所有核心功能，如进程管理、内存管理、安全性和网络，都由 Linux 内核管理。在安全性和进程管理方面，Linux 是一个经过验证的平台。Android 利用现有的 Linux 开源操作系统构建了其生态系统的坚实基础。每个 Android 版本都有一个不同版本的底层 Linux 内核。截至 2014 年 9 月，当前的 Android 版本 4.2 是建立在 Linux 内核 3.4 或更新版本之上的，但具体的内核版本取决于实际的 Android 设备和芯片组。

库

在 Linux 内核之上是 Android 的本地库。借助这些库，设备可以处理不同类型的数据。例如，媒体框架库支持音频、视频和图片格式的录制和播放。这些库是用 C 或 C++编程语言编写的，并且特定于特定的硬件。Surface Manager、媒体框架、SQLite、WebKit、OpenGL 等都是一些最重要的本地库。

达尔维克虚拟机

Android 应用程序是使用 Java 编程语言编写的。选择 Java 的主要原因是因为它是一种众所周知的语言，拥有庞大的开发者基础。Android 希望利用这个现有的开发者社区，而不是提出一种新的语言。

注意

这后来促使 Oracle 对 Google 提起诉讼，声称其侵犯了其版权和专利。但陪审团最终宣布 Google 没有侵犯 Oracle 的专利，审判法官裁定 Google 使用的 Java API 结构不受版权保护。

当 Java 程序编译时，我们得到字节码。Java 虚拟机（虚拟机是一个充当操作系统的应用程序）可以执行这个字节码。在 Android 的情况下，这个 Java 字节码进一步被 dex 编译器转换为达尔维克字节码。这个达尔维克字节码然后被输入到达尔维克虚拟机（DVM）中，它可以读取和使用这个代码。因此，Java 编译器的.class文件使用 dx 工具转换为.dex文件。达尔维克字节码是一种适用于低内存和低处理环境的优化字节码。另外，需要注意的是，JVM 的字节码由一个或多个.class文件组成，取决于应用程序中存在的 Java 文件的数量，但达尔维克字节码只由一个.dex文件组成。每个 Android 应用程序都运行自己的 DVM 实例。以下图表显示了 Java 应用程序和 Android 应用程序的程序编译之间的差异。

JVM 与 DVM

自 Android 5.0 以来，Dalvik 已被Android 运行时（ART）取代为平台默认。ART 在 Android 4.4 上作为实验性功能引入。Dalvik 使用即时（JIT）编译，每次启动应用程序时都会编译字节码。然而，ART 使用预编译（AOT）编译，在安装应用程序时执行。这大大减少了移动设备的处理器使用率，因为在应用程序运行期间的整体编译减少了。

应用程序框架

Android 应用程序是通过 Android 应用程序框架运行和管理的。它负责执行许多关键功能，如资源管理、处理呼叫等。Android 框架包括以下关键服务，引用自fp.edu.gva.es/av/pluginfile.php/745396/mod_imscp/content/2/1_overview_of_the_android_architecture.html：

• 活动管理器：此服务控制应用程序生命周期和活动堆栈的所有方面。

• 内容提供者：此服务允许应用程序与其他应用程序发布和共享数据。

• 资源管理器：此服务提供对非代码嵌入资源的访问，如字符串、颜色设置和用户界面布局。

• 通知管理器：此服务允许应用程序向用户显示警报和通知。

• 视图系统：此服务提供一组可扩展的视图，用于创建应用程序用户界面。

• 包管理器：应用程序可以通过该系统找到有关设备上当前安装的其他应用程序的信息。

• 电话管理器：此服务向应用程序提供有关设备上可用的电话服务的信息，如状态和订阅者信息。

• 位置管理器：此服务提供对位置服务的访问，允许应用程序接收有关位置更改的更新。

应用程序层

Android 堆栈中的最顶层是应用程序（称为应用），这些是用户直接交互的程序。以下讨论了两种类型的应用程序：

• 系统应用程序：这些是预装在手机上并随手机一起发货的应用程序。默认浏览器、电子邮件客户端、联系人等应用程序都是系统应用程序的示例。这些应用程序无法被用户卸载或更改，因为它们在生产设备上是只读的。这些通常存在于/system目录中。直到 Android 4.4，所有存在于/system下的应用程序都被平等对待。但从 Android 4.4 开始，安装在/system/priv-app/中的应用程序被视为特权应用程序，并且只有特权应用程序被授予具有签名或系统保护级别的权限。

• 用户安装的应用程序：这些是用户从各种分发平台（如 Google Play）下载并安装的应用程序。Google Play 是 Android 操作系统的官方应用商店，用户可以浏览和下载应用程序。根据 2014 年 12 月 AppBrain 的统计数据，Play 商店中大约有 1,418,453 个 Android 应用程序。这些应用程序目前位于/data目录中。有关它们之间如何执行安全性的更多信息将在以下部分中讨论。

Android 安全性

作为一个平台，Android 的架构中内置了某些功能，以确保用户、应用程序和数据的安全性。尽管它们有助于保护数据，但这些安全功能有时会阻止调查人员访问必要的数据。因此，从法医学的角度来看，首先要了解固有的安全功能，以便清楚地了解在正常情况下可以或不可以访问的内容。所包含的安全功能和服务旨在实现三个目标：

• 保护用户数据

• 保护系统资源

• 确保一个应用程序不能访问另一个应用程序的数据

接下来的部分将概述 Android 操作系统中的关键安全功能。

通过 Linux 内核在操作系统级别上的安全性

Android 操作系统是建立在 Linux 内核之上的。在过去的几年里，Linux 已经发展成为一个受到许多全球公司信任的安全操作系统。今天，大多数关键任务的系统和服务器都在 Linux 上运行，因为它的安全性。通过将 Linux 内核置于其平台的核心位置，Android 试图确保在操作系统级别上的安全性。此外，Android 还在 Linux 中构建了许多特定的代码，以包括与移动环境相关的某些功能。随着每个 Android 版本的发布，内核版本也发生了变化。以下表格显示了 Android 版本和相应的 Linux 内核版本：

Android 版本	Linux 内核版本
1.0	2.6.25
1.5	2.6.27
1.6	2.6.29
2.2	2.6.32
2.3	2.6.35
3.0	2.6.36
4.0	3.0.1
4.1	3.0.31
4.2	3.4.0
4.3	3.4.39
4.4	3.8

各种 Android 版本中使用的 Linux 内核

Linux 内核为 Android 提供了以下关键安全功能：

• 基于用户的权限模型

• 进程隔离

• 可扩展的安全 IPC 机制

权限模型

Android 为各个应用程序实现了权限模型。应用程序必须声明它们需要哪些权限（在清单文件中）。当应用程序安装时，Android 会向用户呈现列表，以便他们可以查看列表以允许或不允许安装：

Android 中的示例权限模型

与桌面环境不同，这提供了一个机会，让用户提前知道应用程序正在寻求访问哪些资源。换句话说，用户必须获得许可才能访问设备上的任何关键资源。通过查看请求的权限，用户更加了解安装应用程序所涉及的风险。但大多数用户并不阅读这些内容，只是授予了很多权限，使设备暴露于恶意活动之中。

注意

不可能安装具有少量或减少权限的 Android 应用程序。您只能安装具有所有权限或拒绝的应用程序。

如前所述，开发人员必须在名为AndroidManifest.xml的文件中声明权限。例如，如果应用程序需要访问互联网，则可以使用以下代码在AndroidManifest.xml文件中指定INTERNET权限：

<manifest  package="com.example.rohit">

  <uses-permission android:name="android.permission.INTERNET" />

</manifest>

Android 权限分为四个级别，如下所示：

权限类型	描述
普通	这是默认值。这些是低风险权限，不会对其他应用程序、系统或用户造成风险。在安装过程中，此权限会自动授予应用程序，无需用户批准。
危险	这些是可能对系统和其他应用程序造成伤害的权限。因此，在安装过程中需要用户批准。
签名	如果请求的应用程序与声明/创建权限的应用程序使用相同的证书，则会自动授予这些权限。此级别旨在允许套件中的应用程序或其他相关应用程序共享数据。
签名/系统	系统仅授予 Android 系统镜像中的应用程序，或者与声明权限的应用程序使用相同证书的应用程序。

应用程序隔离

为了将应用程序相互隔离，Android 利用了 Linux 基于用户的保护模型。在 Linux 系统中，每个用户被分配一个唯一的用户 ID（UID），并且用户被隔离开来，以便一个用户不会访问另一个用户的数据。特定用户下的所有资源都以相同的权限运行。同样，每个 Android 应用程序都被分配一个 UID，并作为一个单独的进程运行。这意味着，即使安装的应用程序尝试执行一些恶意操作，它也只能在其上下文中以及具有的权限内执行。

这种应用程序隔离是在内核级别完成的。应用程序和系统之间在进程级别的安全性是通过标准的 Linux 设施来确保的，例如分配给应用程序的用户和组 ID。这在下面的截图中显示，引用自www.ibm.com/developerworks/library/x-androidsecurity/。

具有不同 UID 的不同进程上的两个应用程序

默认情况下，应用程序无法读取或访问其他应用程序的数据，并且对操作系统的访问权限有限。例如，如果应用程序 A 尝试读取应用程序 B 的数据，操作系统会阻止这种操作，因为应用程序 A 没有适当的权限。由于应用程序沙箱机制是在内核级别实现的，因此适用于本机应用程序和操作系统应用程序。因此，操作系统库、应用程序框架、应用程序运行时以及所有应用程序都在应用程序沙箱中运行。绕过这个沙箱机制将需要破坏 Linux 内核的安全性。

Android 中的 SELinux

从 Android 4.3 开始，Android 安全模型支持安全增强型 Linux（SELinux）。Android 安全基于自由访问控制，这意味着应用程序可以请求权限，用户可以授予或拒绝这些权限。因此，恶意软件可以通过获取权限在手机上制造混乱。但 SE Android 使用强制访问控制（MAC），确保应用程序在隔离的环境中运行。因此，即使用户安装了恶意应用程序，恶意软件也无法访问操作系统并损坏设备。SELinux 用于强制执行 MAC，包括以 root 权限运行的进程。

SELinux 遵循默认拒绝的原则。任何未明确允许的操作都将被拒绝。SELinux 可以在两种全局模式下运行：宽容模式，其中权限拒绝被记录但不被执行，和强制模式，其中拒绝既被记录又被执行。根据谷歌的文档，在 Android 5.0 棒棒糖版本中，Android 将全面执行 SELinux。这是在 4.3 版本的宽容发布和 4.4 版本的部分执行的基础上构建的。简而言之，Android 正在从对一组关键域（installd、netd、vold和zygote）的执行转变为对所有内容（超过 60 个域）的执行。

应用程序签名

所有 Android 应用程序在安装到设备上之前都需要使用证书进行数字签名。使用证书的主要目的是识别应用程序的作者。这些证书不需要由证书颁发机构签名，Android 应用程序通常使用自签名证书。应用程序开发人员持有证书的私钥。使用相同的私钥，开发人员可以为其应用程序提供更新并在应用程序之间共享数据。在调试模式下，开发人员可以使用 Android SDK 工具生成的调试证书对应用程序进行签名。您可以在调试模式下运行和调试应用程序，但应用程序无法分发。要分发应用程序，应用程序需要使用您自己的证书进行签名。在此过程中使用的密钥库和私钥需要由开发人员保护，因为它们对推送更新至关重要。以下截图显示了在导出应用程序时显示的密钥库选择选项：

导出 Android 应用程序时的密钥库选择

安全的进程间通信

如上所述，应用程序的沙盒化是通过在不同的进程中以不同的 Linux 身份运行应用程序来实现的。系统服务在单独的进程中运行，并具有更多的权限。因此，为了在这些进程之间组织数据和信号，需要一个进程间通信（IPC）框架。在 Android 中，这是通过使用Binder机制实现的。

Android 中的 Binder 框架提供了组织各种进程间通信所需的能力。Android 应用程序组件，如意图和内容提供程序，也是建立在这个 Binder 框架之上的。使用这个框架，可以执行各种操作，比如调用远程对象的方法，就像它们是本地的一样，同步和异步方法调用，在进程之间发送文件描述符等等。假设进程'A'中的应用程序想要使用进程'B'中运行的服务暴露的某些行为。在这种情况下，进程'A'是客户端，进程'B'是服务。使用 Binder 的通信模型如下图所示：

Binder 通信模型

使用 Binder 框架进行的进程间通信都是通过/dev/binder Linux 内核驱动程序进行的。对这个设备驱动程序的权限被设置为全局可读可写。因此，任何应用程序都可以向这个设备驱动程序写入和读取。客户端和服务器之间的所有通信都是通过客户端的代理和服务器端的存根进行的。代理和存根负责发送和接收通过 Binder 驱动程序发送的数据和命令。

使用 Binder 机制公开的每个服务（也称为 Binder 服务）都被分配一个令牌。这个令牌是一个 32 位的值，在系统中的所有进程中是唯一的。客户端可以在发现这个值后开始与服务进行交互。这是通过 Binder 的上下文管理器来实现的。基本上，上下文管理器充当名称服务，使用该服务的名称提供服务的句柄。为了使这个过程工作，每个服务必须向上下文管理器注册。因此，客户端只需要知道一个服务的名称来进行通信。名称由上下文管理器解析，客户端接收后用于与服务进行通信。Binder 驱动程序向每个事务添加了发送方进程的 UID 和 PID 值。正如前面讨论的，系统中的每个应用程序都有自己的 UID，这个值用于识别调用方。调用方可以检查获得的值，并决定是否应完成事务。因此，Binder 令牌作为安全令牌起作用，因为它在所有进程中是唯一的，从而强制执行安全性。

Android 硬件组件

Android 兼容各种硬件组件。由于 Linux 内核的存在，这变得很容易，因为 Linux 支持各种硬件。这使制造商有很大的灵活性，他们可以根据自己的需求设计，而不必担心兼容性。这给取证分析人员在调查过程中带来了重大挑战。因此，了解硬件组件和设备类型将极大地帮助理解 Android 取证。

核心组件

设备中的组件从一个制造商到另一个制造商，以及从一个型号到另一个型号都会有所变化。然而，大多数移动设备中都会找到一些组件。以下部分概述了 Android 设备中常见的组件。

中央处理单元

中央处理单元（CPU），也称为处理器，负责执行移动设备上发生的一切。它告诉设备要做什么以及如何做。其性能是根据它每秒可以完成的任务数来衡量的，称为周期。例如，1 GHz 处理器可以每秒处理十亿个周期。处理器的容量越大，手机的性能就越流畅。

在处理智能手机时，我们会遇到以下术语——ARM、x86（英特尔）、MIPS、Cortex、A5、A7 或 A9。ARM 是一家授权其架构（品牌 Cortex）的公司，每年推出不同型号，如上述的 A 系列（A5、A7 和 A9）。基于这些架构，芯片制造商发布自己系列的芯片组（骁龙、Exynos 等），用于移动设备。最新的智能手机由双核、四核甚至八核处理器驱动。

基带处理器

今天的智能手机支持各种蜂窝协议，包括 GSM、3G、4G 和 4G LTE。这些协议很复杂，需要大量的 CPU 功率来处理数据，生成数据包并将其传输到网络提供商。为了处理这个过程，智能手机现在使用一个基带调制解调器，这是一个单独的芯片，包含在智能手机中，与主处理器通信。这些基带调制解调器有自己的处理器，称为基带处理器，并运行自己的操作系统。基带处理器管理几个无线电控制功能，如信号生成、调制、编码，以及频率转移。它也可以管理信号的传输。

基带处理器通常位于与 CPU 相同的电路板上，但由单独的无线电电子组件组成。

内存

Android 手机，就像普通计算机一样，使用两种主要类型的内存——随机存取存储器（RAM）和只读存储器（ROM）。尽管大多数用户对这些概念很熟悉，但在移动设备上存在一些混淆。

RAM 是易失性的，这意味着其内容在断电时被擦除。RAM 非常快速访问，主要用于软件应用程序的运行时内存（包括设备的操作系统和任何应用程序）。换句话说，它被系统用来加载和执行操作系统和其他应用程序。因此，可以同时运行的应用程序和进程的数量取决于 RAM 的大小。

ROM（通常称为 Android ROM）是非易失性的，这意味着即使断电也会保留其内容。Android ROM 包含引导加载程序、操作系统、所有下载的应用程序及其数据、设置等。

请注意，用于引导加载程序的内存部分通常是锁定的，只能通过固件升级进行更改。其余部分的内存被一些制造商称为用户内存。存储在这里的每个应用程序的数据对其他应用程序是不可访问的。一旦这个内存被填满，设备就会变慢。RAM 和 Android ROM 被制造成一个称为多芯片封装（MCP）的单一组件。

SD 卡

SD 卡对于移动取证具有重要意义，因为经常存储在其中的数据可能是重要的证据。许多 Android 设备都有一个可移动的存储卡，通常称为他们的安全数字（SD）卡。这与苹果的 iPhone 形成对比，后者没有任何 SD 卡的规定。SD 卡是非易失性的，这意味着即使断电也会存储数据。SD 卡使用闪存存储器，一种可擦可编程只读存储器（EEPROM）类型，它以大块而不是单个字节进行擦除和写入。大多数多媒体数据和大文件都存储在 SD 卡中。为了与其他设备互操作，SD 卡实现了一些通信协议和规范。

在一些移动设备中，虽然存在 SD 卡接口，但部分内置 NAND 存储器（非易失性）被划分出来用于创建模拟 SD 卡。这基本上意味着 SD 卡是不可移动的。因此，取证分析人员需要检查他们是否正在处理实际的 SD 卡还是模拟 SD 卡。SD 存储卡有几种不同的尺寸。Mini-SD 卡和 Micro-SD 卡与原始 SD 存储卡具有相同的基础技术，但尺寸更小。

显示屏

移动电话屏幕在过去几年里取得了巨大进步。以下是对一些广泛使用的移动屏幕类型的简要描述，如www.in.techradar.com/news/phone-and-communications/mobile-phones/Best-phone-screen-display-tech-explained/articleshow/38997644.cms所述。

薄膜晶体管液晶显示屏（TFT LCD）是移动电话中最常见的屏幕类型。这些屏幕下面有一盏灯，透过像素发光，使它们可见。

有机活性矩阵有机发光二极管（AMOLED）是一种基于有机化合物的技术，以其出色的图像质量和低功耗而闻名。与 LCD 屏幕不同，AMOLED 显示屏不需要背光；每个像素都会产生自己的光，因此使用这种显示屏的手机可能会更薄。

电池

电池是移动电话的生命线，也是现代智能手机的主要关注点之一。您使用设备及其组件越多，电池消耗就越多。移动电话使用以下不同类型的电池：

• 锂离子（Li-ion）：这些电池是手机中最常用的电池，因为它们轻便易携。它们以高能量密度和低维护而闻名。然而，与其他电池类型相比，它们的制造成本较高。

• 聚合物锂电池（Li-Polymer）：这些电池具有锂离子电池的所有特性，但具有超薄的几何形状和简化的包装。它们是最新的，只在少数移动设备中找到。

• 镍镉（NiCd）：这些电池是旧技术电池，容易出现记忆效应。因此，电池的总容量和寿命会减少。除此之外，镍镉电池由对环境不友好的有毒材料制成。

• 镍氢（NiMH）：这些电池与镍镉电池相同，但可以容纳更多能量，运行时间更长，约为 30%至 40%。它们仍然会出现记忆效应，但相对于镍镉电池来说较少。它们在手机中被广泛使用，而且价格也比较实惠。

可以通过查看电池本体上的详细信息来找到电池类型。例如，以下是锂离子电池的图像：

锂离子电池

大多数 SD 卡位于电池后面。在取证分析中，访问 SD 卡需要取出电池，这将关闭设备。这可能会产生某些影响，将在后面的章节中详细讨论。

除了上述描述的组件外，以下是一些其他众所周知的组件：

• 全球定位系统

• Wi-Fi

• 近场通信

• 蓝牙

• 相机

• 键盘

• USB

• 加速度计和陀螺仪

• 扬声器

• 麦克风

Android 启动过程

了解 Android 设备的启动过程将帮助我们理解涉及与设备在各个层面交互的其他取证技术。当 Android 设备首次上电时，会执行一系列步骤，帮助设备将必要的固件、操作系统、应用程序数据等加载到内存中。以下信息编译自原始文章，发表在www.androidenea.com/2009/06/android-boot-process-from-power-on.html。

Android 启动过程涉及的步骤顺序如下：

1. 启动 ROM 代码执行

2. 引导加载程序

3. Linux 内核

4. init 进程

5. Zygote 和 Dalvik

6. 系统服务器

我们将详细研究这些步骤中的每一个。

启动 ROM 代码执行

在设备上电之前，设备 CPU 将处于未初始化状态。一旦 Android 设备上电，执行就会从启动 ROM 代码开始。这个启动 ROM 代码是特定于设备使用的 CPU 的。如下图所示，这个阶段包括两个步骤：

1. 当启动 ROM 代码执行时，它会初始化设备硬件并尝试检测引导介质。因此，启动 ROM 代码会扫描直到找到引导介质。这类似于计算机引导过程中的 BIOS 功能。

2. 一旦引导序列建立，初始引导加载程序就会被复制到内部 RAM。之后，执行会转移到加载到 RAM 中的代码。

Android 启动过程：启动 ROM 代码执行

引导加载程序

引导加载程序是在操作系统开始运行之前执行的程序片段。引导加载程序存在于台式计算机、笔记本电脑和移动设备中。在 Android 引导加载程序中，有两个阶段——初始程序加载（IPL）和第二程序加载（SPL）。如下图所示，这涉及到三个步骤，如下所述：

1. IPL 处理检测和设置外部 RAM。

2. 一旦外部 RAM 可用，SPL 就会被复制到 RAM 中，并且执行会转移到它。SPL 负责加载 Android 操作系统。它还提供对其他引导模式（如 fastboot、recovery 等）的访问。它启动了几个硬件组件，如控制台、显示、键盘和文件系统、虚拟内存和其他功能。

3. 之后，SPL 会尝试寻找 Linux 内核。它会从引导介质加载并将其复制到 RAM 中。一旦引导加载程序完成了这个过程，它就会将执行转移到内核。

Android 启动过程：引导加载程序

Linux 内核

Linux 内核是 Android 操作系统的核心，负责进程管理、内存管理和设备安全。内核加载后，它会挂载根文件系统（rootfs），并提供对系统和用户数据的访问，如下所述：

1. 当内存管理单元和缓存已经初始化后，系统可以使用虚拟内存并启动用户空间进程。

2. 内核将在 rootfs 中寻找 init 进程，并将其作为初始用户空间进程启动。

Android 启动过程：内核

init 进程

init 是第一个启动的进程，也是所有其他进程的根进程。

1. init 进程将寻找一个名为init.rc的脚本，描述系统服务、文件系统和需要设置的其他参数。

• init进程可以在<android source>/system/core/init路径下找到。

• init.rc文件可以在源树中找到，路径为<android source>/system/core/rootdir/init.rc。

提示

有关 Android 文件层次结构的更多细节将在第三章中进行介绍，了解 Android 设备上的数据存储。

1. init进程将解析init.rc脚本并启动系统服务进程。在这个阶段，您将在设备屏幕上看到 Android 标志。

Android 启动过程：init 进程

Zygote 和 Dalvik

Zygote是设备启动后创建的第一个 init 进程之一。它初始化 Dalvik 虚拟机，并尝试创建多个实例以支持每个 Android 进程。正如前面的部分所讨论的，Dalvik 虚拟机是执行用 Java 编写的 Android 应用程序的虚拟机。

Zygote 有助于在虚拟机之间使用共享代码，从而有助于节省内存并减轻系统负担。之后，应用程序可以通过请求新的 Dalvik 虚拟机来运行。Zygote 为 zygote 连接注册了一个服务器套接字，并预加载了某些类和资源。有关 Zygote 加载过程的更清晰解释，请参见www.kpbird.com/2012/11/in-depth-android-boot-sequence-process.html。如下所述：

• Load ZygoteInitclass: 此类加载ZygoteInit类。源代码：<Android Source>/frameworks/base/core/java/com/android/internal/os/ZygoteInit.java。

• registerZygoteSocket(): 为 zygote 命令连接注册服务器套接字。

• preloadClasses(): 这是一个简单的文本文件，其中包含需要预加载的类的列表将在此处执行。此文件可以在<Android Source>/frameworks/base中看到。

• preloadResources(): 这处理本机主题和布局。所有包括android.R文件的内容都将使用此方法加载。

Android 启动过程：Zygote

系统服务器

设备的所有核心功能，如电话、网络和其他重要功能，都是由系统服务器启动的，如下图所示：

Android 启动过程：系统服务器

在此过程中启动以下核心服务：

• 启动电源管理器

• 创建 Activity Manager

• 启动电话注册表

• 启动包管理器

• 将 Activity Manager 服务设置为系统进程

• 启动上下文管理器

• 启动系统上下文提供程序

• 启动电池服务

• 启动闹钟管理器

• 启动传感器服务

• 启动窗口管理器

• 启动蓝牙服务

• 启动挂载服务

系统发送一个名为ACTION_BOOT_COMPLETED的广播动作，通知所有依赖进程引导过程已经完成。之后，设备显示主屏幕，并准备与用户交互。Android 系统现在已经完全运行，并准备与用户交互。

正如前面所解释的，许多制造商在其设备上使用 Android 操作系统。这些设备制造商大多根据其硬件和其他要求定制操作系统。因此，当发布新版本的 Android 时，这些设备制造商必须将他们的定制软件和调整移植到最新版本。

摘要

了解 Android 架构及其安全模型对于正确理解 Android 取证至关重要。Android 操作系统中固有的安全功能，如应用程序沙箱、权限模型等，保护 Android 设备免受各种威胁，并在调查过程中也作为取证专家的障碍。通过获得这些 Android 内部知识，我们将在下一章更多地讨论设备上存储了什么类型的数据以及它是如何存储的。

第二章：设置 Android 法庭环境

在开始任何法庭审查之前，建立一个已经建立的法庭环境是至关重要的。法庭分析师需要始终完全控制工作站。本章将带您了解建立法庭设置以检查 Android 设备所必需的一切。在本章中，我们将涵盖以下主题：

• 在工作站上安装必要的软件

• 从工作站连接和访问 Android 设备

• 在设备上使用 ADB 命令

• 对 Android 设备进行 Root

Android 法庭设置

在开始任何调查之前，建立一个声音和良好控制的法庭环境是至关重要的。从一个新的和法庭无菌的计算机开始。一个法庭无菌的计算机是一个可以防止交叉污染的潜力，不会引入不需要的数据，并且没有病毒和其他恶意软件的计算机。这是为了确保机器上的软件不会干扰当前的调查。安装基本软件，比如以下这些；它们是连接设备和进行分析所必需的：

• Android SDK

• 移动驱动程序

• MS Office 软件包

• 用于分析的工具

Android SDK

重要的是我们从 Android SDK 开始讨论。Android 软件开发工具包（SDK）帮助开发人员构建、测试和调试在 Android 上运行的应用程序。它包括软件库、API、模拟器、参考资料和许多其他工具。这些工具不仅帮助创建 Android 应用程序，还提供文档和实用程序，这些对 Android 设备的法庭分析非常有帮助。对 Android SDK 有扎实的了解可以帮助您了解设备的细节。这反过来将在调查中帮助您。

在法庭审查期间，SDK 帮助我们连接设备并访问设备上的数据。SDK 在大多数环境中都受支持，包括 Windows、Linux 和 OS X。可以从developer.android.com/sdk/index.html免费下载。

安装 Android SDK

谷歌现在只提供 Android Studio 和 SDK 工具作为下载选项。Android Studio 包含 Android IDE，SDK 工具，Android 5.0（棒棒糖）平台，带有谷歌 API 的 Android 5.0 系统映像，以及其他新引入的功能。然而，对于法庭实验室的设置，仅下载 SDK 工具包就足够了。以下是在 Windows 8 机器上安装 Android SDK 的逐步过程：

1. 在开始安装 Android SDK 之前，请确保系统已安装Java 开发工具包（JDK），因为 Android SDK 依赖于 Java SE 开发工具包。JDK 可以从www.oracle.com/technetwork/java/javase/downloads/index.html下载。根据您的操作系统选择正确的下载。

2. 从developer.android.com/sdk/index.html下载最新版本的 SDK 工具包。建议下载.exe版本的软件包。

3. 运行在步骤 2 中下载的安装程序文件。将出现一个向导窗口，如下截图所示。然后，点击下一步。

Android SDK 设置向导

1. 设置将自动检测系统上是否安装了 Java，并选择安装 Java 的路径。

2. 选择安装位置并记住以备将来使用。在本例中，我们将其安装在C:\Program Files (x86)。在 32 位操作系统的情况下，默认位置将是C:\Program Files。所有必要的文件将被提取到这个位置，如下截图所示：

Android SDK 工具安装

1. 安装完成后，打开C:\Program Files (x86)\Android\android-sdk目录，并双击SDK Manager.exe。确保选择 Android SDK 平台工具和任何一个 Android 的发布平台版本，如下面的屏幕截图所示。有些项目会自动选择。例如，Google USB 驱动程序在 Windows 上与 Android 设备一起使用时是必需的，并且默认已选择。接受许可证条款，然后点击安装按钮进行安装：

Android 软件包安装

前面过程的最后一步需要一些时间来完成。完成后，Android SDK 安装就完成了。现在可以通过指向可执行文件来更新系统的环境变量（路径）。

注意

仅 2MB 大小的最小 ADB 和 fastboot 工具可在 XDA 论坛（forum.xda-developers.com/showthread.php?t=2317790）上免费获得，无需安装完整的 Android SDK。这个工具是一个 Windows 安装程序，可以快速轻松地安装最新版本的 ADB 和 fastboot。

Android 虚拟设备

安装了 Android SDK 后，您可以创建一个Android 虚拟设备（AVD），这是一个在工作站上运行的模拟器。开发人员在创建新应用程序时通常会使用模拟器。然而，在取证调查中，模拟器也被认为是有帮助的。它允许调查人员了解某些应用程序的行为以及应用程序的安装如何影响设备。另一个优点是您可以设计一个具有所需版本的模拟器。这在处理运行较旧版本 Android 的设备时特别有帮助。此外，AVD 默认带有 root 权限。

以下步骤将指导您在工作站上创建 AVD：

1. 打开命令提示符（cmd.exe）。要从命令行启动 AVD 管理器，请导航到 SDK 安装的路径，并按照以下所示使用avd选项调用 android 工具：

C:\Program Files (x86)\Android\android-sdk\tools>android avd

这将自动打开 AVD 管理器，如下面的屏幕截图所示。AVD 管理器也可以使用图形 AVD 管理器启动。要启动它，请导航到 SDK 安装的位置，并双击AVD Manager。

Android 虚拟设备管理器

1. 在AVD 管理器窗口中单击创建以创建新的虚拟设备。单击编辑以更改现有虚拟设备的配置，如下面的屏幕截图所示：

AVD 详细信息

1. 根据以下信息输入必要的详细信息：

• AVD 名称：为虚拟设备提供任何名称，例如MyAVD。

• 设备：根据屏幕大小从可用选项中选择任何设备。

• 目标：此选项可帮助您选择设备的平台。请注意，只有在 SDK 安装期间选择并安装的那些版本才会显示在此处供您选择。平台版本可以根据所占设备的操作系统进行选择。例如，我们选择了 Android 4.4.2 平台。

• 硬件：您可以选择硬件功能来自定义模拟器，例如内部存储器的大小，SD 卡等。再次，可以根据所占设备的详细信息选择屏幕分辨率、硬件等详细信息。

1. 完成后，AVD 管理器屏幕将显示新创建的 AVD 列在Android 虚拟设备选项卡下。选择 AVD 并单击启动。然后，单击启动。

2. 模拟器将自动启动。这可能需要几分钟，具体取决于工作站的 CPU 和 RAM。以下是 AVD 成功启动后的截图：

安卓模拟器

模拟器可用于配置电子邮件帐户、安装应用程序、浏览互联网、发送短信等。取证分析师和安全工程师可以通过利用模拟器并检查网络、文件系统和数据遗物来学习关于安卓及其运行方式的大量知识。在模拟器上工作时创建的数据存储在您的主目录中，名为.android 的文件夹中。例如，在我们的示例中，我们之前创建的MyAVD模拟器的详细信息存储在C:\Users\Rohit\.android\avd\MyAVD.avd中。在此目录下有几个文件，以下是取证分析师感兴趣的一些文件：

• cache.img：这是/cache分区的磁盘映像。

• sdcard.img：这是 SD 卡分区的磁盘映像。

• Userdata-qemu.img：这是/data分区的磁盘映像。/data分区包含有关设备用户的宝贵信息。

• config.ini：这是存储 AVD 本地目录中硬件选项的配置文件。

• emulator-user.ini：此文件包含可以重置窗口位置的值。

• Androidtool.cfg：此文件可用于手动设置 Android SDK 的代理设置。

连接并从工作站访问安卓设备

为了从安卓设备中提取信息，首先需要将其连接到工作站。如前所述，应注意确保工作站在法庭上是无菌的，并且仅用于调查目的。无菌的工作站是指具有适当构建并且没有病毒和其他恶意软件的工作站。当设备连接到计算机时，可以对设备进行更改。因此，法庭鉴定人员必须始终控制设备。在移动取证领域，使用写保护机制可能并不是很有帮助，因为它们会阻止成功获取设备。这是因为在获取过程中，需要向设备发送某些命令以提取必要的数据。

识别设备电缆

可以使用设备的物理 USB 接口将安卓设备连接到工作站。这个物理 USB 接口允许设备与计算机连接、共享数据并充电。USB 接口可能会因制造商和设备而异。有不同类型，如迷你 USB、微型 USB 和其他专有格式。以下是最常用连接器类型的简要描述：

连接器类型	描述
---	---
Mini—A USB	大约 7 x 3 毫米大小，其中一长边的两个角被抬起。
Micro—B USB	大约 6 x 1.5 毫米大小，两个角被切掉形成梯形。
同轴	它有一个圆形孔，中间竖立着一个针。有不同尺寸，直径从 2 到 5 毫米不等。这种类型广泛用于诺基亚手机。
D 亚迷你	它呈矩形，两个圆角。矩形的长度不等，但高度始终为 1.5 到 2 毫米。这种类型主要由三星和 LG 设备使用。

因此，获取的第一步是确定需要什么类型的设备电缆。

安装设备驱动程序

只有在电脑上安装了必要的设备驱动程序时，移动设备才能与电脑通信。如果没有必要的驱动程序，电脑可能无法识别和使用连接的设备。由于安卓可能会被制造商修改和定制，没有一个通用的驱动程序适用于所有的安卓设备。每个制造商都有自己的专有驱动程序，并随手机一起分发。因此，识别需要安装的特定设备驱动程序是很重要的。当然，一些安卓取证工具包带有一些通用驱动程序或一组最常用的驱动程序。它们可能无法与所有型号的安卓手机一起使用。一些 Windows 操作系统能够在设备插入后自动检测并安装驱动程序，但往往情况并非如此。每个制造商的设备驱动程序可以在他们各自的网站上找到。

访问设备

安装必要的设备驱动程序后，使用 USB 电缆直接将安卓设备连接到电脑以访问它是很重要的。使用正宗的制造商特定电缆很重要，因为通用电缆可能无法正常使用某些设备。此外，调查人员可能会遇到某些驱动程序问题。一些设备可能不兼容 USB 3.0，这可能导致驱动程序安装失败。在这种情况下，建议尝试切换到 USB 2.0 端口。一旦设备连接，它将出现为一个新的驱动器，你可以访问外部存储上的文件。一些旧的安卓设备可能无法访问，除非在设备上启用了连接存储到 PC选项（转到设置 | USB 工具）。在这种情况下，连接设备后，需要选择打开 USB 存储选项，如下图所示：

USB 大容量存储连接

这是因为旧的安卓设备需要 USB 大容量存储模式来在电脑和设备之间传输文件。最新的安卓设备使用媒体传输协议（MTP）或图片传输协议（PTP），因为 USB 大容量存储协议存在一些问题。使用 USB 大容量存储，驱动器会完全向电脑开放，就像它是一个内部驱动器一样。

然而，问题在于访问存储的设备需要对其进行独占访问。换句话说，当设备驱动连接到电脑时，必须断开与设备上运行的安卓操作系统的连接才能工作。因此，当连接到电脑时，存储在 SD 卡或 USB 存储上的任何文件或应用将无法使用。在 MTP 中，安卓设备不会将其整个存储暴露给 Windows。相反，当你将设备连接到电脑时，电脑会查询设备，设备会以文件和目录列表的形式回应。如果电脑需要下载文件，它会向设备发送文件请求，设备会通过连接发送文件。PTP 也类似于 MTP，通常被数码相机使用。在这种模式下，安卓设备将与支持 PTP 而不支持 MTP 的数码相机应用程序一起工作。在最新的设备上，你可以通过转到设置 | 存储 | USB 计算机连接来选择 MTP 或 PTP 选项。

提示

在一些安卓设备上，只有在连接设备到电脑后才能提供选择 MTP 和 PTP 协议的选项。设备连接后，留意屏幕顶部的通知栏，你会看到一个 USB 符号出现。下拉通知栏，你会找到在 MTP 和 PTP 之间切换的选项。

如下截图所示，只有在将设备连接到计算机并拉下通知栏后，才会显示MTP和PTP选项：

Android 设备中的 USB PC 连接

在某些 Android 设备（尤其是 HTC）的情况下，连接 USB 电缆时，设备可能会暴露多个功能。例如，如下截图所示，当 HTC 设备连接到工作站时，会显示一个包含四个选项的菜单：

HTC 设备上的磁盘驱动器选项

默认选择是仅充电。选择磁盘驱动器选项时，它将被挂载为磁盘驱动器。当设备被挂载为磁盘驱动器时，您将能够访问设备上的 SD 卡。

从法庭的角度来看，SD 卡具有重要价值，因为它可能包含对调查重要的文件。大多数与多媒体相关的图像和大文件都存储在这个外部存储设备中。SD 卡通常使用 FAT16 文件系统格式化，但您可能也会遇到一些使用 FAT32 和其他文件系统的 SD 卡。正如在第一章中讨论的那样，介绍 Android 取证，请注意，大多数最近的设备都具有模拟 SD 卡功能，该功能使用设备的 NAND 闪存创建一个不可移动的 SD 卡。因此，可以通过这种方式访问外部存储中的所有敏感文件。但是，存储在/data/data下的核心应用程序数据将保留在设备上，无法通过这种方式访问。

Android 调试桥

在 Android 取证中，Android 调试桥（ADB）起着非常关键的作用。它位于<sdk_path>/platform-tools。要使用 ADB，需要启用USB 调试选项。在三星手机上，可以通过转到设置 | 开发者选项来访问此选项；如下截图所示：

Android 中的 USB 调试选项

然而，并非所有设备都是如此，因为不同的设备具有不同的环境和配置功能。有时，检查人员可能需要使用某些技术来访问一些设备上的开发者选项。这些技术是特定于设备的，需要根据设备类型和型号由取证分析师进行研究和确定。

注意

在某些设备上，开发者选项菜单是隐藏的，可以通过点击构建号字段（导航到设置 | 关于设备）七次来打开。

选择USB 调试选项后，设备将在后台运行adb 守护程序（adbd），并将不断寻找 USB 连接。该守护程序通常在非特权 shell 用户帐户下运行，因此不提供对内部应用程序数据的访问。但是，在 rooted 手机上，adbd 将在 root 帐户下运行，因此可以访问整个数据。在安装了 Android SDK 的工作站上，adbd 将作为后台进程运行。此外，在同一工作站上，将运行一个客户端程序，可以通过发出adb命令来调用。我们将在接下来的章节中看到这一点。当启动 adb 客户端时，首先检查 adbd 是否已经运行。如果没有，它将启动一个新的进程来启动 abdb。这些守护程序通过它们的本地主机在端口 5555 到 5585 之间进行通信。偶数端口与设备的控制台通信，而奇数端口用于 adb 连接。adb 客户端程序通过端口 5037 与本地 adbd 通信。

使用 adb 访问设备

如前所述，adb 是一个强大的工具，允许您与 Android 设备通信。我们现在将看一下如何使用 adb 并访问通常无法正常访问的设备的某些部分。重要的是要注意，通过 adb 收集的数据可能会或可能不会被法庭接受为证据。这将取决于各国的法律。以下部分列出了一些常用的 adb 命令，它们的含义以及在逻辑顺序中的用法。

检测连接的设备

将设备连接到工作站后，在发出其他 adb 命令之前，了解 Android 设备是否正确连接到 adb 服务器是有帮助的。这可以使用adb.exe devices 命令来完成，该命令列出连接到计算机的所有设备，如下命令所示。如果模拟器正在运行，它也会列出模拟器：

C:\Program Files (x86)\Android\android-sdk\platform-tools>adb.exe devices
List of devices attached
4df16ac5115e4e04        device

注意

请记住，如果没有安装必要的驱动程序，那么前述命令将显示空白消息。如果遇到这种情况，请从制造商处下载必要的驱动程序并安装它们。

如前述命令所示，输出包含设备的序列号，后跟连接状态。序列号是 ADB 用于识别每个 Android 设备的唯一字符串。连接状态的可能值及其含义在以下行中解释：

• offline：实例未连接到 adb 或未响应。

• device：实例已连接到 adb 服务器。

• no device：没有连接的设备。

将命令定向到特定设备

如果有多个设备连接到系统，您必须在发出命令时指定目标设备。例如，考虑以下情况：

C:\Program Files (x86)\Android\android-sdk\platform-tools>adb.exe devices
List of devices attached
4df16ac5115e4e04        device
7f1c864544456o6e    device

如前述命令行输出所示，有两个设备连接到工作站。在这种情况下，adb需要与-s选项一起使用，以向您选择的设备发出命令：

adb shell -s4df16ac5115e4e04

类似地，-d命令可用于将adb命令定向到唯一连接的 USB 设备，-e命令可用于将adb命令定向到唯一运行的模拟器实例。

发出 shell 命令

如第一章中所述，介绍 Android 取证，Android 运行在 Linux 内核上，并提供了访问 shell 的方法。使用 ADB，您可以访问一个 shell，在 Android 设备上运行多个命令。对于不熟悉 Linux 环境的人来说，Linux shell 是指一个特殊的程序，允许您通过键盘输入某些命令与其交互。shell 将执行命令并显示它们的输出。

有关 Linux 环境中工作原理的更多详细信息已在本章的Rooting Android 设备部分中提供。adb shell 命令可用于进入远程 shell，如下命令行输出所示。一旦进入 shell，您可以执行大多数 Linux 命令：

C:\Program Files (x86)\Android\android-sdk\platform-tools>adb.exe shell
shell@android:/ $

执行命令后，观察到 shell 提示显示给用户。在这个 shell 提示中，可以在设备上执行命令。例如，如下命令行所示，ls命令可用于查看目录中的所有文件：

C:\Program Files (x86)\Android\android-sdk\platform-tools>adb.exe shell
shell@android:/ $ ls
ls
acct
cache
config
d
data
default.prop
dev
efs
etc
factory
fstab.smdk4x12

以下部分解释了一些在与 Android 设备交互时非常有用的广泛使用的 Linux 命令。

基本的 Linux 命令

我们现在将看一些 Linux 命令及其在 Android 设备上的使用：

• ls：ls 命令（无选项）列出当前目录中存在的文件和目录。使用-l选项，它还显示它们的大小，修改日期和时间，文件所有者及其权限等，如下命令行输出所示：

shell@android:/ $ ls -l
ls -l
drwxr-xr-x root     root              2015-01-17 10:13 acct
drwxrwx--- system   cache             2014-05-31 14:55 cache
dr-x------ root     root              2015-01-17 10:13 config
lrwxrwxrwx root     root              2015-01-17 10:13 d -> /sys/kernel/debug
drwxrwx--x system   system            2015-01-17 10:13 data
-rw-r--r-- root     root          116 1970-01-01 05:30 default.prop
drwxr-xr-x root     root              2015-01-17 10:13 dev
drwxrwx--x radio    system            2013-08-13 09:34 efs
lrwxrwxrwx root     root              2015-01-17 10:13 etc -> /system/etc

同样，以下是可以与 ls 命令一起使用的一些选项。根据需求，调查人员可以使用其中一个或多个选项来查看详细信息：

选项	描述
a	列出隐藏文件
c	根据时间戳显示文件
d	仅显示目录
n	显示长格式列表，包括 GID 和 UID 号码
R	同时显示子目录
t	根据时间戳显示文件
u	显示文件访问时间

• cat：cat 命令读取一个或多个文件并将它们打印到标准输出，如下面的命令行所示：

shell@android:/ $ cat default.prop
cat default.prop
#
# ADDITIONAL_DEFAULT_PROPERTIES
#
ro.secure=1
ro.allow.mock.location=0
ro.debuggable=0
persist.sys.usb.config=mtp

> 运算符可用于将多个文件合并为一个。>> 运算符可用于追加到现有文件中。

• cd：cd 命令用于从一个目录切换到另一个目录。在从一个文件夹导航到另一个文件夹时使用。以下示例显示了用于切换到系统文件夹的命令：

shell@android:/ $ cd /system
cd /system
shell@android:/system $

• cp：cp 命令可用于将文件从一个位置复制到另一个位置。该命令的语法如下：

$ cp [options] <source><destination>

• chmod：chmod 命令用于更改文件系统对象（文件和目录）的访问权限。它也可以更改特殊模式标志。该命令的语法如下：

$ chmod [option] mode files

例如，对文件执行 chmod 777 可以让所有人都有读取、写入和执行的权限。

• dd：dd 命令用于复制文件，根据操作数进行转换和格式化。在 Android 中，dd 命令可用于创建 Android 设备的逐位图像。有关成像的更多细节在第五章中有所涵盖，从 Android 设备物理上提取数据。以下是需要与此命令一起使用的语法：

dd if=/test/file of=/sdcard/sample.image

• rm：rm 命令可用于删除文件或目录。以下是该命令的语法：

rm file_name

• grep：grep 命令用于搜索特定模式的文件或输出。以下示例显示了在 default.prop 文件中搜索单词 secure：

 shell@android:/ # cat default.prop | grep secure
ro.secure=1

• pwd：pwd 命令显示当前工作目录。例如，以下命令行输出显示当前工作目录为 /system：

shell@android:/system $ pwd
pwd
/system

• mkdir：mkdir 命令用于创建新目录。该命令的语法如下：

mkdir [options] directories

• exit：exit 命令可用于退出当前所在的 shell。只需在 shell 中输入 exit 即可退出。

安装应用程序

在取证分析过程中，可能会有需要在设备上安装一些应用程序以提取一些数据的情况。为此，您可以使用 adb.exe install 命令。除此命令之外，如下面的命令行输出所示，您需要指定要安装的 .apk 文件的路径：

C:\Program Files (x86)\Android\android-sdk\platform-tools>adb.exe install C:\rohit\test.apk
4311 KB/s (13855934 bytes in 3.138s)
 pkg: /data/local/tmp/test.apk
Success

但是，需要注意的是，在法庭上可能不接受安装第三方应用程序。因此，在设备上安装任何第三方应用程序之前，取证调查人员需要谨慎。

从设备中提取数据

您可以使用 adb pull 命令将 Android 设备上的文件拉取到本地工作站。以下是使用此命令的语法：

adb pull <remote><local>

在这里，<remote> 指的是 Android 设备上文件的路径，<local> 指的是需要存储文件的本地工作站位置。例如，以下命令行输出显示了从 Android 设备中将 Sample.png 文件拉取到计算机上的 temp 文件夹中：

C:\Program Files (x86)\Android\android-sdk\platform-tools>adb.exe pull /sdcard/Pictures/MyFolder/Sample.png C:\temp
1475 KB/s (145039 bytes in 0.096s)

然而，在普通的 Android 手机上，您将无法使用adb pull命令下载所有文件，因为操作系统强制执行的固有安全功能。例如，在未经 root 的 Android 设备上，无法以这种方式访问/data/data文件夹中的文件。有关此主题的更多详细信息已在第四章中进行了介绍，从 Android 设备逻辑提取数据。

将数据推送到设备

您可以使用adb push命令将文件从本地工作站复制到 Android 设备。以下是使用此命令的语法：

adb push <local><remote>

这里，<local>指的是本地工作站上文件的位置，<remote>指的是 Android 设备上需要存储文件的路径。例如，以下命令行输出显示了从计算机复制到 Android 设备的Pictures文件夹中的test.png文件：

C:\Program Files (x86)\Android\android-sdk\platform-tools>adb.exe push C:\temp\test.png /sdcard/Pictures
2950 KB/s (145039 bytes in 0.048s)

您只能将文件推送到用户帐户具有特权的文件夹。

重新启动 adb 服务器

在某些情况下，您可能需要终止 adb 服务器进程，然后重新启动它。例如，如果 adb 不响应命令。这可能会解决问题。

要停止 adb 服务器，请使用kill-server命令。然后，您可以通过发出任何其他 adb 命令来重新启动服务器。

查看日志数据

在 Android 中，logcat命令提供了一种查看系统调试输出的方式。来自各种应用程序和系统部分的日志被收集在一系列循环缓冲区中，然后可以通过此命令查看和过滤：

C:\Program Files (x86)\Android\android-sdk\platform-tools>adb.exe logcat
--------- beginning of /dev/log/main

I/InputReader( 2841): Touch event's action is 0x0 (deviceType=0) [pCnt=1, s=0.40234 ]

I/InputDispatcher( 2841): Delivering touch to current input target: action: 0x0

I/InputDispatcher( 2841): Delivering touch to current input target: action: 0x0

I/InputDispatcher( 2841): Delivering touch to current input target: action: 0x0
...
I/SecCamera-JNI-Java( 2841): stopPreview

V/SecCamera-JNI-Cpp( 2841): release camera

V/SecCamera-JNI-Cpp( 2841): release
...
D/STATUSBAR-BatteryController( 3162): onReceive() - ACTION_BATTERY_CHANGED

D/STATUSBAR-BatteryController( 3162): onReceive() - level:48

D/STATUSBAR-BatteryController( 3162): onReceive() - plugged:2

D/STATUSBAR-BatteryController( 3162): onReceive() - BATTERY_STATUS_CHARGING:

这里显示的日志消息只是一个示例消息。在调查过程中，需要仔细分析日志，以收集有关位置详细信息、日期/时间信息、应用程序详细信息等的信息。每个日志都以消息类型指示器开头，如下表所述：

消息类型	描述
V	冗长
D	调试
I	信息
W	警告
E	错误
F	致命
S	静默

logcat命令也可用于查看完整的蜂窝无线电调试，如下面的命令行输出所示：

C:\Program Files (x86)\Android\android-sdk\platform-tools>adb.exe shell logcat –b radio –v time

03-22 17:06:22.155 E/RIL     (12513): RX: 01
03-22 17:06:22.155 D/RILJ    ( 2815): [UNSL]< UNSOL_RESPONSE_VOICE_NETWORK_STATE_CHANGED
03-22 17:06:22.155 D/RILJ    ( 2815): [7100]> OPERATOR
03-22 17:06:22.155 D/RILJ    ( 2815): [7101]> DATA_REGISTRATION_STATE
03-22 17:06:22.155 E/RIL     (12513): TX: Time: 1095039892 / 164875824
03-22 17:06:22.155 E/RIL     (12513): TX: M:IPC_NET_CMD S:IPC_NET_SERVING_NETWORK T:IPC_CMD_GET
 l:7 m:5e a:0
03-22 17:06:22.160 D/RILJ    ( 2815): [7102]> VOICE_REGISTRATION_STATE
03-22 17:06:22.160 D/RILJ    ( 2815): [7103]> QUERY_NETWORK_SELECTION_MODE
03-22 17:06:22.160 E/RIL     (12513): RX: Time: 1095039894 / 164875826
03-22 17:06:22.160 E/RIL     (12513): RX: M:IPC_NET_CMD S:IPC_NET_SERVING_NETWORK T:IPC_CMD_RES
P l:12 m:ff a:5e
03-22 17:06:22.160 E/RIL     (12513): RX: 02 02 04 34 30 34 34 39 23 19 79
03-22 17:06:22.160 D/RILJ    ( 2815): [7100]< OPERATOR {Airtel, Airtel, 40449}
03-22 17:06:22.170 E/RIL     (12513): TX: Time: 1095039906 / 164875839
03-22 17:06:22.170 E/RIL     (12513): TX: M:IPC_NET_CMD S:IPC_NET_REGIST T:IPC_CMD_GET l:9 m:5f
 a:0
03-22 17:06:22.170 E/RIL     (12513): TX: FF 03
03-22 17:06:22.175 E/RIL     (12513): RX: Time: 1095039909 / 164875841
03-22 17:06:22.175 E/RIL     (12513): RX: M:IPC_NET_CMD S:IPC_NET_REGIST T:IPC_CMD_RESP l:12 m:
ff a:5f
03-22 17:06:22.175 E/RIL     (12513): RX: 04 03 02 0B 19 79 E1 4A 2E 01 00
03-22 17:06:22.175 E/RIL     (12513): TX: Time: 1095039909 / 164875841
03-22 17:06:22.175 E/RIL     (12513): TX: M:IPC_NET_CMD S:IPC_NET_REGIST T:IPC_CMD_GET l:9 m:60...

Rooting Android

"Rooting"是一个在 Android 设备方面经常听到的词。作为法医检查员，深入了解这一点至关重要。这将帮助您获得了解设备内部所需的知识。这也将帮助您在调查过程中遇到的几个问题上获得专业知识。Rooting Android 手机已经成为一种常见现象，在调查过程中经常遇到 rooted 手机。此外，根据情况和要提取的数据，检查员本身必须 root 设备才能提取某些数据。以下各节讨论了 rooting Android 设备和其他相关概念。

什么是 rooting？

要了解 rooting，了解类 Unix 系统的工作原理至关重要。Linux 和其他类 Unix 系统所基于的原始 Unix 操作系统从一开始就被设计为多用户系统。这主要是因为个人计算机尚不存在，因此有必要有一种机制来分离和保护各个用户的资源，同时允许他们同时使用系统。但是，为了执行特权任务，例如授予和撤销普通用户的权限，访问关键系统文件以修复或升级系统等，有必要拥有具有超级用户访问权限的系统管理员帐户。因此，我们有两种类型的帐户：普通用户帐户，权限较少，以及超级用户或根帐户，具有所有权限。

因此，root 是默认情况下具有对 Linux 或其他类 Unix 操作系统上的所有命令和文件的访问权限的用户名或帐户。它也被称为根帐户、根用户和超级用户。因此，在 Linux 中，根用户有权启动或停止任何系统服务，编辑或删除任何文件，更改其他用户的权限等。您已经了解到 Android 使用 Linux 内核，因此，Linux 中的大多数概念也适用于 Android。然而，当您购买 Android 手机时，通常不允许您以根用户身份登录。对 Android 手机进行 root 操作就是为了在设备上获得这种根访问权限，以执行通常不允许在设备上执行的操作。

理解 root 和越狱之间的区别也很重要，因为它们经常被错误地认为是相同的。越狱运行 Apple iOS 的设备允许您删除苹果设置的某些限制和限制。例如，苹果不允许我们在设备上安装未签名的应用程序。因此，通过越狱，您可以安装未经苹果批准的应用程序。相比之下，Android 允许应用程序的侧载。越狱手机涉及同时绕过多个安全限制。因此，在设备上获得根访问权限只是越狱设备的一个方面。

为什么要 root？

许多人进行 root 操作的目标是克服运营商和硬件制造商对 Android 设备设置的限制。通过对 Android 设备进行 root 操作，您可以更改或替换系统应用程序和设置，运行需要管理员级权限的专门应用程序，或执行通常对普通 Android 用户不可访问的操作。这些操作包括卸载默认应用程序（特别是随手机附带的垃圾应用程序）。root 操作也是为了进行极端定制；例如，可以下载和安装新的定制 ROM。然而，从取证分析的角度来看，进行 root 操作的主要原因是获得对通常无法访问的系统部分的访问权限。大多数公共 root 工具将导致永久 root，即使在重新启动设备后更改仍然存在。在临时 root 的情况下，设备重新启动后更改将丢失。在取证案例中应始终首选临时 root。

如第一章介绍 Android 取证中所解释的，在 Linux 系统中，每个用户被分配一个唯一用户 ID（UID），用户被隔离开，以便一个用户无法访问另一个用户的数据。同样，在 Android 中，每个应用程序被分配一个 UID，并作为一个单独的进程运行。应用程序 UID 通常按安装顺序分配，从 10001 开始。这些 ID 存储在/data/system中的packages.xml文件中。除了存储 UID，该文件还存储了每个程序的 Android 权限，如其清单文件中所述。

每个应用程序的私有数据存储在/data/data位置，只能被该应用程序访问。因此，在调查过程中，无法访问该位置的数据。然而，对手机进行 root 操作将允许您访问任何位置的数据。需要记住的是，对手机进行 root 操作有几个影响，如下所述：

• 安全风险：对手机进行 root 操作可能会使设备面临安全风险。例如，想象一下一个恶意应用程序，它可以访问整个操作系统以及设备上安装的所有其他应用程序的数据。

• 设备变砖: 如果 root 操作没有正确进行，可能会导致设备变砖。"变砖"是一个常用词，用于描述无法以任何方式打开的死机手机。

• 使您的保修失效：根据制造商和运营商的不同，对设备进行 Root 操作可能会使您的保修失效，因为这会使设备面临多种威胁。

• 法医学意义：对 Android 设备进行 Root 操作将允许调查人员访问更多的数据，但这涉及对设备的某些部分进行修改。因此，只有在绝对必要的情况下才应对设备进行 Root 操作。

恢复和快速启动

在处理 Root 过程之前，有必要了解 Android 中的引导加载程序、恢复和快速启动模式。以下部分将详细解释这些内容。

恢复模式

Android 手机可以看作是一个具有三个主要分区的设备：引导加载程序、Android ROM 和恢复。引导加载程序位于第一个分区中，是手机开机时运行的第一个程序。这个引导加载程序的主要工作是处理低级硬件初始化并将设备引导到其他分区。它通常默认加载 Android 分区，通常称为 Android ROM。Android ROM 包含运行设备所必需的所有操作系统文件。恢复分区，通常称为原生恢复，用于删除所有用户数据和文件或执行系统更新。

这两种操作都可以从正在运行的 Android 系统开始，也可以通过手动进入恢复模式进行。例如，当您在手机上进行恢复出厂设置时，恢复会启动并擦除文件和数据。同样，通过更新，手机会启动到恢复模式以安装直接写入 Android ROM 分区的最新更新。因此，恢复模式是您在设备上安装任何官方更新时看到的屏幕。

访问恢复模式

恢复映像存储在恢复分区上，它由一个带有硬件按钮控制的 Linux 映像组成。可以通过两种方式访问恢复模式：

• 通过在设备启动时按下某些组合键（通常是在启动过程中按住音量+、音量-和电源按钮）

• 通过向已启动的 Android 系统发出 adb reboot recovery 命令

以下是 Android 设备上原生恢复模式的屏幕截图：

Android 原生恢复

原生 Android 恢复意图上功能非常有限。它有重新启动系统、从 adb 和 SD 卡应用更新、恢复出厂设置等选项。然而，自定义恢复提供了更多选项。

自定义恢复

自定义恢复是第三方恢复环境。将这个恢复环境刷入设备将默认的原生恢复环境替换为第三方定制的恢复环境。这些是自定义恢复中包含的最常见功能：

• 完整备份和恢复功能（如 NANDroid）

• 允许未签名的更新包或允许带有自定义密钥的签名包

• 选择性地挂载设备分区和 SD 卡

• 提供 USB 大容量存储访问 SD 卡或数据分区

• 提供完整的 ADB 访问，ADB 守护程序以 root 身份运行

• 功能齐全的 BusyBox 二进制文件（Busybox 是一个包含强大命令行工具的单个二进制可执行文件集合）

• 今天市场上有几种自定义恢复映像可用，例如 ClockworkMod 恢复、TeamWin 恢复项目等。以下屏幕截图显示了 ClockworkMod 恢复 v6.0.2.5 提供的选项：

ClockworkMod 恢复

快速启动模式

Fastboot 是一种协议，可用于在设备上重新刷写分区。它是随 Android SDK 一起提供的工具之一。它是恢复模式的替代方案，可用于安装和更新，有时也可用于解锁引导加载程序。在快速启动模式下，可以通过 USB 连接从计算机修改文件系统映像。因此，这是安装恢复映像并在某些情况下启动的一种方式。一旦手机启动到快速启动模式，就可以在内部存储器中刷写图像文件。例如，可以通过 ROM Manager 应用程序以这种方式刷写之前讨论过的自定义恢复映像，如 ClockworkMod 恢复。刷写 ClockworkMod 恢复的最简单方法之一是通过 ROM Manager 应用程序。安装在已 root 的 Android 设备上后，该应用程序提供了Flash ClockworkMod Recovery选项来安装恢复：

从 ROM Manager 应用程序刷入 ClockworkMod 恢复

已锁定和未锁定的引导加载程序

引导加载程序可以是已锁定或未锁定的。已锁定的引导加载程序不允许您通过在引导加载程序级别实施限制来对设备的固件进行修改。这通常是通过加密签名验证来完成的。因此，无法向设备刷写未签名代码。换句话说，为了运行任何恢复映像或自己的操作系统，必须首先解锁引导加载程序。解锁引导加载程序可能会导致严重的安全问题。

如果设备丢失或被盗，攻击者只需上传自定义的 Android 引导映像或刷写自定义恢复映像，就可以恢复设备上的所有数据。因此，攻击者可以完全访问设备上包含的数据。因此，在解锁已锁定的引导加载程序时，手机会执行恢厂数据重置，以便擦除所有数据。因此，只有在绝对必要时才执行此操作非常重要。一些设备有官方解锁的方法。对于这些设备，可以将设备放入快速启动模式并运行fastboot oem unlock命令来解锁引导加载程序并完全擦除 Android 设备。

一些其他制造商通过不同的方式提供解锁，例如通过他们的网站等。下面的屏幕截图显示了 HTC 网站提供支持以解锁 HTC 设备：

提供支持解锁引导加载程序的 HTC 网站

如何获取 root 权限

本节讨论如何处理已锁定和未锁定的引导加载程序。在具有未锁定引导加载程序的设备上获得 root 访问权限非常容易，而在具有已锁定引导加载程序的设备上获得 root 访问权限则不那么直接。以下各节将详细解释这一点。

解锁引导加载程序

在类 Unix 系统中，超级用户是用于系统管理的特殊用户帐户，并具有访问和修改操作系统中所有文件的特权。获取 root 权限的过程主要涉及将超级用户（su）二进制文件复制到当前进程路径中的位置（/system/xbin/su），并使用chmod命令授予其可执行权限。因此，这里的第一步是解锁引导加载程序。如在已锁定和未锁定的引导加载程序部分中所解释的，根据所涉及的设备，可以通过快速启动模式或遵循特定供应商的引导加载程序解锁过程来完成引导加载程序的解锁。su 二进制文件通常伴随着一个 Android 应用程序，例如 Superuser，每当应用程序请求 root 访问权限时都会提供一个图形提示，如下面的屏幕截图所示：

超级用户请求

一旦引导加载程序被解锁，您就可以对设备进行所有所需的更改。因此，可以通过多种方式复制 su 二进制文件并授予其可执行权限。最常见的方法是启动自定义恢复镜像。这使我们能够将 su 二进制文件复制到系统分区并通过自定义更新包设置适当的权限。

在解锁的引导加载程序设备上，按照以下步骤对设备进行 root：

1. 从www.clockworkmod.com/rommanager下载自定义恢复镜像，并从superuserdownload.com/下载 su 更新包。自定义恢复镜像可以是任何支持您的设备的镜像。同样，su 更新包可以是 SuperSU、SuperUser 或您选择的任何其他包。

2. 将自定义恢复镜像和 su 更新包都复制到 Android 设备的 SD 卡上。

3. 接下来，将设备放入快速启动模式。

4. 打开命令提示符，并输入以下命令：

C:\Program Files (x86)\Android\android-sdk\platform-tools> fastboot boot recovery.img

1. 在上述命令中，recovery.img是您下载的恢复镜像。

2. 从“恢复”菜单中，选择“应用更新 zip 文件”选项，并浏览到设备上 su 二进制更新包所在的位置。

提示

自 Android 4.1 版本以来，引入了一个名为 sideload 模式的新功能。此功能允许我们通过 ADB 在不事先复制到设备的情况下应用更新 zip。要进行 sideload 更新，请运行adb sideload su-package.zip命令，其中su-package.zip是计算机上更新包的文件名。

或者，您还可以修改工厂镜像以添加 su 二进制文件。这可以通过解包一个 ext4 格式的系统镜像，添加 su 二进制文件，然后重新打包来完成。如果刷入此镜像，它将包含 su 二进制文件，并且设备将被 root。

注意

Rooting 是一个高度特定于设备的过程。因此，在对任何 Android 设备应用这些技术之前，取证调查员需要谨慎。

解锁引导加载程序的 root

当引导加载程序被锁定且无法通过任何可用手段解锁时，对设备进行 root 需要我们找到一个可以被利用的安全漏洞。然而，在此之前，重要的是要确定引导加载程序锁的类型。这可能会因制造商和软件版本而异。对于一些手机，可能不允许快速启动访问，但仍可以使用制造商的专有刷机协议进行刷机，比如三星 ODIN。一些设备仅对选定的分区强制执行签名验证，比如引导和恢复。因此，可能无法引导到自定义恢复模式。但是，您仍然可以修改工厂镜像以包含 su 二进制文件，就像前面部分所述的那样。

如果无法通过任何手段解锁引导加载程序，那么唯一的选择就是找到设备上允许我们利用并添加 su 二进制文件的一些漏洞。漏洞可能存在于 Android 内核、以 root 身份运行的进程或其他问题中。这是设备特定的，需要在尝试任何设备之前进行广泛的研究。以下是在对 Android 设备进行 root 时使用的一些常见漏洞利用：

• psneuter

• asroot

• Exploid

• GingerBreak

• RageAgainstTheCage

• 飞

• Levitator

• zergRush

• mempodroid

• Razr 刀片

已 root 设备上的 ADB

我们已经看到了如何使用 ADB 工具与设备进行交互并在设备上执行某些命令。然而，在普通 Android 手机上，某些位置，比如/data/data，是无法访问的。例如，当您尝试在普通设备上访问/data/data时，会出现以下命令行输出：

C:\Program Files (x86)\Android\android-sdk\platform-tools>adb.exe shell
shell@android:/ $ cd /data/data
cd /data/data
shell@android:/data/data $ ls
ls
opendir failed, Permission denied

这是因为所有应用的私有数据都存储在这个文件夹中。因此，安卓强制执行了安全性。只有 root 用户才能访问这个位置。因此，在已 root 设备上，您将能够看到该位置下的所有数据，就像以下命令中所示：

C:\Program Files (x86)\Android\android-sdk\platform-tools>adb.exe shell
shell@android:/ # ls /data/data
ls /data/data
android.googleSearch.googleSearchWidget
com.android.MtpApplication
com.android.Preconfig
com.android.apps.tag
com.android.backupconfirm
com.android.bluetooth
com.android.browser
com.android.calendar
com.android.certinstaller
com.android.chrome
com.android.clipboardsaveservice
com.android.contacts
com.android.defcontainer
com.android.email
com.android.exchange
com.android.facelock
com.android.htmlviewer
com.android.inputdevices
com.android.keychain
com.android.mms

如前述命令所示，现在可以通过导航到相应的文件夹轻松地看到所有应用程序的私人数据。因此，对于已 Root 的设备上的 ADB 工具非常强大，并允许审查员访问设备上安装的所有应用程序的数据。只要设备没有图案或 PIN 保护，或者已注册到具有 RSA 密钥的机器上，这是可能的。

注意

有时，即使在 Root 手机上，您也会看到权限被拒绝的消息。在这种情况下，在执行 adb shell 命令后，尝试输入超级用户模式，输入su。如果启用了 Root，您将看到#而不需要密码。

总结

设置一个适当的取证环境是在对安卓设备进行调查之前至关重要的。安卓 SDK 的安装是必要的，以便使用其中附带的 ADB 等工具。使用 ADB，审查员可以与设备通信，查看设备上的文件夹，并提取数据并将数据复制到设备上。然而，并非所有文件夹都可以以这种方式在普通手机上访问。这是因为设备的安全执行阻止审查员查看包含私人数据的位置。对设备进行 Root 解决了这个问题，因为它提供了对设备上所有数据的无限访问。对于已解锁引导加载程序的设备，对其进行 Root 是直截了当的，而对于已锁定引导加载程序的设备，则涉及利用一些安全漏洞。

有了对访问设备的了解，您现在将在第三章中学习有关数据在安卓设备上的组织以及许多其他细节，了解安卓设备上的数据存储。

第三章：了解 Android 设备上的数据存储

取证分析的主要目的是从设备中提取必要的数据。因此，为了有效的取证分析，了解存储在设备上的数据类型、存储位置、存储方式以及存储数据的文件系统的细节至关重要。这些知识对于取证分析人员来说非常重要，可以帮助他们做出明智的决定，确定在哪里寻找数据以及可以用来提取数据的技术。在本章中，我们将涵盖以下主题：

• Android 分区布局和文件层次结构

• 设备上的应用程序数据存储

• Android 文件系统概述

Android 分区布局

分区是设备持久存储内存中的逻辑存储单元。分区允许您将可用空间逻辑地划分为可以独立访问的部分。

Android 中的常见分区

分区布局在不同厂商和版本之间有所不同。然而，一些分区存在于所有 Android 设备中。以下部分解释了大多数 Android 设备中发现的一些常见分区。

引导加载程序

这个分区存储手机的引导加载程序。这个程序负责在手机启动时初始化低级硬件。因此，它负责引导 Android 内核和引导到其他引导模式，比如恢复模式、下载模式等。

引导

顾名思义，这个分区包含了手机启动所需的信息和文件。它包含了内核和 RAM 磁盘。因此，没有这个分区，手机无法启动其进程。

恢复

恢复分区允许设备通过恢复控制台启动，通过该控制台执行诸如手机更新和其他维护操作等活动。为此，存储了一个最小的 Android 引导映像。这个引导映像作为一个保险措施。

用户数据

这个分区通常被称为数据分区，是设备的应用程序数据的内部存储。大部分用户数据都存储在这里，这也是我们的大部分取证证据所在。它还存储了所有应用程序数据和标准通信。

系统

除了内核和 RAM 磁盘之外的所有主要组件都在这里。Android 系统映像包含了 Android 框架、库、系统二进制文件和预安装的应用程序。没有这个分区，设备无法启动到正常模式。

缓存

这个分区用于存储频繁访问的数据和各种其他文件，比如恢复日志和通过蜂窝网络下载的更新包。

无线电

具有电话功能的设备在这个分区中存储了基带映像，负责各种电话活动。

识别分区布局

对于给定的 Android 设备，分区布局可以通过多种方式确定。/proc目录下的partitions文件给出了设备上所有分区的详细信息。以下截图显示了partitions文件的内容：

Android 中的分区文件

前面截图中的条目只显示了块名称。要获取这些块与它们的逻辑功能的映射，请检查/dev/block/platform/dw_mmc目录下的by-name目录的内容。以下截图显示了该目录的内容：

块到它们的逻辑功能的映射

如前所示，分区布局中存在各种分区，如系统、用户数据等。

Android 文件层次结构

为了对任何系统（桌面或移动）进行取证分析，了解底层文件层次结构是很重要的。对 Android 如何在文件和文件夹中组织数据有基本的了解，有助于取证分析人员将研究范围缩小到特定位置。如果你熟悉类 Unix 系统，你会很好地理解 Android 中的文件层次结构。在 Linux 中，文件层次结构是一个单一的树，树的顶部被表示为/。这被称为根。这与在驱动器中组织文件的概念（如 Windows）不同。无论文件系统是本地还是远程，它都会存在于根下。Android 文件层次结构是这个现有 Linux 层次结构的定制版本。根据设备制造商和底层 Linux 版本，这个层次结构的结构可能会有一些微不足道的变化。要查看完整的文件层次结构，你需要有 root 访问权限。下面的截图显示了 Android 设备上的文件层次结构：

Android 根目录下的文件夹

目录概述

接下来的部分将概述 Android 设备文件层次结构中存在的目录。

acct

这是 acct cgroup（控制组）的挂载点，用于用户账户。

缓存

这是 Android 存储频繁访问的数据和应用组件的目录（/cache）。清除缓存不会影响个人数据，只是删除其中的现有数据。这个文件夹中还有另一个名为lost+found的目录。这个目录在文件系统损坏的情况下（例如不正确地移除 SD 卡而没有卸载等）会保存恢复的文件（如果有的话）。缓存可能包含取证相关的证据，例如图片、浏览历史和其他应用数据。

d

这是一个符号链接到/sys/kernel/debug。这个文件夹用于挂载 debugfs 文件系统和调试内核。

数据

这是包含每个应用程序数据的分区。用户的大部分数据，例如联系人、短信、拨打的号码等，都存储在这个文件夹中。从取证的角度来看，这个文件夹非常重要，因为它包含有价值的数据。下面的截图显示了这个分区中存在的文件夹：

Android 设备数据分区的内容

接下来的部分将简要解释data文件夹下其他重要子目录的内容。

dalvik-cache

如第一章介绍 Android 取证中所讨论的，Android 应用程序包含优化过的 Java 字节码的.dex文件。当应用程序安装在 Android 设备上时，对应的.dex文件会进行一些修改，并创建一个名为.odex文件（优化的.dex文件）。然后将其缓存到/data/dalvik-cache目录中，以便在每次加载application.log时不必执行优化过程。

这个文件夹包含一些日志，根据具体需求，在检查过程中可能会有用。例如，下面的截图显示了一个名为recovery_log.txt的日志文件，其中包含有关恢复日志的详细信息：

recovery_log.txt 文件输出

data

/data/data分区包含所有应用程序的私有数据。用户的大部分数据存储在这个文件夹中。从取证的角度来看，这个文件夹非常重要，因为它包含有价值的数据。这个分区在内部存储部分有详细介绍。

dev

这个目录包含所有设备的特殊设备文件。这是 tempfs 文件系统的挂载点。这个文件系统定义了应用程序可用的设备。

init

正如在第一章中所讨论的，介绍 Android 取证，在启动 Android 内核时，将执行 init 程序。此程序位于此文件夹下。

mnt

此目录用作所有文件系统、内部和外部 SD 卡等的挂载点。以下屏幕截图显示了此目录中的挂载点：

proc

这是 procfs 文件系统的挂载点，提供对内核数据结构的访问。几个程序使用/proc作为其信息的来源。它包含有关进程的有用信息的文件。例如，如下屏幕截图所示，/proc下的meminfo提供有关内存分配的信息：

Android 中 proc 文件夹下的 meminfo 文件

root

这是 root 账户的主目录。只有在设备被 root 后才能访问此文件夹。

sbin

这包含了一些重要守护进程的二进制文件。从取证角度来看，这并不是很重要。

misc

正如名称所示，此文件夹包含有关杂项设置的信息。这些设置主要定义状态，即开/关。有关硬件设置、USB 设置等信息可以从此文件夹中访问。

sdcard

这是包含设备 SD 卡上数据的分区。请注意，此 SD 卡可以是可移动存储或不可移动存储。您手机上具有WRITE_EXTERNAL_STORAGE权限的任何应用程序都可以在此位置创建文件或文件夹。大多数手机上都有一些默认文件夹，如android_secure、Android、DCIM、media等。以下屏幕截图显示了/sdcard位置的内容：

Android 设备的 sdcard 分区的内容

数码相机图像（DCIM）是数码相机、智能手机、平板电脑和相关固态设备的默认目录结构。一些平板电脑有一个指向相同位置的photos文件夹。在DCIM中，您会找到您拍摄的照片、视频和缩略图（缓存）文件。照片存储在/DCIM/Camera中。

Android 开发者参考解释了一些公共存储目录，这些目录与特定程序没有特定的关联。以下是这些文件夹的快速概述：

• 音乐：媒体扫描器将此处找到的所有媒体分类为用户音乐。

• 播客：媒体扫描器将此处找到的所有媒体分类为播客。

• 铃声：此处的媒体文件被分类为铃声。

• 闹钟：此处的媒体文件被分类为闹钟。

• 通知：此位置下的媒体文件用于通知声音。

• 图片：除了用相机拍摄的照片外，所有照片都存储在此文件夹中。

• 电影：除了用相机拍摄的电影外，所有电影都存储在此文件夹中。

• 下载：各种下载存储在此文件夹中。

system

此目录包含库、系统二进制文件和其他与系统相关的文件。与手机一起预装的应用程序也存在于此分区中。以下屏幕截图显示了 Android 设备上系统分区中的文件：

Android 设备系统分区的内容

以下是/system分区中一些有趣的文件和文件夹，对取证调查员很有兴趣。

build.prop

该文件包含了给定设备的所有构建属性和设置。对于取证分析师来说，该文件提供了有关设备型号、制造商、Android 版本以及许多其他细节的概述。可以通过发出cat命令来查看此文件的内容，如下面的屏幕截图所示：

build.prop 文件输出

如前面的输出所示，您可以通过查看此文件内容来找出产品型号、CPU 详细信息和安卓版本。在已 root 的设备上，调整build.prop文件可能会导致多个系统设置的更改。

应用程序

此文件夹包含系统应用程序和预安装的应用程序。这被挂载为只读，以防止任何更改。以下屏幕截图显示了此文件夹中存在的各种与系统相关的应用程序：

/system/app 分区下的系统应用程序

除了 APK 文件，您可能还注意到了前面输出中的.odex文件。在安卓中，应用程序以.apk扩展名的包形式存在。这些 APK 包含.odex文件，其假定的功能是节省空间。.odex文件是应用程序的某些部分在引导前进行优化的集合。

框架

此文件夹包含 Android 框架的源代码。在此分区中，您可以找到关键服务的实现，例如具有包和活动管理器的系统服务器。还在这里完成了 Java 应用程序 API 和本地库之间的大部分映射。

ueventd.goldfish.rc 和 ueventd.rc

这些文件包含了/dev目录的配置规则。

总之，这是来自wiki.robotz.com/index.php/Android_File_System的 Android 文件树参考的屏幕截图：

安卓文件树

设备上的应用程序数据存储

安卓设备通过应用程序存储了大量敏感数据。尽管我们之前将应用程序分类为系统和用户安装的应用程序，但这里有一个更详细的划分：

• 随安卓一起提供的应用程序

• 由制造商安装的应用程序

• 由无线运营商安装的应用程序

• 用户安装的应用程序

所有这些在设备上存储了不同类型的数据。应用程序数据通常包含了与调查相关的大量信息。以下是可能在安卓设备上找到的数据的样本列表：

• 短信

• MMS

• 聊天消息

• 备份

• 电子邮件

• 通话记录

• 联系人

• 图片

• 视频

• 浏览器历史

• GPS 数据

• 下载的文件或文档

• 属于已安装应用程序的数据（Facebook、Twitter 和其他社交媒体应用程序）

• 日历约会

属于不同应用程序的数据可以存储在内部或外部。在外部存储（SD 卡）的情况下，数据可以存储在任何位置。但是，在内部存储的情况下，位置是预定义的。具体来说，设备上所有应用程序（无论是系统应用程序还是用户安装的应用程序）的内部数据都会自动保存在/data/data子目录中，以包名称命名。例如，默认的安卓电子邮件应用程序的包名为com.android.email，内部数据存储在/data/data/com.android.email中。我们将在接下来的部分详细讨论这一点，但现在，这些知识足以理解以下细节。

安卓为开发人员提供了一些选项来将数据存储到设备上。可以使用的选项取决于要存储的基础数据。属于应用程序的数据可以存储在以下位置之一：

• 共享首选项

• 内部存储

• 外部存储

• SQLite 数据库

• 网络

以下各节提供了关于每个选项的清晰解释。

共享首选项

此位置提供了一个框架，用于以.xml格式存储原始数据类型的键值对。原始数据类型包括布尔值、浮点数、整数、长整数和字符串。字符串以通用字符集转换格式-8（UTF-8）格式存储。这些文件通常存储在应用程序的/data/data/<package_name>/shared_prefs路径中。例如，安卓电子邮件应用程序的shared_prefs文件夹包含少于六个.xml文件，如下屏幕截图所示：

Android 电子邮件应用的shared_prefs文件夹的内容

如第二章中所述，可以使用cat命令查看这些文件的内容。以下截图显示了com.android.email_preferences.xml文件的内容：

Android 电子邮件应用的共享偏好设置文件内容

如前面的截图所示，数据存储在名称-值对中。也许在前面的.xml文件中，account_name、account_password、recent_messages是取证调查中一些有趣的参数。许多应用程序使用共享偏好设置来存储敏感数据，因为它很轻量级。因此，在取证调查中，它们可以成为信息的关键来源。

内部存储

这些文件存储在内部存储中。这些文件通常位于应用程序的/data/data子目录中。存储在这里的数据是私有的，其他应用程序无法访问。甚至设备所有者也无法查看这些文件（除非他们具有 root 访问权限）。但是，根据需求，开发人员可以允许其他进程修改和更新这些文件。

以下截图显示了存储在/data/data目录中的应用程序及其包名称的详细信息：

Android 中/data/data文件夹的内容

每个应用程序的内部数据都存储在它们各自的文件夹中。例如，以下截图显示了 Android 设备上 Twitter 应用程序的内部存储：

Android Twitter 应用的内部存储

通常，大多数应用程序都会创建databases、lib、shared_pref、cache文件夹。以下表格提供了这些文件夹的简要描述：

子目录	描述
shared_prefs	共享偏好设置的 XML 文件
lib	应用程序所需的自定义库文件
files	开发人员保存的文件
cache	应用程序缓存的文件
databases	SQLite 和日志文件

除了这些文件夹之外，还有一些是应用程序开发人员创建的自定义文件夹。databases文件夹包含了在取证调查中有帮助的关键数据。如下截图所示，该文件夹中的数据存储在 SQLite 文件中：

Android 浏览器应用的 databases 文件夹中存在的 SQLite 文件

可以使用 SQLite Browser 等工具查看这些数据。有关如何提取数据的更多详细信息在第四章中有详细介绍，从 Android 设备逻辑提取数据。

外部存储

应用程序还可以将文件存储在外部存储中。外部存储可以是可移动介质，如 SD 卡，也可以是手机自带的不可移动存储。对于可移动 SD 卡，只需将 SD 卡取出并插入到其他设备中，数据就可以在其他设备上使用。SD 卡通常采用 FAT32 文件系统格式，但越来越多地使用其他文件系统，如 EXT3 和 EXT4。与内部存储不同，外部存储没有严格的安全执行。换句话说，存储在这里的数据是公开的，其他应用程序可以访问，前提是请求的应用程序具有必要的权限。

例如，前面讨论的 Twitter 应用程序还在 SD 卡的/Android/data位置存储了某些文件。应用程序加载的大文件，如图像和视频，通常存储在外部存储中，以便更快地检索。

SQLite 数据库

SQLite 是许多移动系统中常见的流行数据库格式，用于结构化数据存储。SQLite 是开源的，与许多其他数据库不同，它体积小且功能丰富。Android 通过专用 API 支持 SQLite，因此开发人员可以利用它。SQLite 数据库是取证数据的丰富来源。应用程序使用的 SQLite 文件通常存储在/data/data/<ApplicationPackageName>/databases目录下。例如，在 Android 电子邮件应用程序的情况下，以下截图显示了其databases文件夹中存在的 SQLite 文件。我们将在接下来的部分更详细地检查这些文件。从取证的角度来看，它们非常有价值，因为它们经常存储应用程序处理的许多重要数据。databases文件夹的内容如下截图所示：

Android 电子邮件应用程序的数据库文件夹

网络

您可以使用网络来存储和检索您自己的基于 Web 的服务上的数据。要进行网络操作，可以使用java.net.*和android.net.*包中的类。这些包为开发人员提供了与网络、Web 服务器等交互所必需的低级 API。

Android 文件系统概述

在 Android 取证中，了解文件系统非常重要，因为它帮助我们了解数据的存储和检索方式。对文件系统属性和结构的了解在取证分析过程中将会很有用。文件系统是指数据从卷中存储、组织和检索的方式。基本安装可能基于一个分成多个分区的卷；在这里，每个分区可以由不同的文件系统管理。微软 Windows 用户大多熟悉 FAT32 或 NTFS 文件系统，而 Linux 用户更熟悉 EXT2 或 EXT4 文件系统。就像在 Linux 中一样，Android 也使用挂载点而不是驱动器（如C:或E:）。每个文件系统定义了自己的规则来管理卷上的文件。根据这些规则，每个文件系统提供了不同的文件检索速度、安全性、大小等。Linux 使用多个文件系统，Android 也是如此。从取证的角度来看，了解 Android 使用的文件系统，并识别对调查具有重要意义的文件系统是很重要的。例如，存储用户数据的文件系统对我们来说是首要关注的，而不是用于引导设备的文件系统。

如前所述，Linux 被认为支持大量的文件系统。系统使用的这些文件系统不是通过驱动器名称访问的，而是合并成一个单一的分层树结构，将这些文件系统表示为一个实体。每当挂载新的文件系统时，它就被添加到这个单一的文件系统树中。

注意

在 Linux 中，挂载是将附加文件系统连接到计算机当前可访问的文件系统的行为。

因此，文件系统被挂载到一个目录上，而此文件系统中的文件现在是该目录的内容。这个目录被称为挂载点。无论文件系统存在于本地设备还是远程设备上都没有区别。一切都集成到以根目录开始的单一文件层次结构中。每个文件系统都有一个单独的内核模块，该模块使用虚拟文件系统（VFS）注册它支持的操作。VFS 允许不同的应用以统一的方式访问不同的文件系统。通过将实现与抽象分离，添加新的文件系统变成了编写另一个内核模块的事情。这些模块要么是内核的一部分，要么是按需动态加载的。Android 内核带有一系列文件系统的子集，从日志文件系统（JFS）到 Amiga 文件系统。当文件系统被挂载时，内核会处理所有后台工作。

注意

上述信息引用自trikandroid.hol.es/page/100/。

在 Android 设备上查看文件系统

通过检查proc文件夹中存在的filesystems文件的内容，可以确定 Android 内核支持的文件系统。可以使用以下命令查看此文件的内容：

shell@Android:/ $ cat /proc/filesystems
cat /proc/filesystems
nodev sysfs
nodev rootfs
nodev bdev
nodev proc
nodev cgroup
nodev tmpfs
nodev binfmt_misc
nodev debugfs
nodev sockfs
nodev usbfs
nodev pipefs
nodev anon_inodefs
nodev devpts
ext2
ext3
ext4
nodev ramfs
vfat
msdos
nodev ecryptfs
nodev fuse
fuseblk
nodev fusectl
exfat

在前面的输出中，由nodev属性引导的文件系统未挂载到设备上。

常见的 Android 文件系统

Android 中存在的文件系统可以分为三个主要类别，如下所示：

• 闪存文件系统

• 基于媒体的文件系统

• 伪文件系统

闪存文件系统

闪存存储器是一种可以按块擦除和重新编程的不断供电的非易失性存储器。由于闪存存储器的特殊特性，需要特殊的文件系统来覆盖介质并处理某些块的长擦除时间。虽然不同的 Android 设备支持的文件系统各不相同，但常见的闪存文件系统如下：

• 扩展文件分配表（exFAT）：这种文件系统是微软专有的，针对闪存驱动器进行了优化。由于许可要求，它不是标准 Linux 内核的一部分。然而，一些制造商提供对这种文件系统的支持。

• 闪存友好文件系统（F2FS）：这种文件系统是三星推出的开源文件系统。基本意图是构建一个考虑基于 NAND 闪存的存储设备特性的文件系统。

• 日志闪存文件系统版本 2（JFFS2）：这种文件系统是 Android 中使用的一种日志结构文件系统。JFFS2 是Android 开源项目（AOSP）自冰淇淋三明治版本以来的默认闪存文件系统。诸如 LogFS、UBIFS、YAFFS 等文件系统已经被开发作为 JFFS2 的替代品。

• 另一个闪存文件系统版本 2（YAFFS2）：这种文件系统是一个开源的、单线程的文件系统，于 2002 年发布。它主要设计用于在处理 NAND 闪存时快速。YAFFS2 利用 OOB。这在取证获取过程中通常无法正确捕获或解码，使分析变得困难。YAFFS2 曾经是最受欢迎的版本，并且仍然广泛用于 Android 设备。YAFFS2 是一个日志结构文件系统。即使在突然断电的情况下也能保证数据完整性。2010 年，有一项声明称在 Gingerbread 之后的版本中，设备将从 YAFFS2 转移到 EXT4。目前，YAFFS2 在较新的内核版本中不受支持，但某些手机制造商可能仍然继续支持它。

• RFS（鲁棒文件系统）：这种类型的文件系统支持三星设备上的 NAND 闪存。RFS 可以总结为启用了事务日志的 FAT16（或 FAT32）文件系统。许多用户抱怨三星应该坚持使用 EXT4。RFS 已知会导致 Android 功能减慢的延迟时间。

基于媒体的文件系统

除了之前讨论的闪存文件系统，Android 设备通常支持以下基于媒体的文件系统：

• 扩展文件系统（EXT2/EXT3/EXT4）：这个文件系统是 1992 年专门为 Linux 内核引入的。这是最早的文件系统之一，使用了虚拟文件系统。EXT2、EXT3 和 EXT4 是后续的版本。日志记录是 EXT3 相对于 EXT2 的主要优势。使用 EXT3 时，在意外关机的情况下，无需验证文件系统。第四个扩展文件系统 EXT4 在实现双核处理器的移动设备中变得重要。YAFFS2 文件系统在双核系统上存在瓶颈。在 Android 的 Gingerbread 版本中，YAFFS 文件系统被替换为 EXT4。

• FAT（文件分配表）：这些文件系统，如 FAT12、FAT16 和 FAT32，都受到 MSDOS 驱动程序的支持。

• VFAT（虚拟文件分配表）：这个文件系统是 FAT16 和 FAT32 文件系统的扩展。大多数 Android 设备支持微软的 FAT32 文件系统。它被几乎所有主要操作系统支持，包括 Windows、Linux 和 Mac OS。这使得这些系统可以轻松地读取、修改和删除 Android 设备上 FAT32 部分的文件。大多数外部 SD 卡都是使用 FAT32 文件系统格式化的。

伪文件系统

除此之外，还有一些伪文件系统，可以被视为文件的逻辑分组。以下是在 Android 设备中发现的一些重要的伪文件系统：

• cgroup（控制组）：这种伪文件系统提供了一种访问和定义多个内核参数的方式。存在许多不同的进程控制组。如下命令行输出所示，可以在/proc/cgroups文件中看到组的列表：

cgroups 文件输出

Android 设备使用这种文件系统来跟踪它们的任务。它们负责聚合任务并跟踪它们。

• rootfs：这种类型的文件系统是 Android 的主要组成部分之一，包含了启动设备所需的所有信息。当设备启动引导过程时，它需要访问许多核心文件，因此会挂载根文件系统。这个文件系统被挂载在/（根目录）下。因此，这是所有其他文件系统逐渐挂载的文件系统。如果这个文件系统损坏，设备将无法启动。

• procfs：这种类型的文件系统包含有关内核数据结构、进程和其他系统相关信息的信息，存储在/proc目录中。例如，/proc/filesystems文件显示设备上可用文件系统的列表。以下命令显示了设备 CPU 的所有信息：

shell@Android:/ $ cat /proc/cpuinfo
cat /proc/cpuinfo
Processor : ARMv7 Processor rev 0 (v7l)
processor : 0
BogoMIPS : 1592.52
processor : 3
BogoMIPS : 2786.91
Features : swp half thumb fastmult vfp edsp neon vfpv3 tls
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x3
CPU part : 0xc09
CPU revision : 0
Chip revision : 0011
Hardware : SMDK4x12
Revision : 000c
Serial : ****************

• sysfs：这种类型的文件系统挂载了包含设备配置信息的/sys文件夹。以下输出显示了 Android 设备中sys目录中的各种文件夹：

shell@Android:/ $ cd /sys
cd /sys
shell@Android:/sys $ ls
ls
block
bus
class
dev
devices
firmware
fs
kernel
module
power

由于这些文件夹中的数据大多与配置相关，这对于法医调查人员通常并不重要。然而，在某些情况下，我们可能需要检查手机上是否启用了特定设置。在这种情况下，分析这个文件夹可能是有用的。请注意，每个文件夹都包含大量文件。通过法医获取捕获这些数据是确保在检查过程中不会更改这些数据的最佳方法。

• tmpfs：这种类型的文件系统是设备上的临时存储设施，它将文件存储在 RAM（易失性内存）中。这通常挂载在/dev目录上。使用 RAM 的主要优势是其更快的访问和检索。然而，一旦设备重新启动或关闭，这些数据将不再可访问。因此，对于法医调查人员来说，重要的是在设备重新启动之前检查 RAM 中的数据或提取数据。

您可以使用mount命令来查看设备上可用的不同分区及其文件系统，如下所示：

shell@Android:/sdcard $ mount
mount
rootfs / rootfs rw 0 0
tmpfs /dev tmpfs rw,nosuid,relatime,mode=755 0 0
devpts /dev/pts devpts rw,relatime,mode=600,ptmxmode=000 0 0
proc /proc proc rw,relatime 0 0
sysfs /sys sysfs rw,relatime 0 0
tmpfs /mnt/asec tmpfs rw,relatime,mode=755,gid=1000 0 0
tmpfs /mnt/obb tmpfs rw,relatime,mode=755,gid=1000 0 0
/dev/block/nandd /system ext4 rw,nodev,noatime,user_xattr,barrier=0,data=ordered 0 0
/dev/block/nande /data ext4 rw,nosuid,nodev,noatime,user_xattr,barrier=0,journal_checksum,data=or dered,noauto_da_alloc 0 0
/dev/block/nandh /cache ext4 rw,nosuid,nodev,noatime,user_xattr,barrier=0,journal_checksum,data=or dered,noauto_da_alloc 0 0
/dev/block/vold/93:64 /mnt/sdcard vfat rw,dirsync,nosuid,nodev,noexec,relatime,uid=1000,gid=1015,fmask=0702, dmask=0702,allow_utime=0020,codepage=cp437,iocharset=ascii,shortname= mixed,utf8,errors=remount-ro 0 0
/dev/block/vold/93:64 /mnt/secure/asec vfat rw,dirsync,nosuid,nodev,noexec,relatime,uid=1000,gid=1015,fmask=0702, dmask=0702,allow_utime=0020,codepage=cp437,iocharset=ascii,shortname= mixed,utf8,errors=remount-ro 0 0
tmpfs /mnt/sdcard/.Android_secure tmpfs ro,relatime,size=0k,mode=000 0 0
/dev/block/dm-0 /mnt/asec/com.kiloo.subwaysurf-1 vfat ro,dirsync,nosuid,nodev,relatime,uid=1000,fmask=0222,dmask=0222,codep age=cp437,iocharset=ascii, shortname=mixed,utf8,errors=remount-ro 0 0

正如前面的命令行输出所示，不同的分区有不同的文件系统，并且它们被相应地挂载。

总结

对安卓的分区布局、文件系统和重要位置有充分的了解，将有助于法医调查人员在从设备中提取数据的过程中。安卓设备上的用户数据位置包含了大量对任何法医调查至关重要的用户信息。然而，大多数这些文件可能只能在已获取 root 权限的手机上访问（特别是/data/data位置的文件）。您还了解了安卓的数据存储选项、安卓使用的各种文件系统及其重要性。

有了这些知识，您现在将学习如何在接下来的章节中从安卓设备中逻辑和物理地提取数据。

第四章：从安卓设备逻辑提取数据

本章将尽可能使用免费和开源工具来覆盖逻辑数据提取。本章大部分内容将使用之前在第二章中讨论过的 ADB 方法。

在本章结束时，读者应该熟悉以下内容：

• 逻辑提取的含义

• 逻辑提取可以期望得到的数据

• 有和没有 Root 权限时可用的数据

• 手动 ADB 数据提取

• ADB 备份提取

• ADB dumpsys 信息

• 如何绕过安卓锁屏

• SIM 卡提取

逻辑提取概述

在数字取证中，逻辑提取一词通常用于指不恢复已删除数据的提取，或者不包括证据的完整比特对比拷贝。然而，在第一章中定义的更正确的逻辑提取的定义是任何需要与基本操作系统通信的方法。由于与操作系统的交互，取证员无法确定他们已经恢复了所有可能的数据；操作系统正在选择允许取证员访问哪些数据。

在传统计算机取证中，逻辑提取类似于复制和粘贴文件夹以从系统中提取数据；这个过程只会复制用户可以访问和看到的文件。如果被复制的文件夹中存在任何隐藏或已删除的文件，它们将不会出现在粘贴版本的文件夹中。

然而，移动取证中逻辑提取和物理提取之间的界限要比传统计算机取证模糊得多。例如，由于 SQLite 数据库的普遍使用，可以经常从移动设备的逻辑提取中恢复已删除的数据。此外，几乎每次移动设备的提取都需要与安卓操作系统进行某种形式的交互；没有简单的等同于拔出硬盘并在不启动硬盘的情况下对其进行成像的操作。对于我们的目的，我们将逻辑提取定义为获取用户可见的数据的过程，并且可能包括已标记为删除的数据。

哪些数据可以逻辑恢复？

在大多数情况下，任何和所有用户数据都可以通过逻辑方式恢复：

• 联系人

• 通话记录

• 短信/彩信

• 应用程序数据

• 系统日志和信息

这些数据的大部分存储在 SQLite 数据库中，因此甚至可以通过逻辑提取恢复大量已删除的数据。

Root 权限

在法庭上分析安卓设备时，限制因素通常不是所寻找的数据类型，而是检查员是否有能力访问数据。在第二章中已经广泛涵盖了 Root 访问权限，但这一点很重要，值得重复。上述所有存储在内部闪存存储器上的数据都是受保护的，需要 Root 访问权限才能读取。例外情况是存储在 SD 卡上的应用程序数据，这将在本书后面讨论。

没有 root 权限，法医检查员无法简单地从数据分区复制信息。检查员将不得不找到某种方法来提升他们的权限，以便访问联系人、通话记录、短信/彩信和应用程序数据。这些方法通常带有许多风险，例如可能破坏或“砖化”设备（使其无法启动），并且可能会改变设备上的数据以获得永久性。这些方法通常因设备而异，并且没有通用的、一键式的方法可以获得对每个设备的 root 权限。商业移动法医工具，如MicroSystemation XRY和Cellebrite UFED，具有内置功能，可以临时和安全地 root 许多设备，但不涵盖所有 Android 设备的广泛范围。

在本章中，我们将注意到每种技术所需的 root 权限。

注意

是否对设备进行 root 处理应根据您所在地区的操作程序和法院意见做出决定。通过 root 获取的证据的法律接受程度因司法管辖区而异。

手动 ADB 数据提取

ADB 的pull命令可用于直接从设备上将单个文件或整个目录拉到法医检查员的计算机上。这种方法对于小型、有针对性的检查特别有用。例如，在严格涉及短信的调查中，检查员可以选择只拉取相关文件。

USB 调试

ADB 环境的设置在本书中已经讨论过。然而，受检设备也必须正确配置。USB 调试是法医检查员的计算机与设备通信的实际方法。USB 调试选项位于设置菜单中的开发者选项下。然而，从 Android 4.2 开始，开发者选项菜单是隐藏的；要显示它，用户必须转到设置 | 关于手机，然后点击版本号字段七次。屏幕上会出现一个对话框，上面写着您现在是开发者！此时，开发者选项在设置菜单中可用；只需打开此菜单并选择启用 USB 调试。

除了 USB 调试，检查员的计算机上还必须安装正确的驱动程序。通常可以在制造商的网站上或www.xda-developers.com上找到。如果在计算机上安装了商业法医工具，则可能已经安装了适当的驱动程序。

提示

另一个很好的资源是可以免费下载的通用 ADB 驱动程序，网址为drivers.softpedia.com/get/MOBILES/Clockworkmod/Clockworkmod-Universal-Android-ADB-Driver.shtml。

在 Android 4.2.2 之前，启用USB 调试是与设备通过 ADB 通信的唯一要求。在 Android 4.2.2 中，Google 添加了安全 USB 调试选项。安全 USB 调试选项增加了在设备屏幕上选择连接到计算机的额外要求；这可以防止来自不受信任计算机的 ADB 访问被锁定的设备：

RSA 指纹对话框

如果选择了始终允许此计算机，设备将存储计算机的 RSA 密钥，并且在将来连接到该计算机时，提示将不会出现，即使设备被锁定。

提示

根据设备和操作系统版本的不同，可能可以规避安全 USB 调试保护。在labs.mwrinfosecurity.com/advisories/2014/07/03/android-4-4-2-secure-usb-debugging-bypass/上找到更多信息。

还可以通过使用先前获得授权访问设备的计算机来绕过安全 USB 调试，这将在本章后面的 Android Lollipop 部分中讨论。

一旦USB 调试已启用并且安全 USB 调试检查通过（取决于 Android 版本），设备就准备好进行检查了。要验证设备是否已连接并准备使用 ADB，执行以下命令：

adb devices

如果没有显示任何设备，请确保USB 调试已启用，并且已安装正确的设备驱动程序：

如果设备状态为离线或未授权，则需要在屏幕上选择安全 USB 调试提示：

如果一切正常运行，设备状态应显示为设备：

使用 ADB shell 来确定设备是否已 root

确定设备是否已 root 的最简单方法是使用 ADB shell。这将在设备上打开一个 shell，取证人员可以在自己的计算机上访问该 shell；这意味着在 shell 中运行的任何命令都将在设备上执行。一旦USB 调试已启用并且安全 USB 调试已绕过（或者从恢复模式中，如本章后面讨论的），在本地计算机上打开终端并运行：

adb shell

shell 将以$或#的方式出现：

在 Linux 系统中，#符号用于表示根用户，$符号表示非根用户。如果 shell 返回显示#，则 shell 具有根访问权限：

在一些已 root 的设备上可能需要进一步的步骤。如果 shell 返回$，尝试运行su命令：

su

如果设备上安装了 su 二进制文件，通常是 root 过程的一部分，这将提升 shell 的权限到 root，如果 shell 没有以 root 权限打开的话。

提示

一些旧设备会自动以 root 身份运行 shell；仅仅打开 ADB shell 可能就足以给取证人员 root 访问权限。

ADB pull

如第二章设置 Android 取证环境中讨论的，ADB pull命令用于将文件从设备传输到本地工作站。ADB pull命令的格式为：

adb pull [-p] [-a] <remote> [<local>]

可选的-p标志显示传输的进度，而可选的-a标志将复制文件的时间戳和模式。<remote>参数是设备上文件的确切路径。可选的<local>参数是文件将被写入到取证人员计算机上的路径。如果没有指定本地路径，文件将被写入到当前工作目录。要查看 ADB pull命令的样子，运行以下命令：

adb pull –p /data/data/com.android.providers.telephony/databases/mmssms.db C:/Users/Cases/Case_0001

此命令将从设备中拉取短信数据库文件，并将其写入到案例的目录中。再次注意，设备必须已 root 才能正常工作；否则，输出将只显示拉取了0个文件。在我们的案例中，获得以下输出：

前面的输出显示文件大小为1020400字节。由于我们的命令，mmssms.db数据库现在位于Case_0001文件夹中：

从设备中拉取的数据库，在 Windows 资源管理器中可见

现在可以使用 SQL 浏览器或其他取证工具来检查数据库，这将在第七章Android 应用程序的取证分析中进行讨论。

同样，如果调查人员希望为整个应用程序拉取文件，也可以使用 ADB pull：

这一次，ADB pull 命令获取了com.google.android.gm目录中的每个文件，这恰好包含了 Gmail 的所有数据。输出非常长，因为它逐个列出了所有31个拉取的文件，所以整个输出在下图中没有显示，我们可以看到传输的总大小显示为1233373字节：

现在，Case_0002目录包含了 Gmail 应用程序的所有文件，如下截图所示：

在 Windows 资源管理器中看到的从 Gmail 目录中拉取的所有文件

甚至可以做到以下事情：

adb pull -p /data/data/ \Cases\Case_0003

这将从/data/data目录中拉取所有可用的逻辑文件，并将它们放在检查员的Case_0003文件夹中。这并不等同于物理镜像，因为某些文件会被跳过，已删除的文件不会被复制，但这是拉取用户应用程序数据绝大部分的简单方法。

ADB pull命令的另一个优点是它非常适用于脚本目的。一个知识渊博的检查员可以维护一个常见感兴趣文件路径的列表，并编写一个自动从设备中拉取这些文件的脚本，甚至可以让脚本自动拉取整个/data/data目录。一个执行此功能的 Python 代码的简单示例是：

from subprocess import Popen
from os import getcwd

command = "adb pull /data/data " + getcwd() + "\data_from_device"
p = Popen(command)
p.communicate()

请注意，代码并不是非常精练；它的唯一目的是说明 ADB 命令可以被脚本化的简易性。至少，正确实现代码应该包括指定输出目录的选项并处理任何错误。然而，前述代码的六行足以逻辑上拉取整个/data/data目录，假设USB 调试已启用并且设备已 root。

恢复模式

为了真正具有法庭取证的可靠性，不应在手机开机时使用 ADB 数据提取。当设备正在运行时，时间戳可能会被修改，应用程序可能在后台运行并更新文件。为了避免这种情况，检查员应该将设备置于自定义恢复模式中，如第二章中所示，设置 Android 取证环境，如果可能的话。通过原始 Android 恢复模式无法访问 ADB。通常，rooting 过程的第一步是刷入自定义恢复模式，以便在出现问题时修复设备。已 root 的设备更有可能包含自定义恢复模式，但是也有可能将自定义恢复模式刷入未 root 的设备。这种方法还允许检查员避免在较新版本的 Android 上出现的安全 USB 调试提示，尽管我们的测试显示这在 Android Lollipop 上不起作用。恢复模式也可能不需要启用USB 调试，这使其成为绕过锁定设备的绝佳选择。

注意

这种方法不适用于启用了全盘加密的设备。进入恢复模式将不解密数据分区。

进入恢复模式的过程对于每个设备都会有所不同。通常情况下，它涉及一些关机并按住音量和电源键的组合。特定型号的指南可以在线找到。

原始恢复模式通常会显示一个正在操作的 Android 的图片：

原始恢复模式

自定义恢复模式看起来像以下的截图。此外，原始恢复模式将不允许 ADB 通信；运行 adb devices 将只显示没有设备。

注意

许多设备的自定义恢复镜像可以在www.clockworkmod.com/rommanager和teamw.in/project/twrp2找到。

如果设备处于自定义恢复模式，并且在审查员的计算机上安装了正确的驱动程序，则可以通过 ADB 访问设备，就像它是活动的一样。请注意，使用 adb devices 命令现在显示它处于恢复模式：

在审查员可以开始通过 ADB 提取数据之前，还有最后一步：必须挂载数据分区以访问用户数据。一些自定义恢复可能会自动挂载这个分区，而其他可能不会。如果使用上面的 URL 中的 Clockwork Mod Recovery 或 Team Win Recovery Project（TWRP）映像，可以通过选择 Mounts 然后选择数据分区来挂载数据分区，如下面的屏幕截图所示。恢复菜单通常可以使用音量键上下移动和电源按钮选择，或者根据使用的自定义恢复映像而可能是基于触摸的。

对于 TWRP 恢复，从主恢复屏幕中选择Mount：

选择Mount后，选择要挂载的分区：

在 Clockwork Mod Recovery 中，选择 mounts and storage：

然后选择要挂载的分区：

一旦数据分区（以及审查员想要调查的任何其他分区）被挂载，审查员就可以执行 ADB 数据提取，就像本章前面演示的那样。

如果设备没有自定义恢复，下一节将显示如何启动到自定义恢复。

快速启动模式

Fastboot 是 Android SDK 中内置的另一个协议实用程序，用于直接与设备的引导加载程序进行交互。基本上，它是 ADB 的一个更低级别版本，并且经常用于向设备刷入新映像。这对审查员有什么帮助呢？

Fastboot 可以允许审查员从自定义恢复映像启动，并临时获得设备的 root 访问权限，从而访问以其他方式无法访问的数据。Fastboot 不需要启用 USB 调试或 root 访问权限。将自定义引导加载程序加载到设备上通常由商业取证工具使用，以临时获取设备的 root 权限，但是熟练的审查员也可以手动执行该过程。使用此方法，恢复映像加载到 RAM 中；设备上的任何永久数据都不会以任何方式被更改。

使用 fastboot 最重要的要求是解锁引导加载程序；锁定的引导加载程序将不允许设备从制造商专门签名的代码启动。不幸的是，出于取证目的，大多数设备不再出厂时带有解锁的引导加载程序，因为这是一个严重的安全风险，并且手动解锁引导加载程序通常会擦除用户数据。因此，这种方法适用的设备数量有些有限。但是，当它起作用时，对于审查员来说，这是一个绝对无价的工具。

注意

此方法不适用于启用了全盘加密的设备。进入恢复模式将不解密数据分区。

确定引导加载程序状态

与涉及 Android 取证的所有内容一样，确定引导加载程序是否已锁定没有一种保证的方法，因为这取决于制造商。要进入引导加载程序，请使用以下 ADB 命令：

adb reboot bootloader

设备应该启动到显示有关引导加载程序的信息的屏幕。通常，此屏幕将显示引导加载程序状态，如下面的屏幕截图所示。

以下是 Nexus 5 的通用、原始快速启动菜单。请注意，Lock State指示引导加载程序已解锁：

标准的 HTC 快速启动屏幕如下：

以下是标准的三星Odin模式屏幕；Odin 是三星专有的等效快速启动：

引导到自定义恢复映像

确定引导加载程序已解锁后，检查员将需要一个自定义恢复映像来引导。恢复映像的绝佳来源是www.clockworkmod.com/rommanager或teamw.in/twrp_view_all_devices。这两个网站都提供各种设备的覆盖，并且将为此方法提供相同的功能。

注意

对于正在检查的设备，选择正确的恢复映像绝对至关重要；它们不能互换，从错误的映像引导可能会砖化设备。

选择并下载恢复映像后，需要将设备放入快速启动模式。可以通过以下两种方式之一完成：

• ADB

• 物理设备按钮

要通过 ADB 进入快速启动设备，设备必须已启用USB 调试。通过 ADB 进入快速启动模式的命令是：

adb reboot bootloader

如果无法启用 USB 调试或无法使用 ADB，通常还有一组按钮组合可在设备启动时按下，类似于进入恢复模式。可以在线找到每个设备特定的确切组合。

设备进入快速启动模式后，运行以下命令将验证设备是否已连接并准备好通信：

fastboot devices

以下命令将加载自定义恢复映像到 RAM 并将设备引导到恢复模式：

fastboot boot 'path to image'

设备现在应该重新启动并进入恢复模式。如恢复模式部分所示，可能需要挂载/data 分区以访问用户数据。

进入 ADB shell 将显示检查员现在具有根访问权限。设备将允许根访问权限，直到重新启动。

如果快速启动引导命令失败，则很可能表明设备的引导加载程序已锁定，如下面的屏幕截图所示：

ADB 备份提取

Google 在 Android 4.0 冰淇淋三明治中实现了 ADB 备份功能。这允许用户（和取证检查员）通过 ADB 将应用程序数据备份到本地计算机。此过程不需要根权限，因此对于取证目的非常有用。但是，它不会获取设备上安装的每个应用程序。当开发人员创建新应用程序时，默认情况下将其设置为允许备份，但开发人员可以更改此设置。实际上，似乎绝大多数开发人员保留默认设置，这意味着备份可以捕获大多数第三方应用程序。不幸的是，大多数 Google 应用程序禁用备份；来自应用程序（如 Gmail 和 Google Maps）的完整应用程序数据将不包括在内。

提示

此方法对于锁定的设备将无效，因为需要用户与屏幕进行交互。

通过 ADB 提取备份

ADB 备份命令的格式是：

adb backup [-f <file>] [-apk|-noapk] [-obb|-noobb] [-shared|-noshared] [-all] [-system|-nosystem] [<packages...>]

以下是标志：

• -f：为输出文件命名路径。如果未指定，默认为当前工作目录中的backup.ab。

• [-apk|noapk]：选择是否备份.apk文件。默认为-noapk。

• [-obb|-noobb]：选择是否备份.obb（APK 扩展）文件。默认为-noobb。

• [-shared|-noshared]：选择是否备份共享存储和 SD 卡中的数据。默认为-noshared。

• [-all]：包括启用备份的所有应用程序。

• [-system|-nosystem]：选择是否包括系统应用程序。默认为-system。

• [<packages>]：显式命名要备份的应用程序包。如果使用-all或-shared，则不需要。

捕获所有可能的应用程序数据的示例 ADB 备份命令如下：

adb backup –f C:/Users/Cases/Case_0001/backup.ab –shared –all

或者，捕获特定应用程序数据的示例 ADB 备份命令如下：

adb backup –f C:/Users/Cases/Case_0001/facebook.ab com.facebook.katana

您应该看到类似的东西：

在执行备份时，用户必须在设备上批准备份。这意味着不能绕过屏幕锁定进行备份：

在设备上接受备份

根据安装的应用程序数量，备份过程可能需要相当长的时间。

解析 ADB 备份

生成的备份数据存储为.ab文件，但实际上是使用Deflate算法压缩的.tar文件。如果在创建备份时在设备上输入了密码，文件也将被 AES 加密。还应该提到，这些文件可能存在于嫌疑人的计算机上，并且可以使用相同的方法进行分析。

有许多免费的实用程序可以将.ab备份文件转换为可以查看的.tar文件。其中一个实用程序是 Android 备份提取工具，位于sourceforge.net/projects/adbextractor/。

要使用 Android 备份提取工具，只需将其文件提取到备份所在的目录中。运行该实用程序的命令是：

java -jar abe.jar unpack backup.ab backup.tar

如果命令正确运行，命令行将显示如下内容：

输出的第一行通知审查员文件未加密。如果文件已加密，审查员将不得不在命令行的末尾作为参数传递密码。如输出所示，即使备份仍然被压缩，上一节中创建的备份大约为 4GB。.tar文件将位于命令行指定的路径或当前工作目录（如果未指定路径）。可以在 Linux 命令行上手动解压缩.tar文件，也可以使用许多 Windows 存档实用程序之一，如 WinRAR 或 7Zip：

备份中的目录，在 Windows 资源管理器中查看

ADB 备份中的数据位置

现在备份已转换为.tar文件并进行了提取，审查员可以查看备份中包含的数据。在我们的示例中，在备份的根目录中找到了两个目录：

• apps：此文件夹包含备份中包含的应用程序的/data/data中的数据。

• shared：此文件夹包含 SD 卡中的所有数据，仅在命令行传递了-shared参数时才存在。

请注意，应用程序目录中的文件存储在其包名称的目录中（就像在 ADB shell 内部的/data/data中看到的那样），共享目录正是用户如果将 SD 卡插入计算机中所看到的。

作为从备份中提取的用户数据的良性示例，下面显示了用户的Pandora活动。 Pandora 是一个在 Google Play 商店中有数百万次下载的流媒体音乐服务。 Pandora 的应用程序数据将包含在备份的 apps 文件夹中，文件夹名为com.pandora.android。

从备份中提取的 Pandora 目录

这是一个相当标准的 Android 应用程序布局，如第二章中所讨论的那样，设置 Android 取证环境。应用程序的数据库将在db文件夹中：

Pandora 备份的 db 文件夹中的文件

XML 配置设置将在sp文件夹中：

Pandora 备份的 sp 文件夹中的文件

使用数据库查看器查看pandora.db，可以查看用户创建的站点以及创建时间戳：

从备份中的 pandora.db 的内容

在 XML 首选项文件中，可以在firstInstallId下找到应用程序安装的时间戳。请注意，转换时间戳的确切方法显示在第七章中，Android 应用程序的法医分析中：

XML 首选项文件的内容

如果由于某种奇怪的原因，用户的 Pandora 使用在调查中是一个重要问题，调查员可以从这两个看似无害的文件中得出什么结论？

首先，lastTransmission和firstInstallID时间戳相差毫秒，表明该应用程序安装后从未使用过。此外，每个站点的创建日期在某些情况下早于应用程序的安装日期，有些甚至早于几年。这表明用户在其他设备上使用了 Pandora，这可能与调查高度相关。

虽然 Pandora 通常与数字取证调查无关，但它是通过 ADB 进行简单备份的数据的一个例子。更详细的应用程序分析将在第七章中呈现，Android 应用程序的法医分析。

ADB Dumpsys

Dumpsys是内置在 Android 操作系统中的工具，通常用于开发目的，以显示设备上运行的服务的状态。但是，它也可能包含法医学上有趣的信息。Dumpsys 不需要 root 访问权限，但与所有 ADB 命令一样，它需要设备上启用 USB 调试和绕过安全 USB 调试。

可以查看的确切服务因设备和 Android 版本而异。要查看可以转储的所有可能服务的列表，请运行以下命令：

adb shell service list

命令的输出将显示为列表，如下所示：

冒号前的服务名称是我们将传递给 dumpsys 的参数。使用前面截图中的服务编号七（iphonesubinfo）的有效 dumpsys 命令如下所示：

adb shell dumpsys iphonesubinfo

在下面的截图中，我们看到iphonesubinfo服务的输出包括设备的 IMEI：

有许多法医学上有趣的 dumpsys 服务；以下是一些示例。由于 dumpsys 服务可能因操作系统版本和设备而异，此列表并不包括所有内容，仅旨在展示 dumpsys 对法医检查员的有用性：

• iphonesubinfo

• batterystats

• procstats

• 用户

• appops

• Wi-Fi

• 通知

Dumpsys batterystats

Batterystats 用于显示正在运行的应用程序的使用情况。根据使用的应用程序数量，其输出可能非常冗长。在下面的截图中，输出被重定向到文件，因为它无法适应 Windows 命令行：

这显示了 Google Chrome 的网络使用情况。这些信息可以用来显示该应用程序最近是否被使用，即使 Chrome 在隐身模式下使用并且在其他地方没有留下法医证据，这些信息仍将存在。

注意

唤醒锁部分对于检测恶意软件非常有用。唤醒锁是一种使设备保持唤醒状态（不进入睡眠模式）的方法，表明应用程序试图在后台保持运行。

Dumpsys procstats

procstats是一种显示运行应用程序的处理器使用情况的服务。与 batterystats 类似，它是可以用来显示应用程序最近在设备上使用的另一种方法，如下截图所示：

Dumpsys user

从 Android Jelly Bean 开始，Google 为平板设备添加了多用户支持。随着 Lollipop 的发布，Google 将此支持扩展到手机。长期以来，数字取证中最具挑战性的问题之一是在执行可疑操作时证明谁在使用设备；“谁在键盘后面？”

在用户服务上运行 dumpsys 将显示所有用户的最后登录信息：

由于一次只能有一个用户登录，查看最近登录的用户将确定设备上当前正在使用的帐户。

Dumpsys App Ops

App Ops可能是最有趣的 dumpsys 服务。术语 App Ops 通常用于指代应用程序可以访问的权限。在较早版本的 Android 中，有传言称 Google 将包括用户可以撤消应用程序的特定权限的功能。尽管这从未实现，但这项服务至少仍然存在，并显示了应用程序上次使用每个可以访问的权限的时间。以下是来自 Google Chrome 的另一个示例：

在上面的输出中，我们可以看到大约在 App Ops 使用 dumpsys 之前 1 小时 7 分钟，Chrome 使用了TAKE_AUDIO_FOCUS权限，后来使用了AUDIO_MEDIA_VOLUME。这表明 Chrome 用于听音乐的时间和内容。

一个更有趣的例子是以下的手机应用程序：

44分钟前，用户使用了电话应用程序并需要READ_CONTACTS权限，然后立即使用了WRITE_CALL_LOG权限。我们可以推断用户在44分钟前打了电话；即使他们之后从记录中删除了通话。

Dumpsys Wi-Fi

Wi-Fi服务将显示已保存连接的所有 SSID 的列表。例如，这可能对于显示用户曾经在某个位置非常有用。更详细的 Wi-Fi 信息也可以在文件系统上找到，但需要 root 权限才能查看。使用 dumpsys，我们可以在不需要 root 权限的情况下访问这些数据：

Dumpsys notification

通知服务将提供有关当前活动通知的信息。这对于记录设备被扣押时的状态，或者识别显示特定通知的应用程序非常有用。每个通知可能相当大，并包含大量信息，其中只有一些可能有用。以下示例显示了来自 Gmail 应用程序的一封新邮件，其中包括主题（这是一封测试邮件）和正文（查看测试通知）：

Dumpsys 结论

在没有服务名称的情况下运行 dumpsys 命令将在所有可用的服务上运行 dumpsys。但是，输出将非常庞大，应将其重定向到文本文件中。在大多数平台上，执行此操作的命令将是：

adb shell dumpsys > dumpsys.txt

这将把输出写入到当前工作目录中的 dumpsys.txt 文件中。然后可以搜索输出，或者运行解析脚本来提取已知的相关字段。

Dumpsys 是一个非常强大的工具，可以用来显示设备上无法在其他地方获取的信息。我们建议在扣押 Android 设备时，在关机之前运行 dumpsys。这将保存各种各样的信息，以后可能会有用，并且不需要 root 权限。

绕过 Android 锁屏

锁屏是安卓取证调查中最具挑战性的方面。调查的整个过程经常取决于取证人员获取锁定设备的能力。虽然有绕过锁屏的方法，但这很大程度上取决于操作系统版本、设备设置和取证人员的技术能力。并没有一种可以在每台设备上都有效的神奇解决方案。商业取证工具如 Cellebrite 和 XRY 具有相当强大的绕过能力，但并非万无一失。本章将展示取证人员如何利用免费工具和方法提高绕过锁定设备的成功率。

注意

取证人员不应尝试在设备上猜测图案/PIN/密码。许多制造商实施了一个设置，将在一定次数的失败尝试后擦除设备。许多还允许用户降低这个次数。

锁屏类型

有许多用于保护设备的方法，以及绕过每种方法的方法都有所不同：

• 无/滑动

• 图案

• PIN

• 密码

• 智能锁

• 可信面部

• 可信位置

• 可信设备

可能存在其他安全选项；由于安卓是开源的，可能性只受开发者想象力的限制。这些是谷歌发布的安卓棒棒糖原始版本中提供的选项。大多数供应商使用的安全选项通常将这些原始选项作为备用选项，以防用户无法使用他们独特的选项登录。首次使用该设置的版本也指的是原始安卓；各种制造商可能更早地实施了它们。

无/滑动锁屏

滑动解锁屏幕是大多数安卓设备的默认设置。它提供了零级安全，并且可以通过在屏幕上滑动手指来绕过。

图案锁屏

图案锁屏是标志性的安卓安全方法。经常被称为滑动码和类似的名称，这些要求用户用手指在设备上划出一个图案。这种锁的常见绕过方法是指纹攻击，寻找用户手指在屏幕上留下的图案。

密码/PIN 锁屏

熟悉苹果 iOS 的用户会认识到这个选项。它要求用户输入密码或 PIN 码才能解锁设备。它们被归为一类，因为在取证上它们是相同的：它们以相同的方式存储密码。

智能锁

智能锁是安卓棒棒糖中引入的术语，尽管面部解锁选项以前就已经存在。它们需要特定条件才能解锁设备：用户的脸必须被识别，用户必须在已知位置，或者附近必须有特定的其他设备。

可信面部

面部解锁的工作原理就像它的名字一样：它使用面部识别来确定用户是否已被设置为可信用户。旧版本的面部锁很容易被信任用户的照片欺骗，尽管新版本可能要求用户眨眼才能解锁设备。

可信位置

可信位置在安卓棒棒糖中可用，通常被称为地理围栏。如果用户在被标记为可信的位置（比如家或工作地点）上，设备将不会锁定。用户无需输入，但必须启用 GPS。

可信设备

可信设备在安卓棒棒糖中可用，通过蓝牙工作；如果附近有设置为可信设备的设备，锁屏将被禁用。这可以与智能手表、通过蓝牙配对的车辆、蓝牙耳机或任何其他蓝牙设备一起使用。

注意

所有智能锁选项都需要图案/PIN/密码作为备用安全方法。这意味着我们只需要学会如何绕过图案/PIN/密码才能破解所有的安全选项。

绕过信息

在所有情况下，绕过锁屏将需要从设备中检索文件。图案锁存储为哈希值，位于/data/system/gesture.key，PIN/密码锁存储为哈希值，位于/data/system/password.key。此外，password.key 哈希值是加盐的；盐值存储在 Android 4.4 之前的设备上的/data/data/com.android.providers.settings/databases/settings.db，以及运行 Android 4.4 及更高版本的设备上的/data/system/locksettings.db。

如果设备被锁定，调查员应该如何访问这些文件？同样，并没有一个可以每次都有效的魔法解决方案，但有一些选项，如下所示：

• ADB

• 需要 root 权限

• 需要USB 调试

• 需要安全 USB 调试配对（取决于操作系统版本）

• 引导到自定义恢复模式

• 不需要 root 权限（通过恢复映像将获得 root 权限）

• 无需 USB 调试（通过 fastboot 完成）

• 不需要安全 USB 调试（这完全被绕过）

• 需要解锁的引导加载程序

• JTAG/Chip-off

• 非常先进

• 不需要任何特定的设备设置或选项

需要拉取的文件以破解 Android 4.4 之前的设备上的 PIN/密码为：

• /data/system/password.key

• /data/data/com.android.providers.settings/databases/settings.db

需要拉取的文件以破解运行 Android 4.4 及更高版本设备上的 PIN/密码为：

• /data/system/password.key

• /data/system/locksettings.db

只需要拉取一个文件即可破解所有版本的 Android 上的图案锁：

• /data/system/gesture.key

提示

并不总是需要实际破解 PIN 或密码。它们也可以通过简单地覆盖或删除文件来绕过。然而，这会改变原始证据，可能在您的司法管辖区内并不具备法医学有效性。

请注意，下面的破解部分不适用于棒棒糖设备。图案锁不再是未加盐的，截至撰写时，尚未发布有关如何恢复盐的信息。然而，仍然可以通过删除相关文件来绕过锁屏。

存在许多可以自动绕过锁屏的工具；然而，在本章中，我们将展示手动过程，以解释这些工具在后台的操作。一款适用于执法人员的好工具可以在andriller.com/找到。

破解 Android 图案锁

现在我们有了gesture.key，其中包含图案锁信息，让我们来看看文件内容：

在十六进制编辑器中的 gesture.key 的内容

文件的十六进制内容是滑动图案的未加盐 SHA-1 哈希。由于可能的图案数量有限（因为每个数字只能使用一次，最小为四位数，最大为九位数），破解此哈希的最简单方法是使用字典攻击。调查员可以创建一个包含每种可能图案的字典，但重新发明轮子并不总是必要的。总部位于英国的 CCL Forensics 提供了一个免费的 Python 脚本来创建哈希字典。它可以在www.cclgroupltd.com/product/android-pattern-lock-scripts/下载。

文件是GenerateAndroidGestureRainbowTable.py。要运行它，调查员的系统必须安装 Python 3。Python 3 可以在www.python.org/downloads/下载。许多取证工具提供 Python 支持或自己使用它，因此调查员可能已经安装了它。要执行该文件，只需导航到包含它的目录并运行：

脚本可能需要一段时间才能运行，可能在 20 到 30 分钟之间。完成后，应该会在与GenerateAndroidGestureRainbowTable.py脚本相同的目录中有一个名为AndroidLockScreenRainbow.sqlite的文件。

现在我们有一个包含每个可能的安卓图案哈希的数据库，我们只需要在gesture.key文件中查找我们找到的哈希。这可以通过 SQLite 查看器或者 SQL 命令手动完成。然而，CCL Forensics 还提供了Android_GestureFinder.py，这是一个脚本，将在之前创建的数据库中查找哈希。

不幸的是，这个免费脚本并不完全符合我们的目的。它是用来查看物理转储二进制并找到锁定屏幕图案的；我们已经有包含图案的文件了。为了使脚本正常工作，我们需要修改代码。Android_GestureFinder.py需要在某种代码友好的编辑器中打开；Notepad++、Sublime Text 或 Python IDLE GUI 都可以。以下截图来自 Sublime Text。复制文件，打开原始文件，找到第 85 行，其中写着：

if regex.match(chunk) is not None:

这一行需要被注释掉。只需在行的开头放一个#号：

#if regex.match(chunk) is not None:

由于 Python 的格式，我们现在需要取消注释后面语句的缩进。第 86、89、91 和 92 行需要向左移动，使它们与我们注释掉的语句对齐。最后，第 94 行需要向左移动四个空格，使其与上面的行相齐。最终的代码应该是这样的：

Android_GestureFinder.py 的最终代码

请注意，第 85 行现在以#开头，第 86、89、91 和 92 行与第 85 行对齐，第 94 行向右缩进一个制表符（或者从原来的位置向左移动四个空格）。

现在代码已经准备好运行我们的文件；保存对Android_GestureFinder.py的更改。确保AndroidLockScreenRainbow.sqlite和gesture.key文件与Android_GestureFinder.py在同一个目录中，并运行以下脚本：

输出应该非常快，因为它只是在哈希数据库中进行简单的查找。Offset是负数，因为我们使用脚本对单个文件进行了操作；如果指向一个二进制物理转储，它将显示在 blob 中锁定屏幕哈希的偏移量。Hash列显示找到的哈希值，Pattern是相应的锁定屏幕图案：

锁定屏幕编号

在这个例子中，图案将从左上角的0开始，经过中间的4，触摸右下角的8，然后穿过底部中间的7，最后在左下角的6结束。现在可以在设备上使用这个图案来绕过锁定屏幕。

如果脚本遇到错误，文件很可能没有正确修改。以下结果很可能表明脚本没有正确修改；也许运行的是文件的副本而不是修改后的版本：

要解决这个错误，验证脚本是否按照上面显示的方式进行了修改。以下错误表明缩进不正确：

要解决这个错误，导航到指定的行（在上面的例子中是第 86 行），确保对齐方式与前面修改后的代码一样。

如果错误无法解决，或者修改脚本对于检查员来说太困难，哈希值总是可以在哈希数据库中手动查找。一个优秀的免费 SQL 查看器，DB Browser for SQLite，可以在sourceforge.net/projects/sqlitebrowser/找到。

使用 DB Browser for SQLite 打开 AndroidLockScreenRainbow.sqlite，然后选择浏览数据选项卡。然后，只需将在 gesture.key 中找到的哈希值输入到哈希列的搜索字段中。请注意，数据库中的字符是小写的；搜索字段区分大小写：

在 SQLite 浏览器中的 AndroidLockScreenRainbow.sqlite 文件的内容

结果与运行脚本的结果相同。

破解 Android PIN/密码

要破解 PIN/密码锁，我们需要查看之前提取的文件的内容。Password.key与gesture.key非常相似；它包含密码的哈希值，如下面的截图所示：

在十六进制编辑器中的 password.key 的内容

然而，这次哈希是有盐的。为了有机会破解它，必须恢复盐。如上所述，其位置将取决于设备运行的 Android 版本。如果设备运行的是 4.3 或更低版本，则将位于secure表中的settings.db文件中。在 4.4 或更高版本中，它将位于locksettings表中的locksettings.db中。下面的示例显示了locksettings.db，但该过程对两者都是相同的。

在数据库文件中，我们需要找到lockscreen.password_salt键。这可以在 SQL 浏览器中完成，或者只需在十六进制编辑器中打开文件并搜索。盐值如下所示：

在十六进制编辑器中的 locksettings.db 的内容

对于图案锁，我们能够使用字典攻击来快速破解图案，因为可能性相对较少。使用盐哈希，字典攻击是不可行的，所以我们将简单地进行暴力破解。

CCL Forensics 再次提供了一个有用的 Python 脚本。也可以使用其他破解工具，如 hashcat。CCL Forensics PIN/密码工具可以免费下载www.cclgroupltd.com/product/android-pin-password-lock-tool/。将下载两个文件，BruteForceAndroidPin.py和RecoverAndroidPIN.py。RecoverAndroidPIN.py用于在物理图像中定位必要的文件；我们不需要它。

BruteForceAndroidPIN.py的格式是：

python BruteForceAndroidPIN.py <hash> <salt> <max code length (4-16)> t

结尾的t参数用于指示哈希是密码的哈希；对于破解 PIN 是不需要的，只会增加运行时间。

上面显示的哈希值来自 PIN，所以我们只需要填写<hash>、<salt>和<max code length>字段：

此示例中的 PIN 为2587，如输出所示。这个 PIN 破解不到一秒，但更长的 PIN 甚至短密码可能需要更长的时间。

Android SIM 卡提取

传统上，SIM 卡用于在设备之间传输数据。过去，SIM 卡用于存储许多不同类型的数据，例如：

• 用户数据

• 联系人

• 短信

• 拨打电话

• 网络数据

• 集成电路卡标识符（ICCID）：SIM 卡的序列号

• 国际移动用户识别码（IMSI）：将 SIM 卡与特定用户账户绑定的标识符

• MSISDN：分配给 SIM 卡的电话号码

• 位置区域标识（LAI）：标识用户所在的小区

• 认证密钥（Ki）：用于在移动网络上进行身份验证

• 其他各种特定于网络的信息

随着设备存储容量、SD 卡和云备份的增加，将数据存储在 SIM 卡上的必要性已经减少。因此，大多数现代智能手机通常不会在 SIM 卡上存储太多用户数据，如果有的话。上述所有网络数据仍然存储在 SIM 卡上，因为 SIM 卡是连接所有现代（4G）蜂窝网络的必要条件。

与所有 Android 设备一样，虽然没有明确规定用户数据不能存储在 SIM 卡上，但默认情况下并不会发生。个别设备制造商可以轻松决定将用户数据写入 SIM 卡，个别用户也可以下载应用程序来提供该功能。这意味着在取证调查期间应该始终检查设备的 SIM 卡。这是一个非常快速的过程，不应该被忽视。

获取 SIM 卡数据

SIM 卡应该始终从设备中取出并单独检查。虽然有些工具声称可以通过设备接口读取 SIM 卡，但这可能无法恢复已删除的数据或 SIM 卡上的所有数据；取证人员确保已获取所有数据的唯一方法是使用经过测试和验证的独立 SIM 卡读卡器读取 SIM 卡。

SIM 的位置会因设备而异，但通常存放在电池下方或设备侧面的托盘中。一旦 SIM 卡被取出，就应该放入 SIM 卡读卡器中。市场上有数百种 SIM 卡读卡器可供选择，所有主要的移动取证工具都配备了一个可与其软件配合使用的读卡器。通常，取证工具也会支持第三方 SIM 读卡器。

令人惊讶的是，缺乏彻底的免费 SIM 卡读取软件。任何使用的软件都应该在实际取证调查之前经过测试和验证，以确保在 SIM 卡上填充了已知数据。此外，请记住，许多免费软件适用于旧的 2G/3G SIM 卡，但可能无法在现代 4G SIM 卡上正常工作。我们使用了 Mobiledit! Lite，Mobiledit!的免费版本，用于以下截图。它可以在www.mobiledit.com/downloads上下载。

以下截图显示了从运行版本为 4.4.4 的 Android 手机中提取的样本 4G SIM 卡；请注意，尽管 SIM 卡在过去一年中一直在使用，但并未获取到可以被视为用户数据的内容，尽管 ICCID、IMSI 和 MSISDN（自己的电话号码）等字段可能对传票/令状或调查的其他方面有用。

SIM 卡提取概述

以下截图突出显示了 SIM 卡上的短信：

以下图片突出显示了 SIM 卡的电话簿：

以下图片突出显示了 SIM 卡的电话号码（也称为 MSISDN）：

SIM 卡安全

由于 SIM 卡符合已建立的国际标准，所有 SIM 卡都提供相同的安全功能：4 到 8 位的 PIN 码。通常，必须通过设备菜单设置此 PIN 码。在 Android 设备上，此设置位于设置 | 安全 | 设置 SIM 卡锁。SIM PIN 完全独立于任何锁屏安全设置，只有在设备启动时才需要输入。SIM PIN 仅保护 SIM 卡上的用户数据；即使 SIM 卡被 PIN 锁定，所有网络信息仍然是可恢复的。

SIM 卡将允许三次尝试输入 PIN 码。如果其中一次尝试正确，计数器将重置。另一方面，如果所有这些尝试都不正确，SIM 卡将进入个人解锁密钥（PUK）模式。PUK 是由运营商分配的 8 位数字，通常在购买 SIM 卡时的文件中找到。使用任何商用取证软件都无法绕过 PUK；因此，检查员不应尝试在设备上输入 PIN 码，因为设备不会指示在激活 PUK 之前还有多少次尝试。检查员可能会无意中将 SIM 卡锁定，无法访问设备。然而，取证工具将显示在激活 PUK 之前还有多少次尝试，如前面的屏幕截图所示。

注意

SIM 卡的通用载体默认的 PIN 码是 0000 和 1234。如果在激活 PUK 之前还有 3 次尝试，检查员可以成功地使用这些默认值解锁 SIM 卡。

运营商经常在发放 SIM 卡时保留 PUK 密钥。这些密钥可以通过发给运营商的传票或令状获得。

SIM 卡克隆

SIM 卡的 PIN 本身几乎没有提供额外的安全性，并且可以很容易地通过 SIM 卡克隆来绕过。SIM 卡克隆是几乎所有商用移动取证软件提供的功能，尽管克隆这个术语有些误导。在移动取证的情况下，SIM 卡克隆是将锁定的 SIM 卡上的网络数据复制到一个没有激活 PIN 的取证无菌 SIM 卡上的过程。手机将根据这些网络数据（通常是 ICCID 和 IMSI）识别克隆的 SIM 卡，并认为它是之前插入的相同 SIM 卡，但这次没有 SIM PIN。这个克隆的 SIM 卡也无法访问蜂窝网络，这使它成为类似飞行模式的有效解决方案。因此，SIM 卡克隆将允许检查员访问设备，但原始 SIM 卡上的用户数据仍然无法访问，因为它仍然受到 PIN 的保护。

我们不知道有任何免费软件可以进行取证 SIM 卡克隆。然而，几乎所有商用移动取证工具都支持这一功能。这些工具通常包括 SIM 卡读卡器、执行克隆的软件，以及多张空白 SIM 卡用于克隆过程。

Android 棒棒糖的问题和机会

正如本章中多次提到的那样，最近发布的 Android 棒棒糖 5.0 版本引入了许多强大的安全功能，这当然给取证检查员带来了复杂性。最初宣布 Android 棒棒糖设备将默认启用全盘加密，然而，由于许多设备上的性能问题，谷歌后来撤回了这一要求。谷歌只是强烈建议用户在首次创建帐户时启用全盘加密。谷歌还暗示这将成为未来操作系统版本的要求，更多信息可以在static.googleusercontent.com/media/source.android.com/en/us/compatibility/android-cdd.pdf的第 9.9 节找到。

启用完整磁盘加密的设备几乎不可能绕过锁定的设备，因为即使可以恢复密钥文件，它们也会被加密；尽管商业工具制造商最终肯定会赶上。在撰写本文时，没有已知的方法可以绕过锁定的、加密的棒棒糖设备，除非它已启用USB 调试并且先前记住了计算机的 RSA 密钥以绕过安全 USB 调试。在这种情况下，可以从嫌疑人的计算机中拉取adbkey和adbkey.pub文件，并将其放在检查机器上；然后设备将认为它正在与已知的、批准的计算机通信。adbkey和adbkey.pub文件可以在 Windows 计算机的C:\Users\<username>\.android和苹果计算机的/Users/<username>/.android中找到。

对于进行棒棒糖取证的检查员来说，有一个重要的优势：本章前面提到的智能锁。智能锁允许用户设置条件，如果满足条件，设备将无需输入密码即可解锁。如果在启用的受信任位置进行检查，检查员将不需要绕过锁定。如果在检查设备时附近有一个已启用的受信任设备，情况也是如此。但是，设备上没有任何指示表明正在使用受信任的设备；设备看起来只是没有锁屏。因此，从现场保护所有数字证据变得更加关键。以前可能被忽视的设备，如蓝牙耳机，可能会成为让检查员绕过锁定设备的关键。越来越普遍的是设备与车辆配对，因此检查员可能不得不在嫌疑人的车辆中进行提取！棒棒糖的额外安全性意味着检查员可能需要在取证过程中变得更有创造力。

Android 棒棒糖还为所有设备带来了多用户支持，这在以前仅限于平板电脑。在具有多个帐户的设备上，所有用户的数据仍然位于/data分区中，但位于稍有不同的位置。如果在设备上设置了多个帐户，则每个帐户的应用数据目录可以在/data/user中找到。每个用户都将被分配一个唯一的编号；0是设备上设置的第一个帐户。/data/user/0目录实际上是一个符号链接到/data/data。第二个帐户位于10目录中，该目录直接包含了第二个用户的所有应用程序数据。每添加一个用户，都会存储在以10递增的目录中；即第三个用户在/data/user/20中，第四个用户在/data/user/30中，依此类推。

摘要

本章涵盖了与 Android 设备的逻辑提取相关的许多主题。简而言之，各种方法及其要求如下：

方法	要求
ADB 拉取

• USB 调试已启用

• 4.2.2+上绕过安全 USB 调试

• 获取用户数据的根访问权限

|

从恢复模式下的 ADB 拉取

• 必须是自定义恢复以启用 ADB 访问

• 获取用户数据的根访问权限

|

从自定义恢复映像中启动的 Fastboot

• 解锁的引导加载程序

• 设备的引导镜像

|

ADB 备份

• USB 调试已启用

• 4.2.2+上绕过安全 USB 调试

• 必须在运行设备上完成（而不是恢复模式）

|

ADB dumpsys

• USB 调试已启用

• 4.2.2+上绕过安全 USB 调试

• 必须在运行设备上完成（而不是恢复模式）

|

SIM 卡提取

• 无，应独立于设备完成

|

此外，有价值的用户数据可以从 SD 卡中恢复，这将在第五章中进行介绍，从 Android 设备物理提取数据。

如果屏幕被锁定，检查员可以使用上述列出的方法提取关键文件并破解它们，以绕过锁定。

本章节有大量的数据。为了帮助简化它，下面展示了一个建议的最佳实践流程图：

.

安卓取证流程图

第五章：从 Android 设备物理提取数据

本章将尽可能使用免费和开源工具来进行物理数据提取。本章涵盖的大部分内容将使用本书中先前讨论过的 ADB 方法。在本章结束时，读者应该熟悉以下概念：

• 物理提取意味着什么

• 从物理提取中期望什么数据

• 使用dd和nanddump命令进行物理数据提取

• RAM 镜像和分析

• SD 卡获取

• JTAG 和芯片脱落方法

物理提取概述

在数字取证中，物理提取是电子媒体的精确比特对比图像，对于移动设备也是如此。在传统的计算机取证中，这通常涉及从嫌疑人的计算机中取出证据驱动器，并通过写入阻断器对其进行镜像，而无需启动驱动器，从而生成包含嫌疑人驱动器的精确副本的图像文件。输出通常被称为原始图像，或简称为 bin（二进制）文件。物理提取与逻辑提取不同，它们是设备内存的精确副本，并包括未分配的空间、文件松弛、卷松弛等。

在移动取证中，结果是相同的；设备的精确比特对比图像，但方法有所不同。例如，从设备中移除闪存存储器进行镜像既耗时又昂贵，并且需要大量专业知识（尽管后面章节中讨论的芯片脱落方法可以实现）。此外，除了使用高级的 JTAG 或芯片脱落方法，设备必须在某种程度上引导（在许多情况下还必须写入）才能访问数据。最后，找到甚至可以解析最终图像文件的工具可能非常困难。硬盘镜像和文件系统长期以来一直被记录和研究，而移动镜像和文件系统经常发生变化；在某些情况下，移动文件系统甚至是特定制造商独有的。知道在获取图像后该如何处理图像可能与首次获取图像一样具有挑战性！

许多在第四章中讨论的技术，即《从 Android 设备逻辑提取数据》，在这里仍然适用。引导到自定义恢复仍然是最具法医学意义的过程；尽量避免物理获取活动设备。

可以从物理上获取哪些数据？

简短的回答是：一切。由于物理获取是设备的精确图像，因此图像文件中包含设备上的所有数据。如前所述，通过物理提取，取证人通常只受其查找相关数据的能力所限制。一般来说，这是由于移动取证领域缺乏良好的图像分析工具。更进一步，应用程序已知会对用户数据进行编码或其他混淆，因此仅通过在十六进制编辑器中浏览图像将经常错过有价值的证据。本章将展示各种方法来挂载或以其他方式查看物理提取的文件系统，而第七章《Android 应用程序的取证分析》将专注于分析特定应用程序的数据。

Root 访问

与逻辑提取一样，Root 访问对于物理提取来说也是至关重要的。要手动对设备进行镜像，我们需要在设备上执行 ADB shell 中的命令，这将需要 Root 权限。如果无法获得 Root 访问权限，通常仍然可以对 SD 卡进行镜像。除此之外，还有 JTAG 或芯片脱落方法。

使用 dd 物理提取数据

dd命令对于任何已经进行过传统硬盘取证的检查员来说应该是很熟悉的。dd命令是一个 Linux 命令行实用程序，用于转换和复制文件，但在取证中经常用于创建整个驱动器的逐位图像。还存在许多dd命令的变体，通常也经常使用，如dcfldd、dc3dd、ddrescue和dd_rescue。由于dd命令是为基于 Linux 的系统构建的，因此它经常包含在 Android 平台中。这意味着在设备上通常已经存在创建图像的方法！

dd命令有许多可以设置的选项，这里只列出了具有法医学重要性的选项。dd命令的格式如下：

dd if=/dev/block/mmcblk0 of=/sdcard/blk0.img bs=4096 conv=notrunc,noerror,sync

• if：此选项指定要从中读取的输入文件的路径。

• of：此选项指定要写入的输出文件的路径。

• bs：此选项指定块大小。数据以指定块的大小读取和写入，默认情况下为 512 字节。

• conv：此选项指定其属性作为转换选项：

• notrunc：此选项不会截断输出文件。

• noerror：如果遇到错误，此选项将继续成像。

• sync：与noerror选项一起，此选项为出现错误的块写入\x00。这对于在图像内保持文件偏移很重要。

提示

不要混淆if和of标志，否则可能会覆盖目标设备！

可以在man7.org/linux/man-pages/man1/dd.1.html找到命令选项的完整列表。

请注意块大小与noerror和sync标志之间的重要关联：如果出现错误，将为整个读取的块（由块大小确定）写入\x00。因此，较小的块大小会导致在出现错误时丢失的数据较少。缺点是，通常情况下，较小的块大小会导致传输速率较慢。检查员将不得不决定是更喜欢及时还是更准确的获取。

在前一章中讨论过，进入恢复模式进行成像过程是最具法医学意义的方法。

确定要成像的内容

在成像计算机时，检查员必须首先找到驱动器的挂载方式；例如/dev/sda。在成像 Android 设备时也是如此。第一步是启动 ADB shell，并使用以下命令查看/proc/partitions文件：

cat /proc/partitions

输出将显示设备上的所有分区：

在前面的屏幕截图中显示的输出中，mmcblk0是设备上的整个闪存。要成像整个闪存，我们可以使用/dev/blk/mmcblk0作为dd命令的输入文件标志（if）。其后的内容，由p1-p29表示，是闪存的一个分区。块的大小以块为单位显示，本例中块大小为 1024 字节，总内部存储大小约为 32GB。要获取设备内存的完整图像，我们将使用mmcblk0作为输入文件运行dd命令。

然而，我们知道从前几章的内容，大多数这些分区不太可能具有法医学意义；我们可能只对其中的一些感兴趣。要查看每个分区的相应名称，我们可以查看设备的by-name目录。这并不是每个设备都有的，有时路径也不同，但对于这个设备，它位于/dev/block/msm_sdcc.1/by-name。通过导航到该目录并运行ls -al命令，我们可以看到每个块符号链接到哪里，如下面的屏幕截图所示：

如果我们的调查只对userdata分区感兴趣，我们现在知道它是mmcblk0p28，可以将其用作dd命令的输入文件。

如果设备上不存在by-name目录，则可能无法识别设备上的每个分区。但是，仍然可以使用 ADB shell 中的mount命令找到其中许多分区。请注意，以下截图来自不包含by-name目录的不同设备，因此数据分区不是mmcblk0p28。

在此设备上，数据分区是mmcblk0p34。如果mount命令不起作用，可以使用cat /proc/mounts命令找到相同的信息。根据设备的不同，还可以使用cat /proc/mtd或cat /proc/yaffs命令来识别分区；这些命令可能适用于旧设备。更新的设备可能在根目录中包含一个名为fstab的文件（通常称为fstab.<device>），其中列出了可挂载的分区。

写入 SD 卡

dd命令的输出文件可以写入设备的 SD 卡。只有在可移除嫌疑 SD 卡并用取证无菌 SD 卡替换以确保dd命令的输出不会覆盖证据时才应执行此操作。显然，如果要写入 SD 卡，请确保 SD 卡大于正在镜像的分区。

注意

在更新的设备上，/sdcard分区实际上是指向/data/media的符号链接。在这种情况下，使用dd命令将/data分区复制到 SD 卡将无效，并且可能会损坏设备，因为输入文件实质上是被写入自身。

要确定 SD 卡符号链接到哪里，只需打开 ADB shell 并运行ls -al命令。如果未显示 SD 卡分区，则可能需要使用第四章中显示的步骤在恢复模式下挂载 SD 卡，从 Android 设备逻辑上提取数据。

在下面的示例中，/sdcard被符号链接到/data/media。这表明dd命令的输出不应写入 SD 卡。

在接下来的示例中，/sdcard不是指向/data的符号链接，因此dd命令的输出可以用来将/data分区图像写入 SD 卡：

在旧设备上，SD 卡甚至可能没有被符号链接。

确定要读取的块以及 SD 卡符号链接的位置后，使用以下命令将/data分区镜像到/sdcard：

dd if=/dev/block/mmcblk0p28 of=/sdcard/data.img bs=512 conv=notrunc,noerror,sync

现在，SD 卡上存在/data分区的图像。可以使用 ADB pull命令将其拉到检查员的计算机上，或者直接从 SD 卡中读取。

使用 netcat 直接写入检查员的计算机

如果图像无法写入 SD 卡，检查员可以使用netcat直接将图像写入其计算机。netcat 工具是一种基于 Linux 的工具，用于在网络连接上传输数据。我们建议在 Linux 或 Mac 计算机上使用 netcat，因为它是内置的，尽管也存在 Windows 版本。以下示例是在 Mac 上完成的。

在设备上安装 netcat

很少有 Android 设备（如果有的话）预装了 netcat。要检查，只需打开 ADB shell 并键入nc。如果返回nc 未找到，则必须在设备上手动安装 netcat。可以在许多在线位置找到为 Android 编译的 netcat。我们分享了我们在sourceforge.net/projects/androidforensics-netcat/files/上使用的版本。

如果我们回顾一下前一节中mount命令的结果，我们可以看到/dev分区被挂载为tmpfs。Linux 术语tmpfs表示该分区旨在在设备上显示为实际文件系统，但实际上只存储在 RAM 中。这意味着我们可以在取证人的计算机上使用以下命令push netcat，而不对设备进行任何永久更改：

adb push nc /dev/Examiner_Folder/nc

该命令应该已经在/dev中创建了Examiner_Folder，并且nc应该在其中。可以通过在 ADB shell 中运行以下命令来验证：

ls /dev/Examiner_Folder

使用 netcat

现在 netcat 二进制文件已经在设备上，我们需要在 ADB shell 中给予它执行权限。可以按照以下步骤完成：

chomd +x /dev/Examiner_Folder/nc

我们需要打开两个终端窗口，其中一个打开了 ADB shell。另一个将用于监听从设备发送的数据。

现在我们需要在取证人的计算机上通过 ADB 启用端口转发：

adb forward tcp:9999 tcp:9999

9999是我们选择用于 netcat 的端口；在 Linux 或 Mac 系统上，可以是 1023 到 65535 之间的任意端口号（1023 及以下保留给系统进程，需要 root 权限才能使用）。Windows 将允许分配任何端口。

在具有 ADB shell 的终端窗口中，运行以下命令：

dd if=/dev/block/mmcblk0p34 bs=512 conv=notrunc,noerror,sync | /dev/Examiner_Folder/nc –l –p 9999

提示

mmcblk0p34是该设备上的用户数据分区，但是整个闪存或任何其他分区也可以使用这种方法进行镜像。在大多数情况下，最佳做法是镜像整个闪存，以便从设备中获取所有可能的数据。一些商业取证工具可能还需要整个内存映像，并且可能无法正确处理单个分区的映像。

在另一个终端窗口中运行：

nc 127.0.0.1 9999 > data_partition.img

data_partition.img文件现在应该在取证人计算机的当前目录中创建。当数据传输完成时，两个终端中的 netcat 将终止并返回到命令提示符。这个过程可能需要相当长的时间，具体取决于图像的大小。

使用 nanddump 物理提取数据

在所有前面的示例中，分区都是多媒体卡（MMC）块，这在较新的设备中很常见。然而，较旧的设备更有可能由存储器技术设备（MTD）块组成。我们过去曾看到dd命令无法正确镜像 MTD 块的情况，尽管往往它可以正常工作。如果dd失败，有一个被广泛分发的实用程序叫做MTD-Utils，用于从 MTD 块读取和写入；nanddump命令是MTD-Utils的一部分，并且可以类似于dd用于从 MTD 块读取。在dd失败的情况下，nanddump总是成功的。

为 Android 编译的nanddump版本可以在许多在线地方找到；我们使用的是在github.com/jakev/android-binaries/blob/master/nanddump找到的版本。

将nanddump放到设备上的过程与之前用于 netcat 的过程相同：

adb push nanddump /dev/Examiner_Folder/nanddump
chmod +x /dev/Examiner_Folder/nanddump

就像dd一样，nanddump命令可以用于通过 netcat 写入 SD 卡或取证人的计算机。从终端窗口中，运行以下命令：

adb forward tcp:9999 tcp:9999

在 ADB shell 中的一个单独的终端窗口中运行以下命令：

/dev/Examiner_Folder/nanddump /dev/block/mmcblk0p34 | /dev/Examiner_Folder/nc –l –p 9999

在使用adb forward命令的第一个终端窗口中，运行以下命令：

nc 127.0.0.1 9999 > data_partition.img

验证完整的物理映像

验证图像文件是否与设备相同是传统数字取证中的关键步骤。在 Android 设备上，这可能会有点棘手，甚至是不可能的。可以使用取证人通常使用的任何工具对创建的图像进行哈希处理。可以通过在 ADB shell 中使用以下命令来验证设备上的内存，其中给定的路径是被镜像的块或分区：

md5sum /dev/block/mmcblk0

然而，md5sum命令并非所有 Android 设备都包含。如果没有包含，检查员可能可以在网上找到适用于其设备的版本，并将其推送到tmpfs分区中，如之前使用 netcat 和nanddump所示。

另一个问题是，如果图像是在活动状态下获取的，即不是在恢复模式下获取的，正如前一章中所讨论的，那么 MD5 哈希值几乎肯定不会匹配，因为设备上的数据不断变化（即使是无线电频率（RF）屏蔽或处于飞行模式）。在这种情况下，检查员必须记录设备在获取时处于活动状态，并解释哈希值不会匹配的原因。

分析完整的物理图像

一旦使用讨论过的方法之一获取了图像，检查员可能可以手动浏览图像并提取每个分区，但可能更倾向于避免这样做。幸运的是，有各种各样的移动取证工具可以接收物理图像，如 Cellebrite、XRY、Mobile Phone Examiner 等。不幸的是，这些工具都不是免费或开源的。迄今为止，最受欢迎的免费开源分析工具是 Brian Carrier 的 Autopsy。

Autopsy

Sleuth Kit 最初是一组基于 Linux 的命令行工具，用于取证；最终，添加了一个名为 Autopsy 的基于浏览器的 GUI。最近，Autopsy 已作为 Windows 上的独立平台发布，并包括分析 Android 图像的支持。版本 3.1.1 如下截图所示。加载和分析图像的完整过程将在第八章中进行介绍，Android 应用程序的取证分析。

Autopsy 可以在www.sleuthkit.org/下载。

图像加载后，扩展图像将显示 Autopsy 发现的所有卷，如下截图所示：

注意

在设备上发现的卷远远多于分区的数量。它们可能是工具创建的误报，也可能是设备上的磨损平衡的结果。

其中一个卷将是数据分区，如下所示：

请注意，上面看到的媒体目录是 SD 卡，因为它被符号链接到data分区。data分区中的data文件夹将包含应用程序数据：

每安装一个应用程序，都会为其创建一个目录。在前面的屏幕截图中，带有文件夹图标上的红色叉号的目录已被删除，表明该应用程序已从设备中移除。

最后，Autopsy 可以自动提取一些数据供检查员使用，但与所有取证工具一样，这些信息应该进行手动验证，如第七章中所示，Android 应用程序的取证分析。

分析物理转储的问题

我们在许多取证论坛和邮件列表上看到的最常见问题是，检查员获取了物理转储，然后无法将其加载到声称支持该设备的工具中。大多数情况下，这是因为检查员未考虑带外（OOB）区域。

带外区域，有时称为备用区域，是保留用于元数据的闪存小部分。元数据通常包括纠错码（ECC）、有关坏块的信息，以及在某些情况下，有关文件系统的信息。这对检查员来说是一个问题，因为大多数移动取证工具不考虑带外区域；它们期望图像中不包含它。当向工具呈现包含备用区域的图像时，工具通常不知道该怎么做，并且无法正确解析数据。

工具无法考虑 OOB 区域的原因是，它不包括在dd镜像中，这是大多数工具用来创建它们的镜像的。使用nanddump命令时，OOB 区域可能会被包括在内，尽管根据使用的二进制文件，可能有一个选项来排除它。OOB 区域包括在芯片脱焊和 JTAG 镜像中。

为了正确加载图像到取证工具中，首先需要删除 OOB 区域。一个经验法则是，OOB 大小基于设备的页面大小；对于每 512 字节的页面大小，将有 16 字节的 OOB 区域。例如，具有 2048 字节页面大小的设备可能在每个页面的末尾有 64 字节的 OOB 区域。然而，这完全取决于存储芯片制造商。在尝试删除 OOB 区域之前，检查员应该找到特定存储芯片的数据表，以确认页面和 OOB 区域的大小。通常可以通过在手机电路板上找到存储芯片并搜索芯片的型号来完成这一点。

以下是一个 Python 脚本的示例代码，用于从图像中删除 OOB 区域。就像上一章一样，我们并不是 Python 专家，我们确信有更好、更有效的方法来做到这一点，但这个方法确实有效：

import sys
file_to_parse = open(sys.argv[1],'rb')
file_after_removal = open('file_out.bin','wb')
while file_to_parse:
  lines_out = file_to_parse.read(2048)
  if lines_out:
    file_after_removal.write(lines_out)
    file_to_parse.seek(64,1)
  if not lines_out:
    break
print 'Done'
file_to_parse.close()
file_after_removal.close()

如果命名为OOB_Remover.py，则可以使用以下命令执行此文件：

python OOB_Remover.py C:\Users\Android_Examiner\physicaldump.bin

输出文件，没有 OOB 区域，将被命名为file_out.bin，保存在执行脚本的目录中。原始文件不会被编辑或修改。

请注意，代码的编写假定页面大小为 2048，OOB 大小为 64；这两个数字需要根据图像所在的存储芯片的具体大小进行编辑。然后输出应该能够加载到商用移动取证工具中。

成像和分析 Android RAM

由于拉取 Android 内存需要 root 访问权限，在很多情况下并不适用。大多数公共 root 过程涉及重新启动手机，这会擦除易失性 RAM，这意味着当检查员获得 root 权限来镜像 RAM 时，为时已晚，因为 RAM 已经被擦除。由于这个原因和可能的其他原因，在商业取证领域对 Android RAM 成像和分析的支持并不是很好。然而，有些情况下成像 RAM 是适用的，并可能非常有价值。如果设备在被扣押时已经 root，那么镜像 RAM 应该是扣押过程中的一个强制步骤。由于关闭手机将擦除 RAM，设备应该被置于飞行模式（任何其他网络连接，如 Wi-Fi 和蓝牙都应该被禁用），并且应该立即镜像 RAM，以避免设备电池在 RAM 被拉取之前耗尽。

当涉及到 RAM 时，主要挑战在于分析。RAM 是完全原始的、无结构的数据；没有文件系统。在十六进制编辑器中查看 RAM 时，RAM 似乎只是一个巨大的数据块，几乎没有任何规律可以帮助检查员弄清楚他们在看什么。现代设备通常有几十 GB 的 RAM，这种困难是由此而来的。RAM 可以很容易地使用传统取证工具和方法搜索关键字，但这假设检查员确切地知道他们在寻找什么。

RAM 中可以找到什么？

任何写入闪存的数据必须通过 RAM 传递，处理器与闪存之间没有其他通信方式。这意味着几乎在设备上执行的任何操作都可能在 RAM 转储的内容中找到。根据设备使用量的不同，数据可能会一直保留在 RAM 中，直到需要被覆盖。RAM 转储经常包含在设备上键入的文本，包括用户名和密码，以及不会永久存储在设备上的应用程序数据。例如，旧版本的 Facebook 应用程序将用户的动态消息内容存储在其应用程序文件夹中的数据库中；新版本不保存用户的动态消息内容，但它存在于 RAM 中。

使用 LiME 成像 RAM

Android RAM 获取最常用的工具是Linux Memory Extractor（LiME），以前被称为 DMD。LiME 是免费和开源的，但并不是非常用户友好，因为它需要用户从源代码编译，这只能在 Linux 系统上完成。编译过程还必须针对每个要检查的设备的每个特定版本的 Android 进行，这在一定程度上限制了它在现场的可用性。这是必要的，因为 LiME 不是一个二进制文件（就像我们之前使用的 netcat 和 nanddump 工具一样）；相反，它是一个必须为将要加载的每个内核专门构建的内核模块。

为了确保下载正确的内核源代码，我们需要确定设备的型号和软件版本，可以通过在手机菜单中滚动到设置 | 关于手机来完成。或者，可以通过在 ADB shell 中运行以下命令来找到这些信息：

cat /system/build.prop

型号中的软件版本应该在文件顶部的前几行中。

幸运的是，大多数 Android 制造商确实发布他们的内核源代码；快速的谷歌搜索通常可以找到每个型号和软件版本的源代码。以下是一些主要制造商的开放源发布网站：

• Samsung: opensource.samsung.com/reception.do

• Motorola: sourceforge.net/motorola/

• HTC: www.htcdev.com/devcenter

• Google Nexus: source.android.com/source/building-kernels.html

提示

必须使用正确的型号和版本源。使用错误的内核源编译 LiME 将至少无法在设备上工作。加载不兼容的内核模块也可能导致设备崩溃。

要获取 LiME 的源代码，请转到github.com/504ensicsLabs/LiME，然后选择Download ZIP选项，然后提取 zip 文件。

有许多在线资源解释了如何为特定内核编译 LiME，以及如何创建自定义的Volatility插件来检查生成的 RAM 转储，因此我们在这里不会详细介绍它们。以下是其中一些：

• lime-forensics.googlecode.com/files/LiME_Documentation_1.1.pdf

• code.google.com/p/volatility/wiki/AndroidMemoryForensics

这些来源中缺少的一点是，使用 ADB pull获取/proc/config.gz文件的步骤可能无法在所有设备上工作。如果文件不存在，则可以在源代码中找到正确的配置文件，通常在/arch/arm/configs文件夹中。通常以处理器型号命名，例如apq8064_defconfig。

使用 mem 成像 RAM

如前节所述，使用 LiME 并非易事；这是一个充满复杂性的艰巨过程。在现场，调查员不太可能下载和编译内核源代码。mem工具是由 James Nuttall 开发的，旨在解决这些问题。与需要根据设备特定情况编译的内核模块不同，mem 是一个二进制文件，类似于本章前面使用的 netcat 和 nanddump 示例。mem 工具可以在sourceforge.net/projects/androidforensics-mem/files/下载。

Mem 是一个可执行二进制文件，需要推送到设备并使用之前详细介绍的 netcat 和 nanddump 的确切过程来执行。在计算机取证中，将某些东西推送到 RAM 以读取 RAM 可能看起来有些违反直觉，但这是计算机取证中的一种必要操作。在我们看来，覆盖一小部分 RAM 要比实际推送到设备并覆盖证据用户数据要好。

Mem 具有读取整个 RAM 的能力，或者针对特定的取证感兴趣的进程（应用程序）。假设 mem 被推送到上面使用 netcat 的设备相同位置，运行 mem 的格式如下：

/dev/Examiner_Folder/mem <PID>

PID是要读取的进程的 ID；如果设置为 0，将镜像整个 RAM。要在 ADB shell 中查看进程列表，使用以下命令：

ps

在下面的截图中，我们可以看到PID是输出的第二列：

输出可能相当大，但通过简单阅读列表可以找到有趣的进程：

在上面的截图中，我们可以看到 Kik、Facebook、日历和 Gmail 都在运行。另一种方法是搜索已知应用程序，使用grep。例如，要在输出中找到 Facebook，我们可以运行以下命令：

ps | grep facebook

其输出将只显示 Facebook 的条目如下：

我们可以看到 Facebook 的 PID 是2252。为了避免在设备上覆盖数据，mem 被设计为与 netcat 一起使用，就像本章的直接使用 netcat 将数据写入调查员计算机部分所示的那样。因此，捕获 Facebook 使用的 RAM 需要以下步骤：

1. 在调查员计算机上的终端中运行：

adb forward tcp:9999 tcp:9999

1. 在 ADB shell 中的终端窗口中运行：

/dev/Examiner_Folder/mem 2252 | /dev/Examiner_Folder/nc –l –p 9999

1. 在调查员计算机上的终端窗口中运行：

nc 127.0.0.1 9999 > FB_RAM.bin

1. 当 mem 运行结束时，调查员的计算机工作目录中应该会有一个名为FB_RAM.bin的文件。

从 mem 输出

如前所述，检查 RAM 的好方法并不多，因为没有文件系统；输出只是一大块数据。这对于使用 mem 获取的数据仍然成立；上面提取的 Facebook RAM 的输出是一个 550MB 的无结构数据块。以下截图可以作为示例查看：

建议使用字符串或其他搜索功能来缩小数据范围，以便找到有用的用户数据。该文件也可以加载到计算机取证工具如 EnCase 或 FTK 中，以搜索关键词，也可以使用雕刻工具来定位图像。

然而，只要有足够的耐心和奉献精神，就可以找到有用的信息，比如用户新闻订阅中的这篇帖子：

最终，mem 的开发人员希望能够开发出一种用于分析输出的 volatility 配置文件。

获取 Android SD 卡

如上所述，在前几章中，SD 卡可以指外部物理 SD 卡或闪存内的分区。可通过写阻断器和典型的计算机取证工具，或使用前一节中显示的dd/nanddump技术，单独成像可移动的外部 SD 卡，尽管前者通常更快，因为它不需要通过 netcat 写入数据。

对 SD 卡进行物理成像与上面讨论的物理成像非常相似；实际上，如果 SD 卡被符号链接到/data分区，它将作为/data分区的一部分在 Autopsy 截图中被获取。该过程的唯一区别在于，如果正在成像 SD 卡，则无法将输出文件写入 SD 卡！这意味着使用先前介绍的 netcat 方法是对内部 SD 卡进行物理成像的最佳选择。

SD 卡上可能会发现什么？

默认情况下，SD 卡通常用于存储大文件，包括下载的项目和使用设备拍摄的照片。许多应用程序还会在 SD 卡上创建自己的目录，用于存储通过聊天应用程序发送或接收的图像等数据。在某些情况下，正如在第八章中所看到的，Android 取证工具概述，甚至有一些应用程序会定期将所有数据备份到 SD 卡上。这对取证人员特别有用，因为他们可能无法访问内部存储器，由于安全设置或无法获取 root 权限，但可能可以访问 SD 卡。

感兴趣的常见 SD 卡位置包括但不限于以下位置：

• /DCIM：此位置包括设备上拍摄的照片

• /Pictures/Screenshots：此位置包含设备上拍摄的截图

• /Download：此位置包含下载的文件

• /Android/data：这是许多应用程序的存储位置

• /AppName：这是许多应用程序的存储位置

提示

即使应用已被删除，/Android/data和/AppName文件夹可能仍然存在。文件夹的内容将被删除，但文件夹可能仍然存在；这表明该应用程序先前曾安装在设备上。

这些只是常见的默认位置。如果设备已获取 root 权限，用户可以将内部存储器中的任何数据放到 SD 卡上。

SD 卡安全

在较旧版本的 Android 中，只需将手机插入计算机即可逻辑挂载 SD 卡，并允许取证人员访问其数据。在某些 Android 版本（可能是 3.0）中发生了变化，尽管在我们检查的各种更改日志中找不到确切的版本。如果使用屏幕锁定，较新版本的 Android 将不会自动允许从计算机访问 SD 卡，这意味着必须绕过屏幕锁定才能访问 SD 卡。显而易见的例外是，可以仍然通过传统的计算机取证方法移除并分析物理的外部 SD 卡。

SD 卡也可以进行加密，可以通过设备全盘加密（如果是内部 SD 卡）或通过第三方应用程序（如果是外部 SD 卡）进行加密。在某些情况下，激活全盘加密会使 SD 卡保持未加密状态，尽管这取决于设备制造商。

提示

Android Lollipop 中的全盘加密也会加密 SD 卡。

高级取证方法

除了前几章讨论的方法外，还有更高级的专业方法可用。JTAG 和芯片取下方法在许多常见情况下都是非常有用的工具，但需要先进的培训（以及在处理现场证据之前进行大量实践！）。最终的高级方法是冷启动攻击以恢复加密密钥，这更多是理论性的。

JTAG

JTAG 是由电气和电子工程师学会（IEEE）制定的标准。在设备生产过程中，它用于通过专用接口与处理器进行通信以进行测试。幸运的是，对于法医检查员来说，它还允许他们直接与处理器通信并检索闪存的完整物理图像。

要执行 JTAG 提取，设备必须拆开到电路板。电路板上将包含多个接触点（设备电路板上的物理接触点），尽管它们通常没有标记，并且通常比 JTAG 所需的接触点多得多。要确定正确的接触点，检查员必须找到在线引脚布局图（或与其选择的工具一起提供），或使用电子测试设备确定每个接触点。然后，检查员必须将一根导线焊接到每个接触点，或使用商业可用的适配器（有时称为夹具），并通过提供的适配器连接到他们的 JTAG 盒子，如下图所示：

HTC Evo 在连接 JTAG 之前和之后的照片（由 http://lowcostwin4n6.blogspot.com/提供）

JTAG 可能听起来很复杂（也许是），但它有许多有用的用途，以下列出了两个优点：

1. 它不需要设备通电，因此：

• 即使设备损坏，也可能成功

• 没有射频屏蔽的担忧

• 不需要 root、ADB 或 USB 调试

1. 它可以用于恢复设备的 PIN/密码，因此：

• 可以对整个闪存进行成像，并恢复/破解密码文件，如第四章所示

许多制造商都生产 JTAG 工具；用于移动取证的许多常用工具可以在teeltech.com/mobile-device-forensic-tools/jtag-equipment/找到。该网站上列出的 RIFF box 可能是移动取证中最常用的工具，因为它支持（包括引脚布局）各种设备。

JTAG 并非总是成功，甚至可能不可能。尽管接口几乎总是在电路板上，但制造商可以选择在设备制造后禁用它。

Chip-off

Chip-off 涉及加热设备的电路板，直到焊料将组件固定到板上融化，然后取出闪存芯片。然后可以使用商业工具读取存储芯片，得到完整的物理图像。Chip-off 技术和 JTAG 一样，源自商业电子生产过程。熔化焊料的过程（通常称为回流或返工）用于在电路板上放置和移除组件，用于获取存储器的读卡器通常用于读取和写入存储芯片，通常是批量使用。

从损坏手机中取出的存储芯片（由 www.binaryintel.com/services/jtag-chip-off-forensics/chip-off_forensics/提供）

Chip-off 具有与 JTAG 相同的优点：它不需要设备通电，并且可以用于获取锁定设备的 PIN/密码；尽管获取 PIN/密码通常是一个无意义的点，但 chip-off 通常被认为是一种破坏性的过程。虽然存储芯片可以更换到设备上，但这是一个技术上要求严格的过程，并需要进一步的培训。但作为最后的手段，chip-off 是无法检查的设备的一个很好的替代方法。

Chip-off 的成本要比 JTAG 高得多，因为需要专门的重焊站和商用存储器读卡器。有数十种重焊站可用，它们都提供基本相同的功能。还有各种各样的存储器读卡器，尽管我们在www.dataman.com/programmers/universal/dataman-48pro2-super-fast-universal-isp-programmer.html上使用了这个价格合理的型号，并取得了巨大成功。重焊站和读卡器并不是与 Chip-off 相关的唯一成本；大多数读卡器还需要为每个芯片型号读取特定的适配器。

绕过 Android 全盘加密

在继续之前，请注意，本节非常不切实际。但是，我们希望一些有抱负的取证开发人员能看到它，并决定它是一个足够值得的事业，使其更广泛适用（也因为它真的很酷）。

冷启动攻击已经被证明并多次使用，但直到最近才能有效地用于 Android 设备。冷启动攻击是基于 RAM 在较低温度下（数据保留更长时间）不太易挥发的想法，因此冷冻设备可以允许检查员访问 RAM 并找到解密设备所需的密钥。最近，一组研究人员成功地进行了演示，他们的论文和研究可以在这里找到：www1.informatik.uni-erlangen.de/frost。

再次注意，这些技术仅针对一个设备（Galaxy Nexus）进行了验证，它们的工具是一个可加载的内核模块，就像 LiME 一样，并依赖于一个为每个使用的设备创建的自定义恢复映像。

总结

本章讨论了用于物理成像内部存储器或 SD 卡的几种技术，以及与它们相关的一些常见问题：

技术	相关问题
dd

• 通常预装在设备上

• 可能无法在 MTD 块上工作

• 无法获取带外区域

|

nanddump

• 不常见于设备上，必须推送到设备上

• 与 MTD 块配合使用效果很好

• 可能根据使用的二进制文件中的选项获取带外区域

|

此外，每种成像技术都可以用于将图像保存在设备上（通常在 SD 卡上），或者与 netcat 一起将文件写入检查员的计算机：

技术	特点
写入 SD 卡

• 简单，不需要将额外的二进制文件推送到设备

• 大多数检查员都熟悉

• 如果 SD 卡被符号链接到正在成像的分区，则无法使用

• 如果正在成像整个存储器，则无法使用

|

使用 netcat

• 通常需要将另一个二进制文件推送到设备

• 有些复杂，必须严格按步骤进行

• 无论正在成像什么都能工作

• 可能比写入 SD 卡更耗时

|

还演示了用于 RAM 成像的多个工具：

工具	特点
LiME

• 必须为每个被检查的设备编译

• 非常复杂的过程

• 已知的，有详细记录的分析程序

• 输出是所有 RAM 的转储

|

内存

• 可以在任何设备上使用，无需额外步骤

• 新工具，使用和记录不如广泛

• 输出是设备上运行的每个进程的一个文件

|

最后，我们简要讨论了 Chip-off 和 JTAG 技术的入门级别。

下一章将演示从物理图像中恢复删除的数据，就像本章创建的那样。

第六章：从安卓设备中恢复已删除的数据

到目前为止，您学到的提取和获取技术将帮助您访问各种详细信息，如通话记录、短信等。然而，这些技术并不能帮助我们查看从设备中删除的数据。在本章中，您将学习关于数据恢复技术，这将使您能够查看设备上已删除的数据。已删除的数据可能包含高度敏感的信息，因此，数据恢复是移动取证的一个关键方面。在本章中，我们将涵盖以下主题：

• 数据恢复概述

• 从 SD 卡中恢复删除的数据

• 从手机内部存储中恢复删除的数据

数据恢复概述

数据恢复是数字取证中的一个强大概念。当无法正常访问设备或 SD 卡时，它是从中检索已删除数据的过程。能够恢复用户删除的数据可以帮助解决几个民事和刑事案件。这是因为大多数被告只是删除设备上的细节，希望证据会被销毁。因此，在大多数刑事案件中，已删除的数据可能至关重要，因为它可能包含用户希望从安卓设备中删除的信息。例如，考虑一下从恐怖分子那里夺取了一部手机的情况。

知道他们删除了哪些项目不是最重要的吗？访问任何已删除的短信、图片、拨打的号码等可能非常重要，因为它们可能会透露大量敏感信息。从普通用户的角度来看，恢复已删除的数据通常指的是操作系统内置的解决方案，如 Windows 中的回收站。虽然可以从这些位置恢复数据，但由于用户意识的增强，这些选项通常不起作用。例如，在台式电脑上，人们现在在想要彻底从桌面上删除文件时使用Shift + Delete。同样，在移动环境中，用户知道应用程序提供的还原操作等。尽管如此，数据恢复技术允许取证人员访问从设备中删除的数据。

就安卓而言，可以恢复大部分已删除的数据，包括短信、图片、应用程序数据等。然而，重要的是以适当的方式扣押设备并遵循一定的程序，否则数据可能会被永久删除。为了确保已删除的数据不会永远丢失，建议您牢记以下几点：

• 扣押后不要对手机进行任何活动。已删除的数据仍然存在于设备上，直到空间被其他新数据所需。因此，手机必须不用于任何活动，以防数据被覆盖。

• 即使手机没有被使用，也会被覆盖。例如，一条新的短信会自动占用覆盖已删除数据的空间。此外，远程擦除命令也会擦除设备上的内容。为了防止这种情况发生，可以考虑将设备放置在法拉第袋中，如第一章介绍安卓取证中所述。因此，应该注意防止通过任何通信方式传递任何新消息或数据。

如何恢复已删除的文件？

当用户从设备中删除任何数据时，数据实际上并没有被抹去，而是继续存在于设备上。被删除的是指向这些数据的指针。所有文件系统都包含元数据，用于维护有关文件层次结构、文件名等的信息。删除实际上并没有抹去数据，而是删除了文件系统的元数据。仅删除元数据可以提高操作系统的性能；删除指针并标记空间为可用是一种非常快速的操作，与实际抹去所有数据相比。因此，当文本消息或其他文件被删除时，它们对用户来说只是不可见的。然而，只要它们没有被其他数据覆盖，这些文件仍然存在于设备上。

因此，在新数据进入并占据空间之前，可以恢复它们。

在安卓上恢复已删除的数据涉及两种情况：

• 从 SD 卡中恢复已删除的数据，如照片、视频等。

• 从设备的内部存储中恢复已删除的数据，如短信、拨号号码、浏览历史、应用程序数据、聊天记录等

以下部分介绍了从安卓设备的 SD 卡和内部存储中恢复已删除数据的技术。

从 SD 卡中恢复已删除的数据

SD 卡上的数据可以在法证调查期间揭示很多有用的信息。照片、视频、语音录音、应用程序数据等存储在 SD 卡上的事实使这一点更加重要。如前几章所述，安卓设备通常在 SD 卡上使用 FAT32 文件系统。这样做的主要原因是 FAT32 文件系统在包括 Windows、Linux 和 Mac OS X 在内的大多数操作系统中都得到了广泛支持。FAT32 格式化的驱动器上的最大文件大小约为 4GB。随着现在可用的分辨率越来越高，这个限制通常会被达到。如果可以将外部 SD 中删除的数据挂载为驱动器，那么恢复这些数据将会相当容易。

如果 SD 卡是可移动的，可以通过连接到计算机上的读卡器将其挂载为驱动器。在挂载时可以传输任何文件到 SD 卡。一些使用 USB 大容量存储的旧设备在通过 USB 电缆连接时也会将设备挂载为驱动器。如前所述，在取证中，为了确保原始证据不被修改，需要对磁盘进行物理映像，并且所有进一步的实验都是在映像本身上进行的。同样，在 SD 卡分析的情况下，需要对 SD 卡进行映像。成像的过程类似于第五章中解释的那样，从安卓设备中物理提取数据。完成成像后，我们会得到一个dd映像文件。在我们的示例中，我们将使用一个免费工具 FTK Imager。这个工具是一个成像实用程序，除了创建磁盘映像外，还可以用来探索磁盘映像的内容。

使用 FTK Imager 恢复 SD 卡内容需要以下步骤：

1. 启动 FTK Imager。单击菜单中的File，然后单击Add Evidence Item。

在 FTK Imager 中添加证据

1. 在Select Source对话框中选择Image File，然后单击Next。

2. 在Select File对话框中，浏览到下载sdcard.dd文件的位置。选择文件，然后单击Finish：

在 FTK Imager 中选择要分析的映像文件

1. FTK Imager 的默认显示将在右下角的View窗格中显示 SD 卡的内容。您还可以单击左下窗格下方的Properties选项卡，查看磁盘映像的属性。

2. 在左窗格中，驱动器已打开。您可以通过单击+号来打开文件夹。当您突出显示一个文件夹时，其内容将显示在右窗格中。选择文件后，其内容将显示在底窗格中。

3. 如下图所示，已删除的文件的图标上会有一个红色叉叉：

已删除的文件上显示红色叉叉图标

1. 要导出文件，请右键单击包含图片的文件，然后选择导出文件：

在 FTK Imager 中导出已删除的文件

有时，只有文件的片段是可恢复的。这个文件片段无法直接读取或查看。在这种情况下，我们需要查看未分配空间中的更多数据。可以使用 Carving 来从未分配空间中恢复数据。Winhex、Scalpel、Foremost 和 Photorec 是一些可以帮助您做到这一点的工具。大多数最新的 Android 设备不作为大容量存储器挂载。这是因为这些设备不支持 USB 大容量存储，而是使用 MTP 或 PTP 协议。使用 USB 大容量存储时，计算机需要对存储器进行独占访问。换句话说，当连接到工作站时，外部存储器需要完全断开与 Android 操作系统的连接。这会导致与移动应用程序相关的其他一些复杂性。当 Android 设备使用 MTP 时，它会显示为计算机的媒体设备，而不是可移动存储，如下图所示：

在 Windows 的可移动设备下显示的 Android 设备

然而，普通的数据恢复工具需要挂载驱动器才能执行扫描，尽管这不是推荐的过程，因为这可能会导致对设备的更改。因此，大多数使用 MTP/PTP 的最新设备不被视为挂载驱动器。因此，传统的适用于计算机的数据恢复工具在这些设备上无法使用。

出于前面提到的原因，当设备使用 MTP/PTP 并且未作为驱动器挂载时，可以通过某些需要打开 USB 调试选项的特定于 Android 的数据恢复工具来进行恢复。市面上几乎所有的 Android 数据恢复工具都需要您启用 USB 调试，以便在开始 Android 数据恢复之前识别您的设备和 SD 卡。此外，这些工具只能在已 root 的设备上使用。现在我们将看看如何从 Android 设备的内部存储器中恢复已删除的数据。

从内部存储器中恢复删除的数据

大多数分析工具不支持从 Android 内部存储器中恢复已删除的文件，例如应用程序数据等。这主要有两个原因。首先，与 SD 卡中使用的常见文件系统不同，内部存储器使用的文件系统可能无法被取证工具识别和挂载。其次，除非手机已 root，否则取证人员无法访问 Android 手机的内部存储器的原始分区。以下是取证人员在尝试从 Android 设备的内部存储器中恢复数据时可能遇到的其他问题：

• 要访问内部存储器，您可以尝试对手机进行 root。但是，root 过程可能涉及向/data分区写入一些数据。这个过程可能会覆盖设备上的有价值的数据。

• 与 SD 卡不同，这里的内部文件系统不是 FAT32（这是法匹配的文件系统）。内部文件系统可能是 YAFFS2（在旧设备中）、EXT3、EXT4、RFS 或专为在 Android 上运行而构建的其他文件系统。因此，许多专为 Windows 文件系统设计的恢复工具将无法使用。

• 安卓设备上的应用程序数据通常以 SQLite 格式存储。虽然大多数取证工具提供对数据库文件的访问，但可能需要将其导出并在本地浏览器中查看。取证人员必须检查原始数据，以确保取证工具没有忽略已删除的数据。

因此，从安卓设备的内部存储器中恢复已删除的数据是困难的，但并非不可能。安卓设备的内部存储器保存了大部分用户数据以及您调查的可能关键。如前所述，设备必须被 root 才能访问原始分区。需要注意的是，市面上大多数安卓恢复工具并未强调它们只能在 root 手机上运行。硬件解决方案，如 UFED 和 XRY，完全能够从内部存储器以及 SD 卡中恢复已删除的数据。现在让我们看看如何从安卓手机中恢复已删除的数据。

通过解析 SQLite 文件恢复已删除的数据

安卓中大多数应用程序数据都存储在 SQLite 文件中。与短信、电子邮件和大多数应用程序数据相关的数据都存储在 SQLite 文件中。SQLite 数据库可以在数据库本身内部存储已删除的数据。用户标记为删除的文件不再出现在活动的 SQLite 数据库文件中。因此，通过分析这些 SQLite 文件，可以恢复已删除的数据，如短信、联系人等。SQLite 页面中有两个区域可能包含已删除的数据：未分配的块和空闲块。大多数恢复已删除数据的商业工具会扫描 SQLite 页面的未分配块和空闲块。可以使用可用的取证工具，如 Oxygen Forensics SQLite Viewer 来解析已删除的数据。SQLite Viewer 的试用版可以用于此目的。但是，您可以恢复的数据量存在一定的限制。

在我们的示例中，我们将从安卓设备中恢复已删除的短信。从安卓手机中恢复已删除的短信是设备取证分析中经常被要求的一部分，主要是因为这是最流行的通信形式。有不同的方法可以从安卓设备中恢复已删除的短信。然而，就通过解析 SQLite 文件进行恢复而言，我们需要了解消息在设备上的存储位置。在第四章中，从安卓设备逻辑提取数据，我们解释了安卓设备上存储用户数据的重要位置。以下是一个快速回顾：

• 每个应用程序都将其数据存储在/data/data文件夹中（同样，这需要 root 权限才能获取数据）。

• /data/data/com.android.providers.telephony/databases中的文件包含有关短信/MMS 的详细信息

通过检查存储在/data/data/com.android.providers.telephony/databases中的名为 mmssms.db 的 SQLite 数据库文件，可以恢复已删除的短信。需要以下步骤：

• 提取 SMS 数据库 SQLite 文件（mmssms.db）。这可以通过逻辑数据提取技术来完成，这些技术在第四章中有所介绍，从安卓设备逻辑提取数据。

• 一旦文件被提取到本地机器，您可以使用可用的工具，如 Cellebrite。这些工具可能会自动提取已删除的细节。您还可以使用十六进制查看器或 SQLite 查看器手动检查碎片，例如 Oxygen Forensics SQLite Viewer。

• 查看已删除的数据的一种方法是单击 Oxygen Forensics SQLite Viewer 中的包含已删除数据的块选项卡，如下面的屏幕截图所示（引用自az4n6.blogspot.in/2013/02/finding-and-reverse-engineering-deleted_1865.html）：

在 Oxygen Forensics SQLite Viewer 中显示的已删除数据

您还可以尝试可用的开源 Python 脚本（az4n6.blogspot.in/2013/11/python-parser-to-recover-deleted-sqlite.html）来解析 SQLite 文件以恢复已删除的记录。

通过文件切割技术恢复已删除的数据

文件切割是取证中非常有用的方法，因为它允许恢复以进行分析的隐藏或已删除的数据。简而言之，文件切割是在没有文件系统元数据的情况下从片段中重新组装文件的过程。在文件切割中，会在二进制数据中搜索指定的文件类型并提取它们，以创建分区或整个磁盘的取证镜像。文件切割仅基于文件结构和内容从驱动器的未分配空间中恢复文件，而不需要匹配的文件系统元数据。

注意

未分配空间是指在文件系统结构中没有任何指针的驱动器部分。

可以通过扫描磁盘的原始字节并重新组装它们来恢复或重建文件。这可以通过检查文件的标头（前几个字节）和页脚（最后几个字节）来完成。

文件切割方法根据所使用的基本技术进行分类。标头-页脚切割方法依赖于根据标头和页脚信息恢复文件。例如，JPEG 文件以 0xffd8 开头，以 0xffd9 结尾。标头和页脚的位置被识别出来，然后在这两个端点之间的所有内容都被切割。类似地，文件结构切割方法基于文件的内部布局来重建文件。然而，传统的文件切割技术，如我们已经解释的那些，如果数据是分段的，则可能无法工作。为了克服这一点，新技术，如智能切割，使用几种流行文件系统的分段特性来恢复数据。

一旦手机被镜像，就可以使用Scalpel等工具进行分析。 Scalpel 是一个强大的开源实用程序，用于切割文件。该工具分析块数据库存储并识别已删除的文件并恢复它们。 Scalpel 与文件系统无关，并且已知可以在各种文件系统上工作，包括 FAT，NTFS，EXT2，EXT3，HFS 等。以下步骤解释了如何在 Ubuntu 工作站上使用 Scalpel 恢复文件：

1. 使用sudo apt-get install scalpel命令在 Ubuntu 工作站上安装 Scalpel。

2. /etc/scalpel目录中的scalpel.conf文件包含有关支持的文件类型的信息，如下面的屏幕截图所示：

Scalpel 配置文件

为了包括与 Android 相关的文件，需要修改此文件。可以从asecuritysite.com/scalpel.conf.txt下载示例scalpel.conf文件。您还可以取消注释文件并保存conf文件以选择所需的文件类型。完成后，用下载的文件替换原始的conf文件。

Scalpel 需要与正在检查的dd镜像上的前述配置文件一起运行。您可以使用以下截图中显示的命令运行该工具，输入配置文件和dd文件。运行命令后，该工具开始雕刻文件并相应地构建它们。

在图像文件上运行 Scalpel 工具

前述命令中指定的输出文件夹现在包含基于文件类型的文件夹列表。每种文件类型都包含基于文件夹名称的数据。例如，jpg 2-0包含与.jpg扩展名相关的恢复文件：

Scalpel 工具的输出

如前所示的截图，每个文件夹包含从 Android 设备中恢复的数据，如图像、.pdf文件、.zip文件等。虽然有些图片完全恢复了，但有些并没有完全恢复，如下图所示：

使用 Scalpel 工具恢复的数据

诸如 DiskDigger 之类的应用程序可以安装在 Android 设备上，从内部存储器和 SD 卡中恢复不同类型的文件。诸如 DiskDigger 之类的应用程序包括对.jpg文件、.mp3和.wav音频、.mp4和.3gp视频、原始相机格式、Microsoft Office 文件（.doc、.xls和.ppt）等的支持。然而，如前所述，该应用程序需要在 Android 设备上具有 root 权限才能从内部存储器中恢复内容。因此，文件雕刻技术在从设备的内部存储器中恢复重要的已删除文件中发挥着非常重要的作用。

分析备份

还建议您检查设备是否安装了任何备份应用程序或文件。Android 的初始版本不包括用户备份其个人数据的机制。因此，用户广泛使用了几个备份应用程序。使用这些应用程序，用户可以将其数据备份到 SD 卡或云端。例如，Super Backup应用程序包含了备份通话记录、联系人、短信等选项，如下截图所示：

Super Backup Android 应用

在检测到备份应用程序时，法庭鉴定人员必须尝试确定数据存储在何处。备份中保存的数据可能包含重要信息，因此在设备上寻找任何第三方备份应用程序可能非常有帮助。

您还可以通过设备上配置的 Google 账户使用恢复联系人选项来恢复联系人。如果设备的用户之前使用 Android 中可用的同步设置选项同步了他们的联系人，这将起作用。此选项会同步联系人和其他详细信息，并将它们存储在云端。具有合法权限或适当同意的法庭鉴定人员可以恢复已删除的联系人，如果他们能够访问设备上配置的 Google 账户。一旦访问了该账户，执行以下步骤来恢复数据：

1. 登录 Gmail 账户。

2. 点击左上角的Gmail，选择联系人，如下截图所示：

Gmail 中的联系人菜单

1. 点击更多，位于联系人列表上方。

2. 点击恢复联系人，将出现以下屏幕：

恢复联系人对话框

1. 使用这种技术，您可以将联系人列表恢复到过去 30 天内的任何时间点的状态。

总结

数据恢复是从设备中检索已删除数据的过程。因此，这是取证中一个非常重要的概念。在本章中，我们看到了从 SD 卡和内部存储器中恢复已删除数据的各种技术。虽然从可移动 SD 卡中恢复数据很容易，但从内部存储器中恢复数据涉及一些复杂性。SQLite 文件解析和文件刻录技术可以帮助取证分析人员恢复安卓设备内部存储器中存在的已删除项目。建议检查设备上是否安装了任何备份应用程序，因为这样可以节省时间和精力。

在下一章中，我们将尝试了解对安卓应用程序进行取证分析的视角。

第七章：Android 应用程序取证分析

本章将介绍应用程序分析，使用免费和开源工具。它将重点分析使用第四章和第五章中详细介绍的任何逻辑或物理技术恢复的数据。它还将大量依赖于第二章中讨论的存储方法。我们将看到第二章中描述的文件层次结构中各个位置的众多 SQLite 数据库、XML 文件和其他文件类型。在本章结束时，您应该熟悉以下主题：

• 应用程序分析概述：

• 联系人/通话/短信

• Wi-Fi

• 用户词典

• 列出了第三方应用程序和流行应用程序用于存储和混淆数据的各种方法。

• 纯文本

• 时代时间

• WebKit 时间

• 错误命名文件扩展名

• 儒略日期

• Base64 编码

• 加密

• 基本隐写术

• SQLCipher

• 基本应用程序逆向工程

应用程序分析

对应用程序进行取证分析既是一门艺术，也是一门科学。应用程序可以存储或混淆数据的方式多种多样。甚至同一应用程序的不同版本可能以不同的方式存储相同的数据。当开发者选择如何存储他们的数据时，他们实际上只受到他们的想象力（和 Android 平台的限制）的限制。由于这些因素，应用程序分析是一个不断变化的目标。一天使用的方法可能在第二天就完全无关紧要了。

对应用程序进行取证分析的最终目标始终是相同的，即了解应用程序的用途并找到用户数据。

在本章中，我们将查看许多常见应用程序的当前版本。由于应用程序可以通过更新改变它们存储数据的方式，因此本章中的内容并不是分析该应用程序的权威指南。相反，我们将查看广泛的应用程序范围，展示应用程序用于存储数据的各种不同方法。在大多数情况下，我们将查看非常常见的应用程序（从 Google Play 下载了数百万次），除非查看一个不常见的应用程序可以揭示存储数据的有趣新方法。

注意

虽然我们在填充测试数据时尽力全面地使用了每个应用程序的功能，但有可能并没有使用每个应用程序的每个功能。以下部分中分析的应用程序是如何检查该应用程序的数据的示例，但可能并不包括可能恢复的每一小部分数据。

我们所有的测试都使用了每个应用程序的默认设置，就好像应用程序是下载并立即使用的一样。不同的设置可能会影响存储的数据以及设备上数据的位置。

此外，这项分析是在运行 Android 5.0.1 的 Nexus 5 上进行的。某些制造商，如 HTC 和三星，可能提供复制这些应用程序功能的应用程序（例如访问 Facebook 的主屏幕小部件）。这些应用程序可能会将数据存储在不同的位置。我们分析的一些文件可能在其他版本上不存在。

为什么要进行应用程序分析？

首先，即使是标准的手机功能，如联系人、通话和短信，也是通过 Android 设备上的应用程序完成的。因此，即使获取基本数据也需要我们分析一个应用程序。其次，一个人的应用程序使用情况可以告诉你很多关于他们的信息：他们去过哪里（以及何时去过），他们与谁交流过，甚至他们可能在未来计划做什么。

许多手机在出厂时都预装了 20 多个应用程序。雅虎在 2014 年的一项研究显示，用户平均安装了 95 个应用程序。尼尔森的一项研究显示，平均用户每月使用 26 个应用程序。鉴定人员无法真正知道这些应用程序中哪些可能包含对调查有用的信息，因此所有应用程序都必须进行分析。鉴定人员可能会忽略某些看起来没有多少有用数据的应用程序，比如游戏。然而，这是一个坏主意。许多流行的游戏，比如《Words with Friends》或《Clash of Clans》，都有内置的聊天功能，可能会提供有用的信息。接下来的分析将重点放在消息应用上，因为我们的经验表明这些应用在法证分析中往往是最有价值的。

本章的布局

对于我们检查的每个应用程序，我们将提供包名称、版本号（如果可能的话）和感兴趣的文件。例如：

包名称：com.android.providers.contacts

版本：默认版本，带有 Android 5.0.1（未在应用程序中列出）

感兴趣的文件：

• /files/

• photos/

所有应用程序默认都将其数据存储在/data/data目录中。如果应用程序在安装时请求了这个权限，它们也可以使用 SD 卡。包名称是/data/data目录中应用程序目录的名称。感兴趣的文件来自包名称的根目录（即前面示例中的/data/data/com.android.providers.contacts/files/photos）。SD 卡上数据的路径以/sdcard开头（即/sdcard/com.facebook.orca）。不要期望在应用程序的/data/data目录中找到以/sdcard开头的数据路径！

我们将首先查看一些谷歌的应用程序，因为这些应用程序预装在绝大多数设备上（尽管不一定）。然后，我们将查看可以在 Google Play 上找到的第三方应用程序。

确定安装了哪些应用程序

要查看设备上有哪些应用程序，鉴定人员可以导航到/data/data并运行ls命令。然而，这并不提供格式良好的数据，无法在法证报告中展示。我们建议您提取/data/system/packages.list文件。该文件列出了设备上每个应用程序的包名称和其数据的路径（如果设备上不存在此文件，则adb shell pm list packages -f命令是一个很好的替代方法）。例如，这是 Google Chrome 的一个条目（我们的测试设备上完整的文件包含了 120 个条目）：

注意

这是数据存储的第一种方法：纯文本。通常，我们会看到应用程序以纯文本形式存储数据，包括您意想不到的数据（比如密码）。

也许更有趣的是/data/system/package-usage.list文件，它显示了包（或应用程序）上次使用的时间。这并不完美；文件中显示的时间与我们上次使用应用程序的时间并不完全一致。似乎应用程序的更新或接收通知（即使用户没有查看）可能会影响时间。然而，它对用户最后访问的应用程序的一般指示是有用的：

如果你想知道前一行的时间在哪里，它是以 Linux 纪元时间的格式知道的。

理解 Linux 纪元时间

Linux 纪元时间，也称为 Unix 时间或 Posix 时间，存储为自 1970 年 1 月 1 日 UTC 午夜以来的秒数（或毫秒数）。10 位数表示秒数，而 13 位数表示毫秒数（至少对于可能在智能手机上找到的时间，自 2001 年以来，9 位数秒和 12 位数毫秒值就没有出现过）。

在上面的例子中，该值为1422206858650；Google Chrome 自 1970 年 1 月 1 日午夜以来已经使用了 10 亿 4220 万 6858 秒和 650 毫秒！别担心；我们也不知道那是什么日期/时间。有许多可供下载的脚本和工具可用于将此值转换为人类可读格式。我们更喜欢免费工具DCode，可以在www.digital-detective.net/digital-forensic-software/free-tools/找到。

在 DCode 中，只需从下拉列表中选择Unix：毫秒值，在解码值字段中输入值，然后单击解码：

添加偏差字段可以选择将时间转换为所需的时区。

另外，还有一个非常有用的在线时代转换器，网址为www.epochconverter.com/。

使用任一方法，我们可以看到 Google Chrome 实际上是在 2015 年 1 月 25 日 17:27:38.650 UTC 最后使用的。Linux 时代时间经常用于 Android 设备上存储日期/时间值，并将在我们的应用程序分析中反复出现。

注意

这是第二种数据存储方法：Linux 时代时间。

Wi-Fi 分析

Wi-Fi 在技术上不是一个应用程序（这可以从它没有从/data/data中恢复出来来证明），但它是一个宝贵的数据来源，应该被检查。因此，我们在这里简要讨论一下。Wi-Fi 连接数据可以在/data/misc/wifi/wpa_supplicant.conf中找到。wpa_supplicant.conf文件包含了用户选择自动连接的访问点列表（当连接到新的访问点时，默认设置为自动连接）。用户通过设备设置“忘记”的访问点将不会显示。如果访问点需要密码，密码也会以明文存储在文件中。在下面的例子中，NETGEAR60访问点需要密码（ancientshoe601），而hhonors不需要：

注意

在这个文件中存在服务集标识符（SSID）并不意味着这个设备连接到了该访问点。这些设置保存在用户的 Google 账户中，并在设置该账户时添加到设备中。检查员只能得出用户从某个 Android 设备连接到这些访问点的结论，但不一定是正在检查的设备。

联系人/通话分析

联系人和通话记录存储在同一个数据库中。联系人不一定要由用户明确添加。当通过 Gmail 发送电子邮件时，或者在 Google+上添加一个人，或者可能还有其他许多方式时，它们可能会被自动填充。

包名：com.android.providers.contacts

版本：默认版本与 Android 5.0.1（未在应用程序中列出）

感兴趣的文件：

• /files/

• photos/

• profile/

• /databases/

• contacts2.db

files目录包含了用户联系人的photos目录中的照片和用户的个人资料照片在profile目录中。

contacts2.db数据库包含了设备上所有通话记录和用户 Google 账户中的所有联系人的信息。它包含以下表格：

表格	描述
accounts	这显示了设备上具有访问联系人列表权限的账户。至少一个账户将显示用户的 Google 账户电子邮件地址。此列表可能包括已安装的第三方应用程序，这些应用程序具有访问联系人列表的权限（我们将在 Tango、Viber 和 WhatsApp 部分看到这一点）。

| calls | 这包含有关设备的所有呼入和呼出电话的信息。number列显示远程用户的电话号码，无论是发送还是接收的呼叫。date列是呼叫的日期/时间，以 Linux 时代格式存储。duration列是呼叫的长度，以秒为单位。type列指示呼叫的类型：

• 1 = 收到的

• 2 = 发出的

• 3 = 未接

name列显示远程用户的名称，如果该号码存储在联系人列表中。geocoded_location列显示基于区号（对于美国号码）或国家代码的电话号码的位置。

contacts	这包含联系人的部分信息（更多数据可以在raw_contacts表中找到）。name_raw_contact_id值对应于raw_contacts表中的_id值。photo_file_id值对应于/files/photos目录中找到的文件名。times_contacted和last_time_contacted列显示从设备呼叫或接听该联系人电话的次数，以及最后一次呼叫的时间（Linux 时代格式）。
data	该表包含每个联系人的所有信息：电子邮件地址、电话号码等。raw_contact_id列是每个联系人的唯一值，可以与raw_contact_id中的_id值相关联以识别联系人。请注意，每个联系人可能有多行，如相同的raw_contact_id值所示。有 15 个数据列（data1到data15）包含有关联系人的一些信息，但没有可辨认的模式。同一列可能包含联系人姓名、电子邮件地址、Google+个人资料等。data14列中的值与/files/profiles路径中图像的文件名相关联。data15列包含联系人个人资料照片的缩略图。
deleted_contacts	这包含contact_id值和以 Linux 时代格式的deleted_contact_timestamp。然而，这不能与任何其他表相关联以确定已删除的联系人的名称。可能可以使用第六章中的已删除数据恢复技术来恢复联系人名称。contact_id值对应于raw_contacts表中的contact_id列。
groups	这显示联系人列表中的组，可以是自动生成的或用户创建的。组的标题是组的名称。似乎没有办法识别每个组中的用户。
raw_contacts	这包含联系人列表中每个联系人的所有信息。display_name列显示联系人的名称，如果可用。要确定联系人的电话号码、电子邮件地址或其他信息，必须将_id列的值与数据表中的raw_contact_id值匹配。sync3列显示时间戳，但根据我们的测试，不能假定这是联系人添加的时间。我们有一些几年前的联系人在本月同步了。times_contacted和last_time_contacted列仅适用于电话呼叫；向联系人发送电子邮件或短信不会增加这些值。我们无法确定任何方法来确定联系人是通过电话界面添加的，还是作为 Google+上的朋友添加的，或者是通过其他方法添加的。

短信/彩信分析

短信和彩信消息存储在同一个数据库中。根据我们的经验，无论使用何种应用程序发送短信/彩信（即，通过 Google Hangouts 发送短信将填充此数据库，而不是在此处检查的 Hangouts 数据库），都会使用此数据库。但是，第三方应用程序也可能将数据记录在其自己的数据库中。

包名称：com.android.providers.telephony

版本：Android 5.0.1 的默认版本（在应用程序中未列出）

感兴趣的文件：

• /app_parts

• /databases/

• mmssms.db

• telephony.db

app_parts目录包含了作为彩信发送和接收的附件。

telephony.db数据库很小，但包含了一个潜在有用的信息来源。telephony.db 中的表描述如下：

表	描述
siminfo	这包含了设备中使用过的所有 SIM 卡的历史数据，包括 ICCID、电话号码（如果存储在 SIM 卡上）和移动国家码（MCC）/ 移动网络码（MNC），可以用来识别网络提供商。

mmssms.db数据库包含了关于短信和彩信消息的所有信息，如下表所述：

表	描述
part	这包含了附加到彩信的文件的信息。每条消息至少有两个部分：一个 SMIL 头和附件。这可以在mid和ct列中看到，以及附加的文件类型。_data列提供了在设备上找到文件的路径。
pdu	这包含了每条彩信的元数据。date列标识了消息发送或接收的时间，以 Linux 纪元格式表示。_id列似乎对应于 part 列中的 mid 值；对这些值进行对应将显示特定图像发送的时间。msg_box列显示消息的方向（1 = 接收，2 = 发送）。
sms	这包含了每条短信的元数据（不包括 MMS 信息）。address列显示远程用户的电话号码，无论是发送还是接收消息。person列包含一个值，可以在contacts2.db数据库中查找，并与data表中的raw_contact_id对应。如果是发送消息或远程用户不在联系人列表中，person列将为空。date列显示消息发送的时间戳，以 Linux 纪元格式表示。type列显示消息的方向（1 = 接收，2 = 发送）。body列显示消息的内容。seen列指示消息是否已读（0 = 未读，1 = 已读）；所有发送的消息都将标记为未读。
words，words_content，words_segdir	这似乎包含了重复的消息内容；这个表的确切目的不清楚。

用户词典分析

用户词典是调查员的一个难以置信的数据来源。虽然它不一定是一个独立的应用程序，但它的数据存储在/data/data目录中，就好像它是一个独立的应用程序一样。用户词典在用户输入一个未被识别的单词并选择保存该单词以避免被自动更正时被填充。有趣的是，我们的测试设备上包含了许多我们从未在设备上输入或保存过的单词。这些数据似乎与用户的 Google 账户同步，并在多个设备上持久存在。从账户同步的单词按字母顺序添加到数据库顶部，而之后手动添加的单词则按添加顺序填充到底部。

包名：com.android.providers.userdictionary

版本：Android 5.0.1 的默认版本（在应用程序中未列出）

感兴趣的文件：

• /databases/user_dict.db

用户词典中的表描述如下：

表	描述
words	word列包含了添加到词典中的单词。frequency列可能应该被忽略；无论我们使用该单词的次数如何，它都显示相同的值（250）。

以下是用户词典的示例条目：

Gmail 分析

Gmail 是谷歌提供的电子邮件服务。在首次设置设备时，通常会要求使用 Gmail 帐户，但并非必需。

包名称：com.google.android.gm

版本：默认版本与 Android 5.0.1（未在应用程序中列出）

感兴趣的文件：

• /cache

• /databases/

• mailstore.<username>@gmail.com.db

• databases/suggestions.db

• /shared_prefs/

• MailAppProvider.xml

• Gmail.xml

• UnifiedEmail.xml

应用文件夹中的/cache目录包含最近附加到电子邮件中的文件，包括已发送和已接收的文件。即使用户没有明确下载这些附件，它们也会保存在这里。

mailstore.<username>@gmail.com.db文件包含各种有用的信息。数据库中的有趣表包括以下内容：

表	描述
附件	这包含有关附件的信息，包括它们在设备上的大小和文件路径（前面提到的/cache目录）。每行还包含一个messages_conversation值。这个值可以与conversations表进行比较，以将附件与其所包含的电子邮件相关联。filename列标识了文件在设备上的路径。
对话	在旧版本中，可以恢复整个电子邮件对话。在当前版本中，Google 不再在设备上存储整个对话，可能是因为假定用户将有数据连接来下载完整的对话。相反，只能恢复主题行和“片段”。片段大致是在应用程序的通知栏或收件箱屏幕上显示的文本量。fromCompact列标识了发件人和其他收件人。

suggestions.db数据库包含在应用程序中搜索的术语。

shared_prefs目录中的 XML 文件可以确认与应用程序一起使用的帐户。Gmail.xml包含了另一个与我们的测试帐户关联但从未与应用程序一起使用的帐户。UnifiedEmail.xml包含了给该帐户发送电子邮件的发件人的部分列表，但没有明显的原因。列表中有许多发件人，但远非全部，并且它们没有按特定顺序出现。Gmail.xml还包含了应用程序上次同步的时间，以 Linux 纪元格式表示。

Google Chrome 分析

Google Chrome 是一款网络浏览器，也是 Nexus 和许多其他设备上的默认浏览器。设备上的 Chrome 数据有些独特，因为它不仅包含来自设备的数据，还包含用户在所有登录到 Chrome 的设备上的数据。这意味着用户在桌面电脑上浏览的数据很可能会在他们手机的数据库中找到。然而，这也导致了大量的数据需要鉴定人员整理，但这是一个好问题。

包名称：com.android.chrome

版本：40.0.2214.89

感兴趣的文件：

• /app_chrome/Default/

• Sync Data/SyncData.sqlite3

• 书签

• Cookies

• Google Profile Picture.png

• 历史

• 登录数据

• 偏好设置

• 热门网站

• Web 数据

• /app_ChromeDocumentActivity/

/app_chrome/Default文件夹中列出的所有文件，除了一个.png文件、书签和偏好设置之外，都是 SQLite 数据库，尽管没有文件扩展名。

SyncData.sqlite3数据库很有趣，因为它似乎包含了从用户设备同步到谷歌服务器的数据列表。我们的数据库中，一个活跃的 Chrome 账户包含了超过 2700 条条目，包括浏览历史、自动填充表单信息、密码和书签。举例来说，我们能够找到其中一位作者从 2012 年搜索过的一个词，如下截图所示。这很有趣，因为用户是在 2014 年购买了这部手机，但之前的数据仍然同步到了设备上。

表	描述
metas	数据库中有许多列包含时间戳，在我们的数据库中，它们似乎都是每个条目的时间相差不到一秒。目前还不清楚哪个时间对应于条目被添加的确切时间，但所有时间大致对应于用户账户中的活动时间。具有时间戳的列包括mtime、server_mtime、ctime、server_ctime、base_version和server_version。non_unique_name和server_non_unique_name列显示了被同步的内容。例如，我们的一个条目显示：autofill_entry | LNAME | Tindall这些列中的其他条目包括访问过的 URL、密码，甚至是账户使用过的设备。

Bookmarks文件是一个纯文本文件，包含了与账户同步的书签信息。它包括了每个被书签的网站名称、URL 以及被书签的日期/时间，以我们尚未遇到的格式存储：WebKit 格式。要解码这些值，请参阅解码 WebKit 时间格式部分。

注意

这是第三种数据存储方法：WebKit 时间格式。

Cookies数据库存储了访问过的网站的 cookie 信息（取决于网站和 Chrome 设置），包括网站名称、cookie 保存日期以及上次访问 cookie 的时间，以 WebKit 时间格式显示。

Google Profile Picture.PNG文件是用户的个人资料图片。

History数据库包含了用户的网络历史，存储在以下表中：

表	描述
keyword_search_terms	这包含了在 Chrome 中使用 Google 搜索的搜索词列表。term列显示了搜索的内容，而url_id可以与 URL 表相关联，以查看搜索的时间。
segments	这个表包含了一些被访问过的 URL，但并非全部。目前还不清楚是什么导致数据被输入到这个表中。
urls	这包含了 Google 账户在所有设备上的浏览历史，而不仅仅是从数据库中提取的设备。我们的历史记录大约可以追溯到 3 个月前，包含了 494 条记录，尽管 Google 账户的历史要比这更久，我们在那段时间内肯定访问了超过 494 个页面。目前还不清楚是什么导致了这种差异，或者决定了历史记录的截止日期。id列是表中每行的唯一值。url和title列包含了访问的 URL 和页面名称。visit_count列似乎是 URL 被访问的准确次数。typed_count列的值始终等于或小于visit_count列的值，但我们不确定它具体表示什么。对于一些网站，这种差异可以通过考虑通过书签访问网站的次数来解释，而不是直接输入 URL，但并非所有情况都适用。last_visit_time列是 URL 最后被访问的时间，以 WebKit 时间格式显示。
访问	这包含了 urls 表中每次访问的行；此表中对于一个 URL 的条目数量对应于url表中的visit_count列的值。url列的值与url表中的id列的值相关联。每次访问的时间可以在visit_time列中找到，同样以 WebKit 时间格式。

登录数据数据库包含在 Chrome 中保存的登录信息，并在使用 Google 账户的所有设备上同步。

表	描述
logins	origin_url是用户最初访问的网站，action_url是如果用户被重定向到登录页面，则是登录页面的 URL。如果访问的第一个页面是登录页面，则两个 URL 相同。username_value和password_value列显示了以明文存储的该 URL 的用户名和密码；不，我们不会包含我们数据库的截图！创建日期是登录信息首次保存的日期/时间，以 WebKit 时间格式存储。同步日期列是登录数据在本地设备上同步的日期/时间，同样以 WebKit 时间格式。使用次数列显示了 Chrome 保存后自动填充登录信息的次数（不包括第一次登录，因此有些值可能为 0）。

首选项文件是一个文本文件，包含用户使用 Chrome 登录的 Google 账户。

热门网站数据库包含最常访问的网站，因为这些网站在 Chrome 打开时默认显示。

Web Data数据库包含用户保存的信息，以便在网站上自动填写表单。

表	描述
autofill	这包含基于网页的表单上的字段列表和用户输入的值。名称列显示了用户输入的字段名称，而值列显示了用户输入的内容。创建日期和最后使用日期列是不言自明的，并以 Linux 纪元格式存储。请注意，虽然这可能是非常有价值的信息（例如，我们的数据库中包含了一些其他地方没有存储的用户名），但可用的上下文信息非常少。信息未存储的 URL 可能无法确定。
autofill_profile_emails	这包含用户保存的所有值，用于自动填充网页表单上的电子邮件字段。
autofill_profile_names	这包含用户保存的所有值，用于自动填充网页表单上的名、中间名、姓和全名字段。
autofill_profile_phonwa	这包含用户保存的所有值，用于自动填充网页表单上的电话号码字段。
autofill_profiles	这包含用户保存的所有值，用于自动填充网页表单上的地址信息字段。

/app_ChromeDocumentActivity/目录包含了在设备上最近打开的标签的历史记录文件。可以从这些文件中恢复被访问的网站的 URL。

解码 WebKit 时间格式

以下是一个样本 WebKit 时间值：13066077007826684。

乍一看，它似乎与 Linux 纪元时间非常相似，只是稍微长一些（也许它存储的是纳秒？）。试图将其解码为纪元时间的审查员将得到 2011 年 5 月的日期，这可能看起来准确，但实际上比正确日期晚了几年！

WebKit 时间是一个纪元时间。它只是以不同的起始点为基础，而不是 Linux 纪元时间。WebKit 纪元时间是自 1601 年 1 月 1 日午夜以来的微秒数。是的，我们说的是 1601 年。一旦我们知道纪元开始的地方，转换为可识别的格式就变成了一个数学问题。然而，再一次，我们宁愿使用 DCode。

这一次，在 DCode 中，选择解码格式下拉选择中的 Google Chrome 值，然后单击解码：

我们示例的实际值是 2014 年 11 月 2 日 UTC 时间 18:04:33。这与我们认为的 Linux 纪元时间值有很大不同！

Google Maps 分析

Maps 是由 Google 提供的地图/导航应用程序。

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

版本：9.2.0（#902013124）

感兴趣的文件：

• /cache/http/

• /databases/

• gmm_myplaces.db

• gmm_storage.db

/cache/http文件夹中包含许多文件，具有.0和.1文件扩展名。.0文件是对应.1文件的网络请求。.1文件主要是图像，可以通过适当更改其扩展名来查看。在我们的测试设备上，它们要么是.jpg文件，要么是.png文件。这些文件主要是用户附近的位置，不一定是用户专门搜索的位置。

注意

这是第四种数据存储方法：错误命名的文件扩展名。

始终验证无法打开的文件的标头，或使用 EnCase 等自动工具检测不匹配的标头/文件扩展名。验证文件签名的一个很好的资源是www.garykessler.net/library/file_sigs.html。

gmm_myplaces.db数据库包含了用户保存的位置。这个文件与用户的 Google 帐户同步，因此这些位置不一定是使用应用程序保存的。

gmm_storage.db数据库包含了以下表中的搜索结果和导航到的位置：

表	描述
gmm_storage_table	_key_pri列似乎标识了位置的类型。bundled 似乎是搜索结果，而ArrivedAtPlacemark标识了实际导航到的位置。_data列包含位置的地址。

Google Hangouts 分析

Hangouts是由 Google 提供的聊天/SMS 应用程序。 Hangouts 是 Android 设备上的默认短信客户端。

包名称：com.google.android.gm

版本：Android 5.0.1 的默认版本（不在应用程序中列出）

感兴趣的文件：

• /cache/volleyCache/

• /databases/babel#.db（我们的设备上有 babel0.db 和 babel1.db）

• /shared_prefs/accounts.xml

cache目录包含了之前在 Google Maps 示例中讨论的.0文件。这些文件包含了获取联系人的个人资料图片的 URL，以及文件中嵌入的.jpg。访问 URL 或从文件中提取.jpg将恢复联系人的图片。

babel#.db文件包含了所有的消息数据。在我们的测试设备上，babel0.db是空白的，babel1.db包含了活动帐户的所有数据。这个数据库中有许多值得关注的表：

表	描述
conversations	这包含对话数据。每次聊天都有一个唯一的conversation_id值。latest_message_timestamp列是最近聊天的时间，以 Linux 纪元格式表示。generated_name列列出了聊天中所有参与者的列表，减去设备上的帐户。snippet_text列是最近消息的内容；与 Gmail 一样，整个聊天并未存储在设备上。latest_message_author_full_name和latest_message_author_first_name列标识了snippet_text列的作者。inviter_full_name和inviter_first_name列标识了谁发起了对话。
dismissed_contacts	这里列出了曾经发送消息的前联系人的名称。这些在应用程序中标记为“隐藏联系人”。
messages	如预期的那样，这包含了每次对话的详细消息历史。text列包含消息的内容，timestamp列是 Linux 纪元格式的日期/时间。remote_url列再次是一个 URL，用于检索消息中共享的图像。同样，它可以公开访问。author_chat_id是一个值，可以与参与者表相关联，以识别每条消息的作者。
participants	这包含了与之聊天的人的列表。它包括全名、个人资料图片 URL 和chat_id值，用于在消息表中识别该人。

accounts.xml文件有一个phone_verification字段，其中包含与 Google 帐户关联的电话号码，当 Hangouts 配置为发送短信时。这可能非常有用，因为通常很难获得设备的电话号码，因为它通常不存储在设备上。

谷歌 Keep 分析

Keep 是谷歌提供的一款笔记应用。它也可以用来设置提醒，无论是在特定的日期/时间还是当用户在指定的位置。

包名称：com.google.android.keep

版本：默认版本为 Android 5.0.1（未在应用程序中列出）

感兴趣的文件：

• /databases/keep.db

• /files/1/image/original

files/1/image/original目录包含使用该应用程序拍摄的照片。笔记和提醒都可以与图像关联。

keep.db包含有关笔记和提醒的所有信息。再次，有几个感兴趣的表：

表	描述
alert	这包含了基于位置的提醒的信息。reminder_id列可以与提醒表中的条目相关联。reminder_detail表包含为提醒设置的纬度和经度。scheduled_time列是提醒设置的日期/时间，以 Linux 纪元时间表示。
blob	这包含了关于/files目录中图像的元数据，包括文件名和大小。blob_id列可以与blob_node表中的_id列相关联。
blob_node	这包含了/files目录中图像的创建时间值，以 Linux 纪元时间表示。
list_item	这个表存储设备上每个笔记的数据。text列包含每个笔记的完整文本。list_parent_id列是每个笔记的唯一值。如果多行具有相同的值，这意味着它们是在同一个笔记中创建的列表。time_created和time_last_updated列是笔记创建的时间和最后与 Google 服务器同步的时间，以 Linux 纪元时间表示。
reminder	这包含了应用程序中设置的每个提醒的数据。如果提醒是基于时间的，julian_date和time_of_day列将被填充。

转换儒略日期

儒略日期类似于 Linux 纪元格式，只是从不同的日期开始。儒略日期系统计算自公元前 4713 年 1 月 1 日中午以来的天数。美国海军天文台有一个出色的儒略日期计算器。要从数据库中获取儒略日期，只需将两列组合在一起，中间加上一个小数点。这是一个例子：

前面的日期将对应于儒略日期 2457042.46800000。当这个值输入到网站时，我们可以发现提醒设置的日期是 2015 年 1 月 19 日 23:13:55:2 UTC。如果提醒是基于位置设置的，location_name、latitude、longitude和location_address列将被填充。最后，time_created和time_last_updated列是笔记创建的时间和最后与 Google 服务器同步的时间，以 Linux 纪元时间表示。

注意

第五种数据存储方法是儒略日期。

谷歌加分析

Google Plus 是基于 Google 的社交网络。它允许我们分享文本/视频/图片，添加朋友，关注人，并发送消息。根据用户的设置，Google Plus 也可能自动上传用户设备上拍摄的所有照片。

包名称：com.google.android.apps.plus

版本：4.8.0.81189390

感兴趣的文件：

• /databases/es0.db

Es0.db数据库包含了审查员期望从社交媒体账户中找到的所有信息：

表	描述
all_photos	这包含了用户分享和与用户分享的图片的下载 URL，以及以 Linux 纪元格式表示的创建日期/时间。
activites	这包含在用户的流中显示的数据（即他们的新闻动态）。每篇帖子的创建和修改时间再次存储在 Linux 纪元时间中。标题和评论栏将包含帖子标题以及至少一些评论。permalink栏包含一个 URL，可以通过它来查看帖子，如果它是公开分享的。如果帖子是私下分享的，内容仍然可以从嵌入表中恢复。relateds栏包含 Google 自动生成的帖子标签；即使帖子是私密的，这也会被填充。
activity_contacts	这包含了在活动表中发布帖子的人的姓名列表。
all_photos	这包含了用户备份到 Google Plus 的所有照片列表，无论它们是否被分享。image_url栏中的值可以用于下载用户的任何照片，并且是公开可用的。删除 URL 末尾的-d将查看图片而不是下载。timestamp栏是根据图像元数据拍摄的日期/时间。它不表示图像上传的时间。
all_tiles	这包含了all_photos的一个未知子集，但也包括了与用户分享的图片。
circle_contact	这包含了用户添加到他们圈子中的人的列表。它不包括姓名，但一些link_person_id值包括电子邮件地址。link_circle_id值可以与圈子表相关联，以识别每个圈子的名称。然后link_person_id值可以与联系人表相关联，以确定哪个用户在哪个圈子中。
circles	这包含了用户创建的所有圈子，以及每个圈子中用户数量的计数。
contacts	这包含了用户圈子中的所有联系人列表。
events	这列出了用户被邀请参加的所有活动，无论他们是否参加。name栏是活动的标题。creator_gaia_id栏可以与联系人表中的gaia_id栏相关联，以识别活动的创建者。start_time和end_time栏是活动的时间，以 Linux 纪元格式表示。event_data栏包含活动创建者输入的活动描述，以及如果添加了位置信息。它还列出了所有其他被邀请参加活动的用户。
squares	这包含了用户加入的群组列表。

Facebook 分析

Facebook 是一个社交媒体应用程序，从 Google Play 已经下载了超过 10 亿次。

包名称：com.facebook.katana

版本：25.0.0.19.30

感兴趣的文件：

• /files/video-cache/

• /cache/images/

• /databases/

• bookmarks_db2

• contacts_db2

• nearbytiles_db

• newsfeed_db

• notifications_db

• prefs_db

• threads_db2

/files/video-cache目录包含了用户新闻动态中的视频，尽管似乎没有办法将它们与发布它们的用户相关联。

/cache/images目录包含用户新闻动态中的图片以及联系人的个人资料照片。该目录包含大量其他目录（我们测试手机上有 65 个），每个目录可以包含多个.cnt文件。.cnt文件通常是.jpg文件或其他图像格式。

bookmarks_db2数据库是用户新闻动态侧边栏上显示的项目列表，例如群组和应用程序。许多这些书签是 Facebook 自动生成的，但也可能是用户创建的。

表	描述
bookmarks	这包含了数据库中的所有信息。bookmark_name列是显示给用户的书签的名称。bookmark_pic列有一个公开可访问的 URL，用于查看显示给用户的bookmark图标。bookmark_type列标识了群组的类型。我们的测试显示了profile、group、app、friend_list、page和interest_list。最后，bookmark_unread_count列显示了用户尚未阅读的群组中的消息数量。

contacts_db2数据库可预见地包含有关用户所有联系人的信息，存储在以下表中：

表	描述
contacts	这包含了有关用户联系人的所有信息。fbid列是用于在其他数据库中标识联系人的唯一 ID。first_name、last_name和display_name列显示了联系人的姓名。small_picture_url、big_picture_url和huge_picture_url列包含了联系人个人资料图片的公开链接。communication_rank列似乎是一个数字，用于标识联系人与用户的交流频率（考虑到消息、评论和可能的其他因素）；数字越高表示与该联系人的交流越频繁。added_time_ms列显示了联系人被添加为好友的时间（以 Linux 纪元格式）。bday_day和bday_month列显示了联系人的生日日期，但不包括年份。data列包含了数据库中所有其他数据的副本，但也包含了联系人的位置，这在数据库的其他地方找不到。

nearbytiles_db数据库包含用户附近可能感兴趣的位置。这显然是不断填充的，即使用户不查看这些位置。这很有趣，因为虽然它不是精确的位置（我们大部分的测试显示位置在我们位置的 6-10 英里内），但它是用户曾经去过的地方的一个大致概念。

表	描述
nearby_tiles	这包含了用户附近位置的纬度和经度值，以及从 Facebook 服务器检索到该位置的时间，格式为 Linux 纪元。

newsfeed_db数据库包含显示给用户的新闻动态数据。根据应用程序的使用情况，它可能是一个非常大的文件，包含以下表：

表	描述
home_stories	fetched_at列显示了从 Facebook 服务器获取故事的时间，很可能与用户使用应用程序的时间或看到故事的时间密切对应。story_data列包含以数据块形式存储的故事。在十六进制或文本编辑器中查看时，可以找到发布故事的人的用户名。帖子的内容也可以以纯文本形式找到，并且通常以标签text开头。以下截图显示了一个示例。

注意

请注意story_data列中这个单元格的实际内容。它包含超过 10,000 字节的数据，尽管实际消息只有大约 50 字节。

notifications_db数据库包含发送给用户的通知，存储在以下表中：

表	描述
gql_notifications	seen_state列显示通知是否已被查看和阅读。updated列包含通知更新的时间（即，如果未读则发送的时间，如果已读则阅读的时间），以 Linux 纪元格式表示。gql_payload列包含通知的内容以及发送者，类似于newsfeed_db中的story_data列。消息内容再次经常以标记text开头。summary_graphql_text_with_entities和short_summary_graphql_text_with_entities列中可以找到更少量的显示通知文本的数据。profile_picture_uri包含一个公共 URL，可以查看发送者的个人资料图片，icon_url列有一个链接，可以查看与通知相关的图标。

prefs_db数据库包含以下方式存储的应用程序偏好设置：

表	描述
preferences	/auth/user_data/fb_username行显示用户的 Facebook 用户名。/config/gk/last_fetch_time_ms值是应用程序与 Facebook 服务器最后通信的时间戳，但可能不是用户最后与应用程序互动的确切时间。/fb_android/last_login_time值显示用户通过应用程序登录的最后时间。数据库包含许多其他时间戳。将这些时间戳放在一起，可以用来构建应用程序使用情况的良好概况。/auth/user_data/fb_me_user值包含有关用户的数据，包括他们的姓名、电子邮件地址和电话号码。

threads_db数据库包含以下方式描述的消息信息：

表	描述
messages	每条消息在msg_id列中有一个唯一的 ID。text列包含纯文本消息。sender列标识消息发送者的 Facebook ID 和姓名。timestamp_ms列是消息发送的时间，以 Linux 纪元格式表示。attachments列包含检索附加图像的公共 URL。coordinates列如果发送者选择显示他们的位置，则会包含发送者的纬度和经度。source列标识消息是通过网站还是应用程序发送的。

Facebook Messenger 分析

Facebook Messenger 是一个独立于主要 Facebook 应用程序的消息应用程序。在 Play 商店中已经有超过 5 亿次下载。

包名称：com.facebook.orca

版本：18.0.0.27.14

感兴趣的文件：

• /cache/

• audio/

• fb_temp/

• image/

• /sdcard/com.facebook.orca

• /files/ rti.mqtt.analytics.xml

• /databases/

• call_log.sqlite

• contacts_db2

• prefs_db

• threads_db2

/cache/audio目录包含通过应用程序发送的音频消息。这些文件具有.cnt文件扩展名，但实际上是可以在 Windows Media Player、VLC 媒体播放器和其他程序中播放的.riff文件。

/cache/fb_temp路径包含通过应用程序发送的图像和视频的临时文件。目前尚不清楚这些文件会保留多久。在我们的测试中，我们发送和接收了总共五个文件，一周后所有五个文件仍然在临时文件夹中。

/cache/image目录包含大量其他目录（在我们的测试手机上有 33 个），每个目录可以包含多个.cnt文件。应该验证每个文件的文件头，因为有些是视频文件，有些是图像。找到了fb_temp文件夹中的几个文件，以及一些联系人的个人资料图片。

SD 卡上的fb_temp文件夹仅包含发送的图像和视频。

该应用程序还包括一个选项（默认情况下禁用），可以将所有接收的图像/视频下载到设备的图库中。如果选择了此选项，所有接收的图像/视频将在 SD 卡上找到。

/files/rti.mqtt.analytics.xml文件包含用户的 Facebook UID。

call_log.sqlite数据库包含通过应用程序进行的通话记录。person_summary表包含以下描述的相关数据：

表	描述
person_summary	user_id列包含远程用户的 Facebook ID。这可以与contacts_db2中的fbid列进行关联，以确定用户的姓名。last_call_time列包含以 Linux 纪元格式记录的上次通话时间。该表不包含通话的方向信息（发送或接收）。

contacts_db2文件是一个 SQLite 数据库，尽管没有文件扩展名。该数据库中的有用表包括以下表：

表	描述
contacts	该表包括用户添加的联系人，以及从用户电话簿中抓取的联系人（如果电话簿联系人使用 Facebook Messenger）。它包含每个联系人的名字和姓氏，以及该联系人的 Facebook ID（如前面的call_log.sqlite表中所讨论的）。added_time_ms列显示每个用户被添加到应用程序中的时间。这可以让人们了解联系人是手动添加还是自动添加的。一组在几毫秒内添加的大量联系人很可能是在安装应用程序时自动创建的。small_picture_url、big_picture_url和huge_picture_url列包含联系人个人资料图片的公共链接。联系人的电话号码可以在数据列中的信息块中找到。值得注意的是，我们不知道数据库中的一些联系人是从哪里来的。他们不是我们账户的 Facebook 好友，也不是我们设备电话簿中的联系人，但是在电话簿被抓取的同时被添加。我们最好的猜测是我们手机中的一些联系人的电话号码被 Facebook 与其他用户关联起来。
favorite_contacts	favorite_contacts表显示用户添加为收藏夹的联系人。它们由fbid列标识，可以与联系人表进行关联。

prefs_db数据库包含有关应用程序和账户的有用元数据：

表	描述
preferences	/messenger/first_install_time值表示应用程序安装的时间，以 Linux 纪元时间表示。/auth/user_data/fb_username值显示与应用程序关联的用户名。/config/neue/validated_phonenumber值显示与应用程序关联的电话号码。用户的名字和姓氏可以在/auth/user_data/fb_me_user值中找到。

最后，threads_db2数据库包含有关消息的数据：

表	描述
group_clusters	这显示用户创建的文件夹。
group_conversations	这包含每个群聊的thread_key值。这可以与messages表进行关联。
messages	thread_key值是为每个聊天会话生成的唯一 ID。text列包含发送和接收的每条文本消息的内容。这还可以通过短语“您呼叫了 Facebook 用户。”、“Facebook 用户呼叫了您。”和“您错过了来自 Facebook 用户的电话。”来识别语音通话。sender列标识每条消息的发送者（或每次通话的发起者）。timestamp_ms列以 Linux 纪元格式显示每条消息发送的时间。attachments列将显示每个发送或接收的附件的数据。文件类型也可在数据中看到。pending_send_media_attachment列显示设备上恢复已发送附件的路径。直接找到接收的附件似乎不可能，尽管它们在前面讨论过的/cache/images目录中被恢复。没有办法将它们与特定的消息或发送者进行关联。

Skype 分析

Skype 是一款语音/视频通话应用，也是一款由微软拥有的消息应用。它在 Google Play 上有超过 1 亿次安装。

包名称：com.skype.raider

版本：5.1.0.58677

感兴趣的文件：

• /cache/skype-4228/DbTemp

• /sdcard/Android/data/com.skype.raider/cache/

• /files/

• shared.xml

• <username>/thumbnails/

• <username>/main.db

• <username>/chatsync

/cache/skype-4228/DbTemp目录包含多个没有扩展名的文件。其中一个文件（在我们的设备上为temp-5cu4tRPdDuQ3ckPQG7wQRFgU）实际上是一个包含它连接到的无线接入点的 SSID 和媒体访问控制（MAC）的 SQLite 数据库。

SD 卡路径将包含在聊天中接收的任何图像或文件。如果下载了文件，它将位于 SD 卡根目录下的Downloads文件夹中。

shared.xml文件列出了帐户的用户名以及连接到 Skype 的最后 IP 地址：

<username>/thumbnails目录包含了用户的个人资料图片。

main.db数据库包含了应用程序的使用历史记录。一些重要的要查看的表格如下：

表格	描述
Accounts	显示了设备上使用的帐户和相关的电子邮件地址。
CallMembers	这包括了应用程序的通话日志。duration表是通话的持续时间，start_timestamp列是 Linux 纪元格式的开始时间；如果呼叫没有被接听，这两列都不会被填充。creation_timestamp列是呼叫的实际开始时间。只要在应用程序中发起呼叫，它就会被填充，所以即使未接听的呼叫也会显示在这一列中。ip_address列显示了连接呼叫的用户的 IP 地址。type列指示呼叫是呼入还是呼出（1=呼入，2=呼出）。guid列还显示了呼叫的方向，从左到右列出了每个参与者，左侧的用户是发起呼叫的用户。call_db_id列可以与Calls表相关联，以找到有关呼叫的更多信息。
Calls	这与CallMembers非常相似，但信息较少。值得注意的是，这个表中的begin_timestamp列与CallMembers中的creation_timestamp是相同的。有一个is_incoming列来显示呼叫的方向；0表示呼出，1表示呼入。最后，值得注意的是，一些呼叫的持续时间与CallMembers表中的持续时间不匹配。其中一个持续时间比另一个表中指示的持续时间长一秒。看起来CallMembers表根据start_timestamp计算持续时间，而Calls表根据begin_timestamp计算持续时间。持续时间的差异很可能是由用户接受呼叫所花费的时间引起的。
ChatMembers	这显示了每个聊天中的用户。adder列列出了发起聊天的用户。
Chats	这列出了每个唯一的聊天会话。timestamp列是对话开始的日期/时间，以 Linux 纪元格式表示。dialog_partner列显示了聊天中的用户，不包括设备上的帐户。posters列显示了在聊天中发表评论的每个用户，如果设备上的帐户已经发表了，也会包括在内。participants列类似于dialog_partner列，但包括用户的帐户。最后，dbpath列包含在<username>/chatsync目录中找到的聊天备份文件的名称。这在进一步分析中将变得重要。
Contacts	这实际上是一个非常误导性的表。在我们的测试中，我们向我们的联系人列表中添加了两个用户；Contacts表有 233 个条目！is_permanent列指示了此表中列出的用户的状态；如果是1，用户将作为实际联系人添加到应用程序中。其他 231 个条目似乎是在我们搜索联系人时出现的结果，但我们从未与他们交流或添加他们。
Conversations	我们不知道Conversations和Chats之间的区别。它们大部分包含相同的信息，实际上似乎是在引用相同的聊天会话。

| Messages | 这包含了来自聊天/对话的每条单独消息。convo_id列对于每个对话有一个唯一的值；具有相同convo_id值的任何消息都来自同一个对话。author和from_dispname列显示了谁写了每条消息。timestamp列再次显示了消息的日期/时间，以 Linux 纪元格式显示。type列指示了发送的消息的类型。以下是我们测试的值：

• 50: 好友请求

• 51: 请求已接受

• 61: 纯文本消息

• 68: 文件传输

• 30: 通话开始（语音或视频）

• 39: 通话结束（语音或视频）

• 70: 视频消息

body_xml列包含消息的内容。对于纯文本消息和好友请求，内容就是消息的内容。文件传输显示文件的大小和名称。视频消息显示它们是视频消息，但没有提供其他信息。通话如果连接了会显示持续时间，如果错过/忽略了则不会显示持续时间。identities列显示谁发送了每条消息，但如果是由设备上的用户帐户发送的，则可能为空。reason列似乎是用于通话，并显示no_answer或busy来解释为什么通话未连接。

Participants	这类似于ChatMembers。它显示了参与聊天/对话的每个用户。
SMSes	我们的测试不包括短信。然而，这个表中的每一列似乎都很容易理解。
Transfers	这显示了有关传输文件的信息。这包括文件名、大小和设备上的路径。partner_dispname列标识了哪个用户开始了文件传输。
VideoMessages	这显示了视频消息的作者和创建时间戳。请注意，视频消息不存储在设备上。如何访问它们将在本章的后面单独的部分中介绍。
VoiceMails	我们的测试不包括语音邮件。然而，这个表中的每一列似乎都很容易理解。

从 Skype 中恢复视频消息

正如前面所述，视频消息不会存储在设备上。幸运的是，它们可以通过互联网访问。第一步是通过查看Messages表中的body_xml列来验证是否发送了视频消息。接下来，注意以下截图中显示的消息的convo_id字段。

我们的视频消息在convo_id 257中。

第三步，在Chats表中查找conv_dbid列中的convo_id，并找到dbpath值。这将是对话的备份文件的名称，如下截图所示：

要找到备份文件，请查看files/<username>/chatsync。每个对话都会有一个文件夹；文件夹的名称是备份名称的前两位数字。我们的备份将在文件夹28中。

在十六进制编辑器中打开备份文件，并搜索videomessage。你应该会找到一个 URL 和一个访问视频的代码：

从 Skype 中恢复视频消息

注意

实际上，访问该 URL 可能需要额外的授权或法律许可，具体取决于您当地的司法管辖区。由于这些数据不在设备上并且是私人的，未经法律指导的查看可能会使视频中发现的任何证据无效。

Snapchat 分析

Snapchat 是一个拥有超过 1 亿次下载的图片分享和文本消息服务。它的特色是发送的图像和视频会在发送者设定的时间限制内"自毁"，从 1-10 秒不等。此外，如果用户对图像截屏，发送者会收到通知。文本聊天没有过期计时器。

包名称：com.snapchat.android

版本：8.1.2

感兴趣的文件：

• /cache/stories/received/thumbnail/

• /sdcard/Android/data/com.snapchat.android/cache/my_media/

• /shared_prefs/com.snapchat.android_preferences.xml

• /databases/tcspahn.db

/cache/stories/received/thumbnail路径包含用户在设备上拍摄的缩略图。/sdcard路径包含全尺寸图像。即使超过时间限制，接收者也无法再访问这些图像。这两个位置的文件可能没有正确的文件扩展名。

com.snapchat.android_preferences.xml文件包含了用于创建账户的电子邮件地址以及与账户注册的设备的电话号码。

tcspahn.db数据库包含了应用程序使用的所有其他信息：

表	描述
聊天	这列出了所有的文本聊天。它显示了发送者、接收者和 Linux 纪元时间戳以及消息的文本。
Snapchat 上的联系人	这显示了用户电话簿中安装了 Snapchat 的所有用户。如果用户实际上已被添加为联系人，则isAddedAsFriend列将显示1值。
对话	这包含了每个打开对话的信息。它包括发送者和接收者以及最后发送和接收的快照的时间戳（以 Linux 纪元格式）。
朋友	这类似于Snapchat 上的联系人，但只包括已添加为好友的用户。它包括每个用户添加对方的时间戳。
接收的 Snaps	这包含了关于接收的图像和视频的元数据。一旦图像/视频被查看，它似乎会在某个时候从这个表中删除。它包含每条消息的时间戳、状态、快照是否被截屏的信息以及发送者。
发送的 Snaps	这包含了关于发送的图像和视频的元数据。一旦图像/视频被查看，它似乎会在某个时候从这个表中删除。它包含每条消息的时间戳、状态和接收者。

Viber 分析

Viber 是一个拥有超过 1 亿次下载的消息和语音/视频通话应用程序。

包名称：com.viber.voip

版本：5.2.1

感兴趣的文件：

• /files/preferences/

• activated_sim_serial

• display_name

• reg_viber_phone_num

• /sdcard/viber/media/

• /用户照片/

• /Viber 图像/

• /Viber 视频/

• /数据库/

• viber_data

• viber_messages

/files/preferences中的文件包含 SIM 卡的集成电路卡识别码（ICCID）、用户在应用程序中显示的名称以及用于注册应用程序的电话号码。

/sdcard/viber/media路径中的文件是用户联系人列表中使用 Viber 的人的个人资料照片（无论他们是否已在应用程序中添加为好友）以及通过应用程序发送的所有图像和视频。

viber_data文件是一个数据库，尽管它没有.db文件扩展名。它包含了关于用户联系人的信息：

表	描述
通话	这个表没有填充，即使我们在应用程序内拨打了电话。
phonebookcontact	从法医角度来看，这个表可能非常有价值。当 Viber 首次打开时，它会扫描用户的电话簿，并将找到的所有条目添加到这个数据库中。这意味着它可能包含有关用户联系人的历史数据。如果用户稍后从电话簿中删除了一个条目，它仍然可能在这个数据库中恢复。这个表只包括电话簿中联系人的姓名。
phonebookdata	这与电话簿联系人类似，只是它包括了设备电话簿中联系人的电子邮件地址和电话号码。
vibernumbers	这显示了设备电话簿中使用该应用的每个联系人的 Viber 电话号码。actual_photo中的值对应于/sdcard/viber/media/User Photos目录中的文件名。

viber_messages文件是一个数据库，尽管它没有.db文件扩展名。它包含了关于应用使用情况的信息：

表	描述
conversations	这包含了每个独特对话的唯一 ID、接收者和日期。
messages	这包含了所有对话中的每条消息。地址是对话中远程一方的电话号码。date列以 Linux 纪元格式表示。type列对应于传入或传出；1表示传出消息，0表示传入消息。如果共享了位置，则location_lat和location_lng列将被填充。共享的文件可以与描述文本一起发送；这在description列中找到。
messages_calls	这个表没有填充，尽管我们在应用内进行了通话。
participants_info	这包含了与用户进行过对话的每个账户的个人资料信息。

Tango 分析

Tango 是一款语音/文字/视频消息应用程序。在 Play 商店中已经有超过 1 亿次下载。

包名：com.sgiggle.production

注意

这个包名看起来毫无可疑，可能会被调查人员认为是一个游戏而忽略。这是为什么每个应用都应该被分析的一个例子。

版本：3.13.128111

感兴趣的文件：

• /sdcard/Android/data/com.sgiggle.production/files/storage/appdata/

• TCStorageManagerMediaCache_v2/

• conv_msg_tab_snapshots/

• /files/

• tc.db

• userinfo.xml.db

SD 卡上的/TCStorageManagerMediaCache_v2路径包含了通过该应用发送和接收的图片，以及联系人的个人资料图片。然而，它还包含了许多从未在应用中看到或使用过的图片。它们似乎要么是广告图片，要么是可以附加到对话中的库存表情类型图片。在这里找到的文件名可以与tc.db相关联，以找到在对话中使用的确切图片。

SD 卡上的conv_msg_tab_snapshots路径包含了扩展名为.dat的文件。在十六进制编辑器中查看，我们能够找到一些对话的纯文本片段，以及在对话中发送和接收的图片的路径和 URL。目前尚不清楚是什么导致了这些文件的存在，但可能可以从这些文件中检索可能已在tc.db中被删除的内容。

tc.db数据库是 Tango 用来存储所有消息信息的数据库：

表	描述
conversations	此处每个对话在conv_id列中包含唯一 ID。

| messages | 这包含了通过应用发送和接收的消息。msg_id列是每条消息的唯一标识符，conv_id列标识了消息来自哪个对话。send_time列标识了消息发送的时间或接收的时间，取决于方向。direction列显示了消息的方向；1表示发送，2表示接收。type列标识了消息的类型。根据我们的测试，它们如下：

• 0 = 纯文本消息

• 1 = 视频消息

• 2 = 音频消息

• 3 = 图像

• 4 = 位置/坐标

• 35 = 语音通话

• 36 = 尝试语音通话（被任一方错过）

• 58 = 附加的股票图片，例如在 TCStorageManagerMediaCache_v2 路径中找到的表情符号

最后，payload列包含消息的内容。数据是 Base64 编码的，这将在下一节详细讨论。

user_info_xml.db数据库包含有关帐户的元数据，例如用户的姓名和电话号码。但是，它的数据完全是 Base64 编码的，就像tc.db中的消息一样。

注意

下一个数据存储方法是 Base64。

解码 Tango 消息

Base64 是一种常用于数据传输的编码方案。它不被视为加密，因为它有一个已知的解码方法，并且不需要一个唯一的密钥来解码数据。Base64 包含 ASCII 可打印字符，但底层数据是二进制的（这将使我们的输出有些混乱！）。tc.db的messages表中payload列中的一个示例如下：

EhZtQzVtUFVQWmgxWnNRUDJ6aE44cy1nGAAiQldlbGNvbWUgdG8gVGFuZ28hIEhlcmUncyBob3cgdG8gY29ubmVjdCwgZ2V0IHNvY2lhbCwgYW5kIGhhdmUgZnVuIYABAKoBOwoFVGFuZ28SABoWbUM1bVBVUFpoMVpzUVAyemhOOHMtZyILCgcKABIBMRoAEgAqADD///////////8BsAHYioX1rym4AYKAgAjAAQHQAQDoAdC40ELIAgTQAgDqAgc4MDgwODg5yAMA2AMA2AXTHw==

注意

我们消息末尾的等号。这是数据被 Base64 编码的强烈指示符。要编码的输入需要被 3 整除，才能使 Base64 的数学运算正常工作。如果输入不能被 3 整除，它将被填充，导致在输出中看到的等号。

例如，考虑以下表：

输入字符串	字符数/字节数	输出
Hello, World	12	SGVsbG8sIFdvcmxk
Hello, World!	13	SGVsbG8sIFdvcmxkIQ==
Hello, World!!	14	SGVsbG8sIFdvcmxkISE=

您可以看到 12 字节的输入（可被 3 整除）没有填充，而另外两个输入有填充，因为它们不能被 3 整除。这很重要，因为它表明虽然等号是 Base64 的强烈指示符，但缺少等号并不意味着它不是 Base64！

现在我们对 Base64 有了一点了解，并且认识到我们的payload列很可能是 Base64 编码的，我们需要对其进行解码。有一些网站允许用户粘贴编码数据，然后进行解密（例如www.base64decode.org）。然而，对于大量数据来说，这是不方便的，因为每条消息都必须单独输入（在大多数情况下，将证据数据放在互联网上也是不受欢迎的）。同样，它可以在基于 Linux 的系统的命令行上解码，但对于大量数据同样不方便。

我们的解决方案是构建一个 Python 脚本，从数据库中提取 Base64 数据，对其进行解码，并将其写回到一个新文件中：

import sqlite3
import base64

conn = sqlite3.connect('tc.db')
c = conn.cursor()
c.execute('SELECT msg_id, payload FROM messages')
message_tuples = c.fetchall()
with open('tcdb_out.txt', 'w') as f:
  for message_id, message in message_tuples:
    f.write(str(message_id) + '\x09')
    f.write(str(base64.b64decode(message)) + '\r\n')

运行代码，只需将此代码粘贴到一个名为tcdb.py的新文件中，将脚本放在与tc.db相同的目录中，然后在命令行上导航到该目录并运行：

python tcdb.py

该脚本将在相同的目录中创建一个名为tcdb_out.txt的文件。在文本编辑器中打开该文件（或将其导入 Excel 作为制表符分隔的文件）将显示msg_id值，以便审查人员可以将消息与消息表关联起来。解码的负载显示了一个纯文本消息（在数据库中标记为类型0）。

注意

请注意，消息内容现在以纯文本形式可见，并且前面有对话 ID。我们的输出中还有大量的二进制数据，这很可能是 Tango 使用的元数据或其他信息。如果消息已收到，用户的姓名也将显示在输出中（上面是 Tango）。

还有其他值得关注的消息类型。这是视频消息的解码负载条目：

请注意，对于视频消息，我们可以看到两个 URL。它们都是公开的，意味着任何人都可以访问它们。以缩略图结尾的 URL 是视频的缩略图，而另一个 URL 将以.mp4格式下载完整的视频。还显示了图片的 SD 卡路径和文件名。

图像和音频消息以非常相似的格式存储，并包含 URL 以查看或下载文件。它们还包含文件在 SD 卡上的路径。

这是一个示例位置消息：

这一次，我们可以看到用户所在的确切坐标以及地址。同样，SD 卡上的路径也存在，并将显示位置的地图视图。与其他消息类型一样，接收到的消息也会显示发送者的姓名。

最后，让我们来看看userinfo.xml.db数据库。这是在正确解码之前的样子：

我们编写了另一个与第一个非常相似的脚本来解析userinfo.xml.db数据库：

import sqlite3
import base64

conn = sqlite3.connect('userinfo.xml.db')
c = conn.cursor()
c.execute('SELECT key, value FROM profiles')
key_tuples = c.fetchall()
with open('userinfo_out.txt', 'w') as f:
  for key, value in key_tuples:
    if value == None:
      value = 'Tm9uZQ=='
    f.write(str(base64.b64decode(key)) + '\x09')
    f.write(str(base64.b64decode(value)) + '\r\n')

代码中唯一的区别是文件名、表名和值发生了变化。这一次，数据库中的两列都是 base64 编码的。同样，可以通过将代码放在与userinfo.xml.db相同的位置并使用以下命令运行它来运行代码：

python userinfo.py

以下是输出文件的相关部分，显示用户用于注册账户的个人数据：

在输出的更下方，还有一个使用 Tango 的用户联系人列表。输出还包括联系人的姓名和电话号码。

WhatsApp 分析

WhatsApp 是一款流行的聊天/视频消息服务，在 Google Play 上已经有超过 5 亿次下载。

包名：com.whatsapp

版本：2.11.498

感兴趣的文件：

• /files/

• Avatars/

• me

• me.jpeg

• /shared_prefs/

• RegisterPhone.xml

• VerifySMS.xml

• /databases/

• msgstore.db

• wa.db

• /sdcard/WhatsApp/

• Media/

• Databases/

/files/avatars目录包含使用该应用的联系人的个人资料图片的缩略图，me.jpg是用户个人资料图片的全尺寸版本。me文件包含与账户关联的电话号码

与账户关联的电话号码也可以在/shared_prefs/RegisterPhone.xml中恢复。/shared_prefs/VerifySMS.xml文件显示了账户验证的时间（当然是以 Linux 纪元格式），指示用户首次开始使用该应用的时间。

msgstore.db数据库，顾名思义，包含消息数据：

表	描述
chat_list	key_remote_jid列显示用户与之通信的每个账户。表中的值是远程用户的电话号码。例如，如果值是13218675309@s.whatsapp.net，则远程用户的号码是1-321-867-5309。
group_participants	这包含有关群聊的元数据。
messages	这显示了所有消息数据。再次，key_remote_jid字段标识了远程发送者。key_from_me值表示消息的方向（0 = 接收，1 = 发送）。数据列包含消息的文本，时间戳是发送或接收时间，以 Linux 纪元格式表示。对于附件，media_mime_type标识文件格式。media_size和media_name列应该是不言自明的。如果附件有标题，文本将显示在media_caption列中。如果附件是位置，则latitude和longitude列将适当填充。thumb_image列中包含大量无用的数据，但也包含设备上附件的路径。raw_data列包含图像和视频的缩略图。

wa.db数据库用于存储联系人信息：

表	描述
wa_contacts	与其他应用程序一样，WhatsApp 会抓取并存储用户的整个电话簿，并将信息存储在自己的数据库中。它包含联系人的姓名和电话号码，以及如果联系人是 WhatsApp 用户，则包含他们的状态。

SD 卡是 WhatsApp 数据的宝库。/sdcard/WhatsApp/Media文件夹包含每种类型媒体的文件夹（音频、通话、图像、视频和语音备忘录），并将该类型的所有附件存储在文件夹中。发送的媒体存储在一个名为Sent的目录中。接收的媒体简单地存储在文件夹的根目录中。

Databases目录是更多信息的一个更大的来源。WhatsApp 每晚都会备份msgstore.db并将备份存储在这里。这允许检查员查看可能已被删除的历史数据。如果我今天删除了一个聊天，但你查看了昨天的备份，你就可以访问我删除的数据。该应用程序甚至很友好地将日期放在文件名中，例如msgstore-2015-01-21.1.db。唯一的问题是这些备份是加密的！

解密 WhatsApp 备份

幸运的是，有一个可用于解密备份的工具。它可以在这里找到，并附有详细的安装说明：forum.xda-developers.com/showthread.php?t=1583021。不幸的是，它已经有一段时间没有更新了，并且似乎无法在应用程序的新版本上运行。

我们不知道有没有一个适用于 WhatsApp 新版本的简单自动提取工具。然而，对于我们测试的 WhatsApp 版本，我们使用了forum.xda-developers.com/android/apps-games/how-to-decode-whatsapp-crypt8-db-files-t2975313上的说明取得了巨大成功。请注意，这必须在 Linux 计算机上完成。一旦成功完成这些步骤，结果应该是一个与之前解释的msgstore.db相同的数据库。

这是可能的，因为 WhatsApp 将解密密钥存储在设备的/files目录中。

注意

数据存储方法 7 使用加密文件。

Kik 分析

Kik 是一个拥有超过 5000 万次下载量的消息应用程序。

软件包名称：kik.android

版本：7.9.0

感兴趣的文件：

• /cache/

• chatPicsBig/

• contentpics/

• profPics/

• /files/staging/thumbs

• /shared_prefs/KikPreferences.xml

• /sdcard/Kik/

• /databases/kikDatabase.db

/cache目录中的chatPicsBig和contentpics目录包含使用该应用程序发送和接收的图像。contentpics中的文件包含了在图像之前嵌入的 Kik 元数据。.jpg必须从这些文件中切割出来。在我们的测试中，contentpics中的所有文件也存储在chatPicsBig中，尽管这可能会随着更广泛的应用程序使用而改变。用户的个人资料图片可以在/profPics目录中找到。

注意

数据存储方法 8 使用基本隐写术，这意味着一个文件存储在一个更大的文件中。

/files/staging/thumbs目录包含使用该应用程序发送和接收的图像的缩略图。我们的测试发现这个位置中的图像与/cache目录中的图像相同，但是可能随着更广泛的应用程序使用而有所不同。

/shared_prefs中的KikPreferences.xml文件显示了用户在应用程序中使用的用户名和电子邮件地址。有趣的是，它还包含了用户密码的未加盐的 SHA1 哈希。

/sdcard/Kik目录包含了在应用程序中发送和接收的全尺寸图像。文件名可以与kikDatabase.db数据库中的messagesTable相关联，以确定哪条消息包含了该图像。

kikDatabase.db数据库包含了应用程序中所有的消息数据，存储在以下表中：

表	描述
KIKContentTable	这个表包含有关发送和接收图像的元数据。每条消息都被分配一个唯一的content_id值，对应于sdcard/Kik目录中的文件名。每个图像的预览和图标值对应于在/files/staging/thumbs找到的文件名。每个图像还包含一个file-URL值。这是一个公共 URL，可以访问以查看文件。
KIKcontactsTable	这个表显示了每个联系人的user_name和display_name值。in_roster值似乎是为用户专门添加的联系人设置的（如果设置为1）。in_roster值为0的联系人似乎是自动添加的默认联系人。jid列是每个联系人的唯一值。
messagesTable	这个表包含了使用该应用程序发送和接收的所有消息的数据。body列显示了消息中发送的文本数据。partner_jid值可以与KIKcontactTable中的jid列相关联，以识别远程用户。was_me列用于指示消息的方向（0 = 发送，1 = 接收）。read_state列显示消息是否已读；500 = 已读，400 = 未读。时间戳再次以 Linux 纪元格式显示。content_id列用于消息附件，并可以与KIKContentTable相关联以获取更多信息。

微信分析

微信是一个在 Play 商店中有超过 1 亿次下载的消息应用程序。

包名：com.tencent.mm

版本：6.0.2

感兴趣的文件：

注意

以下一些路径包含星号（*）。这用于表示一个唯一的字符串，每个帐户都不同。我们的设备在星号的位置有7f804fdbf79ba9e34e5359fc5df7f1eb。

• /files/host/*.getdns2

• /shared_prefs/

• com.tencent.mm_preferences.xml

• system_config_prefs.xml

• /sdcard/tencent/MicroMsg/

• diskcache/

• WeChat/

• /sdcard/tencent/MicroMsg/*/

• image2/

• video/

• voice2/

• /MicroMsg/

• CompatibleInfo.cfg

• */EnMicroMsg.db

在/files/host中找到的*.getdns2文件可以作为文本文件或十六进制编辑器中打开。有一个名为[clientip]的部分，显示用户连接的 IP 地址以及连接时间的 Linux 纪元格式。我们的设备包含了三个这样的文件，显示了三次不同的连接，尽管增加的应用程序使用可能会生成超过三个这样的文件。

/shared_prefs中的com.tencent.mm_preferences.xml文件记录了设备的电话号码在login_user_name字段中。system_config_prefs.xml文件包含了用户在设备上的个人资料图片的路径，以及以后需要的default_uin值。

SD 卡包含大量的微信数据。/tencent/MicroMsg/diskcache目录中包含一个从未在应用程序中使用过的图像。我们认为当附加不同的图像时，它被放在那里，因为微信从设备的图库加载了许多图像的视图。/sdcard/tencent/MicroMsg目录中的/WeChat目录包含从设备发送的图像。

/video，/voice和/voice2文件夹在/sdcard/tencent/MicroMsg/*中包含确切的内容：使用该应用程序发送的视频和语音文件。

微信相当独特，因为它在应用程序的目录结构中不使用/databases目录。MicroMsg是它的等价物。CompatibleInfo.cfg包含设备的 IMEI，这将在以后有用。

*目录在/MicroMsg中包含EnMicroMsg.db数据库。只有一个问题：数据库使用SQLCipher加密！SQLCipher 是 SQLite 的一个开源扩展，可以加密整个数据库。幸运的是，就像我们看到的其他使用加密的应用程序一样，解密文件的密钥就在设备上。

注意

数据存储方法 9 使用了 SQLCipher，涉及整个数据库的加密。

解密微信 EnMicroMsg.db 数据库

对我们来说幸运的是，Forensic Focus 在articles.forensicfocus.com/2014/10/01/decrypt-wechat-enmicromsgdb-database/上有一篇关于如何做到这一点的优秀文章。

他们甚至提供了一个 Python 脚本来为我们完成这项工作gist.github.com/fauzimd/8cb0ca85ecaa923df828/download#。

要运行 Python 脚本，只需将 EnMicroMsg.db 文件和 system_config_prefs.xml 文件放在与脚本相同的目录中，并在命令行中输入：

python fmd_wechatdecipher.py

然后脚本将提示您输入设备的国际移动台设备识别码（IMEI）。这可以在/MicroMsg/CompatibleInfo.cfg文件中找到，打印在设备的某个地方（在电池后面，SIM 卡托盘上或在设备的背面上），或者通过在手机拨号器中输入*#06#来找到。

脚本应该运行。在目录中放置一个名为EnMicroMsg-decrypted.db的文件。

最后，我们现在可以检查EnMicroMsg-decrypted.db数据库，以了解其中存储的以下表：

表	描述
ImgInfo2	这包含了发送和接收图像的路径信息。bigImgPath列包含图像的文件名。这可以在 SD 卡上搜索以找到图片。或者，图像存储在/sdcard/tencent/MicroMsg/*/image2目录中，这些目录对应于文件名。例如，名为3b9edb119e04869ecd7d1b21a10aa59f.jpg的文件可以在/3b/9e路径的image2目录中找到。这些文件夹按名称的前 2 个字节和名称的后 2 个字节进行分解。thumbImgPath列包含图像缩略图的名称。
message	这包含了应用程序的所有消息信息。isSend列表示消息方向（0 = 接收，1 = 发送）。createTime表是消息的时间戳，采用 Linux 纪元格式。talker列包含远程用户的唯一 ID。这可以与rcontact表相关联，以识别远程用户。content列显示了以文本形式发送的消息数据，并将视频通话标识为“voip_content_voice”。imgPath列包含图像缩略图的路径，可以与ImgInfo2表相关联，以定位全尺寸图像。它还包括音频文件的文件名，可以在/sdcard/tencent/MicroMsg/*/voice2目录中搜索或定位。
rcontact	这包含了联系人列表，并包括应用程序默认添加的许多联系人。username列可以与message表中的talker列相关联。nickname列显示用户的姓名。type列指示联系人是手动添加还是自动添加（1 = 设备用户，3 = 用户添加，33 = 应用程序添加）。唯一的例外是用户“weixin”，它是自动添加的，但类型值为3。
userinfo	这个表包含有关用户的信息，包括他们的姓名和电话号码。

应用程序逆向工程

绝大多数 Android 应用程序都是用 Java 编写的。为了真正逆向工程 Java 代码，一般应该首先能够编写 Java 代码。教授 Java 远远超出了本书的范围。然而，我们将展示一些我们认为会有用并且可以由普通移动取证人员完成的一些有用的逆向方法。已经有数百个关于 Android 逆向的教程和指南在线撰写，从非常基础的到高级的都有。

任何寻找更多信息的人都应该能够轻松找到他们想要的东西。一如既往，www.xda-developers.com是一个非常有用的资源，整本书都致力于这个主题。还有一个由 Ashish Bhatia 制作的非常详细的、更新的工具列表，可以在github.com/ashishb/android-security-awesome找到。

获取应用程序的 APK 文件

应用程序是通过.apk文件安装的。应用程序的 APK 文件存储在设备上，即使应用程序已安装（并且在删除应用程序时删除）。此 APK 包含应用程序的编译 Java 代码，应用程序中使用的图标和字体，以及声明应用程序所需权限的AndroidManifest.xml文件。

通过 Google Play 安装的应用程序的APK文件可以在/data/app目录中找到。查找 APK 位置的另一种方法是使用adb shell pm path <package_name>命令。无法在没有 root 权限的情况下删除的预安装系统应用程序的 APK 文件可以在/system/app 目录中找到。APK 文件本身存储在以其包名称命名的目录中，后跟破折号和数字。例如，Kik 的包名称是kik.android，在/data/app中的 APK 存储为inkik.android-1。

以下是我们测试的设备中/data/app中的 APK 目录列表：

请注意，我们测试的每个应用程序在此目录中都有一个 APK 文件，以及我们没有查看的许多应用程序。

获取 APK 文件就像使用 adb pull 命令一样简单。要拉取 Kik APK，我们将使用以下命令：

adb pull /data/app/kik.android-1

这应该拉取一个lib目录和一个base.apk文件，它将在运行命令的当前目录中：

反汇编 APK 文件

首先，APK 文件实际上只是一个 ZIP 压缩文件。将扩展名更改为.zip 将允许检查员打开容器并浏览其中包含的文件：

但是，您可能无法查看 AndroidManifest.xml 文件。有许多工具和方法可以完全反汇编 APK，这些可以在我们上面链接的列表中找到。不过，我们个人最喜欢的工具是一个允许您简单右键单击 APK 并对其进行反汇编（仅限 Windows）的工具。APK_OneClick 工具可以在forum.xda-developers.com/showthread.php?t=873466找到。

Java 运行环境（JRE）必须安装。它可以在www.oracle.com/technetwork/java/javase/downloads/jre8-downloads-2133155.html找到。

工具和 JRE 安装完成后，检查员可以简单右键单击 APK 并选择反汇编 APK 和解码资源：

弹出窗口将显示进度，并且如果遇到问题，它将消失：

如果反汇编成功结束，现在将在与 APK 相同的目录中有一个名为base-disasm的文件夹。浏览目录将显示许多与我们将 APK 重命名为.zip文件时看到的相同的文件和文件夹：

确定应用程序的权限

了解应用程序具有哪些权限对于审查员来说可能非常有用。首先，它可以帮助缩小数据存储的范围。例如，没有权限将数据写入 SD 卡的应用程序将不会在那里存储任何数据。当嫌疑人被发现携带非法材料时，最常听到的辩护之一是，当然，嫌疑人不知道它是如何出现的，而是被病毒放置在那里的。如果他说某个特定的应用程序将数据放在他的 SD 卡上，审查员可以证明该应用程序无法这样做，因为它没有权限写入 SD 卡。这只是一些基本的例子，但再次强调，这是非常基础的逆向工程！

前面讨论的 APK 的AndroidManifest.xml文件将包含应用程序的权限。这相当于用户在安装应用程序时所看到并需要批准的内容：

关于每个权限允许应用程序执行的具体操作，谷歌在developer.android.com/reference/android/Manifest.permission.html上维护了一个列表。

查看应用程序的代码

使用 APK_OneClick 工具查看应用程序的代码，只需右键单击 APK 并选择浏览 APK 的 Java 代码。同样，一个窗口将暂时弹出显示进度，并且如果没有遇到错误，它将消失。完成后，将出现一个 Java 反编译器窗口，允许审查员浏览 Java 代码。

总结

本章对特定的 Android 应用程序进行了深入研究，以及它们存储数据的方式/位置。我们查看了 19 个特定的应用程序，并发现了 9 种不同的存储和混淆数据的方法。知道应用程序以各种方式存储它们的数据应该有助于审查员更好地了解他们正在审查的应用程序的数据。这种知识应该帮助他们在找不到他们期望应用程序具有的数据时更加努力。审查员必须能够适应应用程序分析不断变化的世界。随着应用程序不断更新，审查员必须能够更新自己的方法和能力以跟上步伐。

下一章将介绍几种免费和开源工具，用于对 Android 设备进行成像和分析，并对应用程序进行逆向工程，以发现它们的数据存储位置。

第八章：Android 取证工具概述

本章概述了免费和开源的 Android 取证工具，并将向您展示如何在常见的调查场景中使用这些工具。在本章结束时，读者应该熟悉以下工具：

• ViaExtract

• Autopsy

• ViaLab

ViaExtract

ViaExtract 是由 NowSecure（以前称为 ViaForensics）创建的逻辑和物理提取工具。免费版本提供逻辑获取（包括备份），而付费版本则添加了物理提取。它在 NowSecure 的 Santoku Linux 发行版中以虚拟机文件（VMWare 或 Virtual Box 格式）的形式免费分发。在使用免费版本时需要活动的互联网连接。下载和完整的功能列表可以在www.nowsecure.com/forensics/community/找到。需要注册。

在 ViaExtract 虚拟机的桌面上可以找到注册工具和启动 ViaExtract 的图标：

在启动 ViaExtract 之前，请确保要检查的设备通过 USB 连接到计算机。这将确保设备被检测到。设备还需要通电。请注意适当的网络隔离措施，如第一章中所讨论的介绍 Android 取证。在下面的示例中，我们将检查运行 Android Lollipop 5.1 的 LG Nexus 5。请注意，这在下面屏幕截图的左下角显示。

然后，按照以下步骤进行：

1. 在左上角点击新建按钮将弹出创建新项目对话框：

2. 选择前进将弹出设备信息选项卡，这是我们将开始提取的地方。支持的提取列表如下屏幕截图所示。在这种情况下，我们的两个选项是Android 备份或Android 逻辑：

使用 ViaExtract 进行备份提取

要执行备份提取，请按照以下步骤进行：

1. 单击提取（如前面的屏幕截图所示）将显示选择提取类型对话框。我们首先从类型下拉菜单中选择备份提取：

2. 填写所有字段后，确定按钮将变为可用。选择确定将显示在设备上接受该过程的说明。但是，此步骤目前在设备上不可用：

3. 在Android 备份：允许备份屏幕上选择前进后，ViaExtract 将为您提供尝试恢复已删除的 SQLite 数据的选项。尽管这只是逻辑提取，但可能会成功，因为 SQLite 数据库存储数据的方式已在本书中详细讨论过。

4. 在Android 备份：SQLite 恢复屏幕上选择前进将开始备份。此时，备份将需要在设备上接受，如前面的Android：允许备份屏幕截图所示：

5. 点击关闭后，备份现在应该在任务选项卡中显示进度，如下面的屏幕截图所示：

使用 ViaExtract 进行逻辑提取

要开始逻辑提取，请按照以下步骤进行：

1. 从设备信息选项卡中选择提取，就像我们之前完成的备份提取一样。但是，这次从类型下拉菜单中选择Android 逻辑。这将启动逻辑提取向导，它首先指出需要我们在设备上安装一个应用程序：

2. 选择前进将进入逻辑提取：选项菜单。在这里，可以忽略某些文件类型以加快提取过程：

3. 此时，ViaExtract 应用程序将被推送到设备上，并且可能需要在设备上进一步操作。我们将在以下弹出消息上选择DECLINE：

4. 在拒绝弹出窗口后，可以看到应用程序正在设备上运行：

5. 回到电脑上，将显示以下消息：

6. 进度将再次在左上角的任务选项卡中可见，如下所示：

在 ViaExtract 中检查数据

一旦提取完成，数据可以在左上角的项目选项卡中查看：

要查看内容，只需点击它，它将显示在右侧。这是在逻辑提取中找到的书签的示例：

当检查备份时，流程是一样的。这里是在《第七章》Android 应用程序的取证分析中分析的Tango tc.db文件的摘录：

在 ViaExtract 中检查数据

ViaExtract 中的其他工具

ViaExtract 还可以尝试对设备进行 root 和绕过密码。从设备信息选项卡中点击Root按钮将启动 root 向导。只需按照弹出消息进行操作即可对设备进行 root。我们在我们的测试设备 Nexus 5、Moto X（2013 年型号）和 HTC Droid DNA 上没有成功。

从右上角的工具菜单中启动解锁屏幕向导。然后，选择解锁屏幕。这将向设备推送一个应用程序（需要启用 USB 调试和通过 RSA 身份验证），该应用程序将删除锁定屏幕。这是一个有用的工具，因为与[第四章]中显示的手动方法不同，从 Android 设备逻辑提取数据，它不需要 root 访问权限。它在我们的 Nexus 5 和 HTC Droid DNA 上失败了，但在我们的 Moto X 上完美地工作。

Autopsy

Autopsy 是由 Brian Carrier 最初开发的免费开源分析工具。Autopsy 最初是基于 Linux 的 SleuthKit 工具集的图形用户界面，但最新版本（版本 3）是为 Windows 构建的独立工具。Autopsy 可以在www.sleuthkit.org/autopsy/上下载。

Autopsy 并不打算执行移动设备的获取，但可以分析最常见的 Android 文件系统（如 YAFFS 和 ext）。在这个例子中，我们将加载从 HTC Droid DNA 通过 dd 获得的完整物理镜像，如《第五章》从 Android 设备物理提取数据中所述。

在 Autopsy 中创建一个案例

打开 Autopsy 时，用户将被提示选择创建新案例、打开最近的案例或打开现有的案例：

我们将创建一个新案例。按照以下步骤进行：

1. 填写“案例名称”字段后，“下一步”按钮将变为可用：

2. 在下一个屏幕上，可以输入可选的“案例编号”和“审查员”：

3. 选择“完成”将显示“输入数据源信息”屏幕。单击“浏览”将允许用户选择要加载的图像文件：

4. 选择图像文件后，可以单击“下一步”按钮以进入“配置摄取模块向导”：

摄取模块是内置在 Autopsy 中的工具，可以在案例启动时或之后的任何时候运行。此版本的 Autopsy 中的默认模块如下：

• 最近活动：这会提取最近的用户活动，如网络浏览、最近使用的文档和已安装的程序。

• 哈希查找：这会使用提供的哈希数据库识别已知和显著的文件，如标准 NSRL 数据库。它还允许导入自定义哈希数据库。

• 文件类型识别：这会基于二进制签名匹配文件类型。

• 存档提取器：这会提取存档文件（.zip、.rar、.arj、.7z、.gzip、.bzip2、.tar）。它会自动提取这些文件类型，并将它们的内容放入目录树中。

• EXIF 解析器：这会摄取 JPEG 文件并检索它们的 EXIF 元数据。

• 关键词搜索：这会使用关键词和正则表达式在列表中执行文件索引和定期搜索。它允许加载自定义关键词/列表。

• 电子邮件解析器：此模块检测和解析 mbox 和 pst/ost 文件，并在黑板上填充电子邮件工件。

• 扩展名不匹配检测器：这些是基于文件类型的非标准扩展名的标志文件。

• E01 验证器：这会验证 E01 文件的完整性。

• Android 分析器：这会提取 Android 系统和第三方应用程序数据。

• 有趣文件标识符：这会识别有趣的项目，如有趣的项目规则集所定义的那样。

注意

许多这些模块对于 Android 设备来说是不需要的（例如 E01 验证器和电子邮件解析器）。只选择有用的模块将加快摄取时间。此外，请注意，单击模块可能会带来更多选项，如前面的屏幕截图所示。

1. 单击“下一步”将加载数据源并开始摄取过程。遇到的任何错误都将被记录：

2. 选择“完成”将带领审查员到摄取案例的主要屏幕进行分析：

在 Autopsy 中分析数据

尽管案例仍在加载并且摄取模块正在运行（如前一个屏幕截图右下角的进度条所示），审查员可以开始分析案例。展开左上角的图像文件将显示 Autopsy 识别的分区/卷：

Autopsy 在我们的设备上识别了 65 个分区，其中绝大多数是未分配的。要找到数据分区（因为我们知道我们感兴趣的绝大多数数据存储在这里），我们可以简单地展开已分配的分区，直到找到一个看起来像数据分区的分区：

在我们的图像中，卷 124 是数据分区。我们可以看到它有一个应用程序目录（存储 APK 文件的位置）、一个数据目录（存储应用程序数据的位置）和一个媒体目录（SD 卡的符号链接位置）。

展开数据目录将显示我们应该从第七章中记住的信息，即Android 应用程序的取证分析。这也可以在以下屏幕截图中看到：

我们立即可以看到com.android.providers.telephony和userdictionary以及com.facebook.katana。如何分析这些应用程序在第七章Android 应用程序取证分析中有所涵盖；这是如何使用 Autopsy 访问相关文件的方法。例如，展开com.android.providers.telephony将显示分析短信和彩信数据所需的mmssms.db文件。

右键单击文件将允许用户选择提取文件或在外部查看器中打开以进行进一步分析：

现在，让我们看看 Autopsy 的其他功能。在屏幕左侧展开视图部分将显示一些使用的摄入模块的结果，如下所示：

文件类型视图显示了由文件类型识别模块识别的文件。最近文件显示了最近活动模块的结果。在这种情况下，设备似乎在 6 天内没有使用，然后在最后一天使用了。查看这里识别的文件可以显示用户在那段时间内的活动。请注意红色的叉号，表示其中一些文件已被删除，但被 Autopsy 恢复了：

在我们的案例中，我们可以看到downloads.db和EmailProvider.db数据库已被修改。分析这些文件将显示收到带附件的电子邮件，然后附件被下载到设备上。

最后，视图部分标识了已删除的文件（这在移动设备上非常常见，因为磨损平衡的结果），以及大文件（可以快速找到图像/视频或识别隐写术）。

结果部分将显示 Android 分析器和关键词搜索模块的输出，如下面的截图所示：

在提取的内容下看到的 Android 分析器结果大多如预期。值得注意的是联系人（1）部分只指向contacts.db文件，并没有实际解析数据。例如，通话记录显示了从contacts2.db中提取的数据，如第七章Android 应用程序取证分析中所述：

扩展名不匹配检测结果还显示了我们在第七章Android 应用程序取证分析中发现的数据。有几个应用程序被描述为具有实际上是 JPEG 图像的.cnt文件，这些文件被 Autopsy 恰当地识别出来，如下面的截图所示：

双击上面看到的任何文件将带用户到文件在文件系统中的位置。

关键词命中部分恰当地找到了许多电子邮件地址和电话号码。然而，许多这些都是在应用程序文件中找到的（即应用程序开发者的联系信息）以及用户实际上没有存储的其他位置（这在移动和计算机取证工具中都很常见）。

Autopsy 还有许多其他更高级的功能，这里没有涵盖。要了解更多信息，Basis Technology 提供了 Autopsy 培训课程，网址为www.basistech.com/digital-forensics/autopsy/training/。

ViaLab 社区版

ViaLab 社区版是 NowSecure 开发和发布的另一个免费工具。它作为一个独立的虚拟机发货，并且可以在www.nowsecure.com/apptesting/community/找到（需要注册）。该虚拟机实际上与我们在本章开头讨论的 Santoku 下载非常相似，但包括 ViaLab 社区版工具。

提示

ViaLab 要求检查员的计算机必须有互联网连接，以便使用该工具。

ViaLab 的主要目的是分析 APK 的行为，尽管许多用于此目的的功能在免费的社区版中不可用。ViaLab 允许您手动将 APK 文件加载到 Android 模拟器中，或在已 root 的设备上运行应用程序。在我们的示例中，我们手动将 Kik 的 APK 文件加载到 Android 模拟器中。我们选择 Kik，因为它在第七章中进行了彻底分析，因此我们对预期结果有很好的了解，并且可以确认我们之前的发现。这样做的一个很好的取证用例是研究一个应用程序以了解它存储了哪些数据。例如，如果检察官正在寻找保存的视频，检查员可以确定应用程序是否具有该功能以及它们存储在何处。

在 ViaLab 中设置模拟器

使用 ViaLab 之前，必须先激活。这是通过在桌面上找到的 ViaForensics 产品激活工具完成的。注册后，按照以下步骤设置模拟器：

1. 单击桌面上的ViaLab图标启动工具：

2. 程序可能会提示输入 root 密码。在 ViaLab VM 中，默认密码是vialab1：

3. 程序启动后，将运行系统检查。单击关闭将完成系统检查。还可以取消选择启动时始终运行系统检查框，以在将来跳过此步骤：

4. 要启用 Android 模拟器（或配置 ViaLab 的真实设备），请在主屏幕左下角选择设备管理器图标，并在打开的窗口中进行适当的选择：

5. 第一次使用 Android 模拟器时，将需要安装额外的软件包：

6. 安装模拟器包并重新启动 ViaLab 后，设备管理器现在将显示启动模拟器选项。选择此选项启动 Android 模拟器：

7. Android 模拟器将启动并显示在单独的窗口中。主屏幕右下角的设备管理器图标应显示 ViaLab 现在已连接到模拟器：

在模拟器上安装应用程序

要开始 ViaLab 分析，请按照以下步骤操作：

1. 在左上角选择新建。这将打开一个窗口以添加新项目：

2. 从添加项目对话框中选择前进将带您到设置页面：

3. 要选择要安装到模拟器中的 APK 文件，请选择手动添加应用程序并选择文件。一旦选择了 APK 文件，下载按钮将变为可用。选择此按钮将 APK 推送到模拟器，并在完成后选择确定：

4. 现在您可以转到模拟器窗口并使用该应用程序填充测试数据。请注意，性能可能会非常慢，因为模拟器是在虚拟机中运行的虚拟机：

应用程序在模拟环境下可能会有不同的表现。例如，Kik 要求我们解决验证码以证明我们是人类！其他应用程序可能会有降低的功能（例如涉及 GPS 数据的任何内容）。

使用 ViaLab 分析数据

在应用程序中填充数据后，让我们来分析它！按照以下步骤进行：

1. 返回 ViaLab 并选择屏幕顶部的取证选项卡。选择刷新应用程序文件夹将从设备中提取数据：

2. 一旦数据同步完成，可以选择文件列表按钮按类型筛选文件：

例如，这是我们在应用程序中填充的联系人数据，存储在我们在第七章中检查的数据库中，Android 应用程序取证分析：

总结

本章概述了一些供 Android 取证人员使用的免费工具。这些工具在下表中进行了总结：

工具	特点
ViaExtract

• 免费，需要注册和有效的互联网连接

• 通过将应用程序推送到设备进行逻辑提取

• 备份提取

• 如果设备已 root，则进行文件系统提取

• 对设备进行 root

• 通过将应用程序推送到设备，无需 root 即可绕过屏幕锁定

|

Autopsy

• 免费且开源

• 用于检查其他工具提取的数据

• 允许关键字搜索、哈希列表和其他常见取证方法

• 强大的时间轴功能

• 可以从支持的文件系统中恢复已删除的数据

|

ViaLab

• 免费，需要注册和有效的互联网连接

• 允许取证人员从 APK 运行应用程序并确定数据存储位置

• 在模拟器或测试设备上运行应用程序

• 宝贵的工具，可以向取证人员展示应用程序目录中的数据存储位置，以及查看应用程序的功能

|

结论

我们希望所有人在未来的 Android 取证中都能好运。我们真诚地希望本书中的内容能在某个时候帮助到您。我们的目标是制作一本关于整个 Android 取证过程的信息指南。我们希望您在学习的过程中有所收获（我们在写作过程中也有很多收获）。谢谢您的阅读！