简介：面向需要保护 .NET/C# 程序集的开发者与安全测试人员，IntelliLock 1.7 工具包围绕加壳、混淆、加密和许可证管理提供一套较完整的代码防护方案，可用于降低 Reflector 等反编译工具对核心逻辑的直接解析风险。压缩包共 21 个文件、约 7.98MB，以 10 个 DLL 组件为主，配合 EXE 主程序、CONFIG 配置、DAT 数据库、ICO 图标、JPG 说明图、LNK 快捷入口、TXT 清单与 CHM 帮助文档，覆盖运行、配置、Visual Studio 集成和 SDK 示例等用途。已有 2822 人学习下载。读者可据此了解程序集加壳与加密的配置方式，借助混淆重命名、控制流变形增加逆向难度，并通过许可证管理组件、SQLite 数据支持和示例工程入口，完成从保护策略设置、敏感数据加密到对关键算法和许可证信息进行保护，再到集成验证的完整参考，适合具备一定 C#/.NET 基础、关注知识产权保护与发布安全的中高级开发者。

1. 反直觉的版本坑：IntelliLock 1.7 装得上，程序不一定能跑

上周帮人看一个 C# 桌面端的加壳问题。项目本来是 .NET Framework 4.8 的 WinForms，后来有人手快把一部分工程挪到了新运行时，再用 IntelliLock 1.7 做 C# 代码保护，加壳进度条一路走到 100%，出来的 exe 双击直接退出，连异常框都没有。这类翻车在 C# 加壳、混淆、加密这条线上特别常见——工具装得很顺，问题全出在目标程序集和目标运行时对不上。IntelliLock 1.7 这套东西在 .NET Framework 2.0/3.5/4.x 的托管程序集上算成熟方案，混淆、字符串加密、加壳、授权绑定能一次配完；但它不是万能壳，对新的运行时基本没辙。这篇写给我自己复盘，也写给第一次装这套工具、准备给自家 DLL 和 EXE 上保护的开发者。

2. 环境清单先列清：IntelliLock 1.7 的运行时依赖与安装路径

装这类工具最怕的是「装完了才发现方向就不对」。我一般不在装完之后才去确认目标程序集是什么运行时，而是把这一步提到最前面，因为 IntelliLock 1.7 只处理托管程序集，而且只认 .NET Framework 那一代。你手上如果是 .NET Core、.NET 5/6/7/8 的项目，或者用了单文件发布、AOT 编译，那这套流程从第一步就走不通，后面所有参数调优都是白费功夫。所以这一章先把环境按表格列清楚，再落地安装。

2.1 工具版本与目标程序集的对照表

我这边实际跑通的组合是这样，照着对一遍基本不会踩空：

表里最后一行不是洁癖。我见过安装目录带中文导致工程文件读写异常、构建时提示找不到临时文件的情况，改回纯英文路径立刻正常。这类问题不会在安装时报错，只会在你构建到一半的时候突然给你一下。

2.2 装之前先跑三条检查

不要急着双击安装包，先在目标机器上把这三条命令跑一遍，省得后面来回折腾。

# 1) 查本机 .NET Framework 4.x 的发布版本号（Release 键值） (Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full' -ErrorAction SilentlyContinue).Release # 2) 查系统架构，决定加壳产物对齐 x86 还是 x64 [Environment]::Is64BitOperatingSystem # 3) 查目标程序集的运行时版本，确认它是 Framework 而不是新运行时 [System.Reflection.AssemblyName]::GetAssemblyName('D:\work\DemoProtect\bin\Demo.exe').ImageRuntimeVersion

第一条读注册表里的 Release 值，这是判断 .NET Framework 版本最可靠的方式，比看控制面板里的功能列表准。对照关系记几个常用的就够：461808 是 4.7.2，528040 及以上是 4.8，533320 是 4.8.1。返回值空或者报错，说明 4.x 运行时根本没装，先把运行库补上再谈安装工具。

