混淆是保护.NET 6+应用最实际的方案，通过重命名、控制流混淆等使反编译结果难读；配合ReadyToRun可提升逆向门槛，但核心逻辑仍应服务化以确保安全。
用 IL 保护工具混淆 dotnet 程序集最实际
发布 .NET 6+ 应用时，dotnet publish 默认输出的是可反编译的 IL 字节码，不是机器码。直接丢出 .dll 或 .exe 就等于把源逻辑敞开——哪怕你用了 internal、private，ILSpy 两下就全出来。真正能落地的防护，是混淆（obfuscation）。
推荐用 ConfuserEx（开源、支持 .NET Core/5/6/7）或商业工具 Eazfuscator.NET（对 SDK 风格项目集成更顺）。它们不加密文件，而是重命名类型/方法、插入无用控制流、折叠字符串、打乱元数据结构，让反编译结果难以阅读和调试。
- 混淆前确保所有依赖项都已
publish完整，否则混淆器可能找不到引用而报错Could not resolve assembly - 避免混淆
[Serializable]类、Newtonsoft.Json或System.Text.Json序列化用的属性名，否则运行时报JsonSerializationException - 混淆后务必做完整回归测试——有些反射调用（如
Type.GetType("MyNS.MyClass")）会因类名被改而失败
dotnet publish 时启用 ReadyToRun 和 AOT 编译能提高门槛
ReadyToRun（R2R）不是加密，但会把 IL 预编译成平台相关机器码片段，嵌入到程序集中。反编译工具（如 ILSpy）面对 R2R 模块会直接显示 “Not supported” 或大量无效指令，比纯 IL 难啃得多。
AOT（.NET 7+ 的 nativeaot）更进一步：彻底不带 IL，只输出原生二进制。但代价明显——不支持反射动态加载、Assembly.LoadFrom、dynamic、LINQ 表达式编译等。
- 启用 R2R：
dotnet publish -c Release -r win-x64 --self-contained false /p:PublishReadyToRun=true - 启用 AOT：
dotnet publish -c Release -r win-x64 --self-contained true /p:PublishAot=true - R2R 不影响运行时行为；AOT 必须提前配置好所有需要反射的类型，用
rd.xml声明，否则启动就崩溃
敏感逻辑别写在客户端，该抽走就抽走
再强的混淆或 AOT，也防不住用户把整个进程 dump 下来静态分析或动态调试。真正高价值的逻辑（比如许可证校验、算法密钥、业务规则判定），只要没被硬编码进客户端，就永远多一层屏障。
- 把校验逻辑移到 Web API，客户端只传哈希/签名，服务端验证并返回结果
- 用
Windows DPAPI（DataProtectionProvider）加密本地配置中的密钥，但注意：同一用户在同一机器上总能解密，不能替代服务端校验 - 别在代码里拼接 SQL 或硬写连接字符串——这些信息一旦泄露，数据库就裸奔
别信“加密 DLL”或“源码编译为 EXE”这类伪方案
有人试图用第三方工具把 .cs 文件打包成加密 .exe，运行时再内存解密执行。这类方案本质是自托管一个解释器或 JIT，性能差、兼容性烂，且解密后的 IL 仍存在于内存中，用 ProcDump + dnSpy 一抓一个准。
还有人想用 C++/CLI 把核心逻辑写成非托管 DLL 再 P/Invoke 调用——这确实增加了一点逆向成本，但 C++ 符号未剥离时照样能定位函数，且跨平台、调试、部署都变复杂，得不偿失。
- 任何“运行时解密 IL”的方案，都绕不开内存中存在可读字节码的事实
- 混淆 + R2R 是目前平衡安全性、兼容性和维护成本的最佳实践组合
- 如果真有不可妥协的 IP 保护需求，唯一可靠路径是服务化——把核心逻辑锁死在你可控的服务器上
混淆和 AOT 都不是银弹，它们解决的是“防止快速批量盗用”，而不是“绝对防破解”。真正容易被忽略的，是开发者常把“我混淆过了”当成终点，却忘了删掉调试符号（.pdb 文件）、没清理临时构建产物、或者在日志里打印了明文密钥——这些才是第一道防线崩塌的地方。
