镜像加密是将可执行代码以“运行时动态解密+内存加载”方式封装为类镜像结构，不落盘明文，仅内存解密执行，阻断静态反编译；核心为校验→解密→注入三步，需叠加内存防dump、签名校验、反调试等运行时保护。
镜像加密不是指对 Docker 镜像或系统镜像做简单打包加密，而是特指将可执行代码（如 Java 字节码、Python 脚本、SO 库）以“运行时动态解密+内存加载”方式封装成类镜像结构——即代码不以明文形式落盘，只在内存中解密执行。这种方式能有效阻断静态反编译工具（如 Jadx、JD-GUI、uncompyle6）的直接解析路径。
镜像加密的核心逻辑
本质是把代码变成“带壳的镜像文件”，运行时由自定义加载器完成三步操作：校验 → 解密 → 注入内存执行。整个过程不生成可被提取的 .class/.pyc 文件，规避了传统反编译依赖的静态字节码输入源。
- 代码不再以标准格式（如 .jar、.pyc）直接部署，而是打包为加密二进制 blob（如 .img、.dat），外观类似资源文件
- 启动时通过轻量级 loader（Java 中用自定义 ClassLoader，Python 中用 import hook）读取 blob，校验签名后 AES 解密
- 解密后的字节码不写入磁盘，直接 defineClass 或 exec(compile(...)) 加载进 JVM/Python VM
- 关键算法模块（如跳距计算、模型推理）可单独镜像化，与主逻辑隔离，降低暴露面
适用于不同语言的镜像加密实践
不是所有语言都原生支持，但可通过适配层实现：
- Java/Spring Boot：用自定义 ClassLoader + AES-256 加密 .class 数据块。推荐结合 R8 混淆后再镜像化，避免解密逻辑本身被逆向。Spring Boot 启动类需重写 SpringApplication.run()，插入 loader 初始化流程
- Python（如 wechat_jump_game）：将核心脚本（wechat_jump_auto_ai.py）编译为字节码，再用 PyInstaller 的 --key 参数或自研 loader 加密为 .dat 文件。运行时通过 importlib.util.spec_from_loader 动态加载，跳过 .pyc 缓存
- Android APK：不直接加密 dex，而是将关键 so 库或 Java 算法逻辑提前 native 化（JNI），再对 so 文件做 VMP 加固 + 镜像加载（如使用 dlopen + mmap 内存解密）。Jadx 无法解析未落地的 so 行为
必须配套的防护措施
单靠镜像加密不够，攻击者可能通过内存 dump 获取解密后代码。需叠加运行时保护：
- 内存防 dump：在解密后立即调用 mprotect(MPROTECT_WRITE) 锁定内存页，或使用 JNI 在 native 层分配不可读写内存（仅执行）
- 完整性校验：loader 启动时校验自身及镜像文件 SHA256，失败则退出；可嵌入签名校验（如 ECDSA），防止镜像被替换
- 反调试检测：检查 ptrace、/proc/self/status、TracerPid 等，发现调试器则清空内存并终止进程
- 环境可信判断：集成 ROOT 检测、模拟器指纹识别（如 Build.FINGERPRINT）、设备绑定（MAC/IMEI 绑定），非授权环境拒绝加载镜像
企业级落地注意事项
镜像加密会带来少量性能开销和运维复杂度，需权衡使用粒度：
- 优先加密 P0 级资产（如支付风控规则、AI 推理核心、通信协议加解密逻辑），而非全量代码
- 避免在 loader 中硬编码密钥，应通过安全元件（SE）、TEE 或服务端动态下发密钥种子
- 构建自动化流水线：源码提交 → 混淆 → 编译 → 镜像加密 → 签名 → 发布，全程无人工干预
- 保留 debug 模式开关（如环境变量 DEBUG=1），方便内部测试，但生产包默认关闭且不可绕过