第二条决定后面加壳时目标平台怎么选。开发机是 x64，但客户现场很可能还有 32 位的老机器，AnyCPU 在这类场景里经常出问题，所以我在工程里会显式指定平台，而不是交给默认值。

第三条返回 v4.0.30319 一般对应 Framework 4.x，返回 v2.0.50727 对应 2.0/3.5。注意这个字段对新运行时也会返回 v4.0.30319，所以还要多看一步：目标目录里如果有.deps.json或runtimeconfig.json，那就是新运行时的产物，直接放弃这套方案，别浪费时间。

2.3 安装过程：六步，别跳

清单不长，但每一步都有它的道理，跳过哪一步后面都要补回来。

1. 把杀毒软件的实时防护对安装目录做排除。加壳工具的行为特征和恶意程序高度相似，压缩、加密、改写 PE 头，启发式引擎十有八九会拦。不是关掉防护，是把安装目录和产物目录加进白名单。
2. 校验安装包完整性。拿到安装包先算一次哈希，和来源方给的比对，内网分发尤其要做，半截文件装出来的问题最难查。
3. 右键以管理员身份运行安装程序。普通权限装完，注册表项写不全，后面构建会报权限错误。
4. 安装路径手动改成D:\Tools\IntelliLock，不要用默认的 Program Files 路径。Program Files 有 UAC 虚拟化，工具往自己目录写临时文件和日志的时候容易写到 VirtualStore 里去，排查起来极其难受。
5. 装完先别急着建工程，直接启动一次主程序，确认界面能正常打开、菜单能点。
6. 在安装目录里确认命令行工具的存在。命令行可执行文件的命名在不同小版本之间有差异，我这边的目录里能看到带 CommandLine 字样的那个，以你实际安装出来的文件为准，别照抄文件名。

第 4 步是我踩过坑之后形成的习惯。早期图省事用默认路径，结果工具生成的中间文件被重定向到用户目录下，构建成功但产物找不到，翻了半天才在%LOCALAPPDATA%\VirtualStore里发现。从那以后所有这类需要写自身目录的工具，我一律装到D:\Tools下。

2.4 首次启动：授权导入与两个全局开关

第一次启动一般会提示授权。有正式授权的，按界面提示导入授权文件，工具会把它和机器特征绑定；没有授权的会进试用模式，产物上会带标记，这个不要想着绕，带标记的产物在客户那里可能直接被拦。授权导入后重启一次工具，让配置生效。

第二个要处理的是自动更新检查。内网机器、离线机器一定要在设置里把这个关掉，否则每次启动工具都要卡几秒等超时，构建脚本里调用命令行工具时更明显，一个循环跑二十个 DLL，光超时就能耗掉几分钟。

第三个是临时目录。默认临时目录在系统盘，加壳过程会产生几倍于原文件大小的中间文件，系统盘紧张的时候会直接失败，报错信息还很不直观。我在设置里把工作目录指到D:\work\il-temp，并且保证这个目录所在磁盘有至少 2 GB 余量。

这三件事做完，环境这一层就算稳了。接下来才是真正容易出错的地方——工程配置。

3. 工程配置写进文件：把混淆、加密、加壳参数固化下来

界面点一遍能出产物，但下周再点一遍，参数就未必一样了。这是我坚持用工程文件驱动的原因：所有开关落在.ilproj里，进版本库，谁构建都是同一套参数。这一章讲清楚每个开关到底改了什么，再给一条能塞进构建脚本的命令行。

3.1 新建工程：先加 EXE，再加依赖 DLL

新建工程的顺序有讲究。先加主程序 EXE，再把它引用的业务 DLL 一个个加进来，最后才是第三方库。原因是工具在解析程序集引用关系时，主程序的引用链是根，先有根再加叶子，合并和重命名映射才不会有遗漏。

工程文件默认保存成.ilproj后缀（以你安装版本实际保存的类型为准），我一般放在解决方案根目录下，和.sln平级，命名跟主程序一致，比如DemoProtect.ilproj。这个文件是纯文本，可以直接进 Git，改参数走 diff，比截图记录靠谱得多。

