【移动安全基础篇】——28、Apk加固

1. java 混淆

1) 名称替换
proguard：
-printmapping map.txt
-applymapping map.txt
dex2jar：
d2j-init-deobf –f –o map.txt x.jar
d2j-jar-remap –f –c map.txt –o x2.jar x.jar
jeb：
script
2) 字符串加密

3) 反射替换

4) 其他
日志清除：Log.x
XML 混淆：清除 string 信息
Assert 加密：Hook AssertManager.open 方法

5) Demo 演示
执行了恢复脚本后的效果对比，左为混淆版本，右为恢复版本

恢复脚本：

2. ELF 内存加载
加载 so 文件的函数，so 文件在 assert 文件夹中

so 文件是被加密的，只能看到几个段。因为文件格式不正确，所以需要先将文件格式进行修复。

修改后拖到 IDA 里就不会报错了。

因为 JNI_OnLoad 是被加密的，程序的执行首先会在 init_array 处。

程序在执行的时候只用到了程序头部表和各个段，节区头部表没有被用到。有时候节区头部表会被删掉，如果要恢复的话就需要用到链接视图中的相关信息。

对流程混淆的 so 文件进行恢复

动态调试 so 文件

设置断点

不过由于该 app 中存在反调试，所以调试出错，接下来换另一种方法

手动对 so 文件的该部分进行修改，将其改成死循环。然后对该文件重新打包并签名将该 app 安装之后直接运行并用 ida 进行 attach

程序停在了所修改的地方，然后将其改回去

可以进行动态调试，在解密函数处下个断点，加密方式是 RC4

使用脚本将解密后的部分 patch 出来

打开 patch 后的 so 文件，可以看到代码正常

在这三个函数中，前两个是为了防止 dump，后面一个是对程序的 upx 段进行解码

对其中的加密字符串进行还原

接下来使用动态跟踪的方式对 RC4 操作进行跟踪

整个 upx 的内存段已经被解密了，将其直接 dump 下来

对其文件头进行修改，使其能够被识别

使用 ida 打开后发现该 so 文件依旧是被加密的

此处的 dlopen 实现内存加载在 dlopen 处下好断点

将解密后的数据 patch 出来，将该文件用 ida 打开后，代码已经完全被还原，得到了原始的 so 文件

3. Dex 整体加密
1) Dex 整体加密方案

替换 classloader 时机：
Application:attachBaseContext()
ContentProvider:OnCreate()
Application:OnCreate()
加载原始 application：
获取原始 application 的 class name
加载原始 application 并生成对象
替换 API 层的所有 Application 引用
设置 baseContext 并调用原始 application 的 OnCreate()

旧版本中存在的是 DexClassLoader

DexFile 的结构体

得到 DvmDex 结构之后就能够获取原始 Dex 文件
加载 dex 文件操作

2) Demo

StubApplication 继承自 Application，通过 StubApplication.interface()释放 so 文件

此处注册了两个 native 方法的函数

先执行 classLoader，然后再执行 interface7()函数，该函数更改了 ContentProvider，也更改了 Application 和 Context 的一些相关引用。stubApplication 的 OnCreate()函数执行结束时，内存中的 Application 的对象(ClassLoader)都指向了新的 Application，与 stubApplication 没有关系了。取获取 dex 明文将脱壳后的 so 文件替换之前 apk 文件中的 so 文件，并在 so 文件执行时设置了断点。