Android智能终端中基于日志的文件恢复方法

丁云冰，杨 戈，卜 凡

(中国船舶工业系统工程研究院，北京 100089)

随着移动智能终端的发展，Android操作系统由于其开源性的特点，使得Android智能终端在市场份额中占比越来越重，智能终端已经和人们的生活、工作息息相关。而智能终端中存储着大量用户数据，如通讯录、短信、联系人、照片、文件等，一旦丢失将对用户造成较大影响。因此，基于Android操作系统的数据恢复研究也越来越引起研究者的重视。

Android操作系统由于其开源性特点，被大多数手机厂商所使用，每个厂商则更多地定制个性化的系统以突出其特点。随着Google对Android操作系统的不断升级，目前现有的数据恢复方法较多依赖于终端所开放的备份方式，备份的能力完全取决于终端厂商所提供的接口。如果终端获取到ROOT权限，则可以提取到终端分区镜像，那么可以恢复的数据范围不再依赖于厂商的备份接口。本文正是在已获取到终端镜像为前提条件下，提出一种基于日志区的文件恢复方法。

1 关键技术分析

1.1 Android文件系统简介

Android是基于Linux内核发展起来的开源操作系统，采用NAND进行数据存储，早起的Android系统普遍采用yaffs2文件系统。然而随着eMMC芯片的发展，Android终端越来越多地采用eMMC存储芯片，随之而来的变化是文件系统转变为Linux所支持的EXT4文件系统。

EXT4文件系统是第四代扩展文件系统(Fourth extended file system，缩写为 EXT4)，是Linux系统下的日志文件系统，是EXT3文件系统的后继版本。EXT文件系统从EXT3开始，引入日志的概念。EXT4对EXT3及以前的版本都支持向下兼容，与EXT3相比，EXT4只在如inode节点的部分位(如引入区段树，后续会介绍)做了改变[1-2]。

1.2 块及块组

EXT4文件系统内按块(block)存储，块通常为固定大小，通常为1K、2K或4K，EXT4一般是4 KB，即连续8个扇区(每扇区512 B)。块均有编号，初始编号为0。在分区格式化时就设置好了。EXT4文件系统写文件的最小单位是块，如果文件大于块大小，则一个文件会占用多个块数量。

若干连续块在一起组成块组(block group)，文件系统对块组进行统一管理。通常32 768个块组成一个块组。对于文件系统来说，块组包含的块数是固定的，也是格式化时就定义好了的。块组也有相应编号，初始编号为0。

若干个连续块组放在一起，称为一个flexible Block Group，一般EXT4文件系统是由16个块组作为一个flexible Block Groups，每个flexible Block Groups中所有块组的block bitmap、inode bitmap、inode table(后续会介绍)都在首块组中按序存储。

1.3 文件系统关键元素

Linux文件系统的基本信息可以用dumpe2fs命令来查看。图1为通常情况下一个块组的布局结构。

superblock(超级块)记录此文件系统的必要基础信息，包括如块数量、inode数量，未使用的块数量、inode数量，block与inode大小等。superblock通常占用1个块，它对于文件系统至关重要；group descriptor table(保留的GDT)为以后使用留存空间，通常占用若干块；block bitmap(块位图)记录该块组中所有块的使用情况，能够对块组中的32 768个块作映射，若块组中第N个块被使用了，则标记块位图的第N位为1，否则为0；inode bitmap(inode位图)与块位图同理，记录该块组中inode的使用情况；inode table则用于存放块组中的所有inode。

图1 块组布局结构

图2是从手机(Android5.1.1，已ROOT)的data分区的superblock中分析得到的文件系统部分基本信息。包括inode、块总数量，每个块大小为4 096字节，每个块组中包含32 768个块等信息。

图2 文件系统基础信息举例

1.4 Inode节点

每个文件、目录均有自己的inode号，inode分两种：指向文件的inode和指向目录的inode，这两种inode均存放在inode table中，而文件、目录内容存储在数据块中，inode节点记录了数据块的实际物理地址。对于文件系统来说，inode节点大小是固定的，EXT4文件系统的inode一般是256 B，每个块组中inode节点是固定的，随分区而定。每个inode均有编号，每个文件对应一个inode节点，日志文件的inode号码固定为8。在Linux系统中通过命令“stat + 文件名”可以查看文件inode号。inode节点存储了除了文件名以外的全部文件信息，包括如文件访问模式、文件所有者与组(owner/group)、文件大小、文件时间戳、该文件数据块物理地址、链接数。

2 基于日志的文件恢复原理

2.1 日志介绍

基于上述介绍的文件系统基本元素，在EXT4文件系统中，新建一个文件或目录时，文件系统会先在数据块中写入真实数据，并更新inode指向该文件。接着，将刚刚写入的信息同步更新到inode bitmap和block bitmap中，并更新superblock(下文将此部分信息称为metadata)。superblock，inode bitmap 及 block bitmap 的数据是经常变动的，每次新增、移除、编辑时都可能会影响到这3个部分的数据。

正常情况下，上述动作可以顺利执行，但是如文件在写入文件系统时，因为如突然断电等问题发生时，可能造成同步升级metadata步骤失败。这样会造成实际数据块内容与metadata的数据不一致的问题产生。

日志型文件系统正是为了解决这一问题而产生的。EXT4是日志型文件系统，在某一事务提交前，例如修改文件，日志区会记录文件要写入的动作，完成数据和metadata的升级后，在日志区标记该事务提交状态，以完成文件的修改。这样即便是中途发生了断电等问题，文件系统也会根据日志区中记录的未提交事务进行数据的回滚处理。

2.2 EXT4文件存储分析

