如开篇所述, 传统的SQLite数据库数据恢复要求恢复对象必须是SQLite数据库文件且数据库文件完整有效, 能够被SQLite数据库程序正常识别访问。具体恢复过程如图1所示, 在SQLite数据库文件完整的前提下, 在数据库内部进行数据分析, 得到无指针指向的曾经进行过删除数据操作的自由块或未分配空间, 在其中进行数据挖掘^{[4, 5]}。

图1

Fig.1

	Figure Option ViewDownloadNew Window
	图1 SQLite数据库删除操作示例Fig.1 Example of SQLite database deletion operating

本文设计的搜索方法, 是基于SQLite数据库存储特定数据的规范进行“ 遍历” 查找, 因此可以无需获取完整的SQLite数据文件, 可以脱离SQLite数据库解析逻辑, 直接在物理存储层次进行, 也可以针对任意大小的二进制数据区域进行直接的数据挖掘分析, 存储镜像文件、SQLite数据库碎片等都可以直接作为数据源进行数据恢复搜索操作。

下面章节将以安卓手机中系统保存的通话记录数据为例, 针对安卓系统通话记录数据结构特点, 分析并建立安卓系统通话记录数据模型, 并根据模型实现搜索分析方法, 最终测试验证其有效性。

2.2.1 SQLite数据库中通话记录数据字段分析

安卓系统采用SQLite数据库来存放手机通话记录数据, 存放数据的文件位置通常为：/data/data/com.android.providers.contacts/databases/contacts2.db（部分特殊手机厂家可能会有微调）, 针对删除部分手机通话记录, 传统的数据恢复手段主要是在获取该文件后, 直接进行关键数据表calls的数据结构分析（图2）。

图2

Fig.2

	Figure Option ViewDownloadNew Window
	图2 contacts2.db中calls表部分结构样例Fig.2 Partial structure of calls table in contacts 2.db

如图2所示, 表calls中我们主要关心的四个字段为number、date、duration和type。字段含义如下：

1）number为手机号码字段, 根据通话类型的不同记录相应的对方号码。

2）date为通话时间字段, 为国际时间UTC时间, 单位为ms, 一般为13位长整型数字。

3）duration为通话时长字段, 为单位为s的整数数字。

4）type为通话类型字段, 根据手机厂家定义, 规则为：1呼入、2呼出、3未接、10未知。

2.2.2 SQLite数据库中通话记录数据底层分析

本章节针对安卓系统通话记录数据样例数据库文件contacts2.db文件中calls表进行底层数据存储分析, 通过多条样例数据在文件中的查找, 分析得到底层数据的存储模型。

采用的测试通话记录条目为：

手机号码：15910650275

通话时间：1464080245793（UNIX UTC时间, 单位ms）

通话时长：8

通话类型：2

该条数据对应在contacts2.db文件十六进制视图中如图3所示, 浅蓝色部分为ASCII编码方式的手机号码数据, 黄色6个字节为十六进制存储下的通话时间（01 54 E1 FB A4 21）, 白色部分08为通话时长数据, 紫色部分数据02为通话类型数据, 绿色部分数据为相关国别字段, 内容为CN, 灰色部分数据为通话记录数据表中matched_number字段和normalized_number字段, 用于电话号码电话簿匹配和数据清洗。

图3

Fig.3

	Figure Option ViewDownloadNew Window
	图3 安卓系统通话记录底层十六进制数据存储样例Fig.3 Sample of underlying hexadecimal data storage for Android call log

通过分析可以发现, 安卓系统通话记录数据都是按照上面数据结构依次存储在底层的十六进制数据中。无论在存储设备的物理层面上还是文件系统的逻辑层面上, 这种典型的安卓系统通话记录数据结构是保持不变的, 这种通用数据结构为我们的基于底层数据的删除恢复方法的设计提供了理论基础。

2.2.3 SQLite数据库中通话记录数据提取方法设计

通过对安卓系统通话记录底层存储数据的存储分析, 本文得到了关于安卓系统的通话记录数据在底层十六制数据存储中的数据模型, 并根据这个模型设计实现对应安卓系统通话记录数据十六进制格式的专用删除恢复遍历分析方法, 方法流程如图4所示。

2.2.4 SQLite数据库中通话记录数据分析实例

测试案例：

OPPO A11手机一部（无法开机）, 通过芯片提取获取物理存储镜像并提取contacts2.db文件, 数据库文件已损坏, 多种SQLite数据库查看器打开失败。

针对这个真实案例, 为了减小遍历搜索范围, 提高分析效率, 选择将该损坏的数据库文件作为数据源进行遍历搜索, 未来数据源可以扩展为全芯片镜像数据来实现更大范围的遍历搜索, 进而获取更多的删除恢复数据。如图5所示, 通过本文提出的基于底层数据的安卓系统通话记录数据提取方法, 搜索并定位的3条通话记录, 其中蓝色部分为通话记录的电话号码部分, 由于是真实案件数据, 隐去电话号码最后四位; 紧跟号码的黄色字段为通话时间数据, 时间数据后面的一位字节为通话时长, 第一条通话时长字节为空, 表示0通话时长, 即未接通; 紫色部分为通话类型, 这三条数据均为02 , 表示为呼出电话。紫色数据后面是代表国别的字段CN, 这里在CN后面还跟有UTF-8编码的“ 中国” 字段, 对应为E4 B8 AD E5 9B BD 部分, 在这灰色部分数据后面还有重复的一次电话号码字段作为数据库表中的冗余字段, 至此3条通话记录数据分析完毕（表1）。

表1

Table 1

表1(Table 1)

表1 3条通话记录数据分析结果 Table 1 Analytic results of 3 pieces of call log data 电话号码 时间 时长/s 类型 属地 1527080---- 2015/9/8 15:59 0 呼出 中国 1527080---- 2015/9/8 14:02 20 呼出 中国 1527080---- 2015/9/8 13:57 85 呼出 中国

表1 3条通话记录数据分析结果 Table 1 Analytic results of 3 pieces of call log data

本数据通过与实际案件数据相比对, 认定为真实数据。最终从该损坏文件中提取通话记录数据有效数据529条, 经过比对验证, 该结果真实有效, 至此证明本技术方法是可行并有效的。

图4

Fig.4

	Figure Option ViewDownloadNew Window
	图4 安卓系统通话记录数据搜索遍历流程Fig.4 Process of traversal searching for Android call-log data

图5

Fig.5

	Figure Option ViewDownloadNew Window
	图5 安卓系统通话记录十六进制数据搜索测试案例Fig.5 Case test of searching into Android call-log hexadecimal data