简介：面向需要为 C#/.NET 应用增加防护的开发者，这份 IntelliLock 1.7 工具包围绕代码加壳、混淆与加密展开，可用于评估程序集防反编译、敏感逻辑保护及许可证管理等场景，并对三类策略的适用边界与配置代价形成直观认识。压缩包共 21 个文件，约 7.98MB，包含主程序、多枚功能 DLL、Visual Studio 集成组件、配置与数据库文件、帮助文档、示例工程链接及演示图片，覆盖从工具运行到策略配置的主要环节，目录组织便于按功能查找。已有 2822 人学习或下载。读者可通过界面与配套文档了解加壳外壳、名称与控制流混淆、按程序集或代码段加密等能力的配置方式，并借助示例和帮助材料熟悉许可管理、SQLite 数据存储及插件加载等组成，适合需要快速上手 .NET 代码保护工具、对比防护强度或开展内部安全测试的中高级开发者参考。
1. 一个 Release 出来的 exe，反编译只要十秒
把一个刚编译好的桌面程序拖进反编译工具，十秒内就能看到完整的类图、方法体，连 SQL 语句和接口地址都以明文摆在那里。C# 代码保护绕不过去的原因很朴素：.NET 的发布物不是机器码，而是 IL 加元数据，名字和字符串天生就是给人看的。加壳、混淆、加密这三件事，说到底是在发布前把「给人看」的部分改写成「只给运行时看」：重命名抹掉语义，字符串加密让常量不可读，方法体加密把 IL 推迟到 JIT 前才解密，再叠一层授权把拷贝成本抬起来。IntelliLock 1.7 属于把这几步串成可视化流水线的工具，适合交付离线桌面软件、行业客户端、需要试用期与机器绑定的团队；只是公司内网自用的小工具上全套，维护成本反而压过收益。
2. 从 IL 到源码：C# 的透明性来自哪四张表
2.1 元数据堆：泄露面到底在哪几处
.NET 程序集的元数据结构由 ECMA-335 规定，反编译工具不需要「猜」，它只是按表结构确定性地读回来。真正决定你泄露多少的，是四个堆：#Strings放类型名、成员名、命名空间；#US放所有通过ldstr加载的字符串字面量，UTF-16 编码；#Blob放签名和常量；#GUID放各类标识。再配合TypeDef、MethodDef、Field、Property、CustomAttribute、ManifestResource这几张表，一个程序集的骨架就完整了。
| 泄露面 | 存储位置 | 反编译后的样子 | 对应保护手段 |
|---|---|---|---|
| 类型与成员名 | #Strings+TypeDef/MethodDef | OrderService.CalcFreight()一目了然 | 标识符重命名 |
| 字符串字面量 | #US | ldstr "Server=..."直接可读 | 字符串加密 |
| 方法体 IL | MethodDef.RVA指向的代码段 | 反编译回 C# 近似代码 | 方法体加密 / 控制流混淆 |
| 自定义特性 | CustomAttribute+#Blob | [JsonPropertyName("order_no")] | 需要保留，不能盲目重命名 |
| 资源 | ManifestResource | 图片、配置、BAML 原名可列 | 资源加密 |
第三行的自定义特性最容易被忽略。[Route]、[Column]、[JsonPropertyName]、DI 容器的构造函数签名，这些都是运行时按字符串解析的契约。重命名一动它们，编译期一切正常，启动就崩。这条基本决定了后面所有排除规则要怎么定。
2.2 混淆、加壳、加密、授权：四类手段各自解决什么
新手最容易把「加壳」和「方法体加密」混为一谈，实际差别很大。方法体加密保留原程序集的元数据结构和类型布局，只把方法里的 IL 加密，运行时按方法粒度解密；它对反射相对友好，启动开销也分散。加壳是把整个程序集压缩加密后塞进一个 loader stub，入口先解密再内存加载，静态分析看到的第一层根本不是你的代码，但启动会明显变慢，和单文件发布、ReadyToRun 天然打架。
| 手段 | 作用点 | 对抗的分析动作 | 运行时成本 | 典型副作用 |
|---|---|---|---|---|
| 标识符重命名 | 元数据表 | 按名搜索、按名理解调用链 | 基本为零 | 反射、序列化、XAML 断裂 |
| 字符串加密 | #US堆 | 静态搜索接口地址、SQL、密钥 | 启动解密一次 | 内存 dump 仍可见明文 |
| 方法体加密 / 控制流混淆 | IL 代码段 | 反编译出可读方法体 | JIT 前解密，热点方法有感知 | 异常堆栈行号丢失、调试困难 |
| 加壳（内存加载） | 整个程序集 | 直接打开文件看不到代码 | 启动 +100ms 量级 | 与 AOT/单文件冲突，杀软敏感 |
| 授权与试用期 | 业务入口 | 复制到另一台机器直接用 | 可忽略 | 硬件指纹漂移导致误判 |
| 反调试 / 反篡改 | 进程与文件 | 附加调试器、改 IL 回编 | 少量轮询开销 | 开发机自测时自己先被拦 |
授权严格来说不属于「代码保护」，它保护的是商业模型而不是代码；反调试也不是「阻止」，只是把动态分析的时间成本从十分钟拉到几小时。这两件事的定位一定要摆正，否则会在方案评审时被问住。
2.3 选型：按交付形态决定保护强度
保护强度不是越高越好，它是一道成本方程：逆向成本明显高于软件售价乘以可接受的比例，就够了。我一般按四种交付形态分档。内网自用工具只做轻量重命名加剥离 PDB，能挡住「顺手看看」的同事就行；对外售卖的桌面软件上重命名、字符串加密、方法体加密三层，加授权与反调试；被第三方引用的 SDK 或插件，只能混淆内部实现，所有public成员、接口签名、事件名必须原样保留，否则引用方重新编译直接失败；已经切到 NativeAOT 或 ReadyToRun 的项目，IL 层的保护意义大幅下降，重点要转到原生层加壳和授权校验上。
还有一个常被漏掉的判断维度：你的程序是否大量依赖反射。ORM 的实体映射、JSON 序列化、插件扫描、XAML 绑定，这几样占得越多，重命名能下手的空间越小，就得靠字符串加密和方法体加密补强度。选型前先把这几个依赖列一遍，比事后一条条加排除规则省太多时间。
3. 跑通一条保护流水线：IntelliLock 1.7 的六步与九个参数
3.1 前置：先让工程本身「可保护」
跳过这一步直接上工具，九成会得到一堆无法解释的运行时异常。先把发布配置收干净：只发 Release；关掉完整 PDB（或改成嵌入后剥离）；确定性构建可以开，但要知道保护后的产物哈希必然变化，别把哈希校验写进 CI 缓存键里；关掉单文件发布和 ReadyToRun，因为这两者会把 IL 提前编译或打包，IL 层工具根本看不到方法体。我习惯再留一份未保护的基线产物放在out/baseline下，后面所有自测都靠它做对照。
<!-- 发布配置：让保护工具能拿到干净的 IL --> <PropertyGroup Condition="'$(Configuration)' == 'Release'"> <DebugType>none</DebugType> <!-- 不生成 PDB，避免行号和局部变量名外泄 --> <Deterministic>true</Deterministic> <!-- 源码级可复现，与保护后产物无关 --> <PublishSingleFile>false</PublishSingleFile> <!-- 单文件会把 IL 打进 bundle，保护失效 --> <PublishReadyToRun>false</PublishReadyToRun> <!-- R2R 已预编译为原生码 --> <PublishTrimmed>false</PublishTrimmed> <!-- 裁剪与反射冲突，先关 --> </PropertyGroup>这段属性的作用不是「优化」，而是把发布形态降到保护工具能处理的那一档。DebugType=none少给的是行号和局部变量名，代价是线上崩溃堆栈只剩方法名，得靠私有符号库补；PublishSingleFile和PublishReadyToRun必须关，前者把程序集塞进 bundle，后者把 IL 预编译成原生码，两种情况工具的加载器都会解析失败或者干脆「保护成功但没效果」。
3.2 六步流水线：从载入到出包
工具界面看着选项很多，实际是一条固定顺序的流水线。我一般按下面六步走，每一步都有对应的验收动作。
| 步骤 | 做什么 | 关键动作 | 出问题时的现象 |
|---|---|---|---|
| 1 | 载入程序集与依赖 | 把整个发布目录拖进来，让工具解析AssemblyRef | 依赖缺失，重命名范围判断错误 |
| 2 | 配置排除规则 | publicAPI、序列化模型、XAML 命名空间、反射入口 | 启动即MissingMethodException/XamlParseException |
| 3 | 设定重命名策略 | 不可打印字符或单字符短名 | 日志里全是乱码方法名，排障成本飙升 |
| 4 | 开字符串与资源加密 | 排除连接串之外的热路径常量 | 启动变慢，首次调用有明显卡顿 |
| 5 | 开方法体加密与控制流 | 热点方法、启动路径方法单独排除 | 异常堆栈行号全丢，偶发解密失败 |
| 6 | 开反调试与重签名 | 必须重新签名，否则强名称校验失败 | 插件加载报Could not load file or assembly |
九个参数里最值得单独说的是这几个。重命名范围一定选「仅 internal/private」，public成员是外部契约，改了引用方直接编不过。重命名模式选不可打印字符，目的是让反编译工具里的 Ctrl+F 彻底失效，但代价是线上日志里方法名变成方块，所以我会同时保留一份未混淆符号映射表放在内部知识库里。字符串加密别一刀切全开，启动路径上那些拼 SQL、拼配置的常量集中在静态构造函数里，全加密会把首次启动拖慢几百毫秒。方法体加密要单独排除启动入口和异常处理器，这两类地方一旦解密失败就是黑匣子，连日志都打不出来。
还有一条血泪经验：输出目录一定单独指定，别让工具覆盖回bin/Release。我见过一次保护产物覆盖了原文件，源码还在但调试符号和基线全没了，只能回滚仓库重新出包。
3.3 授权：试用期、机器绑定与宽限期
授权配置面板里通常有四组东西：试用天数、硬件指纹项、license 文件格式、功能开关。硬件指纹最容易翻车，取主板加 CPU 加磁盘序列号看起来稳，实际在云桌面、虚拟机迁移、换硬盘扩容这三种场景下会大面积漂移。我的做法是取两到三项，允许其中一项变化，再配一个「重新激活」的离线流程，别把用户逼到只能重装。
代码这一侧，把校验收敛到一个入口比什么都重要。散落在二十个窗体里的校验代码，保护工具加密之后没法排查，想加宽限期要改二十处。
// 授权校验收敛到单一入口：保护工具只需要盯这一处 internal static class LicenseGate { // 未保护时走本地实现；保护后由工具替换为加密实现 internal static Func<LicenseState> Probe { get; set; } = LocalProbe; private static LicenseState LocalProbe() => LicenseState.Valid; internal static bool Ensure(string feature, out string message) { var state = Probe(); // 单一副作用点 if (state == LicenseState.Expired) { message = "授权已过期"; return false; } if (state == LicenseState.MachineMismatch){ message = "授权与本机不匹配"; return false; } message = string.Empty; return true; } } internal enum LicenseState { Valid, Expired, MachineMismatch }把Probe做成委托的意义在于：保护工具对方法体做加密或流程混淆后，调用点越集中，替换、打桩、排查都越容易；同时它天然支持「双点校验」——启动路径调一次，关键功能入口（导出、打印、批量处理）再调一次。只校验启动那一次，是这类方案最常见的破绽，稍微会点的人把入口方法的返回值改掉就绕过去了。
时钟回拨也要处理。常见做法是记录最近一次成功运行的时间戳到本地加注册表双写，发现当前时间早于记录值就进宽限期，而不是直接判失效——直接判失效误伤的是那些主板电池没电的正常用户。
3.4 产物验收：出包后必须自己先打一遍
出包别急着发给测试。先跑三条命令：确认输出目录里每个 dll 都被处理过、确认强名称已重签、确认程序能正常起。
# 1) 逐个体检：能否被反汇编（打不开说明加壳生效） Get-ChildItem .\out\protected\*.dll | ForEach-Object { $r = ildasm /text $_.FullName 2>&1 if ($LASTEXITCODE -ne 0) { "已加壳/加密: $($_.Name)" } else { "仍可反汇编: $($_.Name)" } } # 2) 强名称校验：保护后必须重签 Get-ChildItem .\out\protected\*.dll | ForEach-Object { $n = [Reflection.AssemblyName]::GetAssemblyName($_.FullName) "{0} -> {1}" -f $_.Name, ($n.GetPublicKeyToken() -join '') } # 3) 冒烟：能起、能登录、能导出 Start-Process .\out\protected\App.exe -ArgumentList '--selftest' -Wait第一条命令的判定逻辑要说清楚：ildasm打不开并不总是「保护成功」，也可能是文件损坏。所以第二、三条必须跟上——能加载出程序集名说明 PE 结构完好，能跑通自检说明运行时解密链路正常。三条全过，才算这次出包有效。
4. 避坑：五条保护后翻车的现场记录与处置
4.1 坑一：重命名之后，DI 和 JSON 序列化集体失灵
现象是程序能启动，但所有接口返回空对象，日志里一串Unable to resolve service。原因很直接：DI 容器按类型名注册、System.Text.Json默认按属性名匹配字段，重命名把这些字符串契约全改了，运行时自然找不到。解决方式有两层：短痛是在工具里把实体模型和 ViewModel 的命名空间整体加进排除规则；长痛是把序列化改成显式映射，[JsonPropertyName]一个个标上，DI 注册改成显式工厂。前者十分钟搞定，后者要两天，但下次换工具不用再改一遍。
4.2 坑二：WPF 启动直接 XamlParseException
现象是双击就崩，堆栈指向InitializeComponent。WPF 的x:Class、资源 key、Binding Path全是以字符串形式存在 BAML 里的，重命名资源名或者 View 的命名空间，解析器就找不到对应项。处置办法是把所有 View、ViewModel、资源字典所在的命名空间排除在外，只混淆 Service 层往下。这件事没有捷径——用编译期绑定（x:Bind或强类型转换器）能缓解一部分，但存量项目改造量不小，老老实实加排除规则更现实。
4.3 坑三：插件加载报 Could not load file or assembly
现象是主程序正常，插件目录里的扩展全部加载失败。原因是强名称：保护后程序集哈希变了，原签名失效，重签时如果换了密钥，PublicKeyToken就变了，引用方配置文件里的bindingRedirect全部对不上。解决方式是固定一份key.snk进仓库，保护流程最后一步固定用它重签，然后在 CI 里加一条断言——比对保护前后的PublicKeyToken是否一致，不一致就让构建失败。
4.4 坑四：开了单文件发布，保护等于没做
现象是保护流程显示成功，但产物拖进反编译工具照样能看到全部代码。原因在 3.1 说过：单文件发布把程序集打包进 bundle，ReadyToRun 则把 IL 预编译成原生码，保护工具处理的还是中间目录里那份 IL，最终发布的根本不是它。处置顺序必须是「先保护、再发布」，并且把PublishSingleFile、PublishReadyToRun在 Release 配置里硬关掉。如果业务上确实需要单文件，那就得接受 IL 层保护失效，把预算挪到原生壳和授权上。
4.5 坑五：来源不明的安装包，把编译机变成了靶机
现象是装完工具之后编译机多出计划任务、杀软开始报警、编译产物里莫名多一个引用。原因不用绕弯子：这类工具的所谓注册机、补丁包，是供应链投毒最经典的载体，你给它管理员权限，它给你装什么都有可能。处置方式很简单也很硬：只从官方渠道取安装包，拿到先算哈希、和官方公布值比对，装的时候放隔离虚拟机、断网、快照，确认行为正常再进内网。工具本身的价值在于流水线，不在于那个「已激活」的状态，为了省一笔授权费把整个构建环境搭进去，不划算。
5. 用逆向视角验收：三个可量化指标和一组授权测试
5.1 指标一：可读标识符占比
「感觉混淆得挺狠」不算验收。可量化的是：所有类型名里，还长得像人写的名字占多少比例。目标定在 10% 以下。这里有个细节，别用Assembly.LoadFrom去反射枚举，那会触发模块初始化器，反调试一开你自己先被拦。用MetadataLoadContext只读元数据，全程不执行任何代码。
// 需要 NuGet: System.Reflection.MetadataLoadContext using System.Reflection; static (int readable, int total) CountReadableTypes(string dir) { var files = Directory.GetFiles(dir, "*.dll") .Concat(Directory.GetFiles(dir, "*.exe")).ToArray(); var resolver = new PathAssemblyResolver(files); using var mlc = new MetadataLoadContext(resolver); // 只读元数据，不跑初始化器 int readable = 0, total = 0; foreach (var f in files) { Assembly asm; try { asm = mlc.LoadFromAssemblyPath(f); } catch { continue; } // 加壳的跳过 foreach (var t in asm.GetTypes()) { total++; var n = t.Name; // 长度大于 3 且全是字母数字下划线，说明还是人类可读的名字 if (!n.StartsWith("<") && n.Length > 3 && n.All(c => char.IsLetterOrDigit(c) || c == '_')) readable++; } } return (readable, total); }这段的关键点是MetadataLoadContext与PathAssemblyResolver的配合：前者提供只读上下文，后者负责解析依赖，缺一个就会在GetTypes()时抛FileNotFoundException。返回值拿来做趋势对比最有意义——同一套代码，保护前后各跑一次，可读类型数应该从几百掉到个位数。
5.2 指标二：明文字符串残留数
#US堆里的字符串是 UTF-16LE 存储，而且不保证从文件偶数偏移开始。所以扫描脚本要从偏移 0 和 1 各解一次，两边都不命中才算干净。
# 用法: .\Scan-Literal.ps1 -Path .\out\protected\App.dll -Literal 'SELECT * FROM Orders' param([string]$Path, [string]$Literal) $bytes = [IO.File]::ReadAllBytes($Path) foreach ($offset in 0, 1) { $len = $bytes.Length - $offset $text = [Text.Encoding]::Unicode.GetString($bytes, $offset, $len - ($len % 2)) if ($text.Contains($Literal)) { "命中明文: $Path (offset=$offset)"; break } }挑三到五个「业务特征串」当探针：一条完整 SQL、一个接口域名、一句提示文案。三个全部扫不到，字符串加密这条就算通过。注意别拿太短的串当探针，两三个字符的残余在别的堆里也可能碰巧出现，误报会把你带沟里。
5.3 指标三：动态分析的时间成本
静态指标过了，还要看动态。三个动作，自己动手做一遍：附加调试器到受保护进程，预期是进程立即退出或弹授权失败；在Assembly.Load相关调用上下断点，预期是断不下来或者断了也看不到有意义的参数；用dotnet-dump抓一份内存转储，搜索刚才那几个探针字符串，预期是能找到——内存里必然是明文，这一条是提醒你「字符串加密只防静态不防动态」，别把它当万能药。
5.4 授权绕过测试矩阵
| 测试场景 | 预期结果 | 常见的翻车表现 |
|---|---|---|
| 拷贝到另一台机器 | 提示机器不匹配，进离线激活流程 | 直接可用，说明指纹没生效 |
| 系统时间回拨 30 天 | 进宽限期，不立即失效 | 直接判过期，误伤正常用户 |
| 删掉 license 文件 | 转试用期，剩余天数正确 | 崩溃或无限试用 |
| 关键功能入口二次校验 | 启动校验通过后仍拦截 | 只校验启动，改个返回值就绕过 |
| 试用期到期后改文件时间戳 | 仍然判定过期 | 只比对本地文件时间，可被伪造 |
这张表我每次发版前都会跑一遍，跑完再决定要不要加严。全部通过的方案不一定够强，但有任意一格翻车，说明这条授权链路基本没起作用。
6. 塞进 CI：双产物策略与发布前的一键校验
手工点工具这件事，只要重复三次就一定会有人漏点某个开关。我的做法是把保护工程保存成工具自己的项目文件，在 MSBuild 里挂一个发布后目标去调命令行，参数集中在这一个 target 里，改配置只改一处。
<!-- 发布后自动跑保护；具体开关以工具自带的命令行帮助为准 --> <Target Name="ProtectAssemblies" AfterTargets="Publish" Condition="'$(Configuration)' == 'Release'"> <Exec Command=""$(ProtectorExe)" --project "$(MSBuildProjectDirectory)\protect\app.ilproj" --output "$(PublishDir)protected"" ContinueOnError="false" /> <Error Condition="!Exists('$(PublishDir)protected\App.exe')" Text="保护产物缺失，构建中止" /> </Target>ContinueOnError="false"和后面那条Error是配套的：工具返回 0 但产物没生成的情况遇到过不止一次，只靠退出码判断会漏。另外记得给 CI 准备一份baseline产物同步归档——保护后的程序集行号全丢，线上崩溃只剩方法名和 token，没有基线符号表就只能靠猜。
真正让我改掉「最后一天再保护」这个习惯的，是一次线上事故：出包当天才开方法体加密，结果一个启动路径上的静态构造函数解密失败，日志里什么都没有，用户只看到白屏。从那以后我每次发版都强制走一遍「可读标识符占比 + 三个探针串 + 授权矩阵」这套动作，跑完才允许上传安装包。希望帮到你。
本文还有配套的精品资源，点击获取
