2022年梆梆加固方案分析和破解--论梆梆安全加固的不可靠.pdf

梆梆加固方案分析和破解-论梆梆安全加固的不可靠一、梆梆安全加固方案技术分析. .错误 !未定义书签。（1）APK包文件特征.错误 !未定义书签。（2）dex 文件分析.错误 !未定义书签。（3）SO文件分析.错误 !未定义书签。二、梆梆安全加固破解. .错误 !未定义书签。精品资料 - - - 欢迎下载 - - - - - - - - - - - 欢迎下载 名师归纳 - - - - - - - - - -第 1 页，共 5 页 - - - - - - - - - - 一、梆梆安全加固方案技术分析样例分析环境：APK包： 齐鲁银行运行环境：安卓模拟器平台：ARM 平台， （ X86暂不分析）分析工具： JEB，APKIDE ，IDA 及 HEX编辑工具等（1）APK包文件特征图 1 齐鲁银行 apk 文件结构图 1 可见文件极小。非应用真正的dex 文件。图 2 assets/文件目录梆梆把 SO文件都放在assets中。图 2 中比较重要文件有： ， ， ， ，4 个 so 文件以及一个jar文件。（2）dex 文件分析图 3 dex 结构代码中能看到的so 调用有 2 处： ACall 中的，以及ApplicationWrapper中的。初步总结： 根据 apk 包文件结构以及dex 逆向中可见的调用关系，大约可推断出梆梆整体的保护策略：多层次，明暗集合。（3）SO文件分析开始详细分析梆梆的SO文件。根据上面几个方面的观察，梆梆具有4 个 so 文件。2 个为显式调用， 2 个为隐式调用 （调用代码隐藏在so 中） 。1）四个 so 相互调用关系：本人的初步研究：首先，Dex 中的ACall调用，其次，调用, 再次， Dex 中的ApplicationWrapper调用，最后，这个 so 文件很奇怪，好像并没有被调用过。2）四个 so 各自特征详细分析：* 文件大小81KB ，破坏参数ELF中的 section节表信息，采用加壳保护-变种 UPX壳（无法使用工具直接脱壳），函数和变量名都加入混淆处理。图 4 仅存在段表，upx 加壳 (elf文件 ) 特有段表结构精品资料 - - - 欢迎下载 - - - - - - - - - - - 欢迎下载 名师归纳 - - - - - - - - - -第 2 页，共 5 页 - - - - - - - - - - 图 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 函数至此的启动代码部分大概流程解析出来。其中功能性函数与dex 有关的很多。 本人搜索了一些关键词。发现前面提到的一个这个jar包也在该so 中处理。总结： 该 so 的特点，加壳，名称混淆，但未混淆函数实现。获得dex 修复功能，与和通讯交互调用了一些功能函数。*第二个核心so 文件。根据对的研究。Libsecmain属于隐式被调用者，调用者很可能就是这个jar文件（本人猜测） 。文件大小157KB ，破坏 ELF中的 section节表信息，采用加壳保护-变种 UPX壳（无法使用工具直接脱壳） ，函数和变量名都加入混淆处理。虽然本 so 与的保护方式几乎一样（采用同样技术的重复的图就不截了）。初步分析后， 发现它仍然有一些自己的独特之处。（1）无 JNI_load函数，说明该so 为纯被调用者。被java 或其他 so 调用。自身不会去主动调用java 相关代码，如：jar包， dex 文件等。（2）新增混淆IDA 解析能力，伪造了一批函数。比如：把入口函数.init_proc的代码放精品资料 - - - 欢迎下载 - - - - - - - - - - - 欢迎下载 名师归纳 - - - - - - - - - -第 3 页，共 5 页 - - - - - - - - - - 在另一个函数内部（对于elf文件来说关心的定位并不受影响，程序仍可以正确执行） 。且此类保护技术在该so 中很多。本人尚未进行更进一步的研究。图 13可见 B6EAA000是真正的入口点，因为隐藏在另一个函数内，IDA 无法按照单一独立函数进行解析（且母函数本身也不一定合法），导致解析能力明显偏弱, 很多东西无法正确解析，静态环境就需要手动修复（关键是要重置函数上下界）。只要能动态调试起来影响到是不太大。（3）观察该 so 中未混淆的函数so_main(dlopen打开和 , 通过 dlsym 获取多个进程操作函数fork, ptrace, wait, kill, mprotect, waitpid，双进程反调试功能就在该so 中， getpid)，该函数执行结束后，进程列表中将会有2 个。mykill,init,libc_pread64 等。处理过程中多次申请动态堆内存，其目的还需深入研究。（4）观察了一些混淆的函数发现该 so 中有不少open 和 fopen 操作，可见有进行读写文件。综上所述： 该 so 的功能大概有2 方面： 1. 开启多进程反调试保护，2. 文件恢复（极可能是生成文件，当然生成一个半成品的dex 文件） ，因为时间问题暂时动态调试只进行到多进程保护部分就被卡住，后续准备细致研究后后把多进程防护功能关闭后，再继续往下调试，以便获得更多的信息。*文件大小458KB ，很明显该so 的核心功能就是修复dex 文件。启动前的内存系统和文件系统实时情况：图 14 内存中进程情况，可见，1197 为核心进程， 1199 为反调试子进程图 15 执行文件夹内的多了一个720KB的显而易见， 经过 (24kb), , , , , 以及等几个模块的前期处理，生成了一个待修复模版型的（ 720kb） 。经过测试，该为非法不完整的dex 文件。到此 (24kb) 中的 ApplicationWrapper去加载进行运行时修复（720kb） 。该 so 的特点：1 未加壳2 未破坏 elf文件 segment 和 section表3 入口点为start函数（未加密， 存放在自定义代码段seg011 中，大量 code 也在该段中）*文件大小14KB ，极小型。该 so 的特点：1 内部仅 1 个函数： strlen, 感觉函数名与函数功能无关2 无 JNI_onLoad 函数3 未加壳4 未混淆精品资料 - - - 欢迎下载 - - - - - - - - - - - 欢迎下载 名师归纳 - - - - - - - - - -第 4 页，共 5 页 - - - - - - - - - - 图 17 strlen函数代码Strlen函 数 一 共 就 这 几 行 代 码 。 函 数 功 能 也 极 其 简 单 ， 从 系 统 环 境 变 量LD_PRELOAD_SECSO中获取某个so 库名并dlopen打开，在用dlsym 获取 so 库中函数名为” p88c9ade20f808e0fdeb7988的函数指针，再从系统环境变量LD_PRELOAD_ARGS中获取函数相关参数信息，最终调用p88c9ade20f808e0fdeb7988函数。至此上面就是，梆梆加固保护机制分析结果。二、梆梆安全加固破解使用自主开发的脱壳工具对梆梆加固的某银行级别的应用进行脱壳。首先在手机上安装该银行 apk，然后运行apk。使用动态脱壳工具指令进行脱壳。会在 /data/下面生成脱壳之后的smali文件，截取部分内容如下：经过我们解密处理之后，就会生成完整的smali 代码； 在经过一定的处理之后，我们可以直接看到 java 代码，证明经该厂商加固后的应用被完全破解。总的来说， 梆梆安全加固的安全加固方案还是基于国外的一些开源项目，保护效果有限且所有被保护的应用均能通过同样的方式轻易破解，对应用的兼容性性能也有明显的不良影响。精品资料 - - - 欢迎下载 - - - - - - - - - - - 欢迎下载 名师归纳 - - - - - - - - - -第 5 页，共 5 页 - - - - - - - - - -