梆梆加固专项方案分析和破解论梆梆安全加固的不可靠.doc

梆梆加固方案分析和破解
--论梆梆安全加固不可靠

一、梆梆安全加固方案技术分析 2
（1）APK包文献特性 2
（2）dex文献分析 3
（3）SO文献分析 3
二、梆梆安全加固破解 9

一、梆梆安全加固方案技术分析
样例分析环境：
APK包： 齐鲁银行
运营环境：安卓模仿器4.4.2
CPU平台：ARM平台，（X86暂不分析）
分析工具：JEB，APKIDE，IDA 6.6及HEX编辑工具等
（1）APK包文献特性

图1 齐鲁银行apk文献构造
图1可见classes.dex文献极小。非应用真正dex文献。

图2 assets/文献目录
梆梆把SO文献都放在assets中。图2中比较重要文献有：，，，，4个so文献以及一种jar文献。
（2）dex文献分析

图3 dex构造
代码中能看到so调用有2处：ACall中libsecexe.so，以及ApplicationWrapper中libDexHelper.so。
初步总结：依照apk包文献构造以及dex逆向中可见调用关系，大概可推断出梆梆整体保护方略：多层次，明暗集合。
（3）SO文献分析
开始详细分析梆梆SO文献。
依照上面几种方面观测，梆梆具备4个so文献。2个为显式调用，2个为隐式调用（调用代码隐藏在so中）。
1）四个so互相调用关系：
本人初步研究：一方面，Dex中ACall调用libsecexe.so ，另一方面，调用libsecmain.so，再次，Dex中ApplicationWrapper调用libDexHelper.so，最后， libsecperload.so这个so文献很奇怪，好像并没有被调用过。
2）四个so各自特性详细分析：
* libsecexe.so
文献大小81KB，破坏参数ELF中section节表信息，采用加壳保护----变种UPX壳（无法使用工具直接脱壳），函数和变量名都加入混淆解决。

图4 仅存在段表，upx加壳(elf文献)特有段表构造

图6 功能性函数和变量名混淆

图7 so入口函数变形，ida无法辨认

图8 JNI_OnLoad函数加密字节特殊解决
综上所见：该SO文献反映了梆梆加固机制大量技术信息。但其核心技术只是国外开源UPX壳。在本文最后会针对UPX壳逆向分析状况进行某些细节阐明。
通过技术手段进行手工脱壳，并dump出so 在内存中map并转存二进制文献。
因Dump出二进制文献，自身无法修复elf段表和节表（手工修复工作量大），因此在分析过程中，结合了runtime动态调试内存技术。

图9-1 脱壳前so在内存中段布局

图9-2 脱壳后so在内存中段布局
由于UPX为压缩壳，因此原加载入内存elf各分段被动态解压到内存中，如LOAD段下方debug002实为LOAD段解压还原后裔码及数据信息。其她各段类似。此处也可看出无法dump出完整elf因素了。Upx解压时，并没有还原section和segment，实际也没这个必要。

图10 相对图7这才是真正so入口点.init_proc源码，即upx脱壳代码

图11 相对图8这是解压还原后JNI_OnLoad函数（深蓝色函数名都是本人分析标注）

图12 JNI_OnLoad一种sub函数
至此libsecexe.so启动代码某些大概流程解析出来。其中功能性函数与dex关于诸多。本人搜索了某些核心词。发现前面提到一种bangcleclasses.jar这个jar包也在该so中解决。
总结：该so特点，加壳，名称混淆，但未混淆函数实现。获得dex修复功能，与classes.dex和bangcleclasses.jar通讯交互调用了某些功能函数。

*libsecmain.so
第二个核心so文献。
依照对libsecexe.so研究。Libsecmain属于隐式被调用者，调用者很也许就是classess.jar这个jar文献（本人猜测）。

