模块模式通过封装边界、内存控制与调用限制提升反编译难度：用Pimpl/接口隔离实现、动态派生密钥、安全内存管理、禁用调试接口，并将核心算法移至JNI层强化防护。
模块模式本身不能“防止反编译”，但它能显著提升反编译后代码的不可读性、不可用性和不可复用性——关键在于把核心加密逻辑从可被静态分析的字节码中剥离出来，并切断外部对敏感状态的直接访问路径。真正起作用的不是“模块”这个容器，而是模块内部如何设计封装边界、控制内存生命周期、限制调用上下文。
用不透明句柄替代公开结构体
避免在头文件或接口定义中暴露密钥缓冲区、状态数组、轮密钥表等原始数据布局。对外只提供抽象操作句柄：
- C++中采用Pimpl惯用法：头文件仅声明
class AESEncryptor;，完整实现（含uint8_t round_keys[240]）严格限定在.cpp内；外部无法sizeof、无法offsetof、无法做指针算术 - Java/Android中不导出
EncryptorImpl类，而返回interface Encryptor实例，其真实类型由模块私有包限定，反射也无法获取具体类名 - Spring Boot中将加解密服务定义为
@Service但不标注@Primary，并通过ApplicationContext.getBean("aesService", Encryptor.class)间接获取，避免被组件扫描自动注入
让密钥永远不以明文形式驻留内存
静态初始化密钥或从配置文件硬编码加载，等于把钥匙挂在门上。模块应拒绝这种做法：
- 首次调用
encrypt()时才派生密钥：用PBKDF2+用户口令，或通过JNI调用TPM/HSM获取会话密钥 - 密钥分配使用
mmap(MAP_ANONYMOUS|MAP_PRIVATE, PROT_READ|PROT_WRITE)，后续立即mprotect(..., PROT_READ)禁写，防止被core dump捕获 - 每次运算结束后，对栈上临时密钥副本调用
explicit_bzero()（C/C++）、Arrays.fill()（Java）或SecureZeroMemory()（Windows），不依赖GC延迟清理
切断标准类加载与调试通道
反编译工具如JADX、Arthas之所以有效，是因为它们依赖JVM开放的元数据和调试接口。模块需主动干预这些通道：
- 自定义
ClassLoader重写findClass()，仅加载本模块签名验证通过的类，拒绝defineClass()被外部反射调用 - 启动参数添加
-XX:+DisableAttachMechanism禁用attachAPI，阻止Arthas、JStack等动态注入 - 运行时检测
ManagementFactory.getRuntimeMXBean().getInputArguments()是否含-agentlib或-javaagent，发现即退出 - 关键方法内嵌
if (Thread.currentThread().getStackTrace().length > 10)校验调用深度，防反射绕过
把最敏感部分移出JVM执行环境
再强的Java混淆也挡不住内存dump。真正防得住的，是让攻击者根本拿不到明文字节码：
- 将AES轮函数、RSA模幂、国密SM4的F函数等核心计算逻辑用C/C++编写，通过JNI暴露极简接口（如
jbyteArray nativeEncrypt(jbyteArray input)） - NDK编译时启用
-fPIE -fstack-protector-strong -D_FORTIFY_SOURCE=2，并关闭符号表：arm-linux-androideabi-strip --strip-unneeded libcrypto.so - Android中配合
android:debuggable="false"和android:vmSafeMode="true"，并在Native层调用prctl(PR_SET_DUMPABLE, 0)禁止进程内存转储
