国内Android市场、论坛层出不穷，且Android app可以容易地被反编译分析甚至破解篡改，从而导致连锁的安全问题。议题主要从Android App面临的安全现状入手分析存在的主要问题，并针对相关脆弱点,对相应的保护措施进行分析和总结。

我来自 WiFi万能钥匙，主要负责安卓立项和保护这块的工作。本文要分享的有七大块：

Android 平台安全现状

Android 安全模型

程序安全

数据安全

系统安全

一款被篡改的 APK

APK 保护措施

1. Android 平台安全现状

左上角这张图是安卓端的恶意程序新增量和感染量。

右下角这张图是恶意程序类型的分布也占了很大的比例。

这些情况对一般用户都是比较敏感的行为，在安卓这块恶意程序的出现，也是应该引起我们一些注意。

移动终端特性：

攻击入口广

浏览器、恶意 app、网络劫持、usb

碎片化

安卓手机厂商多、安卓系统碎片化

用户隐私

通话、短信、应用数据

安卓出现这么多恶意程序，是由于移动终端的特性决定的。

攻击入口比较广，比如安卓上的一些浏览器，一些恶意 APP，网络接口和 USB。浏览器很多时候在用户不知道的情况下可能会点击一些恶意网站的链接，打开以后可能会有一些浏览器的漏洞，导致恶意下载一些 APP，后台可能会有一些静态的 ROOT 这些行为。另外网络劫持也是比较常见的，往往这些劫持的 APP 下载下来都是充满着各种恶意行为。

另外像碎片化，这个在国内更加的普遍，因为在国内安卓厂商比较多，并且系统也是各个厂商定制的比较多，各种各样的厂商不同的入口会导致不同的问题。

还有就是安卓系统，现在8.0版本出来可能稍微好一点。之前安卓系统漏洞是比较多的，像用户的隐私，如通话、短信和应用数据，只要申请一些权限就可以获取这些数据。

2. Android 安全模型

Linux内核安全特性

保留对应版本 Linux 内核的常规安全特性

基于 UID、GID 隔离的访问控制

单用户系统,Android 使用UID、GID 区分不同的 App

沙盒

每一个 App 在/data/data 下拥有一个私有目录

每一个 App 或服务对应单独的 UID,系统级 UID 从1000开始,第三方 App 从10000开始,以此进行 UID 级的资源隔离

权限

App 需要权限来访问各种系统资源

App 可以通过 AndroidManifest.xml 来申请权限

权限分级

由用户在安装时决定是否允许该权限

4.3之后可以动态管理

IPC 进程间访问控制

IPC 用于不同进程之间的数据通信

IPC 在上层有多种体现方式

Intent/Messenger/AIDL

APK完整性

Apk签名

SELinux

内核级的强制访问控制

4.3开始引入 Android

保护系统关键资源

其实安卓做了一些安全的东西，上图左边是安卓的安全架构，第一个是 Applications，第二层是 Android framework，代码签名，系统签名等等，还有多用户访问控制，加密，权限保护等等，但是这些机制并不是完全的够用。

像 Linux 的安全特性，是常规在 Linux 进行修改变化过来的，所以跟我们常见的 PC 上的 Linux 不一样。比如它是基于 UID 和 GID 的访问控制，另外在 APP 端是单独的控制，每个 APP 安装上去都会给你分配一个 UID。这个是安全上的一个沙盒，系统级的 UID 都是从1000开始，第三方 APP 是从10000开始的，以此进行UID级别上的资源隔离。此外，每一个 APP 在系统的/data/data下拥有一个私有的目录，在这些目录下面的隐私数据其他的 APP 也是可以获取到的。

权限这块其实现在对安卓来说是可以做到管理的，可以更好的进行一些控制。以前系统安装的时候直接申请所有权限，要么全部给，要么全部不给。

另外安卓上的一些签名，这在我们平时工作中也会遇到很多挑战或者威胁，因为安卓它本来 APP 是有相应的签名的，但是很容易被绕过，因为现在市场上有很多二次打包的 APP，有一定的加护，可以进行系统校验。我们平时也会遇到这样的问题，即使做了校验，还可以通过系统进行反射绕过的。

3.程序安全

程序安全比较常规的像防止反编译，篡改，代码注入等等。

反编译本来原代码里面是没有这块的，在代码里面加入一些获取插件的代码，往往这些攻击是注重自我的保护，下载这些插件以后过了几秒钟就删掉了，然后在五秒之内会启动自己的插件和服务。

加密算法是比较关键的地方，我们在分析 APP 的时候分析加密算法是比较脆弱的，java 层加密算法其实是没有什么用处的，我们建议在 SO 里面进行加密算法。

另外就是 HTTP 和 HTTPS 这块了，裸奔的 HTTP 是不安全，HTTPS 加密信道安全性依赖于对证书的认证。

4.数据安全

敏感数据

本地数据库

Shared_prefs

网络数据传输

Sdcard

Log

……

