本文主要是介绍dalvik下替换so简单dump出梆梆加固保护的odex，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
- 由于保护技术更迭迅速，不保证本文方法适用于后续或者其它版本的梆梆加固，需要读者自行测试。
梆梆加固后的apk，里面的classes.dex只是个外壳，负责加载libDexHelper.so，而真正的dex被加密放在了\assets\classes0.jar，这不是常规的jar文件无法直接解压，我们的目标就是从内存中dump出解密后的classes0.jar/.dex(并进行适当修复)。
内存dump的方案有很多, 比如直接dd、DexHunter等，但都有一些缺点，dd需要内存地址和大小，这就要求进行暴力搜索，但是内存完全可能被处理过，dump时机很难掌握，于是转到动态调试期望在关键点下断，但由于反调试对抗的存在又会有一堆麻烦；DexHunter很强大，但它要求定制系统，这对逆向工程来说当然不是事，只是同样有针对DexHunter类似原理的对抗，比如检测不安全ROM，等等这些都会带来不必要麻烦，本文提供的方法似乎直接跳过了这些坑。
其实，无论是DexHunter还是本文提供的方案，最关键的不过是取得代码执行先机，因为代码一但被安全的注入，在壳启动前执行我们的代码，我们就能完成很多有意思的事情了。怎么实现呢？我们知道libDexHelper.so是整个壳的核心，修改libDexHelper.so？万一有自校验咋办，这里就有了两种替换方案，第一种查看依赖较少的so，将该依赖的so换成我们的，比如liblog.so，但是这要求我们实现和liblog.so相应的接口，否则dlopen会失败，第二种，也是本文采用的方案，我们直接把它替换了不就好了嘛？
首先，把原来的libDexHelper.so改成libDexHelper2.so, 然后我们需要写一个libDexHelper.so，只需实现JNI_OnLoad即可, 在里面加载libDexHelper2.so并显式调用JNI_OnLoad即可(这里竟然没有检测文件名，呵呵，不过检测也没多大意义，容易bypass。另外由于我用的x86机，梆梆在.cache目录下生成对应的x86 so才是目标):
这篇关于dalvik下替换so简单dump出梆梆加固保护的odex的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
