Question

前面了解了 allowBackup 属性的相关知识点，可以看到 allowBackup 属性的风险非常大。如果这个属性是 true 的话，怎么在没有 root 的设备去获取数据呢？

首先看这样一个场景，现在市场上有一些应用锁类的 App，它们就是给每个应用打开的时候添加一个密码，打开 App 的时候需要输入密码才能进入应用，一般会把自己的银行 App、通讯类的 App 加密。现在市场上这些应用锁的原理也很简单，一般是三种方式实现：

·最古老的方式是后台启动一个 service，然后隔一段时间去轮询，获取当前的 topActivity，然后进行操作。

·因为 Android 5.0 以后，获取当前的 topActivity 需要授权，所以这里还需要做一个操作就是引导用户去开一些权限功能。

·通过辅助功能可以监听当前 Window 的变化，这种方式比上面的轮询方式高效多了。

其实前两种方式差不多，唯一的区别就在于获取 topActivity 的方式，其实 Google 可能意识到了，获取 topActivity 是很危险的一件事：比如现在有一个恶意的软件，可以通过这个功能，当用户启动设备中的一些通讯、银行 App 的时候，可以监听到然后就启动他们自己定义的钓鱼登录页面，模拟这些 App 的登录，最终可以获取到用户名和密码了，完成盗取。

下面来看一个市场上比较火的一款应用锁 App，如图 11-1 所示。

图 11-1　市场中的某个应用锁 App

下载这个 apk 之后使用 aapt 查看它的 AndroidManifest.xml 内容：

在拿到一个 apk 的时候，如果想知道 apk 中的一些资源和配置信息，aapt 命令是个不错的选择，同时，它能够删除 apk 中的一些资源，添加一些资源到 apk 中都是可以的，查看结果如图 11-2 所示。

因为 AndroidManifest.xml 内容有点多，就重定向到一个 txt 文件中，看到 allowBackup 属性为 true，因为非 0 的都是 true。说明 applock.apk 这个应用是可以使用 adb backup 命令进行隐私数据的备份的。接下来就看一下如何进行备份。

第一步：进行数据的备份

代码如下：

·[-system|-nosystem]　这个指令是告诉 adb 在备份时是否要连同系统一起备份。若没有打的话默认是-system 表示会一起备份系统。若连系统一起备份，在还原的时候会复盖系统档案对于已经升级后的手机是非常不好的。我不知道在没有 root 的情况下 adb 是否有权限去还原系统档案，但就算如此，还是不建议这样做。因此-nosystem 是建议一定要打上的指令。

图 11-2　aapt 命令查看应用的 AndroidManifest.xml

·-all　这个指令除非只是要备份单一 App 不然是一定要打上去的。这个是问你是否要备份全部的 App，若有加上-nosystem 的指令。那么就只会备份你目前已经安装上去的 App 而不会连系统 App 一起备份。

·[-apk|-noapk]　默认是-noapk，这个参数的意思是，是否连安装的 apk 一起备份。若为-noapk，则只会备份 apk 的资料档（像是游戏存盘、设定之类的）。

·[-shared|-noshared]　默认是-noshared，这个会问你是否连手机储存空间或是 SD 卡的档案一起备份。关于这个应用的包名，可以直接从上面 dump 出来的 AndroidManifest.xml 中获取即可，如图 11-3 所示。

图 11-3　查看 AndroidManifest.xml 文件

获取包名之后，就可以执行命令，把导出来的文件保存到当前目录下：applock.ab，如下所示，注意这里的格式是 ab，这个也是 Android 中备份文件的格式要求：

当执行这个命令的时候，设备端会出现一个提示页面，如图 11-4 所示。

这时候会提示输入备份密码，为了简单可以不输入，直接点击备份即可，备份完之后的文件如图 11-5 所示。

图 11-4　备份截图

图 11-5　备份之后的文件

第二步：abe 工具来解析 ab 文件

还需要借助一个工具来解析这个 ab 文件。这个工具是开源的，用 Java 语言写的。源码位于： https://github.com/nelenkov/android-backup-extractor