加 DLL 的时候有一条经验：只加自己写的业务程序集。第三方库、日志库、JSON 序列化库这些不要动。原因有两个，一是混淆后的第三方库出了问题你没法排查，二是很多库内部用反射找自己的类型，重命名之后直接崩。

3.2 六个关键开关的取舍

这一节是重点，每个开关都对应一个具体后果，不是开得越多越安全。

混淆强度的原理是重命名元数据里的类型名、方法名、字段名，再加一层控制流混淆，把方法体拆成跳转片段。强度拉满的时候，连编译器生成的闭包类、匿名类型、迭代器状态机都会被改名，而这些东西恰恰是序列化和反射最容易依赖的。所以我的做法是中档起步，跑通全流程之后再逐项往上加，每加一档做一轮回归，出问题立刻能定位到是哪个开关。

字符串加密解决的是最尴尬的一类泄露：反编译工具打开 DLL，SQL 语句、接口地址、密钥提示语全是明文，连分析都不用分析。开了之后这些常量会被加密存放，运行时按需解密。代价是启动时多一次解密，以及某些反射取常量值的代码路径会失效，这类地方要单独测。

反调试和外发版本的关系要说清楚。开发阶段必须关掉，不然你连附加进程都做不到，出问题只能靠日志猜。外发版本开，但要接受一个事实：它会误伤一部分客户环境，尤其是装了企业级终端防护的机器。这块没有完美方案，我的做法是提供两个构建产物，一个内测包不带反调试，一个外发包带，客户报问题时先让他们换内测包复现。

程序集合并是个双刃剑。合并之后所有业务 DLL 变成一个文件，部署简单，反编译也更难拆分。但合并会改变Assembly.Load的解析路径，插件式架构、动态加载、AppDomain隔离这些场景基本都会挂。有插件机制的项目，这个开关直接关掉。

3.3 命令行构建：把界面操作变成可重复的一行命令

界面配置好之后，先手动构建一次，确认产物正常，再把同样的参数搬到命令行。命令行工具的参数在不同小版本之间有差异，所以第一步永远是看帮助。

# 先看命令行工具支持哪些开关，参数名以实际输出为准，别照抄 & "D:\Tools\IntelliLock\IntelliLock.CommandLine.exe" /? # 用工程文件驱动一次完整构建：/project 指定工程，/build 触发构建 & "D:\Tools\IntelliLock\IntelliLock.CommandLine.exe" ` /project "D:\work\DemoProtect\DemoProtect.ilproj" ` /build

第一行的作用是探路。我这里写的/project、/build是常见形式，但不同版本可能用-p、--project或者别的写法，先跑一次帮助把所有可用开关列出来，再照着写脚本，比事后对着一堆报错猜参数名高效得多。

第二行是完整构建，/project指向工程文件，/build表示按工程里保存的配置执行。注意这里没有指定输出目录，输出路径是在工程配置里定死的，这也是我坚持把配置写进文件的原因——命令行不需要重复传参，就不会出现「界面构建和脚本构建产物不一致」的问题。

如果只想处理单个程序集，常见做法是加一个指定输入文件和输出路径的参数组合，把源目录和输出目录严格分开：

# 单文件处理：输入和输出必须分开目录，避免对已加壳文件二次处理 & "D:\Tools\IntelliLock\IntelliLock.CommandLine.exe" ` /project "D:\work\DemoProtect\DemoProtect.ilproj" ` /assembly "D:\work\DemoProtect\bin\Demo.exe" ` /output "D:\work\DemoProtect\protected\Demo.exe"

/assembly是待处理的源文件，/output是产物路径。这两行看着简单，但源目录和输出目录一定不能是同一个，否则第二次构建的时候会把上次的加壳产物当成源文件再处理一遍，出来的东西必然起不来，而且报错信息完全看不出是这个原因。

脚本里还要加一层保险：构建前清空输出目录。PowerShell 里一句Remove-Item "D:\work\DemoProtect\protected\*" -Recurse -Force -ErrorAction SilentlyContinue就够，保证每次拿到的都是这次构建的产物，而不是新旧混在一起。