文献大小157KB，破坏ELF中section节表信息，采用加壳保护----变种UPX壳（无法使用工具直接脱壳），函数和变量名都加入混淆解决。
虽然本so与libsecexe.so保护方式几乎同样（采用同样技术重复图就不截了）。初步分析后，发现它依然有某些自己独特之处。
（1） 无JNI_load函数，阐明该so 为纯被调用者。被java或其她so调用。自身不会去积极调用java有关代码，如：jar包，dex文献等。
（2） 新增混淆IDA解析能力，伪造了一批函数。例如：把入口函数.init_proc代码放在另一种函数内部（对于elf文献来说关怀定位并不受影响，程序仍可以对的执行）。且此类保护技术在该so中诸多。本人尚未进行更进一步研究。

图13
可见B6EAA000是真正入口点，由于隐藏在另一种函数内，IDA无法按照单一独立函数进行解析（且母函数自身也不一定合法），导致解析能力明显偏弱，诸多东西无法对的解析，静态环境就需要手动修复（核心是要重置函数上下界）。只要能动态调试起来影响到是不太大。
（3） 观测该so中未混淆函数
so_main(dlopen打开libdvm.so和libc.so ,通过dlsym获取各种进程操作函数fork，ptrace，wait，kill，mprotect，waitpid，双进程反调试功能就在该so中，getpid)，该函数执行结束后，进程列表中将会有2个.rytong.bankql.ql。
mykill,init,libc_pread64 等。解决过程中多次申请动态堆内存，其目还需进一步研究。
（4） 观测了某些混淆函数
发现该so中有不少open 和fopen操作，可见有进行读写文献。
综上所述：该so功能大概有2方面：1. 启动多进程反调试保护，2.文献恢复（极也许是生成classes.dex文献，固然生成一种半成品dex文献），由于时间问题暂时动态调试只进行到多进程保护某些就被卡住，后续准备细致研究后后把多进程防护功能关闭后，再继续往下调试，以便获得更多信息。

*libDexHelper.so
文献大小458KB，很明显该so核心功能就是修复dex文献。
libDexHelper.so启动前内存系统和文献系统实时状况：

图14 内存中进程状况，可见，1197为核心进程，1199为反调试子进程

图15 执行文献夹内多了一种720KBclasses.dex
显而易见，通过classes.dex(24kb)， classes.des， libsecexe.so， bangcle_classes.jar， classes.jar，以及libsecmain.so等几种模块前期解决，生成了一种待修复模版型classes.dex（720kb）。通过测试，该classes.dex为非法不完整dex文献。
到此classes.dex(24kb)中ApplicationWrapper去加载libDexHelper.so进行运营时修复classes.dex（720kb）。
该so特点：
1> 未加壳
2> 未破坏elf文献segment和section表
3> 入口点为start函数（未加密，存储在自定义代码段seg011中，大量code也在该段中）

*libsecpreload.so
文献大小14KB，极小型。
该so特点：
1> 内部仅1个函数：strlen，感觉函数名与函数功能无关
2> 无JNI_onLoad函数
3> 未加壳
4> 未混淆

图17 strlen函数代码
Strlen函数一共就这几行代码。函数功能也极其简朴，从系统环境变量LD_PRELOAD_SECSO中获取某个so库名并dlopen打开，在用dlsym获取so库中函数名为”p88c9ad42163050e20f808e0fdeb7988"函数指针，再从系统环境变量LD_PRELOAD_ARGS中获取函数有关参数信息，最后调用"p88c9ad42163050e20f808e0fdeb7988"函数。
至此上面就是，梆梆加固保护机制分析成果。
二、梆梆安全加固破解
使用自主开发脱壳工具对梆梆加固某银行级别应用进行脱壳。一方面在手机上安装该银行apk，然后运营apk。使用动态脱壳工具指令进行脱壳。
会在/data/下面生成脱壳之后smali文献，截取某些内容如下：

通过咱们解密解决之后，就会生成完整smali代码；在通过一定解决之后，咱们可以直接看到java代码，证明经该厂商加固后应用被完全破解。

总来说，梆梆安全加固安全加固方案还是基于国外某些开源项目，保护效果有限且所有被保护应用均能通过同样方式容易破解，相应用兼容性性能也有明显不良影响。