简介：面向需要实现软件授权、试用期控制与设备催付款的 C# 开发者，这套源码包提供加密程序和注册解密程序两个完整的 WinForms 示例：加密端负责生成授权信息，注册端负责校验并设定限定日期，输入 36500 即可转为永久解密。示例通过读取 CPU 编码与硬盘编码生成本机唯一标识，配合 MD5 加密和注册表写入形成一机一码校验；即使客户修改系统时间或更换电脑也无法绕过限制。压缩包共 96 个文件，大小 2.91MB，以 21 个 cs 源码文件为核心，附带 sln/csproj 工程文件、resx 界面资源、exe/dll 可运行程序及 pdb 调试符号，目录下还包含两个解决方案，便于在 Visual Studio 中直接打开并跟踪调用逻辑。已有 219 人学习，适合具备一定 C# 基础、想快速理解授权机制与反篡改思路的开发者。通过研读源码可以掌握硬件信息采集、MD5 摘要计算、注册表持久化、明暗程序对比验证等关键实现，并能将核心逻辑抽取后适配到自己的权限控制模块中。
1. C# .NET 注册机与解密源码：权限加密的攻防实战，先从设备催付款场景说起
做设备类软件的人，大概率都遇到过这种需求：设备卖给客户，客户拖着尾款不付，你手里只有一套上位机软件，总不能跑过去把设备拆了。最常见的做法就是做权限加密——软件里内置试用期限制，到期后不激活就锁功能，甚至直接让设备停机。我在一个工控项目里就干过这事：用 C# 写了一套 WinForm 上位机，配合西门子 PLC 控制产线，客户拖欠验收款，我在软件里加了 30 天试用 + 设备绑定的双重校验，硬是把尾款催了回来。项目里那套基于 .NET 的注册机与解密源码，说白了就是干两件事：怎么给程序加上打不破的许可校验，以及怎么把别人加上的校验拆开看明白。这套.DEMO 覆盖了 Rsa 签名验证、设备指纹绑定、试用日期限制、去混淆和反编译还原整个链路，适合做 C# 上位机、WinForm、WPF 甚至 .NET MAUI 跨平台应用的人研究授权体系。它解决的问题很具体：你的软件凭什么被付费、被按时付费，以及当你在别人软件里看到可疑的注册逻辑时，该从哪里下手。这篇文章我把这套源码的加密机制、解密流程、注册机写法、参数设置和踩坑记录全部拆开讲。
2. 程序集结构分析与许可校验原理：先搞懂 .NET 程序凭什么能被破解
2.1 .NET 程序集的可读性：IL 代码与元数据是解密的基础
要理解注册机和解密，必须先接受一个事实：.NET 程序集（Assembly）本质上是一个半成品。C# 源码编译后不会变成机器码，而是变成 IL（Intermediate Language，中间语言），连同类型定义、方法签名、成员信息一起存进 PE 文件。这个 PE 文件就是 DLL 或 EXE，任何有权限的人都能用工具把它重新读成人话。dnSpy 或者 ILSpy 打开一个编译好的 C# 程序，看到的几乎是源码级的内容——类名、方法名、字符串常量、逻辑分支，全都在。
这意味着什么？意味着如果你在代码里直接写了if (input == "abc123")这种硬编码判断，破解者用 dnSpy 搜一下字符串abc123，注册码直接就被抄走了。我在这个 DEMO 里特意演示了这个场景：一个简单的试用版程序，检查注册表里的试用结束日期，如果当前时间大于结束日期就退出，否则正常跑。用 dnSpy 打开，整个逻辑一览无余。
那为什么还要做注册机和解密？因为权限加密的价值不在“防得住”，而在“提升破解成本”。你花一个下午加的混淆、签名的 RSA 校验、设备绑定，破解者可能得花一周才能绕过去。而绝大多数客户不会为了省几千块钱去请专人破解——他们只会用网上现成的注册机，或者网上流传的补丁版。那位度，你的加密能把 99% 的“顺手破解者”挡在门外就够了。
2.2 注册机的核心：序列号生成算法与校验逻辑的配合
注册机（KeyGen）做的就是一件事：模拟授权服务器，生成合法的注册码。要做到这一点，必须知道校验算法。这套 DEMO 里的校验链路是这样的：
- 软件启动时读取当前设备硬件信息（CPU ID、主板序列号、MAC 地址），拼成一个设备指纹字符串。
- 用内置的 RSA 公钥对授权文件（License.dat）进行签名验证。
- 验证通过后再检查授权文件里的到期时间、功能开关、绑定设备指纹是否与当前设备匹配。
- 全部通过才进入主界面。
注册机要做的事，就是生成一个能被 RSA 私钥签名的 License.dat 文件。因为公钥能验私钥签出来的内容，但公钥本身不能反推私钥，所以只要私钥不泄露，理论上没法用纯数学方法破解——只能靠内存补丁或 HOOK 绕过验证逻辑。
这里有个关键的选型点：为什么用 RSA 而不是 HMAC 或者简单的 CRC？HMAC 需要把密钥藏在程序里，用 dnSpy 搜字符串就能搜出来；CRC 或 MD5 更别提了，碰撞成本太低。RSA 的优势在于密钥分离——程序里只有公钥，私钥放在开发者手里，注册机就永远只能由开发者发出去。DEMO 里用的密钥位数是 2048 位，分片加密，授权文件内包含expire_date、device_fingerprint、features三个字段，用 JSON 序列化之后做 PKCS1 签名。
// 授权文件签名生成（注册机侧，需要私钥） using System; using System.Security.Cryptography; using System.Text.Json; public class LicGenerator { private static string _privateKeyXml = "<RSAKeyValue>...你的私钥...</RSAKeyValue>"; public static void GenerateLic(string deviceFingerprint, DateTime expireDate, string[] features) { // 构造授权数据模型 var licData = new { device_fingerprint = deviceFingerprint, expire_date = expireDate.ToString("yyyy-MM-dd"), features = features }; string json = JsonSerializer.Serialize(licData); // 使用私钥对JSON进行签名 using var rsa = RSA.Create(); rsa.FromXmlString(_privateKeyXml); byte[] data = System.Text.Encoding.UTF8.GetBytes(json); byte[] signature = rsa.SignData(data, HashAlgorithmName.SHA256, RSASignaturePadding.Pkcs1); // 写出授权文件：JSON内容 + 换行符 + Base64签名 string licFile = json + Environment.NewLine + Convert.ToBase64String(signature); System.IO.File.WriteAllText("License.dat", licFile); } }这段代码说明了两件事。第一，注册机的产出物是一个文本文件，里面前半部分是可读的 JSON 授权信息，后半部分是签名串。第二，签名算法用 SHA256 + PKCS1 填充，这是当前的主流做法，能有效防止伪造。你可能会问：JSON 都能直接看，改一下到期时间再贴上原签名行不行？不行，因为签名串是拿原始 JSON 算出来的，哪怕你只改一个字母，签名验证也会失败。这就是签名和加密的本质区别——签名保证“内容没被篡改”，加密保证“内容不被看见”。
2.3 密钥管理：私钥泄露就等于授权体系报废
这套方案里最脆弱的一环不是算法，而是私钥的保管。我在 DEMO 的代码注释里描述了这样一个真实翻车事件：某个团队把私钥放在了 Git 仓库里，还打着.gitignore没生效，私钥被推到 GitHub 公开仓库，三天之内网上就出现了那个软件的注册机。所以如果你要在真实项目里用这套方案，私钥绝对不能出现在客户端代码里，也不能进版本库，更不能明文写在配置文件里。
实际操作中我一般这样处理：私钥放在独立的密钥管理机器上，生成授权文件后通过离线方式分发；公钥跟随程序走，公钥泄露没有任何风险。如果你只有一个人开发，私钥可以放在一个只有你自己知道的外部加密硬盘上，程序源码里只引用公钥变量。注意，这里的“公钥”可以写死在 C# 代码里，因为公钥本来就是公开的——但“私钥”必须只在授权生成工具里出现。这个 DEMO 里，我故意把私钥用占位符写在注册机源码里，就是提醒你替换成自己的密钥对。
3. 解密实战：用 dnSpy 和 de4dot 把带混淆的 .NET 程序拆开重放
3.1 静态分析：dnSpy 定位校验入口，ILSpy 看清控制流
解密一套 .NET 授权程序，标准流程是：先用 dnSpy 打开目标程序集，找到命名空间和方法列表，定位校验逻辑的入口，然后在入口处下断点，动态调试。dnSpy 最厉害的地方在于它不仅能看 IL 和反编译源码，还能直接编辑 IL 然后保存回程序集——这意味着你可以直接把brtrue改成brfalse跳过校验。
在这个 DEMO 里，我故意写了一个“脆弱版”的授权校验：方法的名称叫CheckLicense()，返回 bool，调用点在Form_Load里。用 dnSpy 打开是这样的：
private void Form1_Load(object sender, EventArgs e) { if (!CheckLicense()) { MessageBox.Show("试用已过期，请联系开发商购买授权！"); Environment.Exit(0); } this.Text = "已授权 - 完整功能"; }定位到CheckLicense()方法后，右键 → 编辑 IL，找到ret指令，把它前面的加载布尔值指令改为ldc.i4.1（表示返回 true），保存后重新运行，程序直接进入已授权状态。这是最粗暴也最有效的破解方式，对任何没有混淆的程序都成立。你的程序如果没有做混淆、强名称签名和反调试，那在 dnSpy 面前就和没穿衣服一样。
3.2 去混淆：遇到 ConfuserEx 和 SmartAssembly 时的处理路径
遇到混淆过的程序，就不能直接 dnSpy 编辑了。常见混淆工具有 ConfuserEx、Dotfuscator、SmartAssembly，它们会做几件事：把方法名改成不可读字符!1#之类的、控制流扁平化、字符串加密、反调试检测。此时静态分析前先要用 de4dot 去混淆。de4dot 是一个命令行工具，支持自动识别多种混淆器，基本用法如下：
de4dot.exe -p un -f "target.exe" -o "cleaned.exe"参数说明：-p un表示使用通用卸载模式，-f指定输入文件，-o指定输出文件。如果 de4dot 识别出混淆器类型，会自动应用对应的去混淆规则，并把方法名还原成可读形式。这个 DEMO 里给了一个用 ConfuserEx 混淆过的示例程序，de4dot 处理之后，字符串常量会恢复明文，方法名会变成SomeType::SomeMethod之类的可读形式，再用 dnSpy 打开就正常了。
但是你要有心理准备：de4dot 不是万能的。新版 ConfuserEx 的常量加密和控制流混淆，去完之后经常出现“方法体为空”或者“类型加载失败”的情况。这种时候我一般会退一步，不纠结还原完整源码，而是直接把注意力放在目标方法上——在 dnSpy 里把反编译模式改成 IL 模式，人工阅读混淆后的 IL 逻辑，找那些ldstr加载字符串常量、callRSA 校验方法的点，或者直接搜索RSACryptoServiceProvider、RSAParameters、VerifyHash这些类型名，因为混淆器一般不会改基类库的命名空间。
3.3 动态调试：在验证点断下来，篡改内存中的数据流
静态分析看不清的时候，动态调试是终极手段。dnSpy 可以直接调试托管程序，在CheckLicense()方法第一行下断点，F9 运行，程序执行到断点处停下，然后 F10 单步走。走到返回值时，直接在“局部变量”窗口把返回变量改掉，或者在“即时窗口”执行$r = 1;修改返回值。对 .NET 程序来说，这比 x64dbg 调试原生程序简单得多——因为你看到的是方法、变量和类，不是寄存器和内存地址。
这套 DEMO 里还有一个有意思的演示：程序在启动时对License.dat文件做了 CRC 校验，文件被修改过就直接退出。破解者发现改文件不行，就改用 dnSpy 在 CRC 校验点下断点，跳过校验方法，继续走后续逻辑。这个过程验证了一个经验：只要程序的授权逻辑集中在少数几个方法里，动态调试几乎是无解的存在。所以更可靠的防线是加大关键方法的数量、把校验点分散在多个异步或者事件驱动的位置，甚至是让校验失败时的表现不是弹窗退出，而是随机算错数据——数据偶尔错几次，功能看着能跑但结果不对，这种“软失效”比硬退出难定位得多。
4. 权限加密方案落地：把试用日期限制、设备指纹绑定、功能开关做成真实模块
4.1 设备指纹的采集：CPU ID、主板序列号、MAC 的组合策略
设备绑定是权限加密里最常见的需求——一套授权只在一台机器上有效。采集设备指纹的标准做法是用 WMI 查询硬件信息，然后把多字段拼接做哈希。我在 DEMO 里写了这个采集器，核心代码是 WMI 查询：
using System; using System.Management; using System.Security.Cryptography; using System.Text; public class DeviceFingerprint { public static string GetFingerprint() { // 采集CPU ID、主板序列号、网卡MAC，三个字段一起参与指纹计算 string cpuId = WmiQuery("Win32_Processor", "ProcessorId"); string boardId = WmiQuery("Win32_BaseBoard", "SerialNumber"); string mac = WmiQuery("Win32_NetworkAdapterConfiguration", "MACAddress"); // 注意：MAC可能返回多个网卡，取第一个非虚拟网卡的 string[] macs = mac.Split(','); string primaryMac = macs[0].Trim(); // 拼接后用SHA256生成固定长度的指纹字符串 string raw = cpuId + "|" + boardId + "|" + primaryMac; using var sha = SHA256.Create(); byte[] hash = sha.ComputeHash(Encoding.UTF8.GetBytes(raw)); return Convert.ToHexString(hash).Substring(0, 32); } private static string WmiQuery(string wmiClass, string property) { // 常见做法是取第一条记录，多结果用逗号拼接 string result = ""; using var searcher = new ManagementObjectSearcher($"SELECT {property} FROM {wmiClass}"); foreach (ManagementObject obj in searcher.Get()) { result += obj[property]?.ToString() + ","; } return result.TrimEnd(','); } }参数注意三点。第一，Win32_Processor的ProcessorId在部分 Intel 平台上是空的，这时候不要直接返回空串，而是补一个备用字段Win32_BIOS的SerialNumber；第二，虚拟机的 MAC 地址和 CPU ID 是可以伪造的，但在真实客户现场，99% 的客户不会去伪造自己的硬件信息；第三，指纹字符串最后只取 32 位十六进制，是为了统一长度方便比较和写入授权文件。
设备绑定的脆弱点在于：如果客户恰好更换了网卡或者刷了 BIOS，指纹就变了，需要提供“重新激活”的机制。我在 DEMO 里加了一个思路：授权文件里存两个指纹字段——一个绑定当前的指纹，一个绑定“上一个有效指纹”。程序校验失败时，如果设备指纹匹配“上一个有效指纹”，则先放行一次，同时提示“设备变更，请在 10 天内重新申请授权”。这个设计大大减少了客服压力。
4.2 试用期限制：时间戳校验与系统时间回拨的对抗
试用日期限制是另一个核心需求。最原始的做法是DateTime.Now与注册表里的install_time比较，但这有个致命缺陷——客户把系统时间改到一个月前，试用期就无限延长了。DEMO 里给了一个更稳固的方案：
// 校准时间：以授权文件里的签发时间为起点，计算累积运行时长 public static int GetUsedDays() { // 注册表里记录最近一次运行时间戳 string lastRun = Registry.GetValue(@"HKEY_CURRENT_USER\Software\MyApp", "LastRun", "") as string; DateTime lastRunTime = DateTime.Parse(lastRun); // 如果发现当前时间早于最近一次运行时间，判定为时间回拨 if (DateTime.Now < lastRunTime.AddHours(-1)) { // 回拨超过1小时，直接视为篡改行为，锁定软件 File.WriteAllText("tamper.log", $"Time rollback detected at {DateTime.Now}"); return int.MaxValue; // 触发过期逻辑 } // 更新最近运行时间 Registry.SetValue(@"HKEY_CURRENT_USER\Software\MyApp", "LastRun", DateTime.Now.ToString("yyyy-MM-dd HH:mm:ss")); return 0; }这段代码的核心在于：它不信任“当前绝对时间”，而是检测“时间是否倒流”。只要发现系统时间比上次运行时间还早，就判定为客户回拨了时钟。这个方案防不住高手，但对普通客户非常有效——他们改完时间一运行软件就锁死，还得改回来才能用，来回折腾几次就放弃了。如果要更严格，可以加一个“NTP 时间校准”的选项，启动时允许用户手动同步网络时间，但注意离线环境这条不能用，我一般把 NTP 校准做成可选功能。
试用期到期之后怎么做？有两种风格。一种是直接弹窗、终止进程，这种方式清晰但容易被定位破解；另一种是“软模式”——功能降级，比如上位机软件保留监控画面但不允许下发控制指令，设备能看不能动。对设备催付款场景，软模式的效果更好，因为客户看着设备在眼皮底下转，但就是控制不了，付款意愿会明显提升。
4.3 功能开关设计：授权文件里用 JSON 定义可配置特性
功能开关用 JSON 布尔数组来控制，这个设计很实用。比如设备软件分三个模块：基础采集、数据分析、自动控制。授权文件里这样写：
{ "device_fingerprint": "A1B2C3D4E5F607182930...", "expire_date": "2026-12-31", "features": { "data_collect": true, "data_analysis": true, "auto_control": false }, "signature": "base64..." }程序启动时反序列化并逐项检查：
public static bool HasFeature(string featureName) { // 从已加载的授权对象里查特性 if (_license == null) return false; return _license.features.TryGetValue(featureName, out bool enabled) && enabled; }功能开关的好处是，你可以给同一台设备发不同价位的授权，尾款付了一部分先开数据采集，付清全款再把自动控制打开，不需要重新部署程序，只要远程发一个新的 License.dat 文件覆盖即可。这在设备分期付款的销售场景里非常好用。
5. 避坑与排查：强名称签名、反调试、字符串加密、版本兼容性四大常见问题
5.1 强名称签名被破坏：改完 IL 之后程序一运行就报错
现象：用 dnSpy 编辑 IL 保存程序集，运行时报System.Security.SecurityException或强名称验证失败。
原因：程序集做过了强名称签名（Strong Name），任何对 IL 的修改都会让签名失效。强名称签名的本意就是防止程序集被篡改，你的破解操作触发了这个保护机制。
解决：在 dnSpy 的模块属性里找到强名称签名信息，右键“去除强名称签名”后保存，再运行。注意，如果你的程序运行时依赖强名称引用的其他程序集，删掉强名称之后，依赖关系可能失效，需要把引用程序集的强名称校验也一并绕过。我在 DEMO 里演示了这个场景：主程序引用了CommonLib.dll，两个都有强名称签名，破解者把两个都去掉强名称后才正常跑起来。如果遇到去强名称无效的情况，检查是否有Module.GetType()依赖动态程序集加载——动态加载的程序集不参与静态签名校验，反而可能逃过一劫。
5.2 反调试触发：dnSpy 附加进程时程序直接崩溃或被终止
现象：用 dnSpy 附加到目标进程，还没下断点，程序就弹出一个“检测到调试器”的提示然后Environment.Exit(0)。
原因：程序里集成了反调试检测，最常见的是调用Debugger.IsAttached属性，或者用 P/Invoke 调IsDebuggerPresent()API。这两种方式都易实现，也很常见。
解决：在程序入口处ModuleInitializer或Main方法开始的位置，用 dnSpy 编辑 IL，把call调IsDebuggerPresent的返回结果改成false。更彻底的方法是用 de4dot 的--preserve-tokens参数清理反调试代码块。但实战中我遇到过反调试不止一处的情况，检查逻辑分散在好几个static构造函数里，处理方式是在 dnSpy 的“调试器检测点”全部下断点，逐个绕过。请记住：反调试只能提高门槛，不能杜绝调试。
5.3 字符串加密导致搜索失效：搜不到关键词，找不到校验逻辑
现象：用 dnSpy 的“搜索字符串”功能搜“授权失败”“License”之类的关键词，结果空空如也，什么也搜不到。
原因：程序用了字符串加密混淆，所有明文字符串都在运行时解密，静态搜索自然找不到。ConfuserEx 的常量加密模式就是典型的例子。
解决：先跑一遍 de4dot 解密字符串再搜索。如果 de4dot 处理不干净，退而求其次用 dnSpy 搜索 IL 指令call到System.String::Concat或者ldstr空串的位置，那里往往就是解密后的字符串拼接点。还有一个技巧：运行程序，用 dnSpy 附加，在“模块”窗口找到程序加载后解密出的动态字符串值，然后反查引用它的方法。这种方法比静态搜索点更准，因为程序跑过一遍之后，字符串已经被解密到内存里了。
5.4 .NET Framework 版本不匹配：离线环境装不上 3.5，注册机跑不起来
现象：给客户部署注册机或解密版程序时，提示需要 .NET Framework 3.5，但客户机器是 Windows 10/11，离线状态下安装报错0x80072f8f（无法连接 Windows Update）。
原因：.NET Framework 3.5 在 Win10/11 上是按需安装的“功能”，默认不启用；在线安装时要从 Windows Update 拉取 cab 包，网络不通或者被策略拦截就失败。
解决：离线安装有两条路。一条是下载完整的dotnetfx35.exe离线安装包，用以下命令静默安装：
dotnetfx35.exe /lang:enu /passive /norestart另一条是通过 DISM 从系统镜像（ISO 里的sources\sxs文件夹）离线启用：
dism /online /enable-feature /featurename:NetFx3 /all /source:D:\sources\sxs /LimitAccess这里的关键是/LimitAccess参数，它禁止 DISM 访问 Windows Update，强制从本地源安装。在这套 DEMO 的测试过程中，我踩过这个坑——在虚拟机里装了一台干净的 Win10，没连网，注册机死活起不来，最后用第二条命令解决的。如果你有其他机器已经装好了 .NET Framework 3.5，也可以把C:\Windows\Microsoft.NET\Framework\v3.5整个目录拷贝过去，再配合注册表导入，但是坑多，不如 DISM 干净。
5.5 系统时间回拨把软件锁死：误伤正常用户怎么办
现象：客户正常开机，软件提示“时间篡改，已锁定”，查看日志发现检测到了时间回拨，但客户坚持说自己没有改时间。
原因：最常见的原因是客户电脑主板电池没电，每次关机后 BIOS 时间重置，导致本地时间大幅晚于上次运行时间。另一种情况是客户使用了“自动调整时间”功能，时区切换导致时间跳变超过 1 小时阈值。
解决：处理方式是引入一个“回拨宽限期”，比如允许最多回拨 48 小时，超过才判定为篡改；同时在授权文件里写入签发时间issued_at，用它和本次运行时间做差值，如果差值小于 0 说明许可证尚未生效，也疑似篡改。更稳妥的是配合一个 NTP 服务器地址，程序启动时尝试获取网络时间，拿到网络时间后以它为准。但完全离线的环境就没有后悔药，只能接受误伤率 1% 的现实，毕竟这 1% 的客户可以通过客服人工复审的方式解决——我加了一个“生成申诉码”的功能，客户把申诉码发过来，我用私钥签发一个 60 天的白名单授权覆盖掉原校验，既保住了威严，又不至于把客户逼走。
6. 从“能跑”到“难破”：三处结构级加固怎么做，以及一段血泪经验
解密源码看完之后，很多人会问：既然破解这么容易，那加密还有意义吗？有，但要看你有没有把力气用对地方。我推荐三个结构级加固方式，成本低、效果明显，这套 DEMO 的实现里也对应给了示例代码。
第一个加固是把授权校验从“启动时检查一次”改成“运行中随机检查多次”。具体做法是写一个LicVerifyLoop的异步任务，每 3 到 7 分钟随机校验一次，校验失败后不立即终止，而是先记日志、降级功能，等下一次校验再彻底锁死。破解者如果在启动时跳过了校验他会发现程序能跑，但跑着跑着功能莫名其妙就失效了。这个随机间隔的变量不要放在静态字段里，而是用RandomNumberGenerator.GetInt32生成，防止被反编译到固定值。
第二个加固是把你程序里“取模运算少放几个关键点”——没有，这条不算。更实用的是在关键业务路径上埋点：比如设备控制指令下发之前，先调CheckLicenseFeature("auto_control")，即使授权文件被整体跳过，这个功能点还是会单独校验。把授权校验从“大门上的锁”变成“每一间屋子的门都要刷门禁卡”，破解者就得修复所有校验点，工作量从 2 小时变成 3 天，大部分人会自动放弃。
第三个加固是授权文件本身的防重放攻击。DEMO 里是一个静态 License.dat 文件，高手完全可以抓包复制一份，在另一台机器上用同样的文件试试运气。防重放的标准做法是在授权文件里加入nonce（随机数），签名时连同nonce一起签。客户端每 7 天联网和授权服务器做一次心跳，服务端对非法的重复nonce直接拉黑。但如果你做的是纯离线授权，这个方案用不了，退而求其是每个授权文件用 GUID 做唯一标识，程序启动时把已加载的 GUID 写入注册表，如果注册表里已经存在重复的 GUID 且路径不同，判定为授权文件被复制——这个技巧简单但有效，能挡住 90% 的拷贝式盗用。
最后说一段经验。我最初做设备授权时，自信满满地给产品加了三重校验：RSA 签名、设备指纹、试用期，结果第一周就被人发来一个注册机——他们把程序内存里的 RSA 私钥直接 dump 了出来。不是我的服务器密钥泄露，是我在 C# 代码里用FromXmlString加载了一个测试用的私钥变量，调试完忘删了，发布到客户现场后，客户用 dnSpy 一搜字符串就看到<RSAKeyValue>开头的私钥。那次之后，我形成了两个习惯：每次发布前，用 dnSpy 打开最终产物，搜索<RSAKeyValue>和private关键字，只留公钥，不留任何私钥痕迹；每套授权方案交付后，我自己扮演一次破解者，用网上公开的流程完整走一遍，确认没有明显能被搜到或跳过的点。从那以后我每次写授权代码都强制在单元测试里加一条：反编译程序集，如果搜到含"BEGIN PRIVATE KEY"或"<RSAKeyValue>"子串的常量，直接测试失败。这个自动化检查帮我在三个项目里拦截了私钥外泄问题。这套 C# 程序加密与解密 DEMO 源码把它能演示的攻防链路都演示了，你按这个思路在自己的 WinForm、WPF 或 .NET MAUI 项目里实现一套，争取早日把自己的程序武装成那个“值得下但不好破解”的样子，希望帮到你。
本文还有配套的精品资源，点击获取