3.4 两套配置分档：内测档和外发档

配置不要只有一套。我一般维护两份工程文件，一份DemoProtect.Debug.ilproj，反调试关、混淆中档、保留完整异常信息；一份DemoProtect.Release.ilproj，反调试开、混淆高档、字符串和资源都加密。两份的差异写在一个说明文件里，进版本库。

这么做的直接好处是排障效率。客户报「程序启动闪退」，你让他换内测包，如果内测包也闪退，问题在业务代码；如果内测包正常、外发包闪退，问题在保护配置，范围立刻缩到几个开关上。没有这两套包，所有问题都要从零开始猜。

维护成本也不算高，两份工程文件的差异通常只有五六个字段，改动的时候一起改，跑一次对比构建就能确认差异符合预期。

4. 加壳落地：EXE 与依赖 DLL 分开处理才不出事

前面都是准备，这一章开始动手。流程本身不复杂，复杂的是各种边界情况——主程序和依赖库处理方式不一样，强名称项目有额外步骤，批量处理还要防止重复加工。我按实际操作的顺序拆开写。

4.1 动手前先做全量备份和基线快照

这一步不能省，而且要做得彻底。备份的不是源码——源码在版本库里——备份的是未加壳的构建产物。我在D:\work\DemoProtect下固定建三个目录：bin放原始产物，protected放加壳产物，baseline放一份原始产物的只读副本。

baseline的作用是随时能够对比。加壳后程序出问题，最常见的排查动作就是拿原始文件和加壳文件做对照：节表变化、文件体积、能不能反编译、字符串是不是明文。没有基线，你连「变化是不是加壳带来的」都判断不了。

顺手把原始产物的哈希记下来：

# 记录原始产物哈希，作为后续比对的基线 Get-ChildItem 'D:\work\DemoProtect\bin\*.exe','D:\work\DemoProtect\bin\*.dll' | Get-FileHash -Algorithm SHA256 | Select-Object Hash, Path | Export-Csv 'D:\work\DemoProtect\baseline\hash-before.csv' -NoTypeInformation -Encoding UTF8

Get-FileHash算 SHA256，Export-Csv落盘成表格，-Encoding UTF8保证中文路径不出乱码。后面每次构建完跑一遍同样的命令导到hash-after.csv，两个文件一比就知道哪些产物真的重新生成了，哪些是残留的旧文件。

4.2 主程序 EXE 的处理流程

主程序是入口，处理顺序上放第一个。在工程里选中主程序集，确认几个关键项：目标平台（按实际部署环境选 x86 或 x64，别用 AnyCPU）、入口点保留、程序集名称保留。

程序集名称必须保留。有些项目为了「更难猜」会把程序集名也混淆掉，结果配置文件里的configSections、绑定重定向、app.config里的程序集全名全部对不上，启动直接失败。界面上如果有「保留程序集名称」这类选项，勾上。

EXE 处理完先单独验证一次，别急着处理 DLL。做法是直接双击运行，走一遍最短的业务路径：能启动、能登录、能打开主界面。这一步失败的话，问题一定在主程序的保护配置上，和 DLL 无关，范围小得多。

我一般在这个阶段会额外看一眼进程能不能正常退出。有些配置下程序能启动但退出时卡住，原因通常是反调试或者资源解密线程没有正确结束，这种问题在功能测试里很容易漏掉，客户用一段时间才发现。

4.3 依赖 DLL 的批量处理

业务 DLL 一多，手工一个个加不现实，写个循环。核心是跳过列表——第三方库和框架程序集一律不处理。

