14、DexGuard实战：金融类App加固案例、游戏App加固案例
好，咱们今天聊点硬核的。DexGuard 这东西，说白了就是 ProGuard 的超级加强版。普通 ProGuard 能做的，它都能做；ProGuard 做不了的，它也能做。我这些年经手过不少金融和游戏类的 App，这两类应用在加固上的诉求其实差别挺大的。金融 App 更看重数据安全和防篡改，游戏 App 则更在意防破解和反外挂。今天我就拿两个真实案例，带大家走一遍 DexGuard 的实战流程。
核心观点：DexGuard 不是简单的“开关一开就完事”，它需要根据业务场景做精细化配置。金融和游戏，就是两个截然不同的配置模板。
14.1 金融类App加固案例：某银行理财App
先说说金融类的。我记得去年帮一家城商行加固他们的理财 App，对方提了几个硬性要求：第一，不能被人用反编译工具直接看到核心的加密算法；第二，关键 API 调用不能被 hook；第三，即使被 root 了，也要能检测出来并阻止运行。
嗯，这些要求其实挺典型的。DexGuard 在这方面有天然优势，因为它内置了字符串加密、反射调用保护、以及反调试功能。我们来看看具体怎么配。
14.1.1 核心配置：字符串与类名加密
金融 App 里最敏感的是什么？是那些硬编码的密钥、API 地址、还有加密算法的类名。这些东西一旦暴露，整个安全体系就形同虚设了。
我个人的习惯是，先把所有敏感字符串用 DexGuard 的 -encryptstrings 指令保护起来。比如这样：
-encryptstrings class com.example.bank.crypto.AESUtils {
public static final java.lang.String KEY;
public static final java.lang.String IV;
}
-encryptstrings class com.example.bank.network.ApiConstants {
public static final java.lang.String BASE_URL;
public static final java.lang.String TOKEN;
}这样配置之后，反编译出来的代码里，这些字符串会变成一堆乱码。只有在运行时才会被动态解密。我曾经见过一个没做字符串加密的金融 App，攻击者直接用 strings 命令就把数据库密码给扒出来了——那画面太美我不敢看。
另外，类名混淆也要做到极致。DexGuard 默认的混淆策略会把类名改成 a、b、c 这种，但金融 App 我建议用 -classobfuscationdictionary 指定一个自定义字典，让类名看起来像正常的业务类名，迷惑攻击者。
-classobfuscationdictionary classdict.txt
# classdict.txt 内容示例：
# PaymentManager
# UserValidator
# DataSyncHelper你想想看，攻击者看到一堆看似正常的类名，但实际上全是混淆后的假类，这种“钓鱼”效果比纯字母混淆好得多。
14.1.2 反调试与反Hook配置
金融 App 最怕什么？怕被人在运行时动态调试。DexGuard 提供了 -dontdebug 和 -checkdebug 指令，可以检测调试器是否附加。如果检测到调试器，直接让 App 闪退或者进入假数据模式。
我建议再加一层 -assumenosideeffects，把调试日志全部干掉。很多开发者习惯在代码里写 Log.d，上线前忘了删，结果被攻击者利用日志信息定位关键逻辑。
-assumenosideeffects class android.util.Log {
public static int d(...);
public static int v(...);
public static int i(...);
}这里有个坑，我曾经遇到过：用了 -assumenosideeffects 之后，某些第三方 SDK 的日志也被干掉了，导致 SDK 初始化失败。所以建议只针对自己的包名做日志清除，不要全局生效。
注意：反调试配置不是万能的。攻击者可以通过修改 framework 层代码绕过检测。所以 DexGuard 的反调试只能作为第一道防线，不能完全依赖它。
14.1.3 资源加密与完整性校验
金融 App 的 assets 目录下经常会有一些配置文件、证书文件。这些文件如果直接打包进 APK，等于白送。DexGuard 支持对 assets 和 res 目录下的文件进行加密，运行时动态解密。
-encryptassets assets/certificates/
-encryptassets assets/config/同时，我还会开启 APK 完整性校验。DexGuard 会在运行时计算 APK 的签名哈希，跟预埋的值做对比。如果发现被重打包，直接拒绝运行。
-checkapksignature com.example.bank这个功能在金融 App 里几乎是必开的。因为一旦 App 被二次打包，攻击者可以植入恶意代码，窃取用户的账户信息。嗯，这里要提醒一下：签名校验的代码本身也要做保护，否则攻击者可以直接 patch 掉校验逻辑。
14.2 游戏App加固案例：某卡牌手游
好，聊完金融，咱们看看游戏。游戏 App 的加固思路跟金融完全不同。游戏最怕的是被破解、被修改内存、被注入外挂。我去年帮一家游戏公司加固他们的卡牌手游，对方的核心诉求是：不能让玩家通过修改内存来刷金币、刷卡牌。
14.2.1 核心逻辑的VMP保护
游戏的核心逻辑，比如战斗计算、抽卡概率、金币增减，这些代码一旦被逆向分析出来，整个游戏的平衡性就崩了。DexGuard 的 VMP（虚拟机保护）功能，可以把这些关键方法编译成自定义的字节码，在运行时由 DexGuard 内置的虚拟机解释执行。
配置起来很简单，只需要在 proguard 配置里加上：
-keepclassmembers class com.example.game.core.BattleEngine {
native <methods>;
}
-keep class com.example.game.core.BattleEngine { *; }
# 开启VMP保护
-vmprotect class com.example.game.core.BattleEngine {
public int calculateDamage(...);
public boolean isCriticalHit(...);
}这样配置之后，calculateDamage 和 isCriticalHit 这两个方法会被 VMP 保护起来。反编译出来的代码里，这两个方法会变成一堆无法理解的字节码。攻击者即使拿到了源码，也看不懂逻辑。
我个人建议，VMP 保护不要滥用。只保护那些最核心、最容易被攻击的方法。因为 VMP 会带来一定的性能开销，如果全量保护，游戏帧率可能会受影响。我之前有个项目，就是因为 VMP 保护了太多方法，导致战斗场景卡顿严重，后来不得不回退了一部分。
14.2.2 内存修改与加速器检测
游戏外挂最常见的手段是什么？内存修改和加速器。DexGuard 提供了 -detectmemorymodification 和 -detectspeedhack 指令，可以检测这些行为。
-detectmemorymodification
-detectmemorymodificationaction exit
-detectectspeedhack
-detectectspeedhackaction exit检测到内存修改或加速器后，可以配置不同的响应动作：exit 是直接退出，report 是上报服务器，fake 是返回假数据。我比较推荐用 fake 模式，让外挂玩家以为自己成功了，但实际上游戏逻辑已经进入了“假数据”分支。这样攻击者很难判断自己的外挂是否生效，增加了他们的调试成本。
小技巧：在游戏里埋一些“蜜罐”变量。比如一个金币变量，正常逻辑下永远不会用到，但外挂玩家如果修改了这个变量，DexGuard 就能检测到异常。我曾经用这个方法抓到了不少外挂作者。
14.2.3 资源文件与Unity脚本保护
很多手游是用 Unity 开发的，DexGuard 对 Unity 有专门的支持。它可以加密 Unity 的 global-metadata.dat 文件，防止攻击者用 Il2CppDumper 之类的工具导出游戏脚本。
-encryptunitymetadata另外，游戏里的资源文件，比如图片、音效、配置文件，也容易被提取。DexGuard 支持对 assets 目录下的文件进行 AES 加密，运行时动态解密。
-encryptassets assets/raw/
-encryptassets assets/bin/Data/这里要注意的是，加密后的资源文件在加载时会有性能损耗。所以建议只加密那些核心资源，比如卡牌数据、战斗特效配置，不要加密所有图片和音效。
14.3 金融与游戏加固对比总结
说了这么多，咱们来做个对比。金融和游戏在加固上的侧重点完全不同，我整理了一个表格，方便大家参考：
| 加固维度 | 金融App | 游戏App |
|---|---|---|
| 核心目标 | 数据安全、防篡改 | 防破解、反外挂 |
| 字符串加密 | 必须，保护密钥和API地址 | 可选，保护关键配置 |
| VMP保护 | 可选，保护加密算法 | 强烈推荐，保护战斗和抽卡逻辑 |
| 反调试 | 必须，防止动态分析 | 可选，防止外挂调试 |
| 内存修改检测 | 可选 | 必须，防止刷金币 |
| 资源加密 | 必须，保护证书和配置文件 | 可选，保护核心资源 |
| 签名校验 | 必须，防止二次打包 | 建议开启，防止盗版 |
你看，同样是 DexGuard，配置策略可以天差地别。所以我不建议直接拿一套配置模板到处套用。一定要根据你的业务场景，想清楚“我要防谁”、“我要防什么”，然后再去配置对应的加固策略。
14.4 本章知识体系
最后，我用一张图来总结本章的核心逻辑。这张图展示了金融和游戏两类 App 在 DexGuard 加固上的不同路径和关键节点。
嗯，这张图把金融和游戏两条路径梳理得很清楚了。你可以看到，金融 App 的加固点集中在数据层和通信层，而游戏 App 则更关注逻辑层和运行时安全。两者有重叠的地方，但侧重点完全不同。
好了，今天的实战案例就分享到这里。DexGuard 的功能远不止这些，但掌握了金融和游戏这两个典型场景的配置思路，其他类型的 App 你也能举一反三。记住，加固不是一劳永逸的事，攻击者的技术在不断进步，我们的防护策略也要持续迭代。