| resources.arsc | 编译后的二进制资源文件索引。 |
4.2DEX文件格式
4.2.1什么是DEX文件?
他是Android系统的可执行文件,包含应用程序的全部操作指令以及运行时数据
由于dalvik是一种针对嵌入式设备而特殊设计的java虚拟机,所以dex文件与标准的class文件在结构设计上有着本质的区别
当java程序编译成class后,还需要使用dx工具将所有的class文件整合到一个dex文件,目的是其中各个类能够共享数据,在一定程度上降低了冗余,同时也是文件结构更加经凑,实验表明,dex文件是传统jar文件大小的50%左右
4.2.2dex文件结构
Dex文件整体结构如下:
Dex文件整体结构说明:
数据名称 | 解释 |
---|---|
dex_header | dex文件头部记录整个dex文件的相关属性 |
string_table | 字符串数据索引,记录了每个字符串在数据区的偏移量 |
type_table | 类似数据索引,记录了每个类型的字符串索引 |
proto_table | 原型数据索引,记录了方法声明的字符串,返回类型字符串,参数列表 |
field_table | 字段数据索引,记录了所属类,类型以及方法名 |
method_table | 类方法索引,记录方法所属类名,方法声明以及方法名等信息 |
class_def | 类定义数据索引,记录指定类各类信息,包括接口,超类,类数据偏移量 |
data_section | 数据区,保存了各个类的真是数据 |
下面是DEX文件目录:
这里面,有3个成员我们需要特别关注,这在后面加固里会用到,它们分别是checksum、signature和fileSize。
checksum字段
checksum是校验码字段,占4bytes,主要用来检查从该字段(不包含checksum字段,也就是从12bytes开始算起)开始到文件末尾,这段数据是否完整,也就是完整性校验。它使用alder32算法校验。
signature字段
signature是SHA-1签名字段,占20bytes,作用跟checksum一样,也是做完整性校验。之所以有两个完整性校验字段,是由于先使用checksum字段校验可以先快速检查出错的dex文件,然后才使用第二个计算量更大的校验码进行计算检查。
fileSize字段
占4bytes,保存classes.dex文件总长度。
这3个字段当我们修改dex文件的时候,这3个字段的值是需要更新的,否则在加载到Dalvik虚拟机的时候会报错。
为什么说我们只需要关注这三个字段呢?
因为我们需要将一个文件(加密之后的源Apk)写入到Dex中,那么我们肯定需要修改文件校验码(checksum).因为他是检查文件是否有错误。那么signature也是一样,也是唯一识别文件的算法。还有就是需要修改dex文件的大小。
不过这里还需要一个操作,就是标注一下我们加密的Apk的大小,因为我们在脱壳的时候,需要知道Apk的大小,才能正确的得到Apk。那么这个值放到哪呢?这个值直接放到文件的末尾就可以了。
所以总结一下我们需要做:修改Dex的三个文件头,将源Apk的大小追加到壳dex的末尾就可以了。
4.3APK打包流程
上图中涉及到的工具及其作用如下:
名称 | 功能介绍 |
---|---|
aapt | 打包资源文件,包括res和assets文件夹下的资源、AndroidManifest.xml文件、Android基础类库 |
aidl | 将.aidl接口文件转换成.java文件 |
javaComiler | 编译java文件,生成.class字节码文件 |
dex | 将所有的第三方libraries和.class文件转换成Dalvik虚拟机支持的.dex文件 |
apkbuilder | 打包生成apk文件,但未签名 |
jarsigner | 对未签名的apk文件进行签名 |
zipalign | 对签名后的apk文件进行对其处理 |
4.4加固原理
Dex文件整体加固原理如下:
在该过程中涉及到三个对象,分别如下:
l 源程序
源程序也就是我们的要加固的对象,这里面主要修改的是原apk文件中的classes.dex文件和AndroidManifest.xml文件。
l 壳程序
壳程序主要用于解密经过加密了的dex文件,并加载解密后的原dex文件,并正常启动原程序。
l 加密程序
加密程序主要是对原dex文件进行加密,加密算法可以是简单的异或操作、反转、rc4、des、rsa等加密算法。
该加固过程可以分为如下4个阶段:
(1)加密阶段
(2)合成新的dex文件
(3)修改原apk文件并重打包签名
(4)运行壳程序加载原dex文件
4.4.1 加密阶段
加密阶段主要是讲把原apk文件中提取出来的classes.dex文件通过加密程序进行加密。加密的时候如果使用des对称加密算法,则需要注意处理好密钥的问题。同样的,如果采用非对称加密,也同样存在公钥保存的问题。
4.4.2 合成新的dex文件
这一阶段主要是讲上一步生成的加密的dex文件和我们的壳dex文件合并,将加密的dex文件追加在壳dex文件后面,并在文件末尾追加加密dex文件的大小数值
在壳程序里面,有个重要的类:ProxyApplication类,该类继承Application类,也是应用程序最先运行的类。所以,我们就是在这个类里面,在原程序运行之前,进行一些解密dex文件和加载原dex文件的操作。
4.4.3 修改原apk文件并重打包签名
在这一阶段,我们首先将apk解压,会看到如下图的6个文件和目录。其中,我们需要修改的只有2个文件,分别是classes.dex和AndroidManifest.xml文件,其他文件和文件加都不需要改动。
首先,我们把解压后apk目录下原来的classes.dex文件替换成我们在0x02上一步合成的新的classes.dex文件。然后,由于我们程序运行的时候,首先加载的其实是壳程序里的ProxyApplication类。所以,我们需要修改AndroidManifest.xml文件,指定application为ProxyApplication,这样才能正常找到识别ProxyApplication类并运行壳程序。
4.4.4运行壳程序加载原dex文件
Dalvik虚拟机会加载我们经过修改的新的classes.dex文件,并最先运行ProxyApplication类。在这个类里面,有2个关键的方法:attachBaseContext和onCreate方法。ProxyApplication显示运行attachBaseContext再运行onCreate方法。
在attachBaseContext方法里,主要做两个工作:
-
读取classes.dex文件末尾记录加密dex文件大小的数值,则加密dex文件在新classes.dex文件中的位置为:len(新classes.dex文件) – len(加密dex文件大小)。然后将加密的dex文件读取出来,解密并保存到资源目录下
-
然后使用自定义的DexClassLoader加载解密后的原dex文件
在onCreate方法中,主要做两个工作:
-
通过反射修改ActivityThread类,并将Application指向原dex文件中的Application
-
创建原Application对象,并调用原Application的onCreate方法启动原程序
五、加壳及脱壳代码实现
5.1、加壳程序项目:
5.2、核心代码
六、常见加固平台
梆梆加固,爱加密,360加固,腾讯加固
市面上常见的加固工具加固之后,他会把你的dex,so 加密存在apk中,然后运行过程会先运行壳的代码,壳的代码再把原来的这个dex、so 解出来加载,不同的厂商有自己的方案,略有差距,但目前多数都是这个思路.
七、App加固的利弊
正面:
1.保护自己核心代码算法,提高破解/盗版/二次打包的难度
2.缓解代码注入/动态调试/内存注入攻击
负面:
1.影响兼容性
2.影响程序运行效率.
3.部分流氓、病毒也会使用加壳技术来保护自己
4.部分应用市场会拒绝加壳后的应用上架
八、App安全未来展望
一款app的流水线,从开发到内测到平台到消费者再到破解者再到平台再到消费者,所以每一个环节都不可轻视!!!
九、App安全总结
风险名称 | 风险 | 解决方案 |
---|---|---|
1.App防止反编译 | 被反编译的暴露客户端逻辑,加密算法,密钥,等等 | 加固 |
2.java层代码源代码反编译风险 | 被反编译的暴露客户端逻辑,加密算法,密钥,等等 | 加固 ,混淆 |
3.so文件破解风险 | 导致核心代码泄漏。 | so文件加固 |
4.篡改和二次打包风险 | 修改文件资源等,二次打包的添加病毒,广告,或者窃取支付密码,拦截短信等 | 资源文件混淆和校验签名的hash值 |
5.资源文件泄露风险 | 获取图片,js文件等文件,通过植入病毒,钓鱼页面获取用户敏感信息 | 资源混淆,加固等等 |
6.应用签名未交验风险 | 反编译或者二次打包,添加病毒代码,恶意代码,上传盗版App | 对App进行签名证书校验 |
7.代码为混淆风险 | 业务逻辑暴露,加密算法,账号信息等等。 | 混淆(中文混淆) |
8.webview明文存储密码风险 | 用户使用webview默认存储密码到databases/webview.db root的手机可以产看webview数据库,获取用户敏感信息 | 关闭wenview存储密码功能 |
9.明文数字证书风险 | APK使用的数字证书用来校验服务器的合法性,保证数据的保密性和完成性 明文存储的证书被篡改造成数据被获取等 | 客户端校验服务器域名和数字证书等 |
10.调试日志函数调用风险 | 日志信息里面含有用户敏感信息等 | 关闭调试日志函数,删除打印的日志信息 |
11.AES/DES加密方法不安全使用风险 | 在使用AES/DES加密使用了ECB或者OFB工作模式,加密数据被选择明文攻击破解等 | 使用CBC和CFB工作模式等 |
12.RSA加密算法不安全风险 | 密数据被选择明文攻击破解和中间人攻击等导致用户敏感信息泄露 | 密码不要太短,使用正确的工作模式 |
13.密钥硬编码风险 | 用户使用加密算法的密钥设置成一个固定值导致密钥泄漏 | 动态生成加密密钥或者将密钥进程分段存储等 |
14.动态调试攻击风险 | 攻击者使用GDB,IDA调试追踪目标程序,获取用户敏感信息等 | 在so文件里面实现对调试进程的监听 |
15.应用数据任意备份风险 | AndroidMainfest中allowBackup=true 攻击者可以使用adb命令对APP应用数据进行备份造成用户数据泄露 | allowBackup=false |
16.全局可读写内部文件风险。 | 实现不同软件之间数据共享,设置内部文件全局可读写造成其他应用也可以读取或者修改文件等 | (1).使用MODE_PRIVATE模式创建内部存储文件(2).加密存储敏感数据3.避免在文件中存储明文和敏感信息 |
17.SharedPrefs全局可读写内部文件风险。 | 被其他应用读取或者修改文件等 | 使用正确的权限 |
造成用户数据泄露 | allowBackup=false | |
16.全局可读写内部文件风险。 | 实现不同软件之间数据共享,设置内部文件全局可读写造成其他应用也可以读取或者修改文件等 | (1).使用MODE_PRIVATE模式创建内部存储文件(2).加密存储敏感数据3.避免在文件中存储明文和敏感信息 |
17.SharedPrefs全局可读写内部文件风险。 | 被其他应用读取或者修改文件等 | 使用正确的权限 |