# 批量处理业务 DLL：跳过第三方库，输入输出目录严格分离 $src = 'D:\work\DemoProtect\bin' $out = 'D:\work\DemoProtect\protected' $skip = @('JsonLib.dll', 'LogLib.dll', 'ReportLib.dll') # 第三方库不处理 Get-ChildItem -Path $src -Filter *.dll | Where-Object { $skip -notcontains $_.Name -and $_.Name -notlike 'System.*' } | ForEach-Object { $target = Join-Path $out $_.Name & "D:\Tools\IntelliLock\IntelliLock.CommandLine.exe" ` /project "D:\work\DemoProtect\DemoProtect.ilproj" ` /assembly $_.FullName ` /output $target # 每个产物单独记录退出码，失败的单独重跑，不要整批重来 "{0} -> exit {1}" -f $_.Name, $LASTEXITCODE }

$skip是白名单机制，只处理自己写的库；-notlike 'System.*'再排除掉框架程序集。Join-Path拼输出路径，保证和源目录不重名冲突。最后一行的$LASTEXITCODE是关键——命令行工具处理失败不一定抛异常，可能只是返回非零退出码然后继续下一个，不打出来你根本不知道哪个失败了。

$LASTEXITCODE每个循环都要读，因为它是上一条外部命令的退出码，被下一条命令覆盖，所以必须紧跟在调用之后输出，不能攒到最后统一看。

批量跑完再统一验证。我习惯先做一次「能不能加载」的粗测：写个小脚本用反射加载每个产物，能加载出程序集名称就算过了第一关。加载不了的，多半是依赖没跟上或者加壳参数不对，单独拿出来查。

4.4 强名称签名的先后顺序

启用强名称的项目有个固定顺序问题：加壳会改写文件内容，原来的强名称签名必然失效，所以必须在加壳之后重新签名，而不是之前。

流程是这样：加壳 → 用原来的.snk密钥文件重新签名 → 验证签名有效性。

# 加壳后重新签名，密钥文件用项目里原来那个，不要重新生成 & "C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.8 Tools\sn.exe" ` -R "D:\work\DemoProtect\protected\Demo.dll" ` "D:\work\DemoProtect\keys\Demo.snk" # 验证签名是否有效 & "C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.8 Tools\sn.exe" ` -v "D:\work\DemoProtect\protected\Demo.dll"

-R是重新签名到已有文件，-v是验证。SDK 工具路径按本机实际安装位置改，找不到就用where.exe sn搜一下。

这里有个容易忽略的点：重新签名必须用原来那个.snk。换一个新密钥文件，签名是有效的，但程序集全名变了，所有引用它的地方——包括主程序的绑定重定向、配置文件里的全名引用——全部失效。现象是主程序启动报「无法加载文件或程序集」，而 DLL 单独看完全正常。

还有一种情况是工具本身提供了「构建后自动重签」的选项。有就勾上，比脚本里手动补一步可靠。没有的话，就在构建脚本里固定加这一步，别指望人记住。

5. 避坑与排查：五个装完才暴露的问题

这一章是血泪经验集。下面这几条都是装完、配完、构建成功之后才暴露的，装的时候一切正常，出问题的时候毫无头绪。

5.1 安装与启动阶段

现象一：安装包刚解压就被杀软删掉，或者装到一半安装程序消失。

原因：加壳工具的行为特征——压缩、加密、改写 PE 头——和恶意程序的启发式特征高度重合，终端防护直接在文件落地时就隔离了。

解决：把安装目录D:\Tools\IntelliLock、工程目录、产物目录三个路径都加进排除项，然后重新解压安装。不要去关整台机器的实时防护，那是给自己挖坑。内网分发的场景更要注意，产物从开发机拷到测试机的时候也会被拦，测试机同样要加排除。

现象二：双击主程序没反应，或者弹「应用程序无法正常启动」。

原因：两种情况。一是 .NET Framework 运行时没装全，工具本身是托管程序，缺运行库连错误框都弹不出来；二是安装路径里有中文、空格或特殊字符。

解决：先跑 2.2 节那三条检查命令确认运行时，没装就补 4.x。运行时没问题的话，卸载重装到D:\Tools\IntelliLock。我遇到过路径里带一个空格导致临时文件写入失败的，报错信息完全指向别的地方，查了两个小时。