APP 上比较常见的本地数据库、Shared_prefs、网络传输。网络传输是比较关键的地方，往往我们在做 APP 的测试的时候对网络和传输这块看的比较多一点，因为网络传输比较容易被劫持。另外像 SD 卡、日志等等。

5. 系统安全

系统环境安全

界面劫持

组件暴露

键盘记录

系统库安全

WebView 不合理导出

targetSdkVersion<= 16、addJavaInterface

运行 js 代码调用本地代码

系统安全比如界面劫持，这个对于金融类的 APP 可能会比较多一点，它会直接弹出一个跟你界面一样的界面，诱导你输入帐号、密码等等。

上面图片就是 WebView 的漏洞。

6. 一款被篡改的 apk

工作原理

篡改程序入口

初始化支付

下载病毒母体

准备提权

下载篡改系统工具包

其它恶意行为

恶意 APP 分析：

上面例子就是恶意的被篡改的 APP 大概的运行过程。

首先是打包一个 APP，在运行中会下载恶意的母体，并且有一些短信拦截和提权等等恶意操作。我们通过反编译能够看到是把这个 APP 的初始化函数加入了一段自己的初始化的代码，然后我们在这个 APP 的一个注册文件里面可以看到上面图中加入的内容，就是如果发生了这样的信号，就可以把自己的相应组件给隐藏起来。

另外还可以看到在代码里面直接写入了支付的代码，并且进行了初始化，这个一旦成功了就可以直接进行支付了。

这只是其一，下面还会从服务器端下载一个恶意的病毒母体，从代码上可看出攻击者有一定的安全意识，他把自己的服务器等等在代码里面都加密了。我们可以通过网络抓包可以看到相应的服务器地址，并且都是加密的。

下载一段 eql，是一个压缩包并且是可执行文件，打开后并不是一个图片，而一个加密的文件，我们对它进行解密可以看到也是一个压缩文件，进一步解密后是 ELF 的文件。

此外还会下载另一个工具包，也是经过加密的，通过解密里面包含了四个文件，第一个是可以篡改系统的脚本，第二个是需要把这个 APP 写入系统目录，第三个是一个 SU 的可执行文件，第四个是命令监控与执行的文件，可以监听 SD 上的文件，然后去执行写入这个文件的所有命令，图中可以看出它执行过程中会做哪些操作，如把系统比如360、QQ安全管家等等都会关掉，做一个篡改，一个系统的目录和其他的恶意行为，比如删除系统文件，篡改系统工具包等等。

图中就是篡改了系统下面的一个文件，这个文件其实是在系统里面执行的文件，他篡改了这个文件后，每次用户重启手机的时候，就会执行他这个恶意行为代码，可以从服务器下载非常多的 APP 文件，在用户后台进行安装，还会定制各种服务，让用户手机进行扣费。

这个例子就是在我们 APP 没有进行很好保护的情况下，会产生很多被篡改，导致用户损失。

7. APK 保护措施

APK 加壳与混淆

加大代码分析难度

代码加密、隐藏、反调试、反逆向分析等

APK 加壳

APK 混淆

APK 完整性检验

变量名混淆、字符串加密、垃圾指令、指令替换、native 扰乱控制流

反调试:ptrace、/proc/self/status、……

反内存 dump

反一键脱壳器

验证证书、校验文件 hash 值等

静态完整性

动态完整性

混淆

代码隐藏

llvm

代码段加密

自定义 so 格式

伪造无效字段信息

非法指令

Manifest 文件修改、资源加密、……

DEX 文件加壳,整体保护、类抽取

防反编译工具,修改文件头、修改 debug 字段数据指针、……

SO 保护

通过上面的例子，我们需要对我们 APP 进行更好的保护。

APP 的保护主要从两个方面入手，一个是加壳，另一个是混淆。

加壳比如代码加密、隐藏、反调试、反逆向分析等等。

APK 混淆就是加上代码。

APK 的校验有静态完整性，像验证证书、校验文件的 Hash 值等。还有动态完整性，像反调试 ptrace 等、反内存 dump、反一键脱壳器。现在网络上面有很多一键脱壳的神器，所以一般的加护并不能很好的保护，还是需要进行反一键脱壳的措施。

像保护方式不管是反调试还是验证证书等，更多还是希望在 SO 里面做，这样相对来说安全性会相对高一点，同时还要对 SO 进行相应的保护，这样可以达到更好的保护效果。

还有混淆，像变量名的混淆、字符串的加密、通过垃圾指令、通过指令替换、native 来干扰扰乱控制流。

代码隐藏主要是通过修改 Manifest 文件、资源加密、DEX 文件的加壳、整体保护、类抽取等等。

其实我们应该更多的对 SO 进行保护，比如像 LLVM、对代码段的加密、自定义 SO 格式，这个可能比较好一点，因为常规的 SO 格式，攻击者会知道，通过自定义的 SO 格式在分析难度上会更加大一点。加入一些在调试的时候导致调试工具自动崩溃的反调试的工具。还可以加入一些非法指令来达到一些保护的目的。