• 梆梆加固分析
–加密原始classes.dex并放置于 assets/bangcle_classes.jar内
–修改AndroidManifest.xml，替换Application对象
–对AndroidManifest.xml中声明的所有Receiver, Service和ContentProvider构造对应的Stub implementation
–运行时首先在内存中解密bangcle_classes.jar，然后 使用custom classloader将其加载至内存并跳转至其 中代码运行
–未保护资源文件和so文件
–运行时会启动2个辅助进程实现anti-ptrace
• 梆梆加固脱壳思路
–Classes.dex并未在加固时执行预处理，运行时 memory dump即可获得完整原始文件
–zjDroid或dextractor可直接脱壳
–也可直接分析/proc/[pid]/maps并dd /proc/[pid]/mem 导出odex文件
爱加密加固分析
–加密原始classes.dex并放置于assets/ijiami.dat内
–修改AndroidManifest.xml，替换Application对象
–在SuperApplication.attachBaseContext处开始解密 （因此无需对Service, Receiver等对象生成Stub)
–运行时首先在内存中解密bangcle_classes.jar，然后 使用custom classloader将其加载至内存并跳转至其 中代码运行
–未保护资源文件和so文件
–运行时会使用3个进程相互保护ptrace
• 爱加密加固脱壳思路
–Classes.dex并未在加固时执行预处理，运行时 memory dump即可获得完整原始文件
–zjDroid或dextractor可直接脱壳
–也可直接分析/proc/[pid]/maps并dd /proc/[pid]/mem 导出odex文件
• 百度加固分析
–加密原始classes.dex并放置于 assets/baiduprotect.jar内
–修改AndroidManifest.xml，替换Application对象 –对ContentProvider生成Stub
–脱壳流程同梆梆和爱加密几乎相同
–未保护资源文件和so文件
–运行时会使用3个进程相互保护ptrace
• 百度加固脱壳思路
–Classes.dex并未在加固时执行预处理，运行时 memory dump即可获得完整原始文件
–zjDroid或dextractor可直接脱壳
–也可直接分析/proc/[pid]/maps并dd /proc/[pid]/mem 导出odex文件
• 腾讯云加固分析
–不替换原始classes.dex，也没有做任何加密处理
–修改Dex的ClassData, 将指定方法标记为native, 从 而绕过静态分析工具，原始字节码仍然未加密的保 存在dex文件中
–应用启动时，在Application的入口点处加载libtup.so, libtup.so会在内存中修改DexFile结构体，重建 Method同CodeItem的映射关系
–此方法和xposed的思路有异曲同工之妙
–原理决定了不支持ART
• 腾讯云加固脱壳思路
–虽然Classes.dex做了较多的预处理操作，但原始字 节码明文保存在classes.dex中显得非常不安全。
–应用运行后，libtup.so会修改Method对象的 accessFlags, registersSize, outsSize, insSize, insns 等属性，将函数复原
–使用xposed或者注入进程后，找到目标Dex文件的 DvmDex结构体，遍历pResMethods，记录每个函 数的insns偏移量。利用这个偏移量，修复加固后的 classes.dex文件即可脱壳
总结：
• classes.dex加密技术可以通过memory dump或 zjDroid破解
• ptrace保护可以轻松绕过 –现有单一应用加固不足以提供足够安全性保障
• 腾讯和360使用的字节码变形能够提高破解门槛
• 类VMProtect虚拟机技术可能是未来发展方向