Dex文件整体结构如下:
dex文件结构的详细分析可以回看第四章-Dex文件结构分析。这里我们在dex整体加密,暂时只用到Dex文件头,所以我们主要介绍下Dex文件头的结构。
这里面,有3个成员我们需要特别关注,这在后面加固里会用到,它们分别是checksum、signature和fileSize。
0x01 checksum字段
checksum是校验码字段,占4bytes,主要用来检查从该字段(不包含checksum字段,也就是从12bytes开始算起)开始到文件末尾,这段数据是否完整,也就是完整性校验。它使用alder32算法校验。
0x02 signature字段
signature是SHA-1签名字段,占20bytes,作用跟checksum一样,也是做完整性校验。之所以有两个完整性校验字段,是由于先使用checksum字段校验可以先快速检查出错的dex文件,然后才使用第二个计算量更大的校验码进行计算检查。
0x03 fileSize字段
占4bytes,保存classes.dex文件总长度。
这3个字段当我们修改dex文件的时候,这3个字段的值是需要更新的,否则在加载到Dalvik虚拟机的时候会报错。
替换classloader时机
Application:attachBaseContext()
ContentProvider:onCreate()
APplication:onCreate()
加载原始application
1.获取原始application的class name
2.加载原始application并生成对象
3.替换API层所有Application引用
4.设置baseContext并调用原始application的onCreate()
Dex 文件整体加固原理如下:
在该过程中涉及到三个对象,分别如下:
l 源程序
源程序也就是我们的要加固的对象,这里面主要修改的是原apk文件中的classes.dex文件和AndroidManifest.xml文件。
l 壳程序
壳程序主要用于解密经过加密了的dex文件,并加载解密后的原dex文件,并正常启动原程序。
l 加密程序
加密程序主要是对原dex文件进行加密,加密算法可以是简单的异或操作、反转、rc4、des、rsa等加密算法。
该加固过程可以分为如下4个阶段:
(1) 加密阶段
(2)合成新的dex文件
(3)修改原apk文件并重打包签名
(4)运行壳程序加载原dex文件
0x01 加密阶段
加密阶段主要是讲把原apk文件中提取出来的classes.dex文件通过加密程序进行加密。加密的时候如果使用des对称加密算法,则需要注意处理好密钥的问题。同样的,如果采用非对称加密,也同样存在公钥保存的问题。
0x02 合成新的dex文件
这一阶段主要是讲上一步生成的加密的dex文件和我们的壳dex文件合并,将加密的dex文件追加在壳dex文件后面,并在文件末尾追加加密dex文件的大小数值。这样我们就合成了新的classes.dex文件。由于我们修改了dex文件,这时候
当然,还可以这样处理。将加密的dex文件保存到其他目录下,如assets资源目录。那么这时候我们新的classes.dex文件就直接是壳程序,不需要合成。两种方案都可以。
前面讲了讲加密dex文件保存到文件末尾,以及保存到资源目录下2中方法。其实还有一种更复杂的方案,就是讲加密dex文件保存到dex header中。我们回顾10.1.3节 Dex文件结构。Dex Header中有一个字段:header_size,这个字段是记录dex文件头的长度,一般情况下dex头文件大小为112bytes。我们可以将header_size修改为header_size和加密dex文件长度两者的总长度,并将加密dex文件嵌入到dex header末