梆梆加固脱壳实战：从内存Dump到DEX修复全流程

搞安全的兄弟对“梆梆加固”这四个字应该都不陌生。这几年做Android样本分析、App隐私合规检测、漏洞挖掘碰到梆梆加固的频率极高。这玩意儿在移动应用加固市场里占了不少份额很多银行类、政企类、头部互联网App都在用。它的保护能力也确实在线DEX整体加密、so库加固、反调试反注入一应俱全想直接静态分析拿原始代码基本是门儿都没有。所以就有了“脱壳圣战”这个说法——攻防双方围绕“加密”和“还原”来回拉扯跟打仗一模一样。这篇文章就记录一次针对梆梆加固的完整脱壳实操。从加固原理、环境准备、内存Dump到DEX修复验证全部走一遍。不管你是刚入行的安全测试新人还是在恶意样本分析里被梆梆拦住的老手这篇都可以直接拿来当参考。当然所有操作都限定在授权测试、样本研究和安全评估的范围内拿着技术去做不该做的事那就没意思了。1. 脱壳之前先搞清楚梆梆加固到底在保护什么老话讲“知己知彼百战不殆”。脱壳不是上来就上Frida一通乱扫先弄明白加固做了什么事情才知道该在哪里下手。1.1 加固后的APK静态看和动态看是两回事梆梆加固的核心思路跟我当年做Web开发时上混淆加密一样让代码在静态状态下不可读。具体到Android平台上它做了这么几件事真正的业务代码classes.dex用密钥加密密钥分散藏在native层也就是so文件里。APK根目录的classes.dex只是一个极小的壳入口只负责加载Application然后触发so里的解密逻辑。lib目录下有若干so文件比如libDexHelper.so、libSecShell.so这类特征库负责在运行时解密DEX、修复环境、检测调试器。运行时会校验包签名、检测Frida/Xposed/root一旦发现有异常就直接退出或崩溃。也就是说你用jadx直接打开加固后的APK看到的只有壳公司的加载逻辑真正的业务方法全在加密的数据块里躺着。想靠静态分析拿到关键代码不行。这就是为什么必须走动态脱壳路线——壳再牛它也得在内存里还原出真正的DEX给系统类加载器用只要它还原了内存里就有了原始DEX的完整形态我们需要做的就是把这个瞬间的完整数据抓下来。1.2 为什么选择“内存Dump”这条路线脱壳的主流方案其实不止一种常见的还有定制ROM脱壳、主动调用脱壳、以及直接在内存里搜DEX。各有优劣势我直接用一个表格对比下方案原理优点缺点定制ROM脱壳修改系统源码在Dalvik/ART加载DEX的必经路径上直接转储自动化程度高、全版本通杀需要刷机、适配机型有门槛主动调用脱壳找到so里的解密函数直接调用让它吐出明文精度高能拿完整原始数据逆向so工作量大耗时较长内存搜索Dump扫描进程内存搜索DEX文件头魔数按地址拷贝操作简单、不依赖特定版本、通用性好内存碎片多时需要拼接稳定性要调我这里选择的是内存搜索Dump。理由很简单足够通用且不依赖梆梆加固的具体版本。不管是低版本的简单的DEX整体加密还是高版本的多DEX处理只要壳把原始DEX还原到内存里了理论上都能搜到。这算是最粗暴也最实用的土办法但好用。1.3 脱壳的黄金时机什么时候下手最合适先说一个核心概念——脱壳必须抓住壳完成解密和加载之间的小窗口。Android的ART虚拟机在执行App代码前会通过ClassLoader加载DEX文件。对于加固应用这个加载过程是壳入口Application启动 - 壳代码解密真正的DEX - 把解密后的DEX交给PathClassLoader/DexClassLoader - 虚拟机构建DexFile对象 - App真正的Application开始执行。如果注入太早壳还没解密完内存里搜不到任何有效DEX。如果注入太晚虽然大概率还在但某些高版本的加固会主动在代码跑完后释放解密缓冲区或者对内存里的DEX做二次篡改导致Dump出来的文件损坏。所以一个稳妥的做法是先用spawn方式启动App让Frida在进程刚起来时就注入再延时几秒等待壳把DEX解密完毕最后才开始扫描。2. 环境准备与加固识别这步做不对后面全白搭脱壳这件事环境搭得好不好直接决定了成功率和效率。很多新手一上来就卡在进程附加不上或者Frida被检测导致应用秒退都是环境问题。2.1 推荐实验环境搭建我这边常用的组合是一台Pixel或支持解锁BL的Android手机 Magisk Root Frida 对应版本的frida-server。用模拟器也行但梆梆加固的某些高版本对模拟器的检测很严格还是真机稳一点。具体版本方面Android 8.0到11.0都是比较舒服的区间。太低的话ART的DEX加载机制跟现在主流加固方案有差异太高的话系统对DEX的处理方式可能引入额外复杂度。我个人目前主力机用的是Android 9跑Frida 15.x配合Python 3.8版本的frida-tools。安装步骤很简单手机Root后从Frida官方Release页面下载对应架构的frida-server注意架构要匹配一般就是arm64。把frida-server推到手机adb push frida-server /data/local/tmp/给执行权限adb shell chmod 755 /data/local/tmp/frida-server启动adb shell /data/local/tmp/frida-server 启动后用frida-ps -U验证如果有进程列表输出说明Frida已经正常工作了。这里要特意提一句frida-server的版本必须和电脑端frida版本一致否则会有协议不兼容的问题报错内容也很误导人动不动就提示unable to communicate with frida-server实际就是版本对不上。2.2 快速识别目标APK是否使用了梆梆加固动手脱壳前先确认目标是不是梆梆加固别一股脑把其他加固也当成梆梆来脱。识别方法不复杂解压APK看几个关键位置就能判断。第一种方法看lib目录下的so文件名。梆梆加固的典型so特征包括libDexHelper.so、libSecShell.so、libSecMain.so、libjiagu.so等不同版本名字略有差别但只要见到这类带“Sec”“DexHelper”“jiagu”字符的so基本可以往梆梆的方向去查。第二种方法直接看classes.dex。用jadx或dex2jar打开加固APK的classes.dex如果发现里面类数量极少总共就那么几个类而且入口Application类名里有“com.secshell.app.SecShellApplication”这种或者一堆类名跟com.secshell、com.secplugin相关的那基本就是梆梆加固没跑了。第三种方法看assets目录。很多加固方案会在assets下放加密数据块梆梆的特征文件包括secData0.jar、secData1.jar这类看到这些文件也可以直接确认。2.3 本次实验目标信息本次演示用的样本包名是com.example.targetapp版本号2.8.1测试设备是Pixel 4同款架构的arm64手机系统为Android 9Frida版本15.1.28。这里说明一下我自己测试的样本是从企业安全评估项目中拿到的授权样本各位在实际操作中请务必保证对目标App有合法测试权限。3. 实战脱壳Frida内存Dump的全过程核心环节来了。整个脱壳过程可以拆成三步启动注入、等待解密、内存扫描。每一步的细节我都会展开讲。3.1 用Spawn方式启动目标App并注入脱壳启动方式上我推荐用frida -U -f com.example.targetapp启动新进程。跟attach方式不同-f参数会冷启动App在App最先执行代码之前就完成注入能保证后续的延时扫描不遗漏解密时机。命令如下frida -U -f com.example.targetapp -l dump_dex.js --no-pause--no-pause的意思是不让进程暂停在启动点直接放行让壳正常走完解密流程。Frida脚本里需要做的第一件事是设置一个延时我一般设置5到8秒。延时太短壳还没解密完延时太长虽然不影响Dump但会浪费分析时间。3.2 编写内存扫描脚本搜索DEX魔数内存Dump的底层逻辑其实很简单ART虚拟机在运行期间进程内存里总会存在一类以dex\n035\0或dex\n036\0、dex\n037\0开头的数据块这些就是DEX文件在内存中的形态。只要扫描进程所有可读内存区域找到特征魔数再解析DEX文件头里的file_size字段就能直接按大小把整段数据抠出来。日志我先把整个Frida脚本贴出来然后逐段解释关键点。// dump_dex.js function dumpDex() { // DEX魔数 var magic 64 65 78 0a 30 33 35 00; var ranges Process.enumerateRanges(r--); var fileCount 0; ranges.forEach(function (range) { Memory.scan(range.base, range.size, magic, { onMatch: function (address, size) { // 解析DEX的file_size字段 var dexSize address.add(0x20).readU32(); // 过滤掉明显不合法的数据 if (dexSize 0x1000 dexSize 0x4000000) { var dexPath /data/local/tmp/dex_ address .dex; console.log([] Found DEX at address , size: dexSize); var file new File(dexPath, wb); file.write(address.readByteArray(dexSize)); file.close(); fileCount; console.log([] Saved to dexPath); } }, onComplete: function () {} }); }); console.log([] Total DEX files: fileCount); } setTimeout(function () { dumpDex(); }, 6000);这个脚本的核心点有三处。第一Process.enumerateRanges(r--)枚举进程所有可读内存区域。这里我用了r--而不是rw-原因是有部分加固会把DEX放在只读页里而且r--能覆盖到映射进内存的APK、ELF、DEX等所有文件区域匹配范围更广。第二DEX文件头的偏移0x20处存放的是整个DEX文件的大小。DEX格式是这样的文件头32字节第0x20到0x24四个字节是file_size。所以我在找到魔数后直接读取这个字段再判断大小是否合理。合理范围我设置的是4KB到64MB之间这基本覆盖了正常App的DEX体积区间也能过滤掉大量内存里的随机噪音。第三保存文件名里带了内存地址这是为了区分多个DEX文件。高版本的梆梆加固会把原始App拆成多个DEX加载一个App dump出来好几个DEX是很正常的事不带地址命名的话容易覆盖掉前面的成果。3.3 执行脱壳并检查Dump结果脚本写好后运行frida -U -f com.example.targetapp -l dump_dex.js --no-pause终端里会先刷出一堆ART运行时的日志然后等到6秒左右脚本开始扫描内存输出类似这样的结果[] Found DEX at 0x75a0f10000, size: 4829612 [] Saved to /data/local/tmp/dex_0x75a0f10000.dex [] Found DEX at 0x75b3be8000, size: 104472 [] Saved to /data/local/tmp/dex_0x75b3be8000.dex [] Total DEX files: 2第一个大文件4.8MB基本就是原始App的主DEX。第二个100KB左右的很可能是加固壳自己的辅助DEX或者是App的第二个dex。当然也有可能会dump出来好几个几十KB的小文件那些大概率是各种类库的碎片或者系统预加载的框架DEX需要进一步甄别。Dump完以后把文件拉出来adb pull /data/local/tmp/dex_0x75a0f10000.dex .拉出来之后先用010 Editor或者HxD打开看看文件头。如果魔数正确内容不是全0下一步就可以直接反编译验证了。另外再补充一个方案。如果你觉得写Frida脚本太麻烦也有一些现成的脱壳工具可以帮你自动完成这件事比如BlackDex这类开源的脱壳工具操作起来更傻瓜化。它同样是基于内存Dump原理只是把扫描逻辑封装成了AppRoot之后一键脱壳。但这类工具对某些深度定制过的加固版本效果相对有限。自己动手写脚本的好处是出了问题你能知道问题出在哪还可以针对性地去改完全黑盒的方式不利于学习原理。4. 脱壳后的修复与验证代码能不能用就看这步Dump出来只是第一步DEX是否能被jadx正常解析代码是否完整还原又是一个需要处理的问题。4.1 检查DEX文件完整性内存Dump出来的DEX有时候会存在两个问题。第一个问题是文件不完整。DEX在内存里并不一定是连续的一段数据如果一个DEX跨越了两个不同的内存映射区域而我的脚本只从一个区域里扫描截出来的文件就会缺失后半截。碰到这种情况按file_size读取时会读到边界之外的数据或者在反编译时报错“DEX file is truncated”。这时候不能干瞪眼需要手动拼接。先定位DEX的起始地址确认DEX头里记录的file_size然后看这个起始地址加上file_size是否超出了当前内存区域范围如果超了再在下一个相邻内存区域里按剩余偏移读取对应长度的数据拼在一起。具体用Frida脚本也能做就是麻烦点。判断方法很简单用jadx直接打开如果能够正常解析出类结构说明文件完整性没问题。第二个问题是文件头损坏。某些加固版本会在释放完DEX后将内存区域释放或者清空一部分关键字段。如果打开Dump出来的DEX发现magic正常但是header里的checksum、signature这些字段被填成0这时候需要手动修复。最简单的修复方式就是用dex2jar这类工具尝试转换它会忽略一部分非关键错误实在不行就用010 Editor的DEX模板手工修改。一般情况下只要main dex能够被jadx解析大部分业务代码就都能看到了。4.2 用jadx反编译并定位核心代码校验通过后直接打开jadx把DEX文件拖进去。这里建议用jadx-gui版本交互界面更直观。加载完成后搜索目标App的包名你会发现之前加固后明明空空如也的代码现在全都回来了Activity、Fragment、网络接口、业务逻辑、加密算法应有尽有。举个例子之前分析一个金融类App样本加固后只能看到一个壳入口什么都没有。脱壳拉出来的DEX里很快就定位到了它的网络协议封装类里面有完整的AES密钥、加密IV、请求签名算法。这就是脱壳实打实的价值。有一种情况要注意dump出来的DEX可能和原始的包结构存在差异尤其是一些使用multidex的项目。原始的多个DEX是分开加载的内存里会存在多个DEX对象脚本一般都能扫到。比如梆梆加固企业版可能会把DEX拆成几十个块来分发这种就特别考验Dump脚本的完整性。碰到多DEX的情况把dump出来的所有文件都拖进jadx里统一分析即可。4.3 反编译结果的动态验证静态反编译能看到代码不代表代码逻辑完全正确。特别是遇到一些加固方案会对DEX做指令抽取——方法体被抽空运行时再动态回填。这种情况你dump到的DEX里代码逻辑是不完整的方法体是空的或者只是抛出异常。怎么判断是否遇到指令抽取很简单反编译后如果一个类的方法大量出现“throw new RuntimeException(...)”或者方法体为空那基本就是被抽取了。如果确认被抽取就得上更高级的手段用Frida Hook MethodEnter/Leave在运行期抓取方法指令。配合脱壳机例如Youpk这类支持指令粒度的脱壳方案。从低版本Android系统上Dump有些指令抽取在高版本、低版本上的实现方式不一样换个环境可能就绕过去了。大多数情况下梆梆加固的免费版和基础企业版不会采用指令抽取这种极端的保护方式Dump出来基本可以正常用。5. 常见问题与排查技巧实录脱壳这活儿不怕技术难就怕问题多。把我在实战中经常遇到的几个坑和排查思路整理一下每条都是真金白银踩出来的经验。5.1 Frida被检测导致秒退怎么办最常见的问题就是Frida注入之后App刚启动就闪退。这说明加固的so里有反Frida检测逻辑会扫描默认的Frida端口、检查maps文件里有没有frida相关映射、排查线程名是否包含gum-js-loop这类特征。解决方案有好几层。最基础的把frida-server改个名字不要用默认的frida-server文件名。再进一步修改frida-server默认端口启动时用监听自定义端口/data/local/tmp/fs -l 127.0.0.1:8888 客户端指定端口连接frida -U -H 127.0.0.1:8888 -f com.example.targetapp -l dump.js如果还是被检测就需要用frida-gadget的方式或者用LSPosed Frida到更底层的绕过。这里不多展开因为加固方也在不断升级检测方式绕过检测本身就是一场持续的猫鼠游戏。我的建议是优先换一个低版本Android系统如Android 7或8很多加固的检测代码在新系统上是基于老的API写的低版本下反而容易蒙混过关。5.2 Dump出来的DEX反编译报错这是几乎每个人都会碰到的问题。症状是jadx打开DEX时报错“File format not recognized”或者“Unable to parse dex file”。我当时遇到这个问题的排查步骤是这样的第一步用十六进制工具看前8个字节。如果前8个字节是64 65 78 0a 30 33 35 00说明魔数正常。看到魔数不是这个说明dump的数据不是标准DEX可能是压缩过、加密过或者文件头被改写了。第二步检查file_size字段。DEX头里偏移0x20处的4字节是文件大小拿这个值跟文件实际大小对比。如果不一致说明文件被截断了需要回炉重dump或者手动拼接。第三步校准checksum。某些加固shell会修改checksum触发反调试导致解析器报错。这时可以用dexfixer这类小工具修复DEX文件头或者用010 Editor的DEX模板自动计算并填充。5.3 内存里搜不到DEX魔数延时等待时间足够长脚本也执行了但扫描结果却是一个DEX都没找到。这种情况我碰到过几次原因基本出在Android新版本和加固新版本的“联手改造”上。Android 8.0之后系统引入了compact dex也就是CDex魔数变成了dex\n039\0而且这个0x39版本的DEX在内存中并不以标准形式呈现而是经过压缩和去重处理的搜索标准魔数就搜不到。解决办法是把脚本里的魔数列表扩展同时搜索几个版本的DEX魔数var magicList [64 65 78 0a 30 33 35 00, 64 65 78 0a 30 33 37 00, 64 65 78 0a 30 33 39 00];另外还有一种情况加固so使用的是自定义DexFile加载逻辑不是走系统标准的DexFile::Open流程而是自己解析、自己初始化整个DEX可能不以明文整体出现在进程内存中。遇到这种情况只能换思路从so层逆向入手找到解密函数主动调用或者主动Hook来拿数据。5.4 脱壳后的代码中看不到关键加密算法有时候代码是出来了但分析半天找不到加密算法这类问题也很典型。原因很可能是关键逻辑不在Java层而被放到了native层。梆梆加固本身就大力推广so加固和VMP虚拟化保护核心代码可能用C/C 写成so甚至so内部还有VMP把指令翻译成了自定义字节码这已经不是脱DEX就能搞定的范畴了。对于这类场景常规DEX脱壳不管用了。要做的后续操作是逆向so的JNI导出函数锁定加密入口。用IDA分析so逻辑重点看Cipher相关算法特征比如AES的S盒、T-Tables。如果so本身做VMP保护就得借用Unicorn、Qiling这类模拟执行框架动态提取算法逻辑。说句实在话到这一步脱壳已经只是热身了真正的攻防集中在native层。但这恰恰说明一个道理脱壳只是分析的起点不是终点。5.5 问题速查表现象可能原因解决方案App秒退Frida被反调试检测改frida-server名称、换端口、用低版本系统Frida连接失败版本不匹配统一电脑端frida与手机端frida-server版本扫不到DEX魔数版本不支持扩展搜索dex\n035/036/037/039魔数Dump文件打不开文件头缺失、尺寸错误用010 EditorDEX模板修复或重新Dump方法体为空指令抽取保护用主动调用脱壳或原生dump指令方式多个DEX混乱原始App用了multidex将全部Dump文件导入jadx统一分析6. 写在最后把脱壳比作圣战虽然有点中二但实际操作下来真是这么回事。每一次成功的脱壳背后都是对系统加载机制的理解、对内存布局的把握、对加固方思路的逆向推演。我个人的心得是别迷信某个万能工具也别指望一个脚本通吃所有版本真正值钱的是对DEX文件格式和ART加载流程的理解框架掉了可以换思路通了才能走远。这套流程里我觉得最有成就感的一刻不是Dump出DEX的那一刻而是jadx里刷出完整的类结构、代码逻辑清晰呈现的时候。就像拼了很久的拼图突然完整了之前很多推断一下子对上了。这种“终于拿到了”的感觉大概就是搞逆向的人乐此不疲的原因吧。最后再分享一个小建议脱壳这条路动手永远是第一位的。挑几个带加固的App自己搭环境、写脚本、处理异常踩过一轮坑以后你对Android应用加固和逆向的认知会上一个台阶。