小伙伴公司需要代码静态分析安全性，上了壳，就逆向分析了下。
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正常解析。
反调试和检测
大概看了下，有些功能没有开启的。
0x3D2B0 Fork后Ptrace，开启各种检测线程。
0x32D08 anti_thread_body函数检查tracerPid和status
0x4EEF8 waitpid 子进程是否终止。
**0x2F488 **do_hook_log
0x2E624 run_addition函数，获取ro.debuggable和signatures等等
sub_50B44 文件hash检测。
Dex解密
0x3D494 查找dex的指针，找到标志位。通过java的DexCache类dexFile找到dex指针，这我也第一次知道这个结构，可以这么定位dexFile。
sub_4F8BC 计算dex大小，申请一大块内存，存储解密后的完整的所有的dex。
0x3E10C 申请内存，解密dex的密文部分，并拷贝回上一步那块内存，加密算法，晕了。
dump后，得到11个dex,收工！
最后
附件是修复后的so，很多字符串明文，很容易理解它的逻辑，仅供学习。
New对象处