1. 项目概述为什么我们需要内存DEX提取在移动安全逆向分析领域尤其是针对Android应用“脱壳”是一个绕不开的核心课题。简单来说脱壳就是从被保护加壳的应用中还原出其原始的、可被分析和理解的代码。而“内存DEX提取”则是当前最主流、最有效的动态脱壳手段之一。为什么这么说因为无论外壳的静态保护多么复杂应用最终都必须在内存中解密、加载原始的DEXDalvik Executable或OATART运行时格式文件才能运行。这就好比一个上了锁的保险箱静态分析是在研究锁的结构而内存提取则是等保险箱被打开、内容物一览无余时直接伸手进去拿。我接触过大量加固强度不一的应用从早期的梆梆、爱加密到现在的腾讯御安全、VMPVirtual Machine Protect等。实战中我发现静态脱壳工具往往追不上加固方案的快速迭代一个脚本可能只针对某个特定版本有效。而基于Frida的动态内存提取其原理是普适的它不关心外壳如何加密、混淆只关心最终在内存中呈现的原始代码镜像。因此掌握这套方法论就相当于拥有了一把“万能钥匙”能够应对绝大多数基于DEX加载的加固方案。本手册旨在将这套实战经验系统化从工具配置、原理剖析到实战对抗手把手带你掌握这门核心技术。2. 核心原理与Frida基础环境搭建2.1 DEX文件在内存中的生命周期要精准提取必须先理解目标在内存中的“存活”状态。一个DEX文件从被外壳保护到最终被ART/Dalvik虚拟机执行大致经历以下几个关键阶段文件加载与解密外壳程序Stub首先被执行。它负责从APK的特定位置如assets读取被加密或压缩的原始DEX数据在内存中进行解密或解压。此时解密后的纯字节流已经存在于进程的堆内存中但还未被系统识别为一个合法的DEX结构。内存镜像构建外壳调用系统底层API如dalvik.system.DexFile.loadDex或 ART下的DexFile相关方法将解密后的字节流构建成虚拟机可识别的内存镜像。这个镜像包含了完整的DEX文件头、字符串池、类定义、方法字节码等所有信息。这是我们提取的第一个黄金时机。类加载与初始化虚拟机根据内存DEX镜像加载其中的类并执行初始化方法如clinit。在这个过程中一些加固方案可能会进行更复杂的运行时混淆或代码变换。即时编译JIT/AOT在ART环境下字节码可能被编译成本地机器码Nexus。提取出的DEX是字节码层面的而机器码的提取如从JIT Code Cache中是另一个更深层次的话题。我们的核心目标就是捕获第2步中构建完成的内存DEX镜像。这个镜像在内存中通常是一块连续的、具有完整DEX文件结构的内存区域。2.2 Frida环境部署与核心工具链工欲善其事必先利其器。一个稳定、高效的Frida环境是成功的基础。服务端Target Device/Emulator:推荐设备首选Root后的真实Android手机如Google Pixel系列其次是指令集兼容性好的模拟器如Android Studio官方模拟器。雷电、夜神等第三方模拟器可能存在兼容性问题。Frida-server安装从Frida官方GitHub releases页面下载与设备架构通常是arm64匹配的frida-server。推送到设备并赋予执行权限adb push frida-server-16.1.4-android-arm64 /data/local/tmp/frida-server adb shell “chmod 755 /data/local/tmp/frida-server”运行服务端在adb shell中启动它建议后台运行adb shell “/data/local/tmp/frida-server ”客户端分析机:Python环境安装Frida的Python绑定pip install frida-tools验证连接确保设备IP可通并运行frida-ps -U列出设备进程确认连接成功。注意市面上存在一些应用会检测Frida的运行痕迹如检测frida-server文件名、端口或特征内存。在对抗高强度加固时可能需要对frida-server进行重命名、端口伪装或使用定制编译版本。这是实战中的第一道门槛。辅助脚本与工具objection一个基于Frida的运行时移动安全评估框架可以快速完成内存搜索、类枚举等操作强烈建议安装 (pip install objection)。编辑器/IDE用于编写Frida脚本推荐VS Code。010 Editor或WinHex用于分析和验证提取出的二进制DEX文件结构。3. 实战定位与提取内存中的DEX镜像理论准备就绪我们进入最关键的实战环节。我将以两种最经典、最有效的思路为例详细拆解每一步。3.1 方法一HookDexFile构造函数一网打尽这是最直接、最可靠的方法。在Android系统中无论是Dalvik还是ART最终承载DEX内存镜像的Java对象通常是dalvik.system.DexFile或ART中对应的内部类。当外壳解密并加载DEX时必然会实例化此类。步骤拆解编写Frida Hook脚本Java.perform(function () { // 定位DexFile类 var DexFile Java.use(“dalvik.system.DexFile”); // Hook其构造函数重点关注接收byte[]或int内存地址的构造方法 DexFile.$init.overload(‘[B’).implementation function (buffer) { console.log(“[] DexFile Constructor Hooked!”); console.log(“[*] Buffer length: “ buffer.length); // 计算可能的DEX文件大小DEX文件头magic为”dex\n035\0” if (buffer.length 0x70) { // 确保有足够长度读取magic var magic ”; for (var i 0; i 8; i) { magic String.fromCharCode(buffer[i]); } console.log(“[*] Magic in buffer: “ magic); if (magic.indexOf(‘dex’) 0) { console.log(“[!!!] Found DEX in buffer!”); // 将字节数组转换为Uint8Array以便保存 var uint8Array new Uint8Array(buffer); // 生成文件名 var timestamp new Date().getTime(); var filePath “/sdcard/Download/dex_” timestamp “.dex”; // 调用我们写的Native函数来写文件见下一步 saveBytesToFile(uint8Array, filePath); console.log(“[] DEX saved to: “ filePath); } } // 继续执行原方法 return this.$init(buffer); }; });这段脚本Hook了接收字节数组的DexFile构造函数。当外壳将解密后的DEX字节流传入时我们就能截获它。实现文件保存函数Frida的JavaScript环境不能直接进行文件I/O我们需要通过NativeFunction调用libc的fopen,fwrite等函数。function saveBytesToFile(bytes, filePath) { var fopen new NativeFunction(Module.findExportByName(null, ‘fopen’), ‘pointer’, [‘pointer’, ‘pointer’]); var fwrite new NativeFunction(Module.findExportByName(null, ‘fwrite’), ‘size_t’, [‘pointer’, ‘size_t’, ‘size_t’, ‘pointer’]); var fclose new NativeFunction(Module.findExportByName(null, ‘fclose’), ‘int’, [‘pointer’]); var path Memory.allocUtf8String(filePath); var mode Memory.allocUtf8String(“wb”); var file fopen(path, mode); if (file.isNull()) { console.log(“[-] Failed to open file for writing.”); return; } // 为字节数据分配内存并拷贝 var buffer Memory.alloc(bytes.length); for (var i 0; i bytes.length; i) { buffer.add(i).writeU8(bytes[i]); } var result fwrite(buffer, 1, bytes.length, file); console.log(“[*] Bytes written: “ result.toString()); fclose(file); }附加进程并执行启动目标应用然后使用Frida附加frida -U -f com.example.targetapp -l dex_hook.js --no-pause触发应用的启动或相关功能观察控制台输出。一旦捕获到DEX脚本会自动将其保存到设备的/sdcard/Download/目录下。实操心得并非所有加固都使用DexFile(byte[])。有些可能使用DexFile(int cookie)其中cookie是一个指向内存DEX镜像的Native指针。你需要同时Hook多个重载方法。在ART上关键的加载类可能是dalvik.system.DexPathList$Element或com.android.dex.Dex。使用objection的android hooking list classes命令搜索所有包含”Dex”的类名能帮你快速定位目标。时机至关重要Hook脚本必须在DEX被加载前注入。使用-f参数在应用启动时即附加能最大概率捕获到所有DEX。3.2 方法二内存扫描与特征匹配大海捞针当Hook点被加固方案隐藏或混淆时内存扫描是更通用的“笨办法”。其原理是一个完整的DEX文件在内存中具有鲜明的特征——文件头魔术字64 65 78 0a 30 33 35 00”dex\n035\0”。步骤拆解使用Frida进行内存范围枚举与搜索Java.perform(function () { // 获取目标进程的所有内存范围 Process.enumerateRanges(‘r--’).forEach(function (range) { // 只搜索可读且较大的内存块提高效率 if (range.size 1024 * 1024) { // 例如大于1MB console.log(‘[*] Scanning range: ‘ range.base.toString(16) ‘ – ‘ range.base.add(range.size).toString(16)); // 在该内存范围搜索DEX魔术字 var dexMagic “64 65 78 0a 30 33 35 00”; var results Memory.scan(range.base, range.size, dexMagic); results.on(‘match’, function (address, size) { console.log(‘[!!!] Potential DEX header found at: ‘ address.toString(16)); // 找到魔术字后需要验证并计算完整DEX大小 // DEX文件头第32-35字节是file_size字段小端序 var fileSizePtr address.add(0x20); var fileSize fileSizePtr.readU32(); // 读取32位无符号整数 console.log(‘[*] DEX file size from header: ‘ fileSize ‘ bytes’); // 从魔术字地址开始读取整个DEX大小的内存 var dexBuffer address.readByteArray(fileSize); if (dexBuffer ! null) { var timestamp new Date().getTime(); var filePath ‘/sdcard/Download/memory_dex_’ address.toString(16) ‘_’ timestamp ‘.dex’; saveBytesToFile(Array.from(dexBuffer), filePath); // 使用之前的保存函数 } }); } }); });优化与验证性能全内存扫描非常耗时且可能卡住应用。务必添加范围大小过滤并优先扫描/data/app/包名路径对应的lib*.so库附近的内存或[anon:libc_malloc]这类堆内存区域。去重同一个DEX可能在内存中有多份拷贝如被不同ClassLoader加载。可以通过计算DEX文件的SHA-1哈希值头部的signature字段来进行去重。验证用file命令或010 Editor打开提取的文件检查其是否为有效的DEX文件。无效的文件可能只是碰巧包含魔术字的随机数据。常见问题与排查扫描无结果DEX可能被分段存储或头魔术字被轻微修改。可以尝试搜索变种魔术字或搜索DEX文件中部的一些固定结构特征。提取的文件损坏file_size字段可能被外壳篡改。一个更稳健的方法是找到魔术字后向后解析DEX文件结构根据map_off和map_size来动态计算真实大小。应用崩溃内存扫描是侵入性操作。尽量在应用空闲时进行或使用Memory.scan的异步API。4. 对抗进阶加固与Frida检测高强度的商业加固方案不会坐以待毙。它们通常会采用多重防御。4.1 对抗反Frida检测加固方会检测Frida的存在常见手段包括端口检测检测默认的27042端口是否被监听。进程名检测遍历/proc/self/task/或/proc/net/tcp查找frida-server相关字符串。内存特征检测在内存中搜索Frida相关字符串如“gum-js-loop”或特定代码片段。线程名检测Frida注入的线程可能有特定名称。应对策略修改Frida-server重命名二进制文件修改默认端口通过frida-server -l 0.0.0.0:8080。使用定制编译的Frida从源码编译修改其中的特征字符串。主动屏蔽检测逻辑用Frida Hook常见的检测函数如fopen,readlink,readdir当它们尝试访问敏感路径如/proc/self/maps或读取特定内容时返回伪造的安全数据。// 示例Hook readdir 过滤掉包含”frida”的目录项 Interceptor.attach(Module.findExportByName(null, “readdir”), { onLeave: function (retval) { if (!retval.isNull()) { var dirEntry retval; // 读取d_name字段这是一个指针 var namePtr dirEntry.add(…); // 结构体偏移量需根据libc确定 var name namePtr.readCString(); if (name name.indexOf(‘frida’) ! -1) { // 如果目录名包含frida跳过此项模拟读到结束 retval.writePointer(NULL); } } } });4.2 对抗VMP等高级保护VMP虚拟机保护会将原始的DEX字节码转换为自定义的指令集在私有虚拟机中执行。这给内存提取带来了巨大挑战挑战1内存中可能不存在完整的、标准的DEX镜像只有被解释执行的“碎片化”代码段。挑战2即使存在DEX的关键数据结构如字符串池、方法字节码可能被加密或混淆。应对思路寻找时机VMP为了兼容性可能在初始化、或某些非关键路径上仍然会解密一部分原始DEX到内存中。通过Hook系统JNI函数如FindClass,GetMethodID并回溯调用栈寻找解密函数。内存快照对比在应用启动初期解密前和功能完全加载后解密后分别对进程内存进行整体dump。使用二进制对比工具如BinDiff找出新增的、具有一定大小的内存块这些块中可能包含解密后的代码。Hook自定义解释器如果能够定位到VMP的解释器核心函数通常是一个大的switch或jit编译块可以尝试Hook它在它执行每一条自定义指令前记录下对应的原始字节码语义从而“重建”出方法逻辑。这是一项极其耗时且需要深厚逆向功底的工作。关注ART层面对于Android 5.0以上的ART虚拟机最终所有代码包括VMP解释的都需要被ART的JIT或AOT编译器处理以转换成ARM/ARM64指令。可以尝试从ART的JIT代码缓存jit_code_cache_中提取已编译的本地代码再反编译分析。这需要深入理解ART内部结构。重要提示对抗VMP是一个高强度的攻防过程没有通用的一键脚本。它考验的是分析者的耐心、底层知识ARM汇编、ART运行时和逆向工程能力。通常需要结合静态分析IDA Pro分析so库和动态分析Frida, GDB进行。5. 提取后的处理与修复成功提取出DEX文件并不意味着结束它可能还存在问题。5.1 DEX文件修复从内存中dump出的DEX其data_off和data_size等字段可能因为内存对齐或外壳修改而不准确导致反编译工具如JADX、GDA无法正确解析。修复步骤使用dexfixer或baksmali这些工具对DEX的容错性较好可以尝试直接反编译。java -jar baksmali-2.5.2.jar d memory_dump.dex -o output_dir手动修复DEX头使用010 Editor的DEX模板进行分析。重点关注checksum和signature可以置零或重新计算。file_size必须修正为文件实际大小。link_off和link_size如果不存在链接数据设为0。data_off和data_size确保data_offdata_sizefile_size。data_off通常指向文件末尾的数据区。重建DEX如果结构损坏严重可以用smali将baksmali反汇编出的smali代码重新汇编成DEX。java -jar smali-2.5.2.jar a output_dir -o repaired.dex5.2 多DEX与动态加载处理现代应用普遍使用MultiDex并且外壳可能将原始APK中的多个classes.dex合并、拆分或动态从网络下载。应对策略多次捕获在应用启动、切换页面、触发特定功能时多次执行提取脚本以捕获不同时机加载的DEX。HookBaseDexClassLoader及其子类这是所有DexClassLoader的父类通过Hook它的findClass或loadClass方法可以追踪到所有被加载的DEX来源。监控文件系统Hookjava.io.File和java.net.URL相关的API监控应用是否从本地缓存或网络下载了新的DEX/JAR文件。6. 自动化与工程化实践手动操作适合学习和针对性分析但对于需要批量处理或长期监控的场景我们需要将流程自动化。6.1 编写自动化提取脚本将上述的Hook、扫描、保存、去重逻辑整合到一个脚本中实现“一键脱壳”。// auto_dump.js 框架示例 Java.perform(function () { var dumpedHashes {}; // 用于去重 function dumpDex(buffer, source) { // 计算哈希 var hash calculateSHA1(buffer); if (dumpedHashes[hash]) return; dumpedHashes[hash] true; // 保存文件 var filename /sdcard/Download/dex_${source}_${Date.now()}.dex; saveBytesToFile(buffer, filename); console.log([] DEX dumped from ${source} to ${filename}); } // 方法1: Hook DexFile hookAllDexFileConstructors(dumpDex); // 方法2: 定时内存扫描谨慎使用 // setTimeout(() { scanMemoryForDex(dumpDex); }, 10000); // 方法3: Hook ClassLoader hookClassLoaderMethods(dumpDex); });6.2 与逆向框架集成可以将Frida脚本集成到更大型的逆向工程工作流中与Xposed模块结合对于需要持久化、开机即生效的场景可以将核心提取逻辑写成Xposed模块。与调试器联动使用Frida的Interceptor功能在关键Native函数处下断点然后使用GDB/LLDB进行更细致的指令级调试和内存观察。使用r2frida在Radare2中直接使用Frida将动态分析与强大的静态分析工具结合。内存DEX提取是一场与加固方案在时间和空间维度上的赛跑。核心在于理解系统原理、抓住内存中稍纵即逝的明文镜像。这套方法并非万能尤其是面对日益流行的纯Native化保护将关键逻辑完全用C实现或越来越深的混淆时可能需要结合静态分析、符号执行等更多手段。但毫无疑问熟练掌握Frida动态脱壳是你打开Android应用逆向分析大门后必须装备的最锋利的一把钥匙。它带给你的不仅是一个脱壳的结果更是对Android运行时深刻的理解。
Android应用内存DEX提取实战：Frida动态脱壳原理与对抗加固技术
1. 项目概述为什么我们需要内存DEX提取在移动安全逆向分析领域尤其是针对Android应用“脱壳”是一个绕不开的核心课题。简单来说脱壳就是从被保护加壳的应用中还原出其原始的、可被分析和理解的代码。而“内存DEX提取”则是当前最主流、最有效的动态脱壳手段之一。为什么这么说因为无论外壳的静态保护多么复杂应用最终都必须在内存中解密、加载原始的DEXDalvik Executable或OATART运行时格式文件才能运行。这就好比一个上了锁的保险箱静态分析是在研究锁的结构而内存提取则是等保险箱被打开、内容物一览无余时直接伸手进去拿。我接触过大量加固强度不一的应用从早期的梆梆、爱加密到现在的腾讯御安全、VMPVirtual Machine Protect等。实战中我发现静态脱壳工具往往追不上加固方案的快速迭代一个脚本可能只针对某个特定版本有效。而基于Frida的动态内存提取其原理是普适的它不关心外壳如何加密、混淆只关心最终在内存中呈现的原始代码镜像。因此掌握这套方法论就相当于拥有了一把“万能钥匙”能够应对绝大多数基于DEX加载的加固方案。本手册旨在将这套实战经验系统化从工具配置、原理剖析到实战对抗手把手带你掌握这门核心技术。2. 核心原理与Frida基础环境搭建2.1 DEX文件在内存中的生命周期要精准提取必须先理解目标在内存中的“存活”状态。一个DEX文件从被外壳保护到最终被ART/Dalvik虚拟机执行大致经历以下几个关键阶段文件加载与解密外壳程序Stub首先被执行。它负责从APK的特定位置如assets读取被加密或压缩的原始DEX数据在内存中进行解密或解压。此时解密后的纯字节流已经存在于进程的堆内存中但还未被系统识别为一个合法的DEX结构。内存镜像构建外壳调用系统底层API如dalvik.system.DexFile.loadDex或 ART下的DexFile相关方法将解密后的字节流构建成虚拟机可识别的内存镜像。这个镜像包含了完整的DEX文件头、字符串池、类定义、方法字节码等所有信息。这是我们提取的第一个黄金时机。类加载与初始化虚拟机根据内存DEX镜像加载其中的类并执行初始化方法如clinit。在这个过程中一些加固方案可能会进行更复杂的运行时混淆或代码变换。即时编译JIT/AOT在ART环境下字节码可能被编译成本地机器码Nexus。提取出的DEX是字节码层面的而机器码的提取如从JIT Code Cache中是另一个更深层次的话题。我们的核心目标就是捕获第2步中构建完成的内存DEX镜像。这个镜像在内存中通常是一块连续的、具有完整DEX文件结构的内存区域。2.2 Frida环境部署与核心工具链工欲善其事必先利其器。一个稳定、高效的Frida环境是成功的基础。服务端Target Device/Emulator:推荐设备首选Root后的真实Android手机如Google Pixel系列其次是指令集兼容性好的模拟器如Android Studio官方模拟器。雷电、夜神等第三方模拟器可能存在兼容性问题。Frida-server安装从Frida官方GitHub releases页面下载与设备架构通常是arm64匹配的frida-server。推送到设备并赋予执行权限adb push frida-server-16.1.4-android-arm64 /data/local/tmp/frida-server adb shell “chmod 755 /data/local/tmp/frida-server”运行服务端在adb shell中启动它建议后台运行adb shell “/data/local/tmp/frida-server ”客户端分析机:Python环境安装Frida的Python绑定pip install frida-tools验证连接确保设备IP可通并运行frida-ps -U列出设备进程确认连接成功。注意市面上存在一些应用会检测Frida的运行痕迹如检测frida-server文件名、端口或特征内存。在对抗高强度加固时可能需要对frida-server进行重命名、端口伪装或使用定制编译版本。这是实战中的第一道门槛。辅助脚本与工具objection一个基于Frida的运行时移动安全评估框架可以快速完成内存搜索、类枚举等操作强烈建议安装 (pip install objection)。编辑器/IDE用于编写Frida脚本推荐VS Code。010 Editor或WinHex用于分析和验证提取出的二进制DEX文件结构。3. 实战定位与提取内存中的DEX镜像理论准备就绪我们进入最关键的实战环节。我将以两种最经典、最有效的思路为例详细拆解每一步。3.1 方法一HookDexFile构造函数一网打尽这是最直接、最可靠的方法。在Android系统中无论是Dalvik还是ART最终承载DEX内存镜像的Java对象通常是dalvik.system.DexFile或ART中对应的内部类。当外壳解密并加载DEX时必然会实例化此类。步骤拆解编写Frida Hook脚本Java.perform(function () { // 定位DexFile类 var DexFile Java.use(“dalvik.system.DexFile”); // Hook其构造函数重点关注接收byte[]或int内存地址的构造方法 DexFile.$init.overload(‘[B’).implementation function (buffer) { console.log(“[] DexFile Constructor Hooked!”); console.log(“[*] Buffer length: “ buffer.length); // 计算可能的DEX文件大小DEX文件头magic为”dex\n035\0” if (buffer.length 0x70) { // 确保有足够长度读取magic var magic ”; for (var i 0; i 8; i) { magic String.fromCharCode(buffer[i]); } console.log(“[*] Magic in buffer: “ magic); if (magic.indexOf(‘dex’) 0) { console.log(“[!!!] Found DEX in buffer!”); // 将字节数组转换为Uint8Array以便保存 var uint8Array new Uint8Array(buffer); // 生成文件名 var timestamp new Date().getTime(); var filePath “/sdcard/Download/dex_” timestamp “.dex”; // 调用我们写的Native函数来写文件见下一步 saveBytesToFile(uint8Array, filePath); console.log(“[] DEX saved to: “ filePath); } } // 继续执行原方法 return this.$init(buffer); }; });这段脚本Hook了接收字节数组的DexFile构造函数。当外壳将解密后的DEX字节流传入时我们就能截获它。实现文件保存函数Frida的JavaScript环境不能直接进行文件I/O我们需要通过NativeFunction调用libc的fopen,fwrite等函数。function saveBytesToFile(bytes, filePath) { var fopen new NativeFunction(Module.findExportByName(null, ‘fopen’), ‘pointer’, [‘pointer’, ‘pointer’]); var fwrite new NativeFunction(Module.findExportByName(null, ‘fwrite’), ‘size_t’, [‘pointer’, ‘size_t’, ‘size_t’, ‘pointer’]); var fclose new NativeFunction(Module.findExportByName(null, ‘fclose’), ‘int’, [‘pointer’]); var path Memory.allocUtf8String(filePath); var mode Memory.allocUtf8String(“wb”); var file fopen(path, mode); if (file.isNull()) { console.log(“[-] Failed to open file for writing.”); return; } // 为字节数据分配内存并拷贝 var buffer Memory.alloc(bytes.length); for (var i 0; i bytes.length; i) { buffer.add(i).writeU8(bytes[i]); } var result fwrite(buffer, 1, bytes.length, file); console.log(“[*] Bytes written: “ result.toString()); fclose(file); }附加进程并执行启动目标应用然后使用Frida附加frida -U -f com.example.targetapp -l dex_hook.js --no-pause触发应用的启动或相关功能观察控制台输出。一旦捕获到DEX脚本会自动将其保存到设备的/sdcard/Download/目录下。实操心得并非所有加固都使用DexFile(byte[])。有些可能使用DexFile(int cookie)其中cookie是一个指向内存DEX镜像的Native指针。你需要同时Hook多个重载方法。在ART上关键的加载类可能是dalvik.system.DexPathList$Element或com.android.dex.Dex。使用objection的android hooking list classes命令搜索所有包含”Dex”的类名能帮你快速定位目标。时机至关重要Hook脚本必须在DEX被加载前注入。使用-f参数在应用启动时即附加能最大概率捕获到所有DEX。3.2 方法二内存扫描与特征匹配大海捞针当Hook点被加固方案隐藏或混淆时内存扫描是更通用的“笨办法”。其原理是一个完整的DEX文件在内存中具有鲜明的特征——文件头魔术字64 65 78 0a 30 33 35 00”dex\n035\0”。步骤拆解使用Frida进行内存范围枚举与搜索Java.perform(function () { // 获取目标进程的所有内存范围 Process.enumerateRanges(‘r--’).forEach(function (range) { // 只搜索可读且较大的内存块提高效率 if (range.size 1024 * 1024) { // 例如大于1MB console.log(‘[*] Scanning range: ‘ range.base.toString(16) ‘ – ‘ range.base.add(range.size).toString(16)); // 在该内存范围搜索DEX魔术字 var dexMagic “64 65 78 0a 30 33 35 00”; var results Memory.scan(range.base, range.size, dexMagic); results.on(‘match’, function (address, size) { console.log(‘[!!!] Potential DEX header found at: ‘ address.toString(16)); // 找到魔术字后需要验证并计算完整DEX大小 // DEX文件头第32-35字节是file_size字段小端序 var fileSizePtr address.add(0x20); var fileSize fileSizePtr.readU32(); // 读取32位无符号整数 console.log(‘[*] DEX file size from header: ‘ fileSize ‘ bytes’); // 从魔术字地址开始读取整个DEX大小的内存 var dexBuffer address.readByteArray(fileSize); if (dexBuffer ! null) { var timestamp new Date().getTime(); var filePath ‘/sdcard/Download/memory_dex_’ address.toString(16) ‘_’ timestamp ‘.dex’; saveBytesToFile(Array.from(dexBuffer), filePath); // 使用之前的保存函数 } }); } }); });优化与验证性能全内存扫描非常耗时且可能卡住应用。务必添加范围大小过滤并优先扫描/data/app/包名路径对应的lib*.so库附近的内存或[anon:libc_malloc]这类堆内存区域。去重同一个DEX可能在内存中有多份拷贝如被不同ClassLoader加载。可以通过计算DEX文件的SHA-1哈希值头部的signature字段来进行去重。验证用file命令或010 Editor打开提取的文件检查其是否为有效的DEX文件。无效的文件可能只是碰巧包含魔术字的随机数据。常见问题与排查扫描无结果DEX可能被分段存储或头魔术字被轻微修改。可以尝试搜索变种魔术字或搜索DEX文件中部的一些固定结构特征。提取的文件损坏file_size字段可能被外壳篡改。一个更稳健的方法是找到魔术字后向后解析DEX文件结构根据map_off和map_size来动态计算真实大小。应用崩溃内存扫描是侵入性操作。尽量在应用空闲时进行或使用Memory.scan的异步API。4. 对抗进阶加固与Frida检测高强度的商业加固方案不会坐以待毙。它们通常会采用多重防御。4.1 对抗反Frida检测加固方会检测Frida的存在常见手段包括端口检测检测默认的27042端口是否被监听。进程名检测遍历/proc/self/task/或/proc/net/tcp查找frida-server相关字符串。内存特征检测在内存中搜索Frida相关字符串如“gum-js-loop”或特定代码片段。线程名检测Frida注入的线程可能有特定名称。应对策略修改Frida-server重命名二进制文件修改默认端口通过frida-server -l 0.0.0.0:8080。使用定制编译的Frida从源码编译修改其中的特征字符串。主动屏蔽检测逻辑用Frida Hook常见的检测函数如fopen,readlink,readdir当它们尝试访问敏感路径如/proc/self/maps或读取特定内容时返回伪造的安全数据。// 示例Hook readdir 过滤掉包含”frida”的目录项 Interceptor.attach(Module.findExportByName(null, “readdir”), { onLeave: function (retval) { if (!retval.isNull()) { var dirEntry retval; // 读取d_name字段这是一个指针 var namePtr dirEntry.add(…); // 结构体偏移量需根据libc确定 var name namePtr.readCString(); if (name name.indexOf(‘frida’) ! -1) { // 如果目录名包含frida跳过此项模拟读到结束 retval.writePointer(NULL); } } } });4.2 对抗VMP等高级保护VMP虚拟机保护会将原始的DEX字节码转换为自定义的指令集在私有虚拟机中执行。这给内存提取带来了巨大挑战挑战1内存中可能不存在完整的、标准的DEX镜像只有被解释执行的“碎片化”代码段。挑战2即使存在DEX的关键数据结构如字符串池、方法字节码可能被加密或混淆。应对思路寻找时机VMP为了兼容性可能在初始化、或某些非关键路径上仍然会解密一部分原始DEX到内存中。通过Hook系统JNI函数如FindClass,GetMethodID并回溯调用栈寻找解密函数。内存快照对比在应用启动初期解密前和功能完全加载后解密后分别对进程内存进行整体dump。使用二进制对比工具如BinDiff找出新增的、具有一定大小的内存块这些块中可能包含解密后的代码。Hook自定义解释器如果能够定位到VMP的解释器核心函数通常是一个大的switch或jit编译块可以尝试Hook它在它执行每一条自定义指令前记录下对应的原始字节码语义从而“重建”出方法逻辑。这是一项极其耗时且需要深厚逆向功底的工作。关注ART层面对于Android 5.0以上的ART虚拟机最终所有代码包括VMP解释的都需要被ART的JIT或AOT编译器处理以转换成ARM/ARM64指令。可以尝试从ART的JIT代码缓存jit_code_cache_中提取已编译的本地代码再反编译分析。这需要深入理解ART内部结构。重要提示对抗VMP是一个高强度的攻防过程没有通用的一键脚本。它考验的是分析者的耐心、底层知识ARM汇编、ART运行时和逆向工程能力。通常需要结合静态分析IDA Pro分析so库和动态分析Frida, GDB进行。5. 提取后的处理与修复成功提取出DEX文件并不意味着结束它可能还存在问题。5.1 DEX文件修复从内存中dump出的DEX其data_off和data_size等字段可能因为内存对齐或外壳修改而不准确导致反编译工具如JADX、GDA无法正确解析。修复步骤使用dexfixer或baksmali这些工具对DEX的容错性较好可以尝试直接反编译。java -jar baksmali-2.5.2.jar d memory_dump.dex -o output_dir手动修复DEX头使用010 Editor的DEX模板进行分析。重点关注checksum和signature可以置零或重新计算。file_size必须修正为文件实际大小。link_off和link_size如果不存在链接数据设为0。data_off和data_size确保data_offdata_sizefile_size。data_off通常指向文件末尾的数据区。重建DEX如果结构损坏严重可以用smali将baksmali反汇编出的smali代码重新汇编成DEX。java -jar smali-2.5.2.jar a output_dir -o repaired.dex5.2 多DEX与动态加载处理现代应用普遍使用MultiDex并且外壳可能将原始APK中的多个classes.dex合并、拆分或动态从网络下载。应对策略多次捕获在应用启动、切换页面、触发特定功能时多次执行提取脚本以捕获不同时机加载的DEX。HookBaseDexClassLoader及其子类这是所有DexClassLoader的父类通过Hook它的findClass或loadClass方法可以追踪到所有被加载的DEX来源。监控文件系统Hookjava.io.File和java.net.URL相关的API监控应用是否从本地缓存或网络下载了新的DEX/JAR文件。6. 自动化与工程化实践手动操作适合学习和针对性分析但对于需要批量处理或长期监控的场景我们需要将流程自动化。6.1 编写自动化提取脚本将上述的Hook、扫描、保存、去重逻辑整合到一个脚本中实现“一键脱壳”。// auto_dump.js 框架示例 Java.perform(function () { var dumpedHashes {}; // 用于去重 function dumpDex(buffer, source) { // 计算哈希 var hash calculateSHA1(buffer); if (dumpedHashes[hash]) return; dumpedHashes[hash] true; // 保存文件 var filename /sdcard/Download/dex_${source}_${Date.now()}.dex; saveBytesToFile(buffer, filename); console.log([] DEX dumped from ${source} to ${filename}); } // 方法1: Hook DexFile hookAllDexFileConstructors(dumpDex); // 方法2: 定时内存扫描谨慎使用 // setTimeout(() { scanMemoryForDex(dumpDex); }, 10000); // 方法3: Hook ClassLoader hookClassLoaderMethods(dumpDex); });6.2 与逆向框架集成可以将Frida脚本集成到更大型的逆向工程工作流中与Xposed模块结合对于需要持久化、开机即生效的场景可以将核心提取逻辑写成Xposed模块。与调试器联动使用Frida的Interceptor功能在关键Native函数处下断点然后使用GDB/LLDB进行更细致的指令级调试和内存观察。使用r2frida在Radare2中直接使用Frida将动态分析与强大的静态分析工具结合。内存DEX提取是一场与加固方案在时间和空间维度上的赛跑。核心在于理解系统原理、抓住内存中稍纵即逝的明文镜像。这套方法并非万能尤其是面对日益流行的纯Native化保护将关键逻辑完全用C实现或越来越深的混淆时可能需要结合静态分析、符号执行等更多手段。但毫无疑问熟练掌握Frida动态脱壳是你打开Android应用逆向分析大门后必须装备的最锋利的一把钥匙。它带给你的不仅是一个脱壳的结果更是对Android运行时深刻的理解。
