1. 从“软件白嫖”说起为什么期限控制是独立开发者的必修课做Unity独立开发或者接外包项目的朋友大概率都遇到过这种糟心事辛辛苦苦开发了几个月的软件交付给客户尾款还没结清对方已经把软件拷走到处用了或者做了一个工具类App想搞个“试用七天满意付费”的模式结果发现Unity打包出来的程序根本没有内置的授权管理机制谁拿到exe都能无限期跑下去。这不是技术难题而是一个产品设计层面的刚需。Unity本身是一个游戏引擎它的强项在渲染、物理、动画这些表现层的东西对于软件授权、使用期限、机器绑定这类“商业逻辑”引擎层面几乎没有提供任何开箱即用的方案。所以每一个想把Unity作品当成商品来卖的开发者迟早都要面对同一个问题怎么给软件加一把靠谱的锁。我前后做过好几个带授权控制的Unity项目从最简单的“首次运行起算30天”到稍微复杂一点的“绑定设备联网校验离线宽限期”踩过的坑不算少。这篇文章就把我实际用过、验证过的几套方案完整拆开讲一遍从最基础的本地时间戳方案到加密存储、防篡改、防时间回拨再到设备指纹绑定和离线授权文件的设计。不管你是刚接触Unity的新手还是已经做过几个商业项目的老手应该都能从中找到可以直接抄作业的部分。提醒一句本文讨论的所有技术方案仅用于保护你自己开发的软件产品的合法权益请勿用于任何违反法律法规或侵犯他人权益的场景。2. 本地期限控制的最小可行方案从PlayerPrefs到加密文件2.1 为什么PlayerPrefs是“纸糊的锁”很多教程一上来就教你用PlayerPrefs存一个首次运行时间然后每次启动对比当前时间。代码大概长这样// 不推荐的做法 if (!PlayerPrefs.HasKey(FirstRunTime)) { PlayerPrefs.SetString(FirstRunTime, System.DateTime.Now.ToString()); PlayerPrefs.Save(); } DateTime firstRun System.DateTime.Parse(PlayerPrefs.GetString(FirstRunTime)); if ((System.DateTime.Now - firstRun).TotalDays 30) { Application.Quit(); }这段代码能跑但基本等于没锁。原因有三第一PlayerPrefs在Windows上就是注册表里的一个键值对路径固定在HKCU\Software\公司名\产品名下面任何人打开注册表编辑器就能看到、能改、能删。第二时间字符串是明文的用户把系统时间往回调30天你的判断直接失效。第三就算用户不主动破解重装系统或者换一台电脑PlayerPrefs清空试用期又重新开始。所以PlayerPrefs方案只适合一种场景你压根不在乎被破解只是想给诚实用户一个“到期提醒”。但凡涉及真实付费这个方案必须升级。2.2 加密存储的实操把时间戳藏进二进制文件升级的第一步是把数据从注册表挪到一个自定义的加密文件里。我的做法是在Application.persistentDataPath下面生成一个二进制授权文件结构大致是文件头魔数 加密后的时间戳 校验码。具体实现上我一般用一个简单的对称加密比如AES密钥不直接写在代码里而是拆成几段、经过一次异或运算后再拼起来。这样做不能防住铁了心逆向的人但能挡住99%的普通用户——他们看到一堆乱码文件不知道里面存的是什么也就无从改起。// 授权文件写入的核心逻辑简化示意 using System.Security.Cryptography; using System.Text; public static class LicenseStorage { private static readonly byte[] KeyPart1 { 0x2A, 0x5F, 0x11, 0x8C }; private static readonly byte[] KeyPart2 { 0x73, 0xE2, 0x4B, 0x9D }; private static byte[] GetKey() { byte[] key new byte[KeyPart1.Length KeyPart2.Length]; for (int i 0; i KeyPart1.Length; i) { key[i] (byte)(KeyPart1[i] ^ KeyPart2[i]); } // 补齐到16字节实际项目会用更完整的密钥派生 return key; } public static void WriteLicense(string path, DateTime firstRun) { string raw firstRun.Ticks.ToString(); byte[] encrypted Encrypt(Encoding.UTF8.GetBytes(raw), GetKey()); // 前面加4字节魔数后面加4字节校验 byte[] magic { 0x4C, 0x49, 0x43, 0x01 }; byte[] checksum ComputeChecksum(encrypted); byte[] final new byte[magic.Length encrypted.Length checksum.Length]; Buffer.BlockCopy(magic, 0, final, 0, magic.Length); Buffer.BlockCopy(encrypted, 0, final, magic.Length, encrypted.Length); Buffer.BlockCopy(checksum, 0, final, magic.Length encrypted.Length, checksum.Length); System.IO.File.WriteAllBytes(path, final); } }这里有几个细节值得展开说。魔数的作用是快速判断文件是否被替换或损坏如果读出来的前四个字节对不上直接判定授权文件无效。校验码我用的是对加密数据做一次简单的哈希读取时重新计算并比对防止有人手动改文件里的字节。密钥拆分和异或运算的目的是避免在反编译工具里直接搜到完整的密钥字符串——虽然专业逆向人员还是能找到但门槛已经抬高了不少。2.3 时间回拨的检测与应对加密存储解决了“改文件”的问题但“改系统时间”这个漏洞还在。用户把系统时钟调回到试用期内你的程序读到的DateTime.Now就是假的。应对时间回拨我试过三种思路各有优劣第一种是记录“上次运行时间”每次启动时对比当前时间和上次记录的时间。如果当前时间比上次还早说明用户回拨了时钟直接判定异常。这个方法的局限在于用户如果每次都在试用期内来回切换时间或者干脆断网离线操作检测效果会打折扣。第二种是联网获取标准时间。程序启动时请求一个时间服务接口拿到网络时间后和本地时间对比。如果两者偏差超过阈值比如24小时就认为本地时间不可信。这个方案最可靠但要求软件必须联网对于纯离线工具类软件不适用。第三种是混合方案联网时以网络时间为准并记录离线时用“上次运行时间累计运行时长”来推算。我目前商业项目里用得最多的就是这种既保证了联网环境下的强校验又给离线场景留了合理的宽限期。// 时间回拨检测的简化逻辑 public static bool IsTimeTampered(DateTime lastRecorded, DateTime current) { // 当前时间比上次记录还早明显异常 if (current lastRecorded.AddMinutes(-5)) return true; // 如果本地时间和网络时间偏差过大 if (HasNetworkTime Math.Abs((NetworkTime - current).TotalHours) 24) return true; return false; }注意时间回拨检测不要做得太激进。有些用户只是系统时区设置有问题或者笔记本电池没电导致BIOS时间重置这些都属于正常情况。我的经验是给一个合理的容差范围比如前后5分钟到24小时不等超过范围才判定异常避免误伤正常用户。3. 设备绑定让授权文件“认机器”3.1 设备指纹的采集与稳定性权衡光有期限控制还不够如果用户把整个软件文件夹拷到另一台电脑上授权文件跟着一起过去照样能用。所以下一步是让授权和特定设备绑定。设备指纹的采集在Unity里没有统一API需要针对不同平台分别处理。Windows上我一般组合这几个信息主板序列号、CPU ID、硬盘序列号、网卡MAC地址。但这里有个坑——不是所有字段都能稳定获取有些虚拟机环境或者精简版系统里WMI查询会返回空值或者抛异常。我的做法是采集多个维度的信息然后做一个加权哈希。比如主板序列号权重最高MAC地址权重最低即使某一项获取失败整体指纹仍然能保持相对稳定。同时要避免使用会频繁变化的字段比如IP地址、内存使用量这些绝对不能进指纹。// Windows平台设备指纹采集示意 using System.Management; public static string GetDeviceFingerprint() { StringBuilder sb new StringBuilder(); try { // 主板序列号 using (var searcher new ManagementObjectSearcher(SELECT SerialNumber FROM Win32_BaseBoard)) { foreach (var obj in searcher.Get()) sb.Append(obj[SerialNumber]?.ToString() ?? NA); } // CPU ID using (var searcher new ManagementObjectSearcher(SELECT ProcessorId FROM Win32_Processor)) { foreach (var obj in searcher.Get()) sb.Append(obj[ProcessorId]?.ToString() ?? NA); } } catch { /* 采集失败时降级处理 */ } // 对拼接结果做哈希输出固定长度字符串 return ComputeHash(sb.ToString()); }3.2 指纹哈希与授权文件的绑定逻辑采集到指纹后不要直接把原始信息写进授权文件——那样等于把用户的硬件信息暴露了。正确做法是对指纹做一次哈希比如SHA256只存储哈希值。授权文件里同时保存这个哈希和期限信息程序启动时重新采集指纹、计算哈希和文件里的值比对。这里有个设计决策是“一机一码”还是“一码多机”一机一码最严格但用户体验差换个电脑就得重新申请。我一般给客户留一个“设备迁移”的余地——允许授权文件在检测到硬件变化时通过联网验证的方式重新绑定但限制迁移次数比如一年内最多3次。这样既保护了开发者利益又不至于让正常换设备的用户太难受。3.3 虚拟机与多系统的特殊情况处理实测下来虚拟机环境是设备绑定最容易出问题的地方。VMware和VirtualBox默认生成的硬件信息很多是重复的如果你只靠MAC地址做指纹很可能出现“一台机器授权所有克隆虚拟机都能用”的情况。我的应对策略是检测到虚拟机环境时额外采集虚拟机特有的标识比如VMware的BIOS UUID并且对虚拟机授权单独设置更短的期限或者更严格的联网校验频率。另外双系统用户同一台电脑装了Windows和Linux的指纹会完全不同这个要在用户协议里提前说明避免售后纠纷。4. 离线授权文件的设计让用户“带着授权走”4.1 授权文件的格式设计对于不能联网的软件离线授权文件是主流方案。用户在一台联网机器上生成请求码开发者用私钥签名后返回一个授权文件用户把文件放到指定目录即可激活。授权文件我一般用JSON格式可读性好方便排查问题。核心字段包括授权类型试用/正式/永久、到期时间、设备指纹哈希、签发时间、签名值。签名值是用非对称加密比如RSA对前面所有字段的内容做签名程序里内置公钥进行验签。这样即使有人改了JSON里的到期时间签名对不上授权直接失效。{ licenseType: professional, expireDate: 2026-12-31T23:59:59, deviceHash: a3f5c8..., issueDate: 2025-01-15T10:30:00, signature: Base64EncodedSignatureString... }4.2 非对称加密在Unity中的落地Unity支持的.NET版本对RSA的支持是完整的但要注意一点RSACryptoServiceProvider在部分平台比如IL2CPP编译后的iOS上可能不可用需要改用RSA.Create()配合ImportParameters的方式。我在实际项目里踩过这个坑Windows编辑器里跑得好好的打包到移动端就报错排查了半天才发现是API兼容性问题。验签的核心逻辑是把JSON里除signature之外的所有字段按固定顺序拼接成字符串用公钥验证签名。拼接顺序一定要固定不能依赖JSON序列化库的字段顺序否则不同版本序列化出来的字符串不一样验签必然失败。public static bool VerifyLicense(string json, string publicKeyXml) { var dict ParseJsonToDict(json); string signContent dict[licenseType] | dict[expireDate] | dict[deviceHash] | dict[issueDate]; byte[] signature Convert.FromBase64String(dict[signature]); using (var rsa RSA.Create()) { rsa.FromXmlString(publicKeyXml); return rsa.VerifyData( Encoding.UTF8.GetBytes(signContent), signature, HashAlgorithmName.SHA256, RSASignaturePadding.Pkcs1); } }4.3 离线宽限期与心跳机制纯离线授权有个天然缺陷开发者无法知道用户是否在到期后继续使用。我的做法是加一个“宽限期”设计——授权到期后程序不立即停止而是进入一个受限模式比如功能阉割、每次启动弹提醒给用户7到15天的缓冲期去续费。这样既不会让用户觉得太粗暴也给开发者留了催付的窗口。另外即使是离线软件我也会在程序里埋一个“心跳记录”每次启动时把当前时间写到一个隐藏的日志文件里。如果检测到日志里的时间出现倒退或者日志文件被删除就触发一次联网校验请求如果网络可用的话。这个机制不能完全防住破解但能大幅提高破解成本。5. 防逆向与代码混淆把锁做得再隐蔽一点5.1 Unity代码被反编译的现实用dnSpy或者ILSpy打开一个没做任何保护的Unity打包程序C#代码几乎是一览无余的。你的授权判断逻辑、密钥、校验流程全部以近乎源码的形式暴露在逆向者面前。我见过最夸张的情况是有人直接把if (IsExpired()) Application.Quit();这一行删掉软件就永久可用了。所以加密和混淆不是可选项而是必选项。但也要清醒认识到没有绝对安全的方案我们的目标是让破解成本高于软件本身的价值。5.2 代码混淆工具的选择与配置市面上针对.NET的混淆工具不少我实际用过并且觉得效果比较均衡的有Obfuscator、ConfuserEx这几类。它们的基本原理是重命名类名、方法名、变量名为无意义的字符插入虚假控制流加密字符串常量。配置的时候要注意保留需要反射调用的类名比如Unity的MonoBehaviour子类否则混淆后程序直接跑不起来。我的经验是分两步走先用混淆工具做基础保护再对核心授权逻辑做一层手写的“校验链”。所谓校验链就是把授权判断拆成多个分散的方法互相调用、互相验证而不是集中在一个CheckLicense()方法里。这样即使逆向者找到了其中一个方法也不容易理清完整的校验逻辑。5.3 关键字符串与常量的保护代码里硬编码的密钥、API地址、校验阈值这些常量是逆向者的重点目标。我的处理方式是不在代码里出现完整的敏感字符串而是拆成多段运行时拼接。比如一个32位的密钥拆成4段8位的分别存在不同的类里用的时候再组合。更进一步的做法是对拼接后的结果再做一次变换比如异或一个固定值让静态分析工具难以直接提取。// 字符串拆分的简单示例 private static string GetApiEndpoint() { string p1 https://api.; string p2 example; string p3 .com/v1/; string p4 verify; return p1 p2 p3 p4; }这种保护强度有限但配合混淆工具使用能把大部分“顺手破解”的人挡在门外。6. 实战中踩过的坑与排查思路6.1 打包后授权失效的排查链路这个问题我遇到过不止一次表现是编辑器里一切正常打包出来就提示授权无效。排查思路可以按这个顺序走第一步确认授权文件的路径。Application.persistentDataPath在不同平台下指向的目录完全不同Windows是C:\Users\用户名\AppData\LocalLow\公司名\产品名Android是应用私有目录iOS又是另一套。如果写文件时用的路径和读文件时不一致自然读不到。第二步检查文件读写权限。移动端和部分受控环境对文件系统有沙箱限制如果授权文件放在StreamingAssets里Android上只能读不能写需要先拷贝到persistentDataPath再操作。第三步验证加密解密逻辑。有时候是密钥派生过程中用到了平台相关的API比如Encoding.Default在不同系统上编码不同导致加密结果不一致。统一用Encoding.UTF8能避免大部分这类问题。第四步检查时间格式。DateTime.ToString()不带格式参数时受系统区域设置影响中文系统输出“2025/1/15 10:30:00”英文系统输出“1/15/2025 10:30:00 AM”解析时就会出错。统一用DateTime.ToString(o)或者存Ticks值最稳妥。6.2 用户反馈“明明没到期却提示过期”的处理这类问题多半和时间回拨检测过于敏感有关。我遇到过一个案例用户的笔记本主板电池没电了每次关机后系统时间重置到出厂日期程序一启动就检测到“当前时间比上次记录早了好几年”直接判定异常。处理这类问题的原则是宁可放过不可错杀。我的调整方案是时间回拨检测触发后不直接封禁而是进入一个“观察模式”——记录异常次数只有连续多次比如3次以上检测到异常才真正限制功能。同时给用户一个申诉入口可以通过联网验证或者联系客服来恢复。6.3 授权文件被误删后的恢复策略用户清理磁盘、重装系统、或者手滑删了授权文件这种情况很常见。如果每次都要重新申请授权售后成本太高。我的做法是在程序里做一个“授权恢复”功能用户输入购买时获得的授权码程序联网验证后重新生成授权文件。授权码和授权文件是两套东西授权码可以重复使用但有次数限制授权文件是本地凭证。另外授权文件我一般会在两个位置各存一份主文件在persistentDataPath备份文件在一个隐藏目录里。启动时如果主文件读取失败自动尝试从备份恢复。这个机制能解决大部分“文件丢失”的问题。7. 几套方案的横向对比与选型建议把前面讲的方案整理成一张表方便根据项目实际情况选择方案类型实现难度防破解强度用户体验适用场景PlayerPrefs明文存储极低极弱好内部工具、无商业价值加密文件本地时间低弱好低价工具、试用期控制加密文件设备绑定中中中商业软件、单机授权联网校验设备绑定中高强依赖网络SaaS、订阅制软件离线签名授权文件高强好离线商业软件、企业授权选型的时候不要一味追求最强防护。我见过有开发者给一个售价几十块的小工具上了联网校验设备绑定代码混淆全套结果用户装完发现要联网激活直接退款差评。防护强度和用户体验之间要找到平衡点核心判断标准是你的软件值多少钱破解它能省多少钱。8. 一些零散但重要的经验补充最后分享几个在实际项目中总结出来的零散经验不一定成体系但都挺实用。第一授权相关的日志一定要单独记录。用户反馈授权问题时如果没有日志排查基本靠猜。我会在persistentDataPath下建一个license_log.txt记录每次启动时的授权状态、时间戳、指纹比对结果。日志本身也要做简单的混淆避免暴露太多内部逻辑。第二测试阶段一定要覆盖“极端时间”场景。把系统时间调到2099年、调到2000年、调到授权到期当天、到期后一天这些边界情况都要跑一遍。我吃过亏有一次到期判断用的是而不是结果到期当天还能用被客户发现了。第三给授权逻辑留一个“紧急开关”。万一线上出现大面积授权误判你需要一个不依赖用户操作就能临时放行的机制。我的做法是在服务器端维护一个版本号程序启动时如果联网拉取这个版本号如果发现当前版本被标记为“授权逻辑异常”就临时跳过本地校验。这个开关平时不用但关键时刻能救命。第四不要把所有鸡蛋放在一个篮子里。授权校验不要只在一个地方做启动时校验一次运行过程中定期再校验关键功能调用前再校验一次。这样即使逆向者绕过了启动校验运行到一半还是会触发。第五文档和用户指引要写清楚。很多授权问题其实是用户不会操作导致的比如不知道授权文件放哪里、不知道怎么看剩余天数。在软件里加一个“授权状态”页面把到期时间、设备信息、剩余天数都展示出来能减少大量售后咨询。这些经验没有什么高深的技术但都是真金白银换来的。授权控制这件事技术方案只是一半另一半是对用户行为的理解和产品流程的设计。把这两方面都做好你的软件才真正具备商业化的基础。 
长河君 · 2026/10/20 4:51:16 · 阅读 1.2k Unity软件授权与期限控制实战：从本地加密到设备绑定
1. 从“软件白嫖”说起为什么期限控制是独立开发者的必修课做Unity独立开发或者接外包项目的朋友大概率都遇到过这种糟心事辛辛苦苦开发了几个月的软件交付给客户尾款还没结清对方已经把软件拷走到处用了或者做了一个工具类App想搞个“试用七天满意付费”的模式结果发现Unity打包出来的程序根本没有内置的授权管理机制谁拿到exe都能无限期跑下去。这不是技术难题而是一个产品设计层面的刚需。Unity本身是一个游戏引擎它的强项在渲染、物理、动画这些表现层的东西对于软件授权、使用期限、机器绑定这类“商业逻辑”引擎层面几乎没有提供任何开箱即用的方案。所以每一个想把Unity作品当成商品来卖的开发者迟早都要面对同一个问题怎么给软件加一把靠谱的锁。我前后做过好几个带授权控制的Unity项目从最简单的“首次运行起算30天”到稍微复杂一点的“绑定设备联网校验离线宽限期”踩过的坑不算少。这篇文章就把我实际用过、验证过的几套方案完整拆开讲一遍从最基础的本地时间戳方案到加密存储、防篡改、防时间回拨再到设备指纹绑定和离线授权文件的设计。不管你是刚接触Unity的新手还是已经做过几个商业项目的老手应该都能从中找到可以直接抄作业的部分。提醒一句本文讨论的所有技术方案仅用于保护你自己开发的软件产品的合法权益请勿用于任何违反法律法规或侵犯他人权益的场景。2. 本地期限控制的最小可行方案从PlayerPrefs到加密文件2.1 为什么PlayerPrefs是“纸糊的锁”很多教程一上来就教你用PlayerPrefs存一个首次运行时间然后每次启动对比当前时间。代码大概长这样// 不推荐的做法 if (!PlayerPrefs.HasKey(FirstRunTime)) { PlayerPrefs.SetString(FirstRunTime, System.DateTime.Now.ToString()); PlayerPrefs.Save(); } DateTime firstRun System.DateTime.Parse(PlayerPrefs.GetString(FirstRunTime)); if ((System.DateTime.Now - firstRun).TotalDays 30) { Application.Quit(); }这段代码能跑但基本等于没锁。原因有三第一PlayerPrefs在Windows上就是注册表里的一个键值对路径固定在HKCU\Software\公司名\产品名下面任何人打开注册表编辑器就能看到、能改、能删。第二时间字符串是明文的用户把系统时间往回调30天你的判断直接失效。第三就算用户不主动破解重装系统或者换一台电脑PlayerPrefs清空试用期又重新开始。所以PlayerPrefs方案只适合一种场景你压根不在乎被破解只是想给诚实用户一个“到期提醒”。但凡涉及真实付费这个方案必须升级。2.2 加密存储的实操把时间戳藏进二进制文件升级的第一步是把数据从注册表挪到一个自定义的加密文件里。我的做法是在Application.persistentDataPath下面生成一个二进制授权文件结构大致是文件头魔数 加密后的时间戳 校验码。具体实现上我一般用一个简单的对称加密比如AES密钥不直接写在代码里而是拆成几段、经过一次异或运算后再拼起来。这样做不能防住铁了心逆向的人但能挡住99%的普通用户——他们看到一堆乱码文件不知道里面存的是什么也就无从改起。// 授权文件写入的核心逻辑简化示意 using System.Security.Cryptography; using System.Text; public static class LicenseStorage { private static readonly byte[] KeyPart1 { 0x2A, 0x5F, 0x11, 0x8C }; private static readonly byte[] KeyPart2 { 0x73, 0xE2, 0x4B, 0x9D }; private static byte[] GetKey() { byte[] key new byte[KeyPart1.Length KeyPart2.Length]; for (int i 0; i KeyPart1.Length; i) { key[i] (byte)(KeyPart1[i] ^ KeyPart2[i]); } // 补齐到16字节实际项目会用更完整的密钥派生 return key; } public static void WriteLicense(string path, DateTime firstRun) { string raw firstRun.Ticks.ToString(); byte[] encrypted Encrypt(Encoding.UTF8.GetBytes(raw), GetKey()); // 前面加4字节魔数后面加4字节校验 byte[] magic { 0x4C, 0x49, 0x43, 0x01 }; byte[] checksum ComputeChecksum(encrypted); byte[] final new byte[magic.Length encrypted.Length checksum.Length]; Buffer.BlockCopy(magic, 0, final, 0, magic.Length); Buffer.BlockCopy(encrypted, 0, final, magic.Length, encrypted.Length); Buffer.BlockCopy(checksum, 0, final, magic.Length encrypted.Length, checksum.Length); System.IO.File.WriteAllBytes(path, final); } }这里有几个细节值得展开说。魔数的作用是快速判断文件是否被替换或损坏如果读出来的前四个字节对不上直接判定授权文件无效。校验码我用的是对加密数据做一次简单的哈希读取时重新计算并比对防止有人手动改文件里的字节。密钥拆分和异或运算的目的是避免在反编译工具里直接搜到完整的密钥字符串——虽然专业逆向人员还是能找到但门槛已经抬高了不少。2.3 时间回拨的检测与应对加密存储解决了“改文件”的问题但“改系统时间”这个漏洞还在。用户把系统时钟调回到试用期内你的程序读到的DateTime.Now就是假的。应对时间回拨我试过三种思路各有优劣第一种是记录“上次运行时间”每次启动时对比当前时间和上次记录的时间。如果当前时间比上次还早说明用户回拨了时钟直接判定异常。这个方法的局限在于用户如果每次都在试用期内来回切换时间或者干脆断网离线操作检测效果会打折扣。第二种是联网获取标准时间。程序启动时请求一个时间服务接口拿到网络时间后和本地时间对比。如果两者偏差超过阈值比如24小时就认为本地时间不可信。这个方案最可靠但要求软件必须联网对于纯离线工具类软件不适用。第三种是混合方案联网时以网络时间为准并记录离线时用“上次运行时间累计运行时长”来推算。我目前商业项目里用得最多的就是这种既保证了联网环境下的强校验又给离线场景留了合理的宽限期。// 时间回拨检测的简化逻辑 public static bool IsTimeTampered(DateTime lastRecorded, DateTime current) { // 当前时间比上次记录还早明显异常 if (current lastRecorded.AddMinutes(-5)) return true; // 如果本地时间和网络时间偏差过大 if (HasNetworkTime Math.Abs((NetworkTime - current).TotalHours) 24) return true; return false; }注意时间回拨检测不要做得太激进。有些用户只是系统时区设置有问题或者笔记本电池没电导致BIOS时间重置这些都属于正常情况。我的经验是给一个合理的容差范围比如前后5分钟到24小时不等超过范围才判定异常避免误伤正常用户。3. 设备绑定让授权文件“认机器”3.1 设备指纹的采集与稳定性权衡光有期限控制还不够如果用户把整个软件文件夹拷到另一台电脑上授权文件跟着一起过去照样能用。所以下一步是让授权和特定设备绑定。设备指纹的采集在Unity里没有统一API需要针对不同平台分别处理。Windows上我一般组合这几个信息主板序列号、CPU ID、硬盘序列号、网卡MAC地址。但这里有个坑——不是所有字段都能稳定获取有些虚拟机环境或者精简版系统里WMI查询会返回空值或者抛异常。我的做法是采集多个维度的信息然后做一个加权哈希。比如主板序列号权重最高MAC地址权重最低即使某一项获取失败整体指纹仍然能保持相对稳定。同时要避免使用会频繁变化的字段比如IP地址、内存使用量这些绝对不能进指纹。// Windows平台设备指纹采集示意 using System.Management; public static string GetDeviceFingerprint() { StringBuilder sb new StringBuilder(); try { // 主板序列号 using (var searcher new ManagementObjectSearcher(SELECT SerialNumber FROM Win32_BaseBoard)) { foreach (var obj in searcher.Get()) sb.Append(obj[SerialNumber]?.ToString() ?? NA); } // CPU ID using (var searcher new ManagementObjectSearcher(SELECT ProcessorId FROM Win32_Processor)) { foreach (var obj in searcher.Get()) sb.Append(obj[ProcessorId]?.ToString() ?? NA); } } catch { /* 采集失败时降级处理 */ } // 对拼接结果做哈希输出固定长度字符串 return ComputeHash(sb.ToString()); }3.2 指纹哈希与授权文件的绑定逻辑采集到指纹后不要直接把原始信息写进授权文件——那样等于把用户的硬件信息暴露了。正确做法是对指纹做一次哈希比如SHA256只存储哈希值。授权文件里同时保存这个哈希和期限信息程序启动时重新采集指纹、计算哈希和文件里的值比对。这里有个设计决策是“一机一码”还是“一码多机”一机一码最严格但用户体验差换个电脑就得重新申请。我一般给客户留一个“设备迁移”的余地——允许授权文件在检测到硬件变化时通过联网验证的方式重新绑定但限制迁移次数比如一年内最多3次。这样既保护了开发者利益又不至于让正常换设备的用户太难受。3.3 虚拟机与多系统的特殊情况处理实测下来虚拟机环境是设备绑定最容易出问题的地方。VMware和VirtualBox默认生成的硬件信息很多是重复的如果你只靠MAC地址做指纹很可能出现“一台机器授权所有克隆虚拟机都能用”的情况。我的应对策略是检测到虚拟机环境时额外采集虚拟机特有的标识比如VMware的BIOS UUID并且对虚拟机授权单独设置更短的期限或者更严格的联网校验频率。另外双系统用户同一台电脑装了Windows和Linux的指纹会完全不同这个要在用户协议里提前说明避免售后纠纷。4. 离线授权文件的设计让用户“带着授权走”4.1 授权文件的格式设计对于不能联网的软件离线授权文件是主流方案。用户在一台联网机器上生成请求码开发者用私钥签名后返回一个授权文件用户把文件放到指定目录即可激活。授权文件我一般用JSON格式可读性好方便排查问题。核心字段包括授权类型试用/正式/永久、到期时间、设备指纹哈希、签发时间、签名值。签名值是用非对称加密比如RSA对前面所有字段的内容做签名程序里内置公钥进行验签。这样即使有人改了JSON里的到期时间签名对不上授权直接失效。{ licenseType: professional, expireDate: 2026-12-31T23:59:59, deviceHash: a3f5c8..., issueDate: 2025-01-15T10:30:00, signature: Base64EncodedSignatureString... }4.2 非对称加密在Unity中的落地Unity支持的.NET版本对RSA的支持是完整的但要注意一点RSACryptoServiceProvider在部分平台比如IL2CPP编译后的iOS上可能不可用需要改用RSA.Create()配合ImportParameters的方式。我在实际项目里踩过这个坑Windows编辑器里跑得好好的打包到移动端就报错排查了半天才发现是API兼容性问题。验签的核心逻辑是把JSON里除signature之外的所有字段按固定顺序拼接成字符串用公钥验证签名。拼接顺序一定要固定不能依赖JSON序列化库的字段顺序否则不同版本序列化出来的字符串不一样验签必然失败。public static bool VerifyLicense(string json, string publicKeyXml) { var dict ParseJsonToDict(json); string signContent dict[licenseType] | dict[expireDate] | dict[deviceHash] | dict[issueDate]; byte[] signature Convert.FromBase64String(dict[signature]); using (var rsa RSA.Create()) { rsa.FromXmlString(publicKeyXml); return rsa.VerifyData( Encoding.UTF8.GetBytes(signContent), signature, HashAlgorithmName.SHA256, RSASignaturePadding.Pkcs1); } }4.3 离线宽限期与心跳机制纯离线授权有个天然缺陷开发者无法知道用户是否在到期后继续使用。我的做法是加一个“宽限期”设计——授权到期后程序不立即停止而是进入一个受限模式比如功能阉割、每次启动弹提醒给用户7到15天的缓冲期去续费。这样既不会让用户觉得太粗暴也给开发者留了催付的窗口。另外即使是离线软件我也会在程序里埋一个“心跳记录”每次启动时把当前时间写到一个隐藏的日志文件里。如果检测到日志里的时间出现倒退或者日志文件被删除就触发一次联网校验请求如果网络可用的话。这个机制不能完全防住破解但能大幅提高破解成本。5. 防逆向与代码混淆把锁做得再隐蔽一点5.1 Unity代码被反编译的现实用dnSpy或者ILSpy打开一个没做任何保护的Unity打包程序C#代码几乎是一览无余的。你的授权判断逻辑、密钥、校验流程全部以近乎源码的形式暴露在逆向者面前。我见过最夸张的情况是有人直接把if (IsExpired()) Application.Quit();这一行删掉软件就永久可用了。所以加密和混淆不是可选项而是必选项。但也要清醒认识到没有绝对安全的方案我们的目标是让破解成本高于软件本身的价值。5.2 代码混淆工具的选择与配置市面上针对.NET的混淆工具不少我实际用过并且觉得效果比较均衡的有Obfuscator、ConfuserEx这几类。它们的基本原理是重命名类名、方法名、变量名为无意义的字符插入虚假控制流加密字符串常量。配置的时候要注意保留需要反射调用的类名比如Unity的MonoBehaviour子类否则混淆后程序直接跑不起来。我的经验是分两步走先用混淆工具做基础保护再对核心授权逻辑做一层手写的“校验链”。所谓校验链就是把授权判断拆成多个分散的方法互相调用、互相验证而不是集中在一个CheckLicense()方法里。这样即使逆向者找到了其中一个方法也不容易理清完整的校验逻辑。5.3 关键字符串与常量的保护代码里硬编码的密钥、API地址、校验阈值这些常量是逆向者的重点目标。我的处理方式是不在代码里出现完整的敏感字符串而是拆成多段运行时拼接。比如一个32位的密钥拆成4段8位的分别存在不同的类里用的时候再组合。更进一步的做法是对拼接后的结果再做一次变换比如异或一个固定值让静态分析工具难以直接提取。// 字符串拆分的简单示例 private static string GetApiEndpoint() { string p1 https://api.; string p2 example; string p3 .com/v1/; string p4 verify; return p1 p2 p3 p4; }这种保护强度有限但配合混淆工具使用能把大部分“顺手破解”的人挡在门外。6. 实战中踩过的坑与排查思路6.1 打包后授权失效的排查链路这个问题我遇到过不止一次表现是编辑器里一切正常打包出来就提示授权无效。排查思路可以按这个顺序走第一步确认授权文件的路径。Application.persistentDataPath在不同平台下指向的目录完全不同Windows是C:\Users\用户名\AppData\LocalLow\公司名\产品名Android是应用私有目录iOS又是另一套。如果写文件时用的路径和读文件时不一致自然读不到。第二步检查文件读写权限。移动端和部分受控环境对文件系统有沙箱限制如果授权文件放在StreamingAssets里Android上只能读不能写需要先拷贝到persistentDataPath再操作。第三步验证加密解密逻辑。有时候是密钥派生过程中用到了平台相关的API比如Encoding.Default在不同系统上编码不同导致加密结果不一致。统一用Encoding.UTF8能避免大部分这类问题。第四步检查时间格式。DateTime.ToString()不带格式参数时受系统区域设置影响中文系统输出“2025/1/15 10:30:00”英文系统输出“1/15/2025 10:30:00 AM”解析时就会出错。统一用DateTime.ToString(o)或者存Ticks值最稳妥。6.2 用户反馈“明明没到期却提示过期”的处理这类问题多半和时间回拨检测过于敏感有关。我遇到过一个案例用户的笔记本主板电池没电了每次关机后系统时间重置到出厂日期程序一启动就检测到“当前时间比上次记录早了好几年”直接判定异常。处理这类问题的原则是宁可放过不可错杀。我的调整方案是时间回拨检测触发后不直接封禁而是进入一个“观察模式”——记录异常次数只有连续多次比如3次以上检测到异常才真正限制功能。同时给用户一个申诉入口可以通过联网验证或者联系客服来恢复。6.3 授权文件被误删后的恢复策略用户清理磁盘、重装系统、或者手滑删了授权文件这种情况很常见。如果每次都要重新申请授权售后成本太高。我的做法是在程序里做一个“授权恢复”功能用户输入购买时获得的授权码程序联网验证后重新生成授权文件。授权码和授权文件是两套东西授权码可以重复使用但有次数限制授权文件是本地凭证。另外授权文件我一般会在两个位置各存一份主文件在persistentDataPath备份文件在一个隐藏目录里。启动时如果主文件读取失败自动尝试从备份恢复。这个机制能解决大部分“文件丢失”的问题。7. 几套方案的横向对比与选型建议把前面讲的方案整理成一张表方便根据项目实际情况选择方案类型实现难度防破解强度用户体验适用场景PlayerPrefs明文存储极低极弱好内部工具、无商业价值加密文件本地时间低弱好低价工具、试用期控制加密文件设备绑定中中中商业软件、单机授权联网校验设备绑定中高强依赖网络SaaS、订阅制软件离线签名授权文件高强好离线商业软件、企业授权选型的时候不要一味追求最强防护。我见过有开发者给一个售价几十块的小工具上了联网校验设备绑定代码混淆全套结果用户装完发现要联网激活直接退款差评。防护强度和用户体验之间要找到平衡点核心判断标准是你的软件值多少钱破解它能省多少钱。8. 一些零散但重要的经验补充最后分享几个在实际项目中总结出来的零散经验不一定成体系但都挺实用。第一授权相关的日志一定要单独记录。用户反馈授权问题时如果没有日志排查基本靠猜。我会在persistentDataPath下建一个license_log.txt记录每次启动时的授权状态、时间戳、指纹比对结果。日志本身也要做简单的混淆避免暴露太多内部逻辑。第二测试阶段一定要覆盖“极端时间”场景。把系统时间调到2099年、调到2000年、调到授权到期当天、到期后一天这些边界情况都要跑一遍。我吃过亏有一次到期判断用的是而不是结果到期当天还能用被客户发现了。第三给授权逻辑留一个“紧急开关”。万一线上出现大面积授权误判你需要一个不依赖用户操作就能临时放行的机制。我的做法是在服务器端维护一个版本号程序启动时如果联网拉取这个版本号如果发现当前版本被标记为“授权逻辑异常”就临时跳过本地校验。这个开关平时不用但关键时刻能救命。第四不要把所有鸡蛋放在一个篮子里。授权校验不要只在一个地方做启动时校验一次运行过程中定期再校验关键功能调用前再校验一次。这样即使逆向者绕过了启动校验运行到一半还是会触发。第五文档和用户指引要写清楚。很多授权问题其实是用户不会操作导致的比如不知道授权文件放哪里、不知道怎么看剩余天数。在软件里加一个“授权状态”页面把到期时间、设备信息、剩余天数都展示出来能减少大量售后咨询。这些经验没有什么高深的技术但都是真金白银换来的。授权控制这件事技术方案只是一半另一半是对用户行为的理解和产品流程的设计。把这两方面都做好你的软件才真正具备商业化的基础。