你是否遇到过这种情况：核心类文件存放在磁盘上，任何人都可以拖走进行反编译，然后你的API密钥、数据库密码、硬编码Token就全部暴露了。市面上许多方案要么是全文件AES加密，破坏ClassFile结构导致JVM直接崩溃；要么干脆不做运行时保护，仅仅依赖混淆来蒙混过关。实际上，有一种更聪明的做法——只加密常量池中真正敏感的字符串，而不是整个class文件。加解密在自定义ClassLoader的findClass方法中完成，密钥通过JVM参数或KMS注入并严格隔离。一句话：让敏感类在磁盘上始终以密文形式存在，仅在JVM加载瞬间解密并进入内存，明文的生命周期极短。
具体操作流程是怎样的？核心思路是：不加密整个class文件，只加密常量池中真正敏感的字符串字面量——比如API密钥、SQL模板、硬编码Token等。下面我们逐步拆解。
只改动常量池，不动字节码整体结构
整文件AES加密是一个大坑——它会直接破坏ClassFile格式，JVM读取不到合法的Magic Number和版本号，直接抛出NoClassDefFoundError。正确的做法是使用ASM或Javassist扫描编译后的.class文件，在常量池（Constant Pool）中定位那些带@Encrypted注解或以ENC_开头的CONSTANT_Utf8_info条目：
- 将原始字符串（比如
"sk_test_xxx"）替换为Base64编码的密文块，格式类似"ENC_aGVsbG8=|iv:abcd|hmac:xyz" - 密文由AES-128-CBC加密生成，每次附带16字节随机IV，并追加HMAC-SHA256签名以防范篡改
- 签名密钥与解密密钥物理分开，避免单点泄露导致整个保护失效
- 替换后的class文件仍然可以通过
javap查看，结构合法，但敏感值不可读
在findClass方法中完成可信解密
接下来需要一个自定义类加载器。继承ClassLoader，重写findClass，绕过双亲委派，直接接管目标类的加载全流程：
- 调用
getResourceAsStream(name.replace('.', '/') + ".class")读取加密字节流 - 用
ASMClassReader解析字节码，遍历常量池，识别ENC_标记项 - 提取密文、IV和HMAC，先验证签名，再通过AES解密得到原始字符串
- 构造新的字节数组，调用
super.defineClass(name, decryptedBytes, 0, len) - 解密完成后立即用
Arrays.fill(keyBytes, (byte) 0)清空密钥内存——这一点很多人会忽略，但恰恰是最容易翻车的地方
密钥必须与代码完全隔离
说到底，密钥是整个方案中最脆弱的一环。任何硬编码都会让保护形同虚设：
- 禁止出现在源码、配置文件、jar包资源中
- 推荐通过JVM启动参数注入，例如
-Dapp.key=xxx - 生产环境对接KMS或HSM；Android上优先使用Keystore
- 多环境支持可按环境变量区分密钥（如
CLASS_ENCRYPT_KEY_PROD），启动时动态加载 - 禁用日志打印密钥，堆转储路径需限制权限，避免
keyBytes泄露
请记住：密钥隔离如果不到位，整个方案就等于零。
绕开框架和反射的加载陷阱
到了这一步，你以为就稳了？别高兴太早——Spring、Hibernate、Servlet容器这些大型框架会提前加载大量类，稍有不慎就会触发初始化失败。实践中必须留意以下几点：
- 不要加密Spring Bean类本身，但可以加密其内部的
static final String字段 - 避免加密被
Class.forName或反射直接引用的类，否则类加载链路会中断 - 对框架扫描路径（如
@ComponentScan）做白名单过滤，确保非敏感类走默认加载器 - 测试阶段启用
-verbose:class观察实际加载顺序，及时发现隐式依赖——这一步如果不做，线上出问题后悔都来不及
总之，这套方案的精髓在于“最小化攻击面”：只动常量池里的敏感字符串，密钥硬隔离，加载时解密即焚。它不像全文件加密那样粗暴，也不像混淆那样脆弱，算得上是企业级运行时保护的一个务实选择。
