梆梆加固方案分析和破解论梆梆安全加固的不可靠文档格式.docx

梆梆加固方案分析和破解论梆梆安全加固的不可靠文档格式.docx

《梆梆加固方案分析和破解论梆梆安全加固的不可靠文档格式.docx》由会员分享，可在线阅读，更多相关《梆梆加固方案分析和破解论梆梆安全加固的不可靠文档格式.docx（11页珍藏版）》请在冰豆网上搜索。

JEB，APKIDE，IDA6.6及HEX编辑工具等

（1）APK包文件特征

图1齐鲁银行apk文件结构

图1可见classes.dex文件极小。

非应用真正的dex文件。

图2assets/文件目录

梆梆把SO文件都放在assets中。

图2中比较重要文件有：

，

，4个so文件以及一个jar文件

。

（2）dex文件分析

图3dex结构

代码中能看到的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功能性函数和变量名混淆

图7so入口函数变形，ida无法识别

图8JNI_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函数（深蓝色的函数名都是本人的分析标注）

图12JNI_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执行文件夹内的多了一个720KB的classes.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，极小型。

内部仅1个函数：

strlen,感觉函数名与函数功能无关

无JNI_onLoad函数

4>

未混淆

图17strlen函数代码

Strlen函数一共就这几行代码。

函数功能也极其简单，从系统环境变量LD_PRELOAD_SECSO中获取某个so库名并dlopen打开，在用dlsym获取so库中函数名为”p88c9ad42163050e20f808e0fdeb7988"

的函数指针，再从系统环境变量LD_PRELOAD_ARGS中获取函数相关参数信息，最终调用"

p88c9ad42163050e20f808e0fdeb7988"

函数。

至此上面就是，梆梆加固保护机制分析结果。

二、梆梆安全加固破解

使用自主开发的脱壳工具对梆梆加固的某银行级别的应用进行脱壳。

首先在手机上安装该银行apk，然后运行apk。

使用动态脱壳工具指令进行脱壳。

会在/data/下面生成脱壳之后的smali文件，截取部分内容如下：

经过我们解密处理之后，就会生成完整的smali代码；

在经过一定的处理之后，我们可以直接看到java代码，证明经该厂商加固后的应用被完全破解。

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