小伙伴公司需要代码静态分析安全性，上了壳，就逆向分析了下。

Java层分析

Apk打开没有太多的代码，在自定义的application中加载了一个名为**Helper的so。

在doAttach函数中能够找到反射调用原application的初始化。

Native层分析

修复so代码

打开so查看dynamic表，存在.init.proc，initarray只有一个函数。
再查看jni_onload函数，发现密文，猜测是init_array或者init_proc中解密so中代码段，修复代码段必定涉及mprotect，要么调用libc要么svc自己实现，能够快速找到可疑位置。

Init.proc，调用sub_10150C，再调用三次sub_1011A0函数修改内存权限，通过svc调用mprotect修改该so在内存中的权限，修复该so原本的代码。


Dump代码段，修复elf，再次查看jni_onload，ida正常解析。

反调试和检测

Dex解密

0x3D494 查找dex的指针，找到标志位。通过java的DexCache类dexFile找到dex指针，这我也第一次知道这个结构，可以这么定位dexFile。


sub_4F8BC 计算dex大小，申请一大块内存，存储解密后的完整的所有的dex。

0x3E10C 申请内存，解密dex的密文部分，并拷贝回上一步那块内存，加密算法，晕了。

dump后，得到11个dex,收工！

最后

附件是修复后的so，很多字符串明文，很容易理解它的逻辑，仅供学习。