小伙伴公司需要代码静态分析安全性,上了壳,就逆向分析了下。
Java层分析
Apk打开没有太多的代码,在自定义的application中加载了一个名为**Helper的so。
在doAttach函数中能够找到反射调用原application的初始化。
Native层分析
修复so代码![](https://img-blog.csdnimg.cn/direct/b047af82380b4f5d81105f44327298d7.png)
打开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的密文部分,并拷贝回上一步那块内存,加密算法,晕了。