现象三：界面能打开，但一点「新建工程」就卡死或者报错退出。

原因：临时目录所在磁盘空间不足，或者临时目录没有写权限。加壳过程中间文件能达到原文件的数倍。

解决：在设置里把工作目录改到空间充足的盘，确认当前用户对该目录有完全控制权限。同时把系统盘的临时目录也清一遍，有些组件还是会往%TEMP%写东西。

5.2 构建阶段：构建成功但程序起不来

现象四：加壳后的 exe 在开发机正常，拷到客户机器启动就闪退。

原因：开发机装了完整 SDK，客户机只有运行时；或者产物是 AnyCPU，在 32 位系统上加载方式不同；再或者客户机缺某个 VC++ 运行库。还有一个很隐蔽的原因——反调试开关在客户机的终端防护环境下被误触发。

解决：加壳时显式指定目标平台，不要留 AnyCPU。用内测包（反调试关）在客户机上复现一次，能跑起来就说明是反调试误伤，外发包把这项关掉或者换一种强度。同时用 Windows 事件查看器看应用程序日志里的 .NET Runtime 错误，绑定失败的详情都在里面。

# 查最近的应用程序错误日志，加壳后闪退的详细堆栈一般在这里 Get-WinEvent -LogName Application -MaxEvents 30 | Where-Object { $_.ProviderName -match 'NET Runtime|Application Error' } | Select-Object TimeCreated, ProviderName, Message | Format-List

-MaxEvents 30控制数量，-match过滤出运行时和应用错误两类，Format-List让长消息完整显示而不是被截断成一行。闪退类问题没有这个日志基本没法查。

现象五：命令行构建出来的产物和界面构建的不一致，体积差很多。

原因：命令行调用时没有加载工程里的完整配置，或者输出路径指到了源目录，导致对已经加壳的文件又处理了一遍，二次加壳。

解决：固定用同一个工程文件和同一个输出目录，构建前清空输出目录。判断是不是二次加壳，看文件体积——二次加壳的产物通常比正常产物大一圈，而且启动必然失败。养成构建前跑一次哈希对比的习惯，能提前发现这类问题。

5.3 运行与分发阶段：只在特定场景出问题

现象六（补充）：插件式架构下，动态加载的类型全部找不到。

原因：混淆把反射用到的类型名、方法名改了；或者程序集合并之后，Assembly.Load的解析路径变了。

解决：在配置里找到重命名排除列表，把反射用到的类型、接口、枚举、特性类全部加进去。有插件机制的项目，程序集合并选项直接关掉。这块没有捷径，只能按业务里实际的反射点一个个补，补完跑一轮完整的插件加载测试。

6. 装完怎么验证：三个动作确认保护真的生效

装完、配完、构建成功，这三件事加起来不等于保护生效。我见过不少情况是产物确实变大了，但反编译一下方法体原封不动，等于白做。验证这一章按静态、动态、清单三块来，都是能重复执行的。

6.1 静态验证：哈希、节表、IL、字符串

第一件事是对比哈希和体积，确认产物真的是这次构建生成的，不是复用的旧文件。

# 加壳前后对比：体积、哈希，确认产物是重新生成的 $before = Get-Item 'D:\work\DemoProtect\bin\Demo.exe' $after = Get-Item 'D:\work\DemoProtect\protected\Demo.exe' [pscustomobject]@{ SizeBefore = $before.Length SizeAfter = $after.Length HashBefore = (Get-FileHash $before.FullName -Algorithm SHA256).Hash HashAfter = (Get-FileHash $after.FullName -Algorithm SHA256).Hash }

哈希不同是基本要求，相同说明文件根本没被处理。体积变化不要求有固定比例，加壳后变大是常态，但突然变大好几倍就要警惕是不是二次加壳。

第二件事看节表。用dumpbin /headers分别看原始文件和加壳文件，对比节区数量、名称、大小和特征值。

