梆梆加固方案分析和破解论梆梆安全加固的不可靠.docx
《梆梆加固方案分析和破解论梆梆安全加固的不可靠.docx》由会员分享,可在线阅读,更多相关《梆梆加固方案分析和破解论梆梆安全加固的不可靠.docx(13页珍藏版)》请在冰豆网上搜索。
![梆梆加固方案分析和破解论梆梆安全加固的不可靠.docx](https://file1.bdocx.com/fileroot1/2023-5/16/350ef1aa-fd89-44c4-8686-92c9b74e3448/350ef1aa-fd89-44c4-8686-92c9b74e34481.gif)
梆梆加固方案分析和破解论梆梆安全加固的不可靠
梆梆加固案分析和破解
--论梆梆安全加固的不可靠
一、梆梆安全加固案技术分析
样例分析环境:
APK包:
齐银行
运行环境:
安卓模拟器4.4.2
CPU平台:
ARM平台,(X86暂不分析)
分析工具:
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个com..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,极小型。
该so的特点:
1>部仅1个函数:
strlen,感觉函数名与函数功能无关
2>无JNI_onLoad函数
3>未加壳
4>未混淆
图17strlen函数代码
Strlen函数一共就这几行代码。
函数功能也极其简单,从系统环境变量LD_PRELOAD_SECSO中获取某个so库名并dlopen打开,在用dlsym获取so库中函数名为”p88c9ad42163050e20f808e0fdeb7988"的函数指针,再从系统环境变量LD_PRELOAD_ARGS中获取函数相关参数信息,最终调用"p88c9ad42163050e20f808e0fdeb7988"函数。
至此上面就是,梆梆加固保护机制分析结果。
二、梆梆安全加固破解
使用自主开发的脱壳工具对梆梆加固的某银行级别的应用进行脱壳。
首先在手机上安装该银行apk,然后运行apk。
使用动态脱壳工具指令进行脱壳。
会在/data/下面生成脱壳之后的smali文件,截取部分容如下:
经过我们解密处理之后,就会生成完整的smali代码;在经过一定的处理之后,我们可以直接看到java代码,证明经该厂商加固后的应用被完全破解。
总的来说,梆梆安全加固的安全加固案还是基于国外的一些开源项目,保护效果有限且所有被保护的应用均能通过同样的式轻易破解,对应用的兼容性性能也有明显的不良影响。