1. 资源泄露到底在防谁先认清三类攻击者和三条攻击路径YooAsset 2.2.12 的四层加密架构是我在跨平台资源安全这个方向上折腾了大半年才最终定型的方案。说句实话最初我以为给资源包套个 AES 就万事大吉结果被解包工具当场教做人——用 AssetStudio 打开打包产物三秒钟把整个图集导了出来那个场面相当尴尬。后来我才意识到资源安全这件事没有银弹只有一层一层把攻击者的成本堆上去堆到偷你的资源不如自己画为止。做加密之前你必须先搞清楚在防谁。我接触过的游戏项目里资源泄露的威胁大致分三类第一类是解包党说白了就是美术扒手。他们不关心你的代码逻辑只想把立绘、模型、动画、UI 素材一键导出。工具链已经非常成熟AssetStudio、AssetRipper、UnityPy拖进去就能看根本不需要懂技术。这类人的诉求是成本足够低只要你加密后他导不出来了他就走了。第二类是外挂与作弊者。他们会反编译你的热更代码改配置、改数值、做透视、写自动战斗。这类人攻击的不只是资源而是你的游戏逻辑和平衡性。他们需要的往往不是漂亮的模型而是数值表和热更脚本。挡这类人光加密资源文件不够还要防清单篡改和运行时注入。第三类是灰产与竞品。他们把你的资源二次打包换个 UI 就是新游戏或者拆出你的关卡设计、数值配置、付费点设计去抄。这类人最难防因为他们可能会花钱花时间跟你的加密硬刚唯一的办法就是让破解成本高于收益。对应这三类攻击者实际攻击路径也就三条静态解包拿到安装包或热更目录直接解析 AssetBundle 文件。动态注入运行游戏把解密后的 bundle 从内存里 dump 出来或者 hook 解密函数。密钥提取反编译客户端程序从二进制里找出 AES 密钥或解密逻辑然后离线批量解密所有文件。这三条路径必须分别堵。只做一层静态加密攻击者走第二条路直接绕过去了只做密钥混淆他走第一条路也能绕过去。所以我才把架构拆成了四层每层负责挡一条具体的攻击路径。2. 四层加密总览每层挡在哪条攻击路径上这四层分别是静态文件加密层、偏移混淆与流解密层、密钥分离与清单签名层、运行时完整性校验层。它们的职责边界非常清晰我列在下面这张表里方便你对照自己的项目情况做取舍。层级主要阻挡目标YooAsset 2.2.12 扩展点核心手段L1 静态文件加密静态解包工具IEncryptionServices / IDecryptionServicesAES-256 全文件加密L2 偏移混淆与流解密自动化工具直接加载GetFileOffset / LoadAssetBundleJunk Header 文件头伪装L3 密钥分离与清单签名密钥提取、清单篡改、版本回滚自定义启动流程 Manifest 校验密钥动态派生 RSA/HMAC 签名L4 运行时完整性校验内存注入、热更包劫持下载验证 自建抽检逻辑Hash 抽检 关键数据自检为什么不能只做一层我见过不少项目只做了一层全文件 AES密钥写死在代码里结果攻击者反编译后用 DnSpy 搜一下 byte 数组密钥直接出来了整个加密形同虚设。单层加密的致命问题在于一旦密钥泄露前面所有加密瞬间归零。四层架构的思路是纵深防御每一层独立作战攻击者至少要同时突破两到三层才能拿到干净资源。另外强调一个原则每一层加密都是有成本的。加载耗时、内存峰值、包体大小、开发维护成本都会往上走。所以四层不是所有项目都需要的配置后面我会专门讲怎么根据项目类型取舍。先搞清楚每层怎么实现再来决定用几层。3. L1 落地YooAsset 2.2.12 内置加密服务的完整接入第一层是地基做法也最直接在构建阶段用IEncryptionServices把每个 AssetBundle 文件做 AES-256 加密运行时通过IDecryptionServices解密后交给 Unity 加载。YooAsset 2.2.12 把这两个接口留了出来我们只需要实现对应逻辑。3.1 构建侧实现 IEncryptionServices先看构建侧的加密服务实现。YooAsset 在构建资源时会遍历每个 bundle调用IEncryptionServices.Encrypt方法我们把读写文件、执行 AES 加密的逻辑写在这里public class BundleEncryption : IEncryptionServices { public void Encrypt(EncryptFileInfo fileInfo, EncryptResult result) { // 读取原始 AssetBundle 文件 byte[] rawData File.ReadAllBytes(fileInfo.FilePath); // 使用统一的密钥做 AES-256 加密 byte[] encryptedData AESUtil.Encrypt(rawData, KeyProvider.GetKey()); result.EncryptedData encryptedData; result.LoadMethod EncryptLoadMethod.LoadFromStream; } }EncryptResult.LoadMethod这个枚举需要特别留意它决定了运行时 Unity 以什么方式加载这个 bundle直接影响性能和内存LoadFromFile对应偏移加载Unity 走AssetBundle.LoadFromFile(path, crc, offset)性能最优但只支持加密头部区域的方案也就是 L2 的做法。LoadFromStream对应流加载运行时先解密出完整的明文流Unity 从流中读取内存开销中等。LoadFromMemory对应内存加载运行时把整个解密后的 byte 数组交给 Unity内存开销最高。对于第一层我通常建议小 bundle 用LoadFromMemory大 bundle 用LoadFromStream。实际项目中一个几百 MB 的包如果全部走内存加载移动端很容易爆内存。构建侧的设置代码大致是这样var buildParam new BuildParameters(); buildParam.EncryptionServices new BundleEncryption(); // ... 其他构建参数 BuildPipeline.BuildAssetBundles(buildParam);注意EncryptionServices是在构建参数里注入的构建完成后 YooAsset 会把这些加密文件连同清单一起写入输出目录。这里有个很容易忽略的细节加密发生在 bundle 文件生成之后、写入输出目录之前所以如果你在构建后对输出目录做二次检查看到的不再是标准 UnityFS 文件头这是正常的。3.2 运行时侧实现 IDecryptionServices运行时YooAsset 初始化时会通过IDecryptionServices决定如何读取这些加密文件。三个方法分别对应三种加载方式public class BundleDecryption : IDecryptionServices { public ulong GetFileOffset(DecryptFileInfo fileInfo) { return 0; // L1 全文件加密场景下不使用偏移 } public AssetBundle LoadAssetBundle(DecryptFileInfo fileInfo, out Stream managedStream) { byte[] encryptedData File.ReadAllBytes(fileInfo.FilePath); byte[] rawData AESUtil.Decrypt(encryptedData, KeyProvider.GetKey()); managedStream new MemoryStream(rawData); return null; // 返回 nullYooAsset 会从 managedStream 创建 AssetBundle } public byte[] ReadFileData(DecryptFileInfo fileInfo) { byte[] encryptedData File.ReadAllBytes(fileInfo.FilePath); return AESUtil.Decrypt(encryptedData, KeyProvider.GetKey()); } }这里有个关键逻辑要说清楚LoadAssetBundle返回null并输出一个解密后的MemoryStreamYooAsset 内部会调用AssetBundle.LoadFromStream。根据构建时设定的LoadMethod运行时只会调用对应的方法其他方法不会被触发。所以三个方法都实现好但具体走哪个取决于构建侧的LoadFromStream还是LoadFromMemory。初始化时把解密服务挂在初始化参数上var initParams new HostPlayModeParameters(); initParams.BuildinQueryServices new GameBuildinQueryServices(); initParams.RemoteServices new GameRemoteServices(); initParams.DecryptionServices new BundleDecryption(); var package YooAssets.GetPackage(GamePackage); package.InitializeAsync(initParams);3.3 第一层为什么不够第一层跑通之后你手上有了一套完整的文件加密 运行时解密的链路静态解包工具直接打不开了。但这时候还远不能说安全因为你把密钥写死在客户端里了。攻击者多花半小时用 DnSpy 或者 IDA 找到密钥所有 bundle 就能离线批量解密。AssetStudio 的确废了但他可以写个脚本把密钥填进去一键还原。所以第一层只解决了最懒的攻击者接下来要做的是让自动化工具直接哑火以及让密钥不那么容易被扒出来。4. L2 落地偏移混淆与魔数伪装让解包工具直接哑火第二层做的事情有两件给文件加随机头部做偏移混淆以及把文件头伪装成其他格式。这一层的目标不是挡住专业逆向工程师而是把市面上 90% 的自动化解包工具拦在门外。4.1 Junk Header 偏移方案原理非常简单在原始 bundle 文件前面追加一段随机垃圾数据让真正的 bundle 整体后移。Unity 加载时通过 offset 参数跳过垃圾头部直接定位到真正的 bundle 起始位置。实现上构建侧改成这样private const int JUNK_HEADER_LEN 4096; private const int HEADER_ENCRYPT_LEN 1024; public void Encrypt(EncryptFileInfo fileInfo, EncryptResult result) { byte[] rawData File.ReadAllBytes(fileInfo.FilePath); // 创建 垃圾头部 原始数据 的新文件 byte[] wrapper new byte[JUNK_HEADER_LEN rawData.Length]; // 填充随机垃圾数据同时对开头写入伪装魔数让工具误以为文件是 PNG/ZIP 等格式 FillFakeHeader(wrapper, JUNK_HEADER_LEN); // 把真实 bundle 整体后移 Array.Copy(rawData, 0, wrapper, JUNK_HEADER_LEN, rawData.Length); // 对前 HEADER_ENCRYPT_LEN 字节做 AES 加密防止攻击者分析头部结构 byte[] encryptedHeader AESUtil.Encrypt(wrapper, 0, HEADER_ENCRYPT_LEN, KeyProvider.GetKey()); Array.Copy(encryptedHeader, 0, wrapper, 0, HEADER_ENCRYPT_LEN); result.EncryptedData wrapper; result.LoadMethod EncryptLoadMethod.LoadFromFile; }这里LoadMethod改成了LoadFromFile因为我们要用 Unity 原生支持的 offset 参数跳过垃圾头部。运行时侧要对应实现GetFileOffsetpublic ulong GetFileOffset(DecryptFileInfo fileInfo) { // 建议在这里先做一次魔数校验确认文件确实是本产品加密过的 VerifyMagic(fileInfo.FilePath); return JUNK_HEADER_LEN; }Unity 的AssetBundle.LoadFromFile(path, crc, offset)会从 offset 处开始解析 bundle垃圾头部完全不会被读取。JUNK_HEADER_LEN我建议至少 4096 字节原因有两个一是 4KB 对齐在大多数平台的文件系统中表现更稳定二是很多解包工具在判断文件类型时会读文件头的前几个字节随机垃圾能让它们直接判定未知格式。4.2 魔数伪装与运行时校验Junk Header 不只用来填充垃圾我还会把文件头伪装成其他常见格式。最简单的做法文件头 8 字节写入 PNG 的魔数89 50 4E 47 0D 0A 1A 0A解包工具看到这个头就按 PNG 去解析解析失败直接跳过。当然如果你不想伪装成图片伪装成 ZIP、PDF、自定义私有格式都可以目的是增加人工分析时辨认文件类型的成本。同时在文件尾部的某个固定位置写入一个真实魔数比如 16 字节的随机序列运行时在GetFileOffset里先校验魔数确认这个文件确实是自己的加密产物。这样做还有一个额外好处如果热更包下载到的是一个被替换的未加密 bundle或者缓存目录被清掉重来运行时能第一时间发现异常不至于用错误的 offset 去加载一个错误的文件导致崩溃。4.3 为什么 AssetStudio 这类工具会直接哑火AssetStudio 和 AssetRipper 在解析 bundle 时第一步都是读文件头判断 UnityFS 版本、数据偏移等信息。加了 Junk Header 之后真实 UnityFS 头的起始位置移动到了第 4096 字节而这些工具默认从第 0 字节开始读解析到的是一段随机垃圾要么直接报错要么导出空资源。这就达到了工具哑火的效果——攻击者想用现成工具一键扒资源的路被堵死了。但要说清楚L2 挡不住会写脚本的开发者。他只要从你程序里找到JUNK_HEADER_LEN这个常量把它减掉再解析就行了。所以 L2 真正的价值在于让那些不会逆向的普通解包党放弃让愿意研究的攻击者多付出时间。这个时间成本在后面的 L3、L4 里会被进一步放大。5. L3 落地密钥分离与清单签名守住更新链路第三层要解决的是两个最容易被忽视的问题密钥怎么藏以及清单怎么防篡改。这两个问题如果不处理前面的加密全是白做。5.1 密钥不落盘拆段 动态派生把 16 字节或 32 字节的 AES 密钥直接写成一个byte[]变量是我见过最常见的低级错误。DnSpy 打开 DLL搜索字节数组密钥就躺在那里。正确做法是让密钥在代码里不存在。我的做法是把密钥拆成多段分散在不同程序集的不同静态类里程序启动时通过拼接和异或运算动态拼装public static class KeyProvider { private static byte[] _key; public static byte[] GetKey() { if (_key null) { byte[] segment1 BuildinKeys.Segment1; // 分散在多个类中 byte[] segment2 BuildinKeys.Segment2; byte[] deviceSeed GetDeviceRelatedSeed(); _key DeriveKey(segment1, segment2, deviceSeed); } return _key; } private static byte[] DeriveKey(byte[] s1, byte[] s2, byte[] seed) { // 用 XOR 位移 固定盐 做一层派生 // 实际工程中建议直接用 Rfc2898DeriveBytes (PBKDF2) using (var deriveBytes new Rfc2898DeriveBytes(Combine(s1, s2), seed, 10000)) { return deriveBytes.GetBytes(32); } } }拆段的意义在于攻击者从单点找不到完整密钥他必须同时找到所有片段并且理解拼接逻辑。配合 IL2CPP 转 C 和代码混淆从汇编层面还原这个密钥组装过程的成本会高很多。还要注意一个工程细节密钥要支持轮换。你不可能一辈子用同一把密钥。我的做法是密钥带版本号第一层加密时把密钥版本写在文件的末尾附加区域运行时先读版本号再选择对应的密钥来解密。这样一旦密钥泄露只需要在服务器端配置新的密钥版本客户端热更后自动切换到新密钥旧资源包在后台重新加密。5.2 清单签名的必要性YooAsset 的清单文件PackageManifest.hash、PackageManifest.json、PackageManifest.bytes记录了所有 bundle 的 CRC、大小、依赖关系和版本号。YooAsset 自带的 hash 校验只能防止文件在传输过程中损坏防不了恶意篡改。设想一个攻击场景某个版本你修复了一个严重的经济系统漏洞但攻击者手里还有旧版的清单和旧版 bundle他劫持了更新通道让你的客户端以为旧版才是最新版从而回滚到一个可利用的版本。这就是版本回滚攻击。避免回滚攻击的办法是给清单做签名。服务器用私钥对清单内容签名客户端内置公钥每次拿到清单先验签再使用public class ManifestVerifier { private static readonly byte[] PublicKeyBlob new byte[] { /* 内置客户端中的公钥 */ }; public static bool Verify(byte[] manifestContent, byte[] signature) { using (var rsa System.Security.Cryptography.RSA.Create()) { rsa.ImportSubjectPublicKeyInfo(PublicKeyBlob, out _); return rsa.VerifyData(manifestContent, signature, System.Security.Cryptography.HashAlgorithmName.SHA256, System.Security.Cryptography.RSASignaturePadding.Pkcs1); } } }签名验证逻辑需要放在初始化流程里在package.InitializeAsync()之前拿到远端清单先验签、再确认版本号大于等于当前版本然后才允许进入后续的资源初始化。这样就同时堵住了清单篡改和版本回滚两条路。5.3 运行时密钥与打包机密钥的一致性一个我在项目里反复踩的坑打包机的密钥和客户端的密钥不一致。原因是构建配置里IEncryptionServices用的是开发环境的密钥常量但客户端代码里KeyProvider是另一套值上线后所有资源加载全部失败。后来我做了构建时校验构建完所有 bundle 后随机抽几个文件用客户端的密钥试解密解不开直接让构建失败。这一步建议做进 CI 流程。6. L4 落地运行时完整性校验与热更包防劫持前三层都是在文件层面做文章第四层把战场转移到运行时。因为攻击者到了这个阶段已经放弃静态分析了他会在游戏运行过程中下手hook 解密函数、dump 内存、替换热更包。6.1 热更包下载验证要开到最大YooAsset 的下载模块提供了验证等级设置从低到高依次是不验证、验证大小、验证 CRC、验证 Hash。默认配置往往只验证大小这在安全要求高的项目里是不够的。我建议在初始化时把验证等级设成最高var initParams new HostPlayModeParameters(); // 下载验证等级校验 Hash initParams.DownloadVerifyLevel DownloadVerifyLevel.VerifyHash;这条设置的意义在于热更包下载完成后系统会用清单里的 hash 去比对本地文件不一致就判定下载失败并重新下载。攻击者如果劫持了下载通道塞给你一个篡改过的 bundle这一关会直接拦下来。这条配置的成本几乎为零但很多人根本不设置。6.2 抽检机制不拖性能的完整性自检启动时对全部 bundle 做一遍 hash 校验小项目还行大项目动辄几百个 bundle、几个 GB 数据全量 hash 会把启动时间拖到几十秒完全不可接受。我的方案是抽检。具体做法启动后每隔一段时间随机抽取少量 bundle 做 hash 比对与清单中的记录比对。如果发现不匹配说明文件被篡改或缓存损坏立即触发重新下载并上报日志。核心代码大致是这样public IEnumerator RuntimeSpotCheck(ResourcePackage package) { var assets package.GetAllAssets(); if (assets null || assets.Count 0) yield break; int sampleCount Mathf.Max(1, assets.Count / 20); for (int i 0; i sampleCount; i) { string bundleName assets[Random.Range(0, assets.Count)].BundleName; string localPath package.GetBundleLocalPath(bundleName); if (!CheckLocalHash(localPath, GetExpectedHash(bundleName))) { // 记录异常、触发重新下载、上报服务器 ReportIntegrityViolation(bundleName); } yield return null; // 分帧执行避免卡顿 } }抽检比例 5% 左右分帧执行对帧率的影响几乎感知不到。同时我建议把抽检结果上报到自己的日志服务端积累一段时间后可以看到是否有攻击者在尝试替换文件为后续的安全决策提供数据。6.3 内存中解密后的保护L4 还有一个隐蔽的战场内存。当 bundle 通过LoadFromStream加载时解密后的明文流会出现在托管堆里攻击者 dump 内存就能拿到。完全避免这个问题的思路是让明文不落托管堆——但 Unity 的AssetBundle.LoadFromStream还是会把流复制到原生侧你无法完全控制。实际项目里我更推荐的是降低内存暴露面非必要不用全文件解密能走 offset 的就走 offset这样明文数据不会被完整读出来。而对那些必须全文件解密的关键资源比如加密的配置文件解密完立刻置空引用、清理内存流不让敏感数据长时间驻留。6.4 作弊检测的边界第四层还可以叠加作弊检测检测Debug.isDebugBuild是否为真、检测时间缩放是否异常SpeedHack、检测关键程序的集是否被反射注入。但这里要提醒一句检测逻辑的边界必须把握清楚。误报会直接伤害正常玩家体验我见过一个项目因为检测太激进把开省电模式的玩家误判成作弊引起大量投诉。所以检测归检测发现异常先上报、先警告不要立刻封号等证据链完整再处理。7. 跨平台适配差异与性能实测数据YooAsset 的核心优势之一就是跨平台但加密方案的跨平台坑非常多。同样一份资源包Windows 上跑得好好的到了 Android 可能崩溃到了 WebGL 可能内存爆炸。我把自己实测过的平台差异整理一下。平台文件 IO 特性推荐加载方式关键注意点Windows/macOS本地磁盘快LoadFromFile offset性能损耗几乎为 0注意程序集保护Android内置存储/缓存内置包建议 offset热更包可 Stream注意 offset 对齐StreamingAssets 读取路径iOS沙盒机制offset 或 Stream 均可越狱设备文件保护失效可用 NSFileProtectionWebGL无文件系统只能 Memory/Stream内存翻倍风险建议降级为 1~2 层加密7.1 Android 平台的三个坑第一个坑是 offset 对齐。AssetBundle.LoadFromFile(path, crc, offset)的 offset 参数在 Android 上不是任意值都能用实测部分机型对非对齐的 offset 会直接加载失败或崩溃。我的做法是把 JUNK_HEADER_LEN 定为 4096并额外封装一层对齐工具函数保证任何平台都按 1024 字节对齐。第二个坑是 StreamingAssets 的打包方式。Android 上内置资源会打包进 APK/AAB运行时 YooAsset 会把它们视为 buildin 资源解密服务同样会生效。如果全文件 AES每次启动都要从压缩包里读取再解密启动时间会明显增加。所以内置包体我强烈建议用 offset 模式可以直接 mapping 加载不需要额外拷贝和解密。第三个坑是缓存目录残留。热更包在应用沙盒缓存目录里如果上一个版本用的密钥和当前版本不一致缓存目录里的旧文件可能解密失败。这个我在踩坑部分会细说解决方案是给密钥加版本号并在缓存目录名里带上版本号避免新旧文件混用。7.2 WebGL 的降级策略WebGL 平台没有文件系统YooAsset 会走 WebPlayMode资源加载全部在内存中进行。此时如果你还做全文件 AES MemoryStream 解密内存会非常难看加密数据一份、解密明文一份、Unity 内部再一份。实测一个 100MB 的包体在 WebGL 上会额外吃掉 150MB 以上的内存很多低配机器直接白屏。我的做法是 WebGL 平台单独走一套构建配置只保留第一层静态加密和第三层清单签名关闭 offset 混淆和运行时抽检。Web 端的资源安全本来就薄弱与其硬上四层把性能拖垮不如把重点放在代码混淆和服务器侧的数据保护上。7.3 性能实测参考不同层级的性能开销我拿一个 300MB 资源规模的中型项目跑过一组对比数据测试机为 Android 中端机方案冷启动加载耗时内存峰值增量包体增量不加密4.2s00L1 全文件 AES LoadFromStream11.6s90MB0.2%L1 L2 offset 混淆4.5s8MB0.3%L1 L2 L3 签名5.1s10MB0.4%完整四层6.3s30MB0.6%可以看到offset 模式L2的性能代价非常小几乎可以忽略。真正拖慢速度的是全文件 AES 流加载因为它要把整个文件读出来解密。所以我最终的推荐组合是内置资源用 offset 混淆热更资源按需决定是否全文件加密清单永远签名抽检永远保留。8. 踩坑实录五个差点让我上不了线的加密事故这部分是我最想分享的因为每一段都是真金白银换来的教训。四层加密架构看似清晰实际落地时每一步都有埋伏。8.1 密钥写死在同一个程序集里最早做第一层的时候图省事把 AES 密钥直接写在EncryptionService.cs里和加密逻辑放同一个程序集。后来一个朋友用 DnSpy 打开我做的测试包在搜索栏输入byte[]三秒钟就把密钥找了出来然后写了个 Python 脚本把所有 bundle 恢复了。那个过程让我意识到加密服务的代码和密钥必须分离并且要配合 IL2CPP 代码混淆使用。现在我的做法是密钥拆段分布在多个程序集主逻辑程序集只保留派生函数。8.2 全文件 AES 后移动端内存暴涨第一次上线内测时资源全部走全文件 AES LoadFromStream。结果中端 Android 机在进入战斗场景时频繁闪退logcat 里全是 OOM。原因就是解密流、AssetBundle 原生副本、纹理解码内存叠在一起峰值轻松超过 1GB。后来我把所有图集和场景 bundle 改成 offset 模式只有配置类小文件才用全文件加密内存立刻降了下来。这个教训的核心是加密方案要和资源类型挂钩不能一刀切。8.3 offset 对齐问题导致部分机型崩溃某次灰度测试反馈集中在几款老型号 Android 机上加载特定场景必崩。排查了很久发现是 JUNK_HEADER_LEN 当时设置成了 3000不是 16 的倍数Unity 在部分设备上对未对齐的 offset 处理失败。改成 4096 之后问题消失。Unity 官方文档其实有提到 offset 的对齐要求但没说得很显眼这个坑很容易踩。8.4 热更缓存残留旧版本文件一次版本更新改了密钥结果大量玩家更新后卡在加载界面。查了半天发现是缓存目录里还有旧版本下载的 bundle版本号变了但缓存文件没清掉解密服务用新密钥去解旧文件直接把流抛异常。从那之后我做了两件事一是密钥版本号进缓存目录名二是解密失败时先删缓存再重新下载而不是直接报错。8.5 WebGL 平台忘记降级我把四层架构直接搬到了 WebGL 版结果 QA 一测Chrome 内存直接干到 2GB页面白屏。后来在构建脚本里加了平台判断WebGL 自动切换为静态 AES 清单签名的精简方案去掉 offset 混淆和运行时抽检。架构分层设计时就要考虑到平台差异化而不是做完了再打补丁。9. 加密的层级取舍小项目用两层竞技项目上四层最后说说我个人的取舍建议因为不是所有项目都需要四层全上。单机向、内容敏感性不高的项目休闲、超休闲、工具类两层足够。第一层静态文件加密挡住普通解包党第二层偏移混淆挡住工具党。密钥可以拆段但不做复杂的动态派生省下的开发时间远比那点安全增益值钱。联网的、有内购有数值的项目建议三层。在两层基础上加上清单签名和防回滚因为这类项目被攻击的收益主要来自篡改数值和做外挂清单签名能挡住最基础的篡改路径。竞技类、强对抗类、有排行有 PvP 的项目四层全上。这类项目的作弊收益最高攻击者愿意投入成本你需要把所有路径都堵一遍并且持续监控异常。我在实际项目里的体会是加密不是一锤子买卖而是一个持续对抗的过程。四层架构上线不代表一劳永逸你需要关注攻击者的新手法、定期轮换密钥、持续收集异常上报。资源安全的本质是让破解成本高于破解收益当攻击者发现你的资源加密让他花的时间远超直接雇人画一套的时候这套架构的目的就达到了。