# 对比加壳前后的 PE 节表，看 .text 节的体积和特征是否变化 dumpbin /headers "D:\work\DemoProtect\bin\Demo.exe" | Select-String -Pattern 'section' dumpbin /headers "D:\work\DemoProtect\protected\Demo.exe" | Select-String -Pattern 'section'

dumpbin需要 VS 开发者命令环境，或者用完整路径调用。加壳之后节区的数量、大小或名称通常会发生变化，这是 PE 层被改写的直接证据。如果两边节表一模一样，说明加壳根本没生效。

第三件事最有说服力：拿反编译工具打开加壳后的程序集，看业务方法体还能不能还原。

# 用 ildasm 把加壳后的程序集导出成 IL，检查关键方法体是否可读 & "C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.8 Tools\ildasm.exe" ` /out:"D:\work\ver\demo-protected.il" ` "D:\work\DemoProtect\protected\Demo.exe" # 对照：原始程序集的 IL & "C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.8 Tools\ildasm.exe" ` /out:"D:\work\ver\demo-origin.il" ` "D:\work\DemoProtect\bin\Demo.exe"

/out指定导出路径，两个文件分别导出后对比。原始文件的 IL 里能看到完整的方法体、局部变量、字符串常量；加壳后的文件里，业务方法体通常无法完整还原，或者导出过程直接报错，这都属于正常结果。ildasm 的路径按本机 SDK 实际位置改，找不到就搜ildasm.exe。

第四件事是字符串扫描，专门验证字符串加密有没有真的起作用：

# 扫二进制里的可打印 ASCII 串，检查业务提示语、接口地址是否还是明文 $bytes = [System.IO.File]::ReadAllBytes('D:\work\DemoProtect\protected\Demo.exe') $text = [System.Text.Encoding]::ASCII.GetString($bytes) [regex]::Matches($text, '[\x20-\x7E]{6,}') | Select-Object -First 40 -ExpandProperty Value

ReadAllBytes把整个文件读成字节数组，转 ASCII 字符串，正则[\x20-\x7E]{6,}匹配连续 6 个以上可打印字符。加壳前的产物里应该能直接看到「用户名或密码错误」「连接字符串」这类内容，加壳后应该搜不到。这一项最直观，也最能验证配置有没有真的被应用。

6.2 动态验证：把真实业务流程跑一遍

静态验证过了只是第一步。加壳最容易出问题的地方恰恰是运行时：反射加载、序列化、资源读取、异常处理，这些在静态上看不出问题，跑起来才知道。

我的做法是准备一份最短业务路径清单，每次构建后固定跑一遍：启动登录、查询列表、打开详情、导出文件、退出。五个动作覆盖了程序集加载、反射、资源读取、文件写入、线程退出这几类最容易出问题的环节。

跑完还要专门测一次授权。有授权绑定的项目，把系统时间往前调一天、或者把产物拷到另一台机器上运行，确认授权校验按预期失败而不是直接崩溃。校验失败应该有明确的提示，不能是未处理异常——这两者在客户现场的处理成本完全不同。

对象序列化也要单独测。混淆改了字段名之后，旧版本的序列化数据可能读不回来，这是升级场景里的经典问题。测试方法是拿一份旧版本产生的数据文件，用加壳后的新版本读一次，能正常反序列化才算过。

6.3 一份可以贴进 checklist 的验证表

把上面这些收敛成一张表，每次发版前逐项打勾，比凭记忆靠谱。

表里最后两项经常被跳过，但恰恰是客户投诉最多的地方。

说个自己的教训。早些年给一个桌面项目加壳，构建成功、静态检查全过、功能测试也过，直接发了外发包。结果上线第三天客户反馈，导出 Excel 的功能全部报错。查下来是导出模块用了反射找列头特性，特性类被重命名，反射拿不到。静态检查看不出，功能测试没覆盖导出，两个都漏了。从那以后我每次构建完，都强制走一遍这份清单，哪怕只是改了一个开关，也一项不落。加壳这事没有「应该没问题」，只有「验证过没问题」。希望帮到你。

本文还有配套的精品资源，点击获取