Unity APK 被反编译这个事做 Unity 的老哥应该都心知肚明辛辛苦苦改了三十几个版本、优化了十几轮的原生代码打包发出去不到一周网上连玩法拆解都出来了速度比自己团队迭代还快。早期做单机向 Unity 游戏的时候我也吃过这个亏APK 拖进反编译工具里代码逻辑清清楚楚连注释都还在那感觉就像自己写的源码白送了一样。后来踩过几次坑试过各种混淆、加壳和运行时保护方案才慢慢摸清楚这套防护体系的正确打开方式。这篇东西不整虚的直接把我在实际项目中用来防止反编译、阻止 APK 逆向破解的混淆加固与保护优化路子讲一遍。适用想保护自己 Unity 产品核心逻辑的开发者无论是休闲游戏还是工具应用这套思路都通用。1. 先搞清楚 Unity APK 的“肉”都藏在哪很多人一上来就找加壳工具结果壳加完发现核心逻辑还是在别人手里问题就在没搞清楚 Unity 打包出来的产物结构。Unity APK 不是所有代码都在 Java 层它比普通安卓应用复杂得多代码分散在好几个位置。1.1 APK 内部最常见的四个代码与资源区反编译的人拿到 APK 后第一件事就是解压他们会重点关注这几个地方classes.dexJava/Kotlin 层代码主要是 Unity 引擎的安卓桥接层、各种第三方推送/广告/登录 SDK 的代码以及你自己写的 Java 插件代码。这个文件恶意反编译工具直接拖进去就能转成可读的 jar。assets/bin/Data/Managed/Assembly-CSharp.dll如果你还停留在 Mono 脚本后端你的核心游戏逻辑就在这里。C# DLL 是可以直接反编译回接近源代码级别的东西ILSpy 一拖进来类名、方法名、字符串全在。lib/armeabi-v7a/libil2cpp.so 和 assets/bin/Data/Managed/Metadata/global-metadata.dat如果你用的是 IL2CPP 脚本后端游戏核心逻辑已经被编译成 native 的 so 文件但这不意味着安全。global-metadata.dat 这个文件包含了原始类名、方法名、字符串配合 Il2CppDumper 这类工具别人能像剥洋葱一样把 IL2CPP 还原回能看懂的伪代码。assets/AssetBundle 和 StreamingAssets 目录我没见过哪个 Unity 项目不打包资源的这里存放场景、预制体、贴图、文本配置、甚至部分 Lua/热更脚本。AssetBundle 不加密的话解压后直接改后缀就能用 Unity 打开看内部资源。1.2 为什么说 Unity 项目比原生安卓更容易被反编译原生安卓应用最少还有个 Java 层代码撑着反编译之后拿到的是 Smali 代码读起来恶心改逻辑也麻烦。但 Unity 的托管函数名、类名结构一目了然尤其 Mono 后端完全是 C# 元数据暴露的问题。哪怕切到 IL2CPPglobal-metadata.dat 仍会泄露大量可读信息。我见过不少开发者的误区以为只要不写注释、把变量名改成 a/b/c 就没关系。实际上 C# 编译器编译后元数据还是会把原始名称写进程序集改变量名只能骗骗同行骗不了反编译工具。真正有效的做法是要做到层级式防护托管层掩盖、native 层混淆、外围资源加密、运行时自校验。2. 混淆方案的分层设计别想着一个工具搞定一切好多人混淆就只知道一个 Obfuscar 或者一个混淆按钮实际上 Unity 的混淆是要分层的Java 层一套、C# 层一套、native 层一套、资源层一套各自解决各自区域的暴露问题。2.1 Java/Kotlin 层使用 ProGuard/R8 的注意事项Unity 本身不是你写 Java 的唯一地方你在 Android 工程里 Adapter 自己写的 Java 桥接类、接入的支付 SDK、统计 SDK 都在 classes.dex 里。这部分代码直接用 Android 自带的 ProGuard 或 R8 就能处理。开启 minifyEnabled true 后类名和方法名会被压缩合并同时加上混淆映射文件 proguard mapping.txt。但这里头有个坑Unity 的 Android 工程和常规工程有差异很多第三方 SDK 内部有反射或动态调用全局混淆容易翻车。我通常的做法是给 SDK 的包名单独配 keep 规则自己写的桥接类可以大胆混淆SDK 的类一个都不要动。比如-keep class com.example.mysdk.** { *; } -keepclassmembers class * extends com.unity3d.player.UnityPlayerActivity { ... }另外接入 Unity 时如果你的 UnityPlayerActivity 是启动入口不能混淆也不要移除否则启动闪退。实际操作里最好把 proguard-unity.txt 官方规则合入再叠加自定义规则。2.2 C# 托管层的混淆与绕过反射坑C# 层的混淆工具主要分三类社区开源的、商业一键型的、自己写 Roslyn 插件的。开源类Obfuscar能重命名类型和方法支持简单的字符串混淆但遇到反射调用经常崩。商业类某些商业混淆器会做控制流混淆和字符串加密还能窃取一些程序集合并防护强度更高。自己改造针对敏感算法自己把字符串拆成字节数组运行时拼接或者把关键方法改成 dynamic 调用让静态反编译工具拿不到直接证据。不过 C# 混淆最麻烦的不是“混淆不混淆”而是混淆后你的代码还跑不跑得动。Unity 引擎内部大量使用反射来调用 MonoBehaviour 的 Awake/Start/Update第三方 SDK 也会反射调用你的方法。直接全混淆新手最容易遇到的就是场景里脚本全部失灵或者行为异常。我的办法是给 MonoBehaviour 继承类、被任何 SDK 或编辑器代码引用的类型、序列化字段加上混淆排除规则。很多混淆器支持特性标签可以写[DoNotObfuscate]这样的注解或者配置排除列表。这个坑我在某跨平台项目上踩了很久后来凡是出现“混淆后功能消失”“UI 点击无效”之类的报错第一反应就是看反射调用链。2.3 IL2CPP 后端的“伪保护”与 metadata 混淆很多团队为了安全把脚本后端切到 IL2CPP以为万事大吉。其实最常见的手法是用 Il2CppDumper 配合全球公开的 Unity 版本把 so 和 global-metadata.dat 结合直接把游戏逻辑从 native 里还原出来。等于你用 C 写了一遍别人用工具又翻译回 C#。所以 IL2CPP 真正该做的是这么几件事对 global-metadata.dat 做整体加密运行时让 libil2cpp.so 在内存里解密后使用让 Dumper 拿不到匹配的 metadata。对 so 文件做指令抽取或加壳这个通常要借助专门的 Unity native 加固方案不是你自己几个宏能做到的。关键字母串打散存储常量不要直接写在代码里。我实测下来的结论是只切 IL2CPP 不加 metadata 加密防小白没问题遇到会玩 IDA 的师傅基本等于裸奔。加一层 metadata 加密之后攻击成本直接翻好几倍。3. 第三方加固方案实操记录从选型到上线讨论了原理实际操作上大多数人还是会选第三方加固服务因为自己实现 native 层保护的成本太高了。市面上常见的有加固服务都有我们直接用“某云端加固平台”这种代称来说。3.1 加固平台的处理流程与实际原理现在主流加固平台处理 Unity APK一般会做这些事DEX 加壳通过自定义类加载器动态解密原始 DEX所以你在安装包里直接看到的是壳 DEX。so 文件保护针对 libil2cpp.so 和 libunity.so 做加密或指令抽取启动时还原。资源防篡改对 assets 目录做完整性校验被改动过的包启动时报错。反调试与防模拟器这个看服务商可选功能里可以打开。流程上基本是上传 APK - 选加固级别 - 下载加固包 - 对加固包二次签名 - 真机测试。我用过一个平台的流程加固后 APK 体积大概增加 8% 到 15%启动时间增加 150 到 400ms这个代价完全可以接受。3.2 加固后签名与渠道包处理的经验加固包下载下来之后没有签名必须用你自己的签名证书重新签名。这里建议使用 apksigner 而不是旧的 jarsigner并且要确保签名方式和你在应用商店注册的签名一致否则更新安装会提示签名不一致。还有一个坑很多人容易忽略如果你多渠道打包使用了友盟之类带有渠道信息的 SDK加固之后再打渠道包时渠道信息可能会被后写入的渠道包逻辑覆盖掉。我踩过的是“加固后华为渠道包启动就崩溃”后来定位发现是渠道 SDK 的 Application 初始化顺序被加固平台改动。解决办法是在加固后设置里开启“兼容模式”或者把渠道 SDK 放进不加固名单。3.3 加固配套的自检与降级策略加固不是加完就结束上架后要密切关注线上崩溃率。很多加固服务会自带崩溃日志解析 SDK如果没有自己在 C# 层加一个 Application.logMessageReceived 钩子收集异常栈再做本地缓存。我给自己项目的标准流程是加固包先在自己工程机侧装运行 2 小时反复点击所有入口重点看支付回调、微信登录、推送跳转这几个反射重灾区。上线后 3 天盯崩溃率如果某类崩溃高于 0.3%立刻准备降级策略。降级就是把加固前的包重新签名直接发版先保证用户体验再回头排查加固到底哪里兼容没做好。4. 自己动手加保护层运行时校验与字符串加密实战光靠第三方加固还不够我习惯在工程内部再埋几道守护逻辑。这些逻辑是别人很难猜到的因为不随工具平台走是刻在产品里的“防盗刺”。4.1 签名校验的正确姿势写一个 C# 工具类在游戏启动的时候读取应用签名和本地预埋的正确签名做比对。不要只校验一次可以分散到各场景的初始化函数里防止别人 Hook 掉入口处的校验。public static string GetSignatures() { using (var player new AndroidJavaObject(android.content.ContextWrapper, context)) using (var pm player.CallAndroidJavaObject(getPackageManager)) { var packageName context.Callstring(getPackageName); var packageInfo pm.CallAndroidJavaObject(getPackageInfo, packageName, 0x40); var signatures packageInfo.GetFieldAndroidJavaObject(signatures); var signature signatures.CallAndroidJavaObject(get, 0); return signature.Callstring(toByteArray).GetType().Name; } }注意这里获取签名信息的方式在高版本 Android 上有限制建议通过 AndroidJavaClass 调用ApplicationInfo或使用 Native 层校验。真实项目里我一般会写成 native 的 C 接口通过 JNI 从 C# 调过去这样不容易被 Java 层 Hook 绕过。4.2 关键字符串加密与还原游戏里的敏感字符串比如服务端地址、加密密钥、URL 参数一定要加密存储。推荐方法是把字符串切割成多个片段每个片段独立存在运行时拼接。更进一步可以用简单的流加密写个小工具类在 C# 侧做public static string Decrypt(byte[] data, byte[] key) { byte[] result new byte[data.Length]; for (int i 0; i data.Length; i) result[i] (byte)(data[i] ^ key[i % key.Length]); return Encoding.UTF8.GetString(result); }这种异或解密虽然强度不高但已经能挡住大部分直接搜索字符串特征的人。更敏感的数据可以上 AES-GCM 方案注意密钥不要硬编码到代码里最好分散存储后运行时从不同位置提取再组合比如一半写在 Java 层、一半写在 Native 层。4.3 反调试与防内存 dump 的轻量实现检测到调试器就直接假退出或者让游戏陷入无限加载这种策略简单粗暴但非常有效。Unity 里可以用System.Diagnostics.Debugger.IsAttached判断但这个在 IL2CPP 下不是特别可靠还是要靠 native 层去读/proc/self/status里的 TracerPid。写一个 native 检测函数在游戏关键节点调用如果 TracerPid 不为 0说明正被调试器跟踪。内存 dump 攻击很难完全挡住毕竟 IL2CPP 运行时肯定要把 metadata 加载进内存。我能做的是把关键的全局变量打散或者给敏感业务逻辑加一层运行时原生函数计算重要判断条件不要全部放到 C# 变量里让内存搜索的难度增大。再配合周期性的完整性校验只要 so 文件或者 metadata 被修改就让游戏功能降级到不可用状态。5. 资源安全与 AssetBundle 加密的实操细节之前忽略资源层的保护结果美术资源被拿去盗用的教训太深刻了。AssetBundle 如果不加密几乎是送给别人的。我后来给所有核心资源都做了加密加载通道。5.1 AssetBundle 加密加载与自定义解密方案AssetBundle 的加密常见方案有两种全量 AES 加密打包出来整个资源文件加密加载时先解密再交给 Unity 加载。浅层扰动改文件头让标准工具无法直接打开。全量加密更安全但读取大资源时会增加解密耗时。实测一个 200MB 的 Bundle 用 AES 解密大概增加 300ms可以接受。加载代码大概是byte[] bytes File.ReadAllBytes(path); byte[] decrypted AESDecrypt(bytes, key, iv); AssetBundle bundle AssetBundle.LoadFromMemory(decrypted);注意 LoadFromMemory 会复制一遍内存频繁切换场景可能导致 GC 压力所以最好在后台线程解密只把最终的 AssetBundleCreateRequest 放到主线程。如果怕 AssetBundle 加密后无法热更新可以把热更资源单独拆包。服务端下发时下发密文客户端下载到本地解密缓存再走 AssetBundle.LoadFromFile 加载解密后的临时文件这样热更新照常运转。5.2 配置文件的编码混淆思路JSON 配置永远是信息泄露的大头。关卡数值、奖励表、概率表这些写在 StreamingAssets 里的明文 JSON别人一行 Python 就能读出来。我在项目里做了一个配置导出工具把 JSON 在打包前转成二进制格式再用自定义序列化器读取。二进制格式可以不采用标准 JSON 结构而是自定义字段索引配合上方异或解密。反编译者即使拿到文件也要先猜出格式定义。这里提醒一句不要用 Unity 的JsonUtility直接读二次加密的字符串因为内部反射机制会把字段名暴露进内存建议用ScriptableObject或者自定义BinaryReader读取数据。6. 常见问题排查与踩坑记录这部分都是真金白银换来的经验。混淆或加固之后十次崩溃里九次是以下这些原因。6.1 混淆后 UI 点击无响应或场景脚本失灵大概率是 MonoBehaviour 的类名被重命名导致 Unity 无法通过反射实例化。Unity 底层是通过类型名称加载脚本的如果混淆器把MainPlayerController改成了abc场景里挂载的脚本引用就断了。排查方法打开混淆器的日志文件看有哪些脚本被重命名将场景预制体里挂载的脚本全部加入排除名单。我一般是设一条规则凡是继承MonoBehaviour的类全部不重命名方法名可以混淆类名和字段名保持稳定。6.2 加固后启动黑屏或秒退如果加固后包启动就崩溃第一步先在本地看 Logcat 有没有ClassNotFound或者UnsatisfiedLinkError。ClassNotFound 多半是 DEX 加固壳把自己的类加载器遮蔽了需要在加固平台配置里把 Unity 的一些启动类加入不加固名单。UnsatisfiedLinkError 一般是 so 文件加壳后无法正常加载看看是不是 so 加固兼容性没打开或者换一个加固档位试。如果报的是verify失败可能是 DEX 里调用了高版本 API 但加固后运行环境不匹配这时把目标 API 调低或者开兼容模式。6.3 第三方反编译扫描仍能还原部分代码有次我加固完自己用反编译工具扫了一下发现 Il2CppDumper 依然能跑出大半函数名。排查下来是 metadata 没有做加密加固平台只保护了 so 本身。后来换了支持 Unity metadata 保护的方案再扫一遍就只剩一堆无意义的符号和地址了。一定要自己亲手验证加固效果别轻信服务商的宣传。6.4 加固导致应用商店审核与性能问题部分应用商店对加壳包有额外检测尤其是过度频繁的签名校验可能被当成风险行为。我在上架某个工具类应用时被提示原始包与加固包行为不一致最后是把签名校验做成了联网配置开关上架审核时默认关闭正式运营时再远程打开。性能上加固后 IL2CPP 的启动时间会变慢优化手段是把Application.targetFrameRate和资源预加载逻辑延后执行优先让首帧画面出来别让玩家盯白屏。另外开启后尽量把反调试检测的采样频率降低不要每帧检测改成每 3 秒一个异步调用。7. 最后再分享一点我的个人体会用了这么多方案我的总结是不要把安全寄托在单一工具上真正的保护是“多层叠加”的结果。加壳挡的是普通玩家字符串加密挡的是搜关键字的半吊子运行时自校验和反调试挡的是那群真正想破解的人。每加一层破解成本就翻倍成本高于收益自然就没人动你了。还有一点很重要混淆和加固方案要跟着 Unity 版本和 Android 版本持续更新不要一套配置用三年。系统安全机制每代都在变老方案很容易失效。我的习惯是每次升级引擎后都会拿最新加固包跑一遍完整攻击实验先自己打败自己再放线上。坚持这么做反编译这个事就不会再成为你的心头刺。
Unity APK 被反编译这个事做 Unity 的老哥应该都心知肚明辛辛苦苦改了三十几个版本、优化了十几轮的原生代码打包发出去不到一周网上连玩法拆解都出来了速度比自己团队迭代还快。早期做单机向 Unity 游戏的时候我也吃过这个亏APK 拖进反编译工具里代码逻辑清清楚楚连注释都还在那感觉就像自己写的源码白送了一样。后来踩过几次坑试过各种混淆、加壳和运行时保护方案才慢慢摸清楚这套防护体系的正确打开方式。这篇东西不整虚的直接把我在实际项目中用来防止反编译、阻止 APK 逆向破解的混淆加固与保护优化路子讲一遍。适用想保护自己 Unity 产品核心逻辑的开发者无论是休闲游戏还是工具应用这套思路都通用。1. 先搞清楚 Unity APK 的“肉”都藏在哪很多人一上来就找加壳工具结果壳加完发现核心逻辑还是在别人手里问题就在没搞清楚 Unity 打包出来的产物结构。Unity APK 不是所有代码都在 Java 层它比普通安卓应用复杂得多代码分散在好几个位置。1.1 APK 内部最常见的四个代码与资源区反编译的人拿到 APK 后第一件事就是解压他们会重点关注这几个地方classes.dexJava/Kotlin 层代码主要是 Unity 引擎的安卓桥接层、各种第三方推送/广告/登录 SDK 的代码以及你自己写的 Java 插件代码。这个文件恶意反编译工具直接拖进去就能转成可读的 jar。assets/bin/Data/Managed/Assembly-CSharp.dll如果你还停留在 Mono 脚本后端你的核心游戏逻辑就在这里。C# DLL 是可以直接反编译回接近源代码级别的东西ILSpy 一拖进来类名、方法名、字符串全在。lib/armeabi-v7a/libil2cpp.so 和 assets/bin/Data/Managed/Metadata/global-metadata.dat如果你用的是 IL2CPP 脚本后端游戏核心逻辑已经被编译成 native 的 so 文件但这不意味着安全。global-metadata.dat 这个文件包含了原始类名、方法名、字符串配合 Il2CppDumper 这类工具别人能像剥洋葱一样把 IL2CPP 还原回能看懂的伪代码。assets/AssetBundle 和 StreamingAssets 目录我没见过哪个 Unity 项目不打包资源的这里存放场景、预制体、贴图、文本配置、甚至部分 Lua/热更脚本。AssetBundle 不加密的话解压后直接改后缀就能用 Unity 打开看内部资源。1.2 为什么说 Unity 项目比原生安卓更容易被反编译原生安卓应用最少还有个 Java 层代码撑着反编译之后拿到的是 Smali 代码读起来恶心改逻辑也麻烦。但 Unity 的托管函数名、类名结构一目了然尤其 Mono 后端完全是 C# 元数据暴露的问题。哪怕切到 IL2CPPglobal-metadata.dat 仍会泄露大量可读信息。我见过不少开发者的误区以为只要不写注释、把变量名改成 a/b/c 就没关系。实际上 C# 编译器编译后元数据还是会把原始名称写进程序集改变量名只能骗骗同行骗不了反编译工具。真正有效的做法是要做到层级式防护托管层掩盖、native 层混淆、外围资源加密、运行时自校验。2. 混淆方案的分层设计别想着一个工具搞定一切好多人混淆就只知道一个 Obfuscar 或者一个混淆按钮实际上 Unity 的混淆是要分层的Java 层一套、C# 层一套、native 层一套、资源层一套各自解决各自区域的暴露问题。2.1 Java/Kotlin 层使用 ProGuard/R8 的注意事项Unity 本身不是你写 Java 的唯一地方你在 Android 工程里 Adapter 自己写的 Java 桥接类、接入的支付 SDK、统计 SDK 都在 classes.dex 里。这部分代码直接用 Android 自带的 ProGuard 或 R8 就能处理。开启 minifyEnabled true 后类名和方法名会被压缩合并同时加上混淆映射文件 proguard mapping.txt。但这里头有个坑Unity 的 Android 工程和常规工程有差异很多第三方 SDK 内部有反射或动态调用全局混淆容易翻车。我通常的做法是给 SDK 的包名单独配 keep 规则自己写的桥接类可以大胆混淆SDK 的类一个都不要动。比如-keep class com.example.mysdk.** { *; } -keepclassmembers class * extends com.unity3d.player.UnityPlayerActivity { ... }另外接入 Unity 时如果你的 UnityPlayerActivity 是启动入口不能混淆也不要移除否则启动闪退。实际操作里最好把 proguard-unity.txt 官方规则合入再叠加自定义规则。2.2 C# 托管层的混淆与绕过反射坑C# 层的混淆工具主要分三类社区开源的、商业一键型的、自己写 Roslyn 插件的。开源类Obfuscar能重命名类型和方法支持简单的字符串混淆但遇到反射调用经常崩。商业类某些商业混淆器会做控制流混淆和字符串加密还能窃取一些程序集合并防护强度更高。自己改造针对敏感算法自己把字符串拆成字节数组运行时拼接或者把关键方法改成 dynamic 调用让静态反编译工具拿不到直接证据。不过 C# 混淆最麻烦的不是“混淆不混淆”而是混淆后你的代码还跑不跑得动。Unity 引擎内部大量使用反射来调用 MonoBehaviour 的 Awake/Start/Update第三方 SDK 也会反射调用你的方法。直接全混淆新手最容易遇到的就是场景里脚本全部失灵或者行为异常。我的办法是给 MonoBehaviour 继承类、被任何 SDK 或编辑器代码引用的类型、序列化字段加上混淆排除规则。很多混淆器支持特性标签可以写[DoNotObfuscate]这样的注解或者配置排除列表。这个坑我在某跨平台项目上踩了很久后来凡是出现“混淆后功能消失”“UI 点击无效”之类的报错第一反应就是看反射调用链。2.3 IL2CPP 后端的“伪保护”与 metadata 混淆很多团队为了安全把脚本后端切到 IL2CPP以为万事大吉。其实最常见的手法是用 Il2CppDumper 配合全球公开的 Unity 版本把 so 和 global-metadata.dat 结合直接把游戏逻辑从 native 里还原出来。等于你用 C 写了一遍别人用工具又翻译回 C#。所以 IL2CPP 真正该做的是这么几件事对 global-metadata.dat 做整体加密运行时让 libil2cpp.so 在内存里解密后使用让 Dumper 拿不到匹配的 metadata。对 so 文件做指令抽取或加壳这个通常要借助专门的 Unity native 加固方案不是你自己几个宏能做到的。关键字母串打散存储常量不要直接写在代码里。我实测下来的结论是只切 IL2CPP 不加 metadata 加密防小白没问题遇到会玩 IDA 的师傅基本等于裸奔。加一层 metadata 加密之后攻击成本直接翻好几倍。3. 第三方加固方案实操记录从选型到上线讨论了原理实际操作上大多数人还是会选第三方加固服务因为自己实现 native 层保护的成本太高了。市面上常见的有加固服务都有我们直接用“某云端加固平台”这种代称来说。3.1 加固平台的处理流程与实际原理现在主流加固平台处理 Unity APK一般会做这些事DEX 加壳通过自定义类加载器动态解密原始 DEX所以你在安装包里直接看到的是壳 DEX。so 文件保护针对 libil2cpp.so 和 libunity.so 做加密或指令抽取启动时还原。资源防篡改对 assets 目录做完整性校验被改动过的包启动时报错。反调试与防模拟器这个看服务商可选功能里可以打开。流程上基本是上传 APK - 选加固级别 - 下载加固包 - 对加固包二次签名 - 真机测试。我用过一个平台的流程加固后 APK 体积大概增加 8% 到 15%启动时间增加 150 到 400ms这个代价完全可以接受。3.2 加固后签名与渠道包处理的经验加固包下载下来之后没有签名必须用你自己的签名证书重新签名。这里建议使用 apksigner 而不是旧的 jarsigner并且要确保签名方式和你在应用商店注册的签名一致否则更新安装会提示签名不一致。还有一个坑很多人容易忽略如果你多渠道打包使用了友盟之类带有渠道信息的 SDK加固之后再打渠道包时渠道信息可能会被后写入的渠道包逻辑覆盖掉。我踩过的是“加固后华为渠道包启动就崩溃”后来定位发现是渠道 SDK 的 Application 初始化顺序被加固平台改动。解决办法是在加固后设置里开启“兼容模式”或者把渠道 SDK 放进不加固名单。3.3 加固配套的自检与降级策略加固不是加完就结束上架后要密切关注线上崩溃率。很多加固服务会自带崩溃日志解析 SDK如果没有自己在 C# 层加一个 Application.logMessageReceived 钩子收集异常栈再做本地缓存。我给自己项目的标准流程是加固包先在自己工程机侧装运行 2 小时反复点击所有入口重点看支付回调、微信登录、推送跳转这几个反射重灾区。上线后 3 天盯崩溃率如果某类崩溃高于 0.3%立刻准备降级策略。降级就是把加固前的包重新签名直接发版先保证用户体验再回头排查加固到底哪里兼容没做好。4. 自己动手加保护层运行时校验与字符串加密实战光靠第三方加固还不够我习惯在工程内部再埋几道守护逻辑。这些逻辑是别人很难猜到的因为不随工具平台走是刻在产品里的“防盗刺”。4.1 签名校验的正确姿势写一个 C# 工具类在游戏启动的时候读取应用签名和本地预埋的正确签名做比对。不要只校验一次可以分散到各场景的初始化函数里防止别人 Hook 掉入口处的校验。public static string GetSignatures() { using (var player new AndroidJavaObject(android.content.ContextWrapper, context)) using (var pm player.CallAndroidJavaObject(getPackageManager)) { var packageName context.Callstring(getPackageName); var packageInfo pm.CallAndroidJavaObject(getPackageInfo, packageName, 0x40); var signatures packageInfo.GetFieldAndroidJavaObject(signatures); var signature signatures.CallAndroidJavaObject(get, 0); return signature.Callstring(toByteArray).GetType().Name; } }注意这里获取签名信息的方式在高版本 Android 上有限制建议通过 AndroidJavaClass 调用ApplicationInfo或使用 Native 层校验。真实项目里我一般会写成 native 的 C 接口通过 JNI 从 C# 调过去这样不容易被 Java 层 Hook 绕过。4.2 关键字符串加密与还原游戏里的敏感字符串比如服务端地址、加密密钥、URL 参数一定要加密存储。推荐方法是把字符串切割成多个片段每个片段独立存在运行时拼接。更进一步可以用简单的流加密写个小工具类在 C# 侧做public static string Decrypt(byte[] data, byte[] key) { byte[] result new byte[data.Length]; for (int i 0; i data.Length; i) result[i] (byte)(data[i] ^ key[i % key.Length]); return Encoding.UTF8.GetString(result); }这种异或解密虽然强度不高但已经能挡住大部分直接搜索字符串特征的人。更敏感的数据可以上 AES-GCM 方案注意密钥不要硬编码到代码里最好分散存储后运行时从不同位置提取再组合比如一半写在 Java 层、一半写在 Native 层。4.3 反调试与防内存 dump 的轻量实现检测到调试器就直接假退出或者让游戏陷入无限加载这种策略简单粗暴但非常有效。Unity 里可以用System.Diagnostics.Debugger.IsAttached判断但这个在 IL2CPP 下不是特别可靠还是要靠 native 层去读/proc/self/status里的 TracerPid。写一个 native 检测函数在游戏关键节点调用如果 TracerPid 不为 0说明正被调试器跟踪。内存 dump 攻击很难完全挡住毕竟 IL2CPP 运行时肯定要把 metadata 加载进内存。我能做的是把关键的全局变量打散或者给敏感业务逻辑加一层运行时原生函数计算重要判断条件不要全部放到 C# 变量里让内存搜索的难度增大。再配合周期性的完整性校验只要 so 文件或者 metadata 被修改就让游戏功能降级到不可用状态。5. 资源安全与 AssetBundle 加密的实操细节之前忽略资源层的保护结果美术资源被拿去盗用的教训太深刻了。AssetBundle 如果不加密几乎是送给别人的。我后来给所有核心资源都做了加密加载通道。5.1 AssetBundle 加密加载与自定义解密方案AssetBundle 的加密常见方案有两种全量 AES 加密打包出来整个资源文件加密加载时先解密再交给 Unity 加载。浅层扰动改文件头让标准工具无法直接打开。全量加密更安全但读取大资源时会增加解密耗时。实测一个 200MB 的 Bundle 用 AES 解密大概增加 300ms可以接受。加载代码大概是byte[] bytes File.ReadAllBytes(path); byte[] decrypted AESDecrypt(bytes, key, iv); AssetBundle bundle AssetBundle.LoadFromMemory(decrypted);注意 LoadFromMemory 会复制一遍内存频繁切换场景可能导致 GC 压力所以最好在后台线程解密只把最终的 AssetBundleCreateRequest 放到主线程。如果怕 AssetBundle 加密后无法热更新可以把热更资源单独拆包。服务端下发时下发密文客户端下载到本地解密缓存再走 AssetBundle.LoadFromFile 加载解密后的临时文件这样热更新照常运转。5.2 配置文件的编码混淆思路JSON 配置永远是信息泄露的大头。关卡数值、奖励表、概率表这些写在 StreamingAssets 里的明文 JSON别人一行 Python 就能读出来。我在项目里做了一个配置导出工具把 JSON 在打包前转成二进制格式再用自定义序列化器读取。二进制格式可以不采用标准 JSON 结构而是自定义字段索引配合上方异或解密。反编译者即使拿到文件也要先猜出格式定义。这里提醒一句不要用 Unity 的JsonUtility直接读二次加密的字符串因为内部反射机制会把字段名暴露进内存建议用ScriptableObject或者自定义BinaryReader读取数据。6. 常见问题排查与踩坑记录这部分都是真金白银换来的经验。混淆或加固之后十次崩溃里九次是以下这些原因。6.1 混淆后 UI 点击无响应或场景脚本失灵大概率是 MonoBehaviour 的类名被重命名导致 Unity 无法通过反射实例化。Unity 底层是通过类型名称加载脚本的如果混淆器把MainPlayerController改成了abc场景里挂载的脚本引用就断了。排查方法打开混淆器的日志文件看有哪些脚本被重命名将场景预制体里挂载的脚本全部加入排除名单。我一般是设一条规则凡是继承MonoBehaviour的类全部不重命名方法名可以混淆类名和字段名保持稳定。6.2 加固后启动黑屏或秒退如果加固后包启动就崩溃第一步先在本地看 Logcat 有没有ClassNotFound或者UnsatisfiedLinkError。ClassNotFound 多半是 DEX 加固壳把自己的类加载器遮蔽了需要在加固平台配置里把 Unity 的一些启动类加入不加固名单。UnsatisfiedLinkError 一般是 so 文件加壳后无法正常加载看看是不是 so 加固兼容性没打开或者换一个加固档位试。如果报的是verify失败可能是 DEX 里调用了高版本 API 但加固后运行环境不匹配这时把目标 API 调低或者开兼容模式。6.3 第三方反编译扫描仍能还原部分代码有次我加固完自己用反编译工具扫了一下发现 Il2CppDumper 依然能跑出大半函数名。排查下来是 metadata 没有做加密加固平台只保护了 so 本身。后来换了支持 Unity metadata 保护的方案再扫一遍就只剩一堆无意义的符号和地址了。一定要自己亲手验证加固效果别轻信服务商的宣传。6.4 加固导致应用商店审核与性能问题部分应用商店对加壳包有额外检测尤其是过度频繁的签名校验可能被当成风险行为。我在上架某个工具类应用时被提示原始包与加固包行为不一致最后是把签名校验做成了联网配置开关上架审核时默认关闭正式运营时再远程打开。性能上加固后 IL2CPP 的启动时间会变慢优化手段是把Application.targetFrameRate和资源预加载逻辑延后执行优先让首帧画面出来别让玩家盯白屏。另外开启后尽量把反调试检测的采样频率降低不要每帧检测改成每 3 秒一个异步调用。7. 最后再分享一点我的个人体会用了这么多方案我的总结是不要把安全寄托在单一工具上真正的保护是“多层叠加”的结果。加壳挡的是普通玩家字符串加密挡的是搜关键字的半吊子运行时自校验和反调试挡的是那群真正想破解的人。每加一层破解成本就翻倍成本高于收益自然就没人动你了。还有一点很重要混淆和加固方案要跟着 Unity 版本和 Android 版本持续更新不要一套配置用三年。系统安全机制每代都在变老方案很容易失效。我的习惯是每次升级引擎后都会拿最新加固包跑一遍完整攻击实验先自己打败自己再放线上。坚持这么做反编译这个事就不会再成为你的心头刺。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
