经常有做Android开发的朋友问我你说市面上那些App加固到底是怎么把DEX藏起来的为什么有些App用jadx打开只有一个空壳这个加密到底是怎么实现的我们自己能不能写一套这篇文章就用一个完整的案例把DEX加密与解密这套东西从原理到代码一层层剥开。你会看到DEX文件格式到底长什么样、Android类加载机制是怎么被“偷梁换柱”的、加密壳是怎么在运行时把真正的代码解密回来以及作为逆向方怎么把内存里的DEX再抠出来修复。不管你是App开发者想做代码保护还是安全研究者想搞明白脱壳的原理这篇都值得你往下看。我尽量讲得直接一点不绕弯子。1. 为什么App要折腾DEX加密先搞明白它在防谁1.1 Android应用面临的代码暴露问题Android应用本质上是个压缩包APK里的classes.dex就是Dalvik/ART虚拟机要执行的字节码文件。问题在于DEX格式是公开的Android的运行时必须要能解析它所以DEX天然就是可被反向解析的。用jadx、GDA、JEB这类工具直接打开APK里的classes.dex只要没有做过任何保护那你看到的几乎是和源码等价的Java代码——方法名、字段名、调用关系、字符串常量全都在。等于把你的业务逻辑、接口地址、加密算法、鉴权流程全部公开了如果有人想抄你的核心逻辑成本低得吓人。所以DEX加密这件事核心目的只有一个让静态分析者拿到APK后看到的不是真正的DEX字节码而是一个无法直接解析的密文文件。这个密文要等App真正运行起来才能在内存里被还原成虚拟机可识别的DEX结构。1.2 “DEX加密”和保护强度的关系我在网上看到很多人把DEX加密等同于“加固”其实不完全是一回事。DEX加密只是加固体系里的第一层也是最基础的一层。真正的商业加固方案在DEX加密之上通常还叠加了指令抽取把DEX中每个方法的指令在运行时动态还原。VMP虚拟机保护把Dalvik字节码翻译成自定义指令集。native层加固把核心校验逻辑沉到SO里。反调试与反HOOK检测Frida、Xposed等运行时环境。完整性校验防二次打包、防动态注入。DEX加密本身解决的是“静态分析直接看到明文代码”的问题。它挡不住一个熟练的逆向工程师但可以大幅度拉高分析门槛让绝大多数脚本小子、初级分析者无功而返。1.3 什么样的情况适合自己做DEX加密商业加固平台(比如各种云加固)用起来很省事上传APK等一会儿就出加固包。但商业加固也有痛点收费、要求联网、加固策略是黑盒、偶尔会有兼容性问题。自己做DEX加密适合这些场景你对安全策略有定制化需求比如想把DEX加密和自身业务绑定密钥从服务端动态下发。你不想把APK交给第三方平台有隐私或合规上的考虑。你想学习加固与脱壳的原理自己动手跑通一遍全流程。你的App对包体大小、启动速度有极致要求需要精确控制加密逻辑。当然自己实现的加密壳在对抗高段位逆向时确实不如商业方案严谨但作为基础防线和原理学习非常够用。2. 动手之前先把DEX文件格式和类加载机制吃透2.1 DEX文件的磁盘布局DEX不是一个普通的数据文件它有严格的二进制格式。在做加密前你必须对它的结构有基本认知不然你都不知道自己加密的对象是什么。DEX文件主要分为以下几个区域区域作用文件头(header)文件魔数、校验和、SHA-1签名、文件大小、各区段的大小与偏移字符串区(string_ids)所有用到的字符串常量索引类型区(type_ids)所有类型描述符索引原型区(proto_ids)方法原型描述参数、返回值字段区(field_ids)字段信息索引方法区(method_ids)方法信息索引类定义区(class_defs)类的定义指向类数据的偏移数据区(data)类字节码、方法指令、注解、调试信息等文件头的魔数是固定的dex\n035\0早期还有036、037、038、039ARM设备上主流是035。ART虚拟机加载DEX时会校验文件头的魔数、checksum和SHA-1签名任何一个不匹配加载都会失败。这就是为什么“直接把DEX某些字节抠掉再放回去”行不通——运行时校验过不去。加密壳的思路是让你根本看不到完整的真实DEX文件它只在内存里存在片刻。2.2 Android类加载的完整链路Java层的类加载无论你怎么写最终都逃不过ClassLoader。Android的类加载有典型的双亲委托机制一个类加载请求会先交给父加载器如果父加载器加载不到才轮到自己。在应用进程里默认的PathClassLoader加载APK里的DEX文件。它的内部结构包含一个DexPathList对象DexPathList里维护着一个Element数组每个Element对应一个DexFile。DexFile在native层对应一个打开的DEX句柄。如果我们要加载一个解密后的DEX有两个办法一种是把这个解密出来的DEX文件丢到一个新建的DexClassLoader里然后想办法让App的所有类查找都走这个新的ClassLoader。另一种是把解密后的DEX追加到默认ClassLoader的DexPathList里也就是插件化框架的原理。DEX加密壳最典型的做法是第一种的变体。自定义Application在attachBaseContext阶段提前介入此时系统的默认ClassLoader还没有加载业务类因为Application本身是AndroidManifest里声明的入口系统先加载它然后才走业务Application的onCreate。在这个窗口期完成解密和ClassLoader替换后续系统加载业务Activity、Service时就会通过我们替换后的ClassLoader去找类。2.3 一个必须明确的边界加密不是混淆很多人把DEX加密和ProGuard/R8混淆混为一谈。它俩完全是两回事。ProGuard/R8混淆是在源码编译成字节码之后对类名、方法名、字段名做无意义化处理同时删除无用代码。混淆之后类名变成a.b.c这种但字节码还是明文可解析的用jadx照样能看逻辑只是阅读体验变差了。DEX加密是把整个DEX文件变换成密文不提供密钥静态分析者连文件内容都无法直接查看。两者可以叠加使用通常做法是代码先做混淆然后再把DEX整个加密。混淆增加逆向者的阅读成本加密增加逆向者获取明文的成本。3. 加密端实施流程与代码实现3.1 整体架构设计DEX加密的基本流程可以分成三块打包期加密把APK里原始的classes.dex以及classes2.dex、classes3.dex等用密钥加密加密后的文件放进APK的assets或res/raw目录原始DEX从APK中移除或只留一个带入口信息的壳DEX。运行时解密Application启动时读取assets里的密文文件用密钥解密还原出完整的DEX数据。运行时加载把解密后的DEX数据交给ClassLoader体系让App后续类加载都能命中。需要注意的是壳DEX需要保留的位置是AndroidManifest里声明的Application类、以及Application的直接依赖类。因为系统启动应用时要先实例化这个Application。我见过很多新手把Application也塞进了加密DEX结果一启动就ClassNotFoundException——系统根本还没执行你的解密逻辑拿不到Application类。3.2 打包期用脚本对DEX做加密处理打包期的加密可以用Python脚本、Gradle Task或者Java命令工具来完成。这里给一个Python的示例思路是一样的。我用的是AES-256-CBC密钥为一个32字节的随机值。密码学算法上没什么特别高深的AES作为对称加密算法加解密性能好适合移动端处理比较大的文件。# encrypt_dex.py import os import sys from Crypto.Cipher import AES from Crypto.Util.Padding import pad KEY b0123456789abcdef0123456789abcdef # 开发环境示例生产环境请妥善管理密钥 IV b1234567890abcdef def encrypt_file(src_path, dst_path): with open(src_path, rb) as f: plain_data f.read() cipher AES.new(KEY, AES.MODE_CBC, IV) encrypted cipher.encrypt(pad(plain_data, AES.block_size)) with open(dst_path, wb) as f: f.write(encrypted) print(f[] encrypted {src_path} - {dst_path}, size{len(encrypted)}) if __name__ __main__: # 用法: python encrypt_dex.py classes.dex assets/dex/classes.enc encrypt_file(sys.argv[1], sys.argv[2])这里有一个细节密文文件不要叫做“classes.dex.enc”最好放在一个看起来无关的路径例如assets/dex/下的随机文件名。这样做的目的不是指望扛住逆向分析而是让静态扫描时不会一眼锁定加密入口增加一点分析成本。实际项目中很多加固方案还会把加密DEX嵌入到SO文件的某个自定义section中或者伪装成图片资源、字体资源进一步隐藏。3.3 运行时解密自定义Application里的核心逻辑运行时解密这一步核心在Application.attachBaseContext。这一步的时间点非常关键它在Application.onCreate之前执行也早于所有业务组件的实例化。我们可以在这个时机安全地替换ClassLoader。下面是一个可直接运行的简化版实现。public class StubApplication extends Application { Override protected void attachBaseContext(Context base) { super.attachBaseContext(base); try { // 1. 从 assets 读取密文 byte[] encryptedData readAsset(base, dex/classes.enc); // 2. 解密还原原始DEX字节流 byte[] originalDex decryptDex(encryptedData); // 3. 写入应用私有目录 File dexFile new File(base.getDir(dex, MODE_PRIVATE), real.dex); if (!dexFile.exists() || dexFile.length() ! originalDex.length) { writeFile(dexFile, originalDex); } // 4. 构造DexClassLoader并替换默认ClassLoader DexClassLoader loader new DexClassLoader( dexFile.getAbsolutePath(), dexFile.getParentFile().getAbsolutePath(), null, base.getClassLoader()); // 5. 反射替换ContextImpl中的mClassLoader Object appContext base; Class? contextImplClass Class.forName(android.app.ContextImpl); Field mClassLoaderField contextImplClass.getDeclaredField(mClassLoader); mClassLoaderField.setAccessible(true); mClassLoaderField.set(appContext, loader); } catch (Throwable t) { t.printStackTrace(); } } private byte[] readAsset(Context context, String path) throws IOException { AssetManager am context.getAssets(); InputStream is am.open(path); ByteArrayOutputStream bos new ByteArrayOutputStream(); byte[] buffer new byte[8192]; int len; while ((len is.read(buffer)) ! -1) { bos.write(buffer, 0, len); } is.close(); return bos.toByteArray(); } private byte[] decryptDex(byte[] cipherData) throws Exception { SecretKeySpec keySpec new SecretKeySpec(KEY_BYTES, AES); Cipher cipher Cipher.getInstance(AES/CBC/PKCS5Padding); cipher.init(Cipher.DECRYPT_MODE, keySpec, new IvParameterSpec(IV_BYTES)); return cipher.doFinal(cipherData); } }这段代码里有几处需要说明MODE_PRIVATE的目录是/data/data/包名/app_dex/写入这个位置可以避免暴露在外部存储上。解密后的文件还是真实存在于磁盘上这是这类方案的一个弱点后面脱壳部分会详细讲。DexClassLoader的四个参数分别是DEX路径、优化缓存目录、native库路径、父加载器。父加载器传base.getClassLoader()这样双亲委托链不会断。替换mClassLoader字段必须反射操作因为系统没有开放setter。Android 9以上对反射隐藏字段有限制但这几个字段属于应用自己进程内可访问的一般没问题。3.4 更高阶的做法不落盘的InMemoryDexClassLoader上面的方案里解密后的DEX会先写到磁盘再加载。只要在磁盘上存在就有被直接拉走的可能。更稳妥的做法是利用Android 8.0(API 26) 引入的InMemoryDexClassLoader直接加载内存中的ByteBuffer不落盘。if (Build.VERSION.SDK_INT Build.VERSION_CODES.O) { ByteBuffer dexBuffer ByteBuffer.wrap(originalDex); InMemoryDexClassLoader memoryLoader new InMemoryDexClassLoader( new ByteBuffer[]{dexBuffer}, base.getClassLoader()); // 替换 ClassLoader 逻辑同上 }用InMemoryDexClassLoader的好处很明显DEX字节流只在Java堆/native内存中短暂存在垃圾回收之后很难再从磁盘恢复。坏处是每次冷启动都要重新解密一次启动耗时变长另外DEX如果很大内存开销也比较大需要自己权衡。4. 解密分析与脱壳实战从内存里把DEX捞回来讲完加密端再站在逆向角度看看怎么解。别误会这不是教大家去破解别人的App而是了解攻防双方博弈之后才能写出更抗分析的代码。就像你得知道锁的原理才知道怎么设计更难撬的锁。4.1 脱壳的关键突破口在哪先明确一个前提无论如何加密最终都要在运行时还原出完整可执行的DEX字节码给ART虚拟机解析。这个还原动作只要发生了就一定有痕迹。常见的脱壳切入思路有这几种内存搜索DEX有固定的魔数dex\n以及文件头里的file_size、header_size、data_size这些字段。在进程内存中搜索dex魔数就能把加密壳解密后但尚未被释放的DEX块找出来。Hook类加载Hook住DexFile、DexClassLoader、BaseDexClassLoader的相关方法拿到传入的dex路径或者ByteBuffer直接dump。Hook ART内部函数在native层hookOpenCommon、DexFileLoader::Open等ART的加载函数。Frida脚本自动遍历现在有很多现成的开源脱壳脚本原理就是上面这些做成了一键dump。用Frida做Hook时最常见的操作是这样的// 快速定位应用内加载了哪些dex Java.perform(function () { var DexFile Java.use(dalvik.system.DexFile); DexFile.$init.overload(java.lang.String).implementation function (path) { console.log([] DexFile init: path); return this.$init(path); }; var InMemoryDexClassLoader Java.use(dalvik.system.InMemoryDexClassLoader); InMemoryDexClassLoader.$init.implementation function (buffers, parent) { console.log([] InMemoryDexClassLoader loaded); return this.$init(buffers, parent); }; });Hook到点之后下一步就是把内存里的DEX字节dump到本地文件开始修复流程。4.2 DEX dump出来以后为什么还要修复很多人以为dump出来就是完整的DEX了其实不然。内存里的DEX往往处于加载中间状态或者因为加固方案对原文件做了裁剪、偏移修改直接扔给jadx是解析不了的。修复DEX主要做这几件事完善文件头确保magic、checksum、signature、file_size、header_size、data_size这些字段自洽。修正偏移如果加固方修改了string_ids、type_ids、class_defs等区段的偏移值需要根据数据区的实际布局重新计算。合并拆分的DEX有些加固把DEX拆成多段存储需要在内存中找到每一段并按顺序拼接。修复工作可以用Hex编辑器手工做也可以用现成工具自动化处理。常用的开源工具有frida-dexdump、Youpk、BlackDex等它们不仅负责dump还会自动处理一部分修复逻辑。4.3 脱壳之后的还原工具链不管用什么方案最后拿到的DEX文件都要能反编译看逻辑这一步的工具链比较固定工具用途jadx直接将DEX/APK反编译成Java代码界面操作适合阅读GDA/JEB功能更强的综合分析工具支持动态调试dex2jar JD-GUI老牌组合DEX转JAR后再反编译Frida动态Hook、内存读写、函数调用跟踪IDA Pro/Ghidra分析SO文件处理native层加固逻辑如果你自己dump出的DEX在jadx里打不开先看两件事一是文件头magic是不是dex\n二是file_size字段文件头偏移0x20处4字节小端是否与实际文件大小一致。大部分“打不开”都是这两个问题。5. 实际操作中容易踩的坑与耗时点5.1 启动闪退Application类不能进入加密DEX这是自己做DEX加密时最高发的问题。前面我提过一次这里再展开说系统启动一个App时Zygote进程fork出应用进程然后ActivityThread会通过Apk里的ClassLoader加载AndroidManifest里指定的Application类。如果这个Application类不在壳DEX里也就是说在解密逻辑执行之前系统根本找不到这个类直接就是ClassNotFoundException。解决方案是壳DEX里必须包含Application类以及这个类构造期间直接引用的类。一般的做法是用一个StubApplication作为真实的入口它在attachBaseContext里执行解密和替换ClassLoader然后再把真实的Application类加载出来继续走正常的生命周期。5.2 每个进程都会执行一遍解密Android应用默认有多个进程比如主进程、推送进程、RemoteViews进程等。每个进程冷启动的时候都会去执行Application.attachBaseContext也就是说每个进程都会尝试解密一次DEX。如果你的App后台存活了多个进程每次启动都做IO读assets、AES解密、写入文件、创建ClassLoader这会造成重复耗时。一个简单的优化是加文件锁或者用原子操作保证只有一个进程执行解密其他进程等锁释放后直接复用磁盘上的明文DEX。再或者用跨进程的SharedPreferences做标记位判断已经解密过就不再解密。5.3 启动速度变慢是必然的解密一个10MB的DEXAES解密本身很快但assets的IO读取和文件写入会有开销整体增加的时间大概在几十毫秒到几百毫秒之间取决于设备性能。优化思路有几个方向只加密真正敏感的业务DEX公共库类比如okhttp、gson可以不加密减少解密体积。解密结果做缓存不是每次冷启动都重新解密。异步预加载如果是多DEX架构可以把非关键DEX的加载放到子线程。但要说清楚启动时解密后替换ClassLoader这个动作本身是同步的因为后续所有类加载都依赖它。你没法把这部分完全塞到子线程里。能优化的只是把重复劳动降到最低。5.4 Android版本兼容性问题Android 8以下的设备没有InMemoryDexClassLoader只能用DexClassLoader落盘方案。这不算大问题写个分支判断就行。Android 9以上对反射隐藏API有限制虽然反射当前进程内的ClassLoader字段通常没问题但如果你的targetSdk很高保险起见最好在AndroidManifest里加上android:usesCleartextTraffic、android:requestLegacyExternalStorage这些兼容项之外还要实测不同机型。还有一个容易踩的坑Android 14之后系统对动态加载代码有更严格的限制如果你的targetSdk版本比较高动态加载很可能会受到拦截或警告需要做特殊适配。5.5 加密密钥别硬编码在DEX明文里这是最讽刺的场景你把DEX用AES加密了但AES密钥就硬编码在StubApplication的Java代码里等于把保险柜钥匙贴在保险柜外面。逆向的人只需从壳DEX里找到密钥瞬间解密全部内容。密钥管理要提升一个档次常见做法有密钥存放在native层的SO里至少要经过一些变换再参与解密运算而不是直接在Java层new String。密钥分段存放在不同位置运行时拼接。密钥由服务端下发客户端不保存但这种情况要考虑弱网和离线场景。不过我要说一句实在话客户端安全永远做不到绝对只能无限拉高门槛。所有密钥最终都在用户设备上一个足够耐心的攻击者用白盒分析总能找到。6. 关于这套方案值不值得用的一点个人看法做了这么多年Android我对DEX加密的态度一直是它不是银弹但是一道必须要加的基础防线。如果你的App有比较核心的算法逻辑、有需要保护的业务规则花几个工作日把这么一套加密流程跑通是值得的。我自己在项目里实践下来的体会是与其花费大量精力在加密算法本身上不如把更多心思花在这几件事上第一DEX加密方案要简单可靠不能为了炫技引入过多不稳定因素否则线上崩溃率会让你欲哭无泪。所有加固方案的本质都是在“安全强度”和“兼容稳定”之间做平衡任何一边失衡都会出问题。第二壳的启动耗时是客观存在的一定要用多DEX拆分来缓解把小DEX当成入口把真正核心的业务DEX放到后面加密加载。第三加密代码最好和业务剥离做成一个独立的模块这样以后想替换成商业加固方案改动面也小。如果你接下来打算自己动手做DEX加密我的建议是先把AS里一个只有MainActivity的Demo工程跑通全流程再去碰复杂项目。这样出问题的时候你能够很清晰地判断是加密逻辑的问题还是外部依赖兼容性的问题。等这套基础版稳定了再去考虑加指令抽取、native校验这些进阶项。