这里没有直接下载源码，然后编译了，直接在网上下载了一个编译好的工具，工具下载地址如下。

提示：工具下载地址：

http://download.csdn.net/detail/jiangwei0910410003/9523470

用法也很简单，看到使用 unpack 参数来将 ab 文件转化成 tar 文件：

再用解压缩软件查看内容，如图 11-6 所示。

图 11-6　压缩软件打开备份文件

现在如果想知道它的密码，可以直接查看 SharePreferences

文件即可，因为一般都会把密码放到这里保存，当然这是一个非常危险的操作，如果再没有对密码进行加密的话，那更是危险了，如图 11-7 所示，是应用的沙盒中 XML 数据。

查看 SmartLockConfig.xml 内容，如图 11-8 所示。

被猜中了，它竟然把手势密码以明文的方式保存在这里。这里它用的是九宫格手势方式加密，03678 代表的应该是一个 L，可以对照图 11-9 九宫格图查看。

图 11-7　SharedPreference 文件

图 11-8　存储密码文件

到这里就成功破解了应用锁应用的加密 App 的功能，而且是在设备没有 root 的情况下。下面来总结一下：

图 11-9　九宫格图

1）这个 App 现在在市场的下载量还是蛮高的，但是看到它一不留神把 allowBackup 属性设置成 true，就导致了数据可能被外泄，更为有趣的是，在使用几个 IDE 工具，默认新建的工程之后，这个属性的值也是 true，如下所示（Eclipse 和 AndroidStudio 开发工具）。

上面就是现在比较常用的两个 IDE 工具：Eclipse 和 AndroidStudio。可以看到当新建一个工程时，默认把这个属性设置成 true，那么当不设置这个属性时，也是可以进行备份的，因为默认值是 true。也许 Google 的想法是为了防止数据的丢失，就留了这个功能，便于用户备份数据。但是这里会隐含一些安全问题，在开发时如果不去注意这个属性的话，就会产生很大风险。以后在开发的过程中一定要记得把这个属性设置成 false，特别是非常重要的需要账号登录的 App。

2）上面分析了应用锁的 App，并非只是一个案例，其实现在很多 App 都有这个问题，看看某市场 App，如下所示：

它也是没有手动改变这个属性为 false，所以它的数据也是可以导出来的。再看看某视频 App，如下所示：

也是一样，不过像这些 App，它们的账号登录密码的信息肯定不是放在本地的，而是放到服务端进行验证的，不像应用锁这样的，它不需要联网也是可以进行操作，所以密码必须放到本地。但是只要这个属性 allowBackup 为 true 的话，就会被查看到沙盒数据，就是不安全的。最后再来看看某社交 App 的 5.0 版本也有这个问题，不过它在 6.0 之后已经把 allowBackup 设置成 false 了，如下所示：

这里看到它没有设置 allowBackup 属性，但是刚刚说了，默认值就是 true，所以还是可以导出来的，下面可以使用上面的导出步骤进行操作，如图 11-10 所示。

图 11-10　社交数据库信息

其实社交 App 把通讯录和聊天记录都是保存到数据库中，但是这个数据库是加密的。数据库加密，其实是需要反编译 App 才知道，然后动态调试跟踪代码破解，因为通讯录和聊天内容是没有网络就可以查看的，那么加解密肯定是放在本地做的，只要是放在本地做的就可以进行破解。

不过可以看到这个 App 在后续的版本已经修复了这个问题，6.0 版本之后就不能导出来数据了，那么 5.0 的用户其实还是会受影响的。

3）还是回到这个应用锁 App 中来，其实在这里还是想说一番的，作为下载量蛮高的 App，竟然把密码用明文保存到 XML 中，这种做法其实是对用户的不负责，首先这里完全可以使用 MD5 来做密码验证就可以了，为何要暴露明文；其次是为什么把这么重要的数据保存到 XML 中，稍微加点破解难度考虑放到 so 中也是可以的。

4）开发的过程中，最后一步发包的时候一定要检查一下这个属性是否为 false，因为它牵涉到应用的太多隐私信息了。