相比于EXT3，EXT4对数据块引用使用了一个全新的概念，即Extent(区段树)，它能够处理更多的存储并允许更大的文件。Extent存储在inode节点的40～99 B中，用于记录文件实际的物理地址。extent结构如图3所示[3-4]。

图3 Extent结构图

Extent由header和entry组成，每个Extent都有一个header结构(见表1所示)，header后紧跟着若干个有效entry，entry中记录着实际数据块的物理地址。若文件较大，由若干个分散的块存储，那么Extent也可以将所有零散的块进行组合。

表1 Extent header头结构说明

3 基于日志的文件恢复方法

由于eMMC存储设备有一定的擦写寿命，频繁地擦写数据会对存储区域造成不可恢复的损坏。为了保证所有存储区域能够均衡受损，文件系统在删除文件后，并没有对其物理块进行彻底删除，而是只断开了其存储位置的索引节点，即上述章节介绍的inode。因此，对于删除的文件，其内容仍就保存在存储区中，文件系统只是找不到其物理地址的索引节点。那么文件恢复的一种可行的思路就是要找到存储区是否仍保存有删除文件的索引。由此，基于日志的文件恢复方法应运而生[5-6]，该方法正是基于日志区能够保存文件系统近期的文件操作的原理，力争在日志区中尽力还原被删文件的索引，找到inode就可以找到物理块位置，进而恢复出文件数据。

3.1 方法设计

2.1节我们分析得到，日志区会对要修改、删除文件的inode进行备份[3，7]，且inode中256字节具备一定的特征规律。基于此，文章设计基于日志的inode搜索方法进行文件恢复。实验的前提是要获取到Android终端镜像，具体的方法如下图4所示：

图4基于日志的文件恢复算法流程

对于给定分区镜像，由于日志inode固定为8号，因此很容易在inode table中查找到8号inode节点，从而定位到日志inode节点位置；得到了inode节点位置后，可以得到inode节点的256字节内容，其中40～99位记录了文件索引，即存储文件的实际物理块地址。由此，可以计算得到此分区的日志文件物理地址，进而得到日志文件全部内容；在得到了日志文件之后，对日志文件内容进行遍历，选取inode结构中的特殊元素，此算法中选择Extent header中的magic number，即0x0AF3，在整个日志文件中进行遍历，将找到的inode特征元素进行扩展，得到256 B的inode，并形成inode集合；得到了inode集合后，此时是得到了日志区中记录的全部inode信息，这里包含了那些最近新建或修改的文件inode，因此要对这些未被删除的文件inode进行筛除。通过遍历inode table可以实现此功能；在得到了有效inode集合后，对每一个inode节点进行分析，计算其所关联的文件物理块地址；最后将每个文件的若干物理块地址对应的数据进行整合，还原得到文件。

3.2 实验

由于本实验是基于镜像的恢复，因此在实验前需要获取终端的分区镜像，选择安装了Android 5.1.1的手机，该手机已经获取到ROOT权限，未获取ROOT权限的手机无法提取镜像。为了方便查看实验结果，将实验中的文件都用图片来进行，这样恢复到的图片更容易查看和对比恢复结果。

实验将按如下步骤展开：1)向手机中放入20张已有图片，如图5所示；2)手动在人工管理器中删除上述所有图片；3)通过取证工具，或DD命令(dd if=待提取的分区挂载点 of=存储的路径)的方式对终端userdata分区镜像进行提取(通过df命令查看到，userdata正是存入的图片所在的分区)，保存为n5.img；4)对n5.img文件，执行实验中编写的python脚本(recovery.py，为本实验方法的实现脚本，图6为代码对应的系统框架图)；5)分析并统计恢复得到的图片。

图5 原始图片数据

实验方法采用python语言开发，按图6所示系统框架图编写recovery.py脚本，用以对实验中得到的镜像进行处理。

通过本实验设计的方法，成功地在日志区中查找并恢复出如图7所示的图片(本方法未对文件名进行恢复)。

对比图5和图7可知，实验存入的20张图片均被完整恢复，同时，还有恢复出了若干张非本次实验删除的图片(上述结果中已做删除)，代码运行速度为10 min以内。随后又对实验进行了扩展，分别向测试终端中手动存入50张、100张、几百张图片，并重复上述实验。整个实验过程中只需要人工存入指定数目的图片、删除并提取终端镜像即可，recovery.py脚本将自动化地进行全部恢复流程。

结果发现，在图片数<100张时，90%以上的图片均可以得到有效恢复。当图片数较多时，恢复得到的百分比降低，但恢复用时相差不大。这是因为，日志区的大小是固定的，只能存储有限数据，当删除、修改、新增文件数较多时，日志区中存储的早前的操作记录就会被覆盖，造成基于日志的文件恢复效果降低。同时，也正是因为日志区大小固定，因此恢复的时间取决于遍历此区域所需时间，图片总数对其影响不大。

图6 系统框架图

图7 恢复的图片

另外，实验中还对比了不同大小的图片删除恢复效果，发现在图片总数较少时，不同大小的图片均能得到有效恢复，也即，基于日志的文件恢复方法中，待恢复的文件大小不会影响本方法的恢复效果。这一结果也和方法的原理是一致的，因为实验中关注的是删除的inode本身(且inode大小固定)，原始文件的大小并不会影响日志区中存储的inode个数，因此不会影响实验结果。

4 结语

日志文件系统为Android平台的文件恢复带来了可能性，通过日志区找到文件所在物理块的索引地址，实现文件内容的恢复。然而，这种思路依赖于Android智能终端可以获取到镜像，而如今随着终端系统版本的升级，获取ROOT权限几乎成为不可能，因此获取镜像的难度越来越大。此外，由于日志区的大小固定、容量有限，对于删除数据的恢复能力还有一定的限制，后续可以结合文件雕刻的方式对镜像中的文件进行进一步恢复。