简介面向 .NET Reactor 4.9 及以下版本程序的脱壳工具包基于 de4dot 深度调整适合逆向分析人员、软件安全学习者以及需要处理加壳样本的程序开发者。压缩包共 51 个文件包含 32 位与 64 位两套可执行程序、配置文件、动态库、调试符号及说明文档整体仅 2.8MB轻量便携无需额外安装即可运行。目前已有 424 人学习下载多用于对 Reactor 加壳样本的快速解密与脱壳前后对比。包内除可直接运行的脱壳器外还附带了示例程序及相应调试符号便于观察程序集改名与去混淆变化示例输出可帮助新手快速掌握常见混淆特征与参数选择同时保留源码部分可查看 de4dot 的修改逻辑辅助理解 Reactor 的混淆与反调试机制也能基于此二次开发定制脱壳流程。适用于单个样本分析或多文件批量场景可有效缩短逆向处理时间。1. 拿到 .NET Reactor 4.9 加固的样本先分清壳和混淆再动手搞 .NET 逆向的同行都清楚.NET Reactor 这壳在商业软件里出现频率有多高。4.9 这个版本尤其典型加密、混淆、反调试、反篡改全给你招呼上扔进 dnSpy 里直接一堆乱码方法名和加密资源看了就头大。这份 de4dot Reactor v4.9 Mod by PC-RET 资源就是在 4.9 及以下版本里跟这壳硬碰硬的主力工具。它不是原版 de4dot而是在原版基础上针对 .NET Reactor 做过专项增强的修改版脱壳能力比重置版强不少。先说清楚它能解决什么把 Reactor 4.9 的代码加密层剥掉、字符串还原、资源解密让你在 dnSpy 里看到接近原始的可读代码。适合谁被 Reactor 壳堵住的分析人员、做恶意样本应急取证的人、还有需要批量处理加壳程序集的工具链开发者。2. de4dot Reactor v4.9 的资源包拆解每个文件是干什么的心里要有数2.1 拿到压缩包先别急着双击先看文件清单再定策略解压之后你会看到一整套文件这里我不建议直接双击de4dot.exe就开干。先花三十秒把包内结构过一遍搞清楚这包里哪些是工具本体、哪些是辅助文件、哪些是测试样例能帮你省掉后面一堆莫名其妙的报错。我把这个包里的关键文件按用途拆成三组你在实际使用前先对照一下文件用途使用时机de4dot.exe / de4dot-x64.exe主程序x86 和 x64 两个版本分析 32 位程序集用前者64 位优先用后者de4dot.pdb / de4dot-x64.pdb调试符号文件需要调试 de4dot 本身或崩溃排查时才用得上de4dot.exe.config / de4dot-x64.exe.config运行时配置文件控制 CLR 版本和运行时行为Test.Rename.exe / Test.Rename.Dll.dll带壳测试样例先用它练手验证工具可用性LICENSES许可证声明确认你能否用于商业环境这里面容易忽略的是.config文件。de4dot 是基于 .NET Framework 的工具如果目标机器上装了高版本 .NET配置不对会直接闪退或者报Could not load file or assembly。我一般会把supportedRuntime那一节确认好再跑正式的脱壳命令。2.2 de4dot 脱壳的核心机制它到底在黑匣子里做了什么de4dot 能脱掉 .NET Reactor不是靠暴力补丁而是靠一套「识别 → 剥壳 → 解密 → 重写」的流程。首先是PE 头部解析与程序集元数据扫描de4dot 加载目标程序集后会用特征匹配引擎扫描方法体里的加密和解密逻辑识别出这个程序集用的是哪种保护器、哪个版本。这也是为何这个修改版叫 Reactor v4.9它内置了针对 Reactor 4.9 的调优特征库识别率比通用版高。紧接着是剥离外层壳代码把加密的入口点、反调试的垃圾指令、控制流混淆的跳转全部替换为标准 IL。这步做完程序集已经能在 dnSpy 里打开了但代码还是加密态。之后是解密阶段de4dot 会动态调用壳的解密函数把加密的字符串、资源、方法体逐个还原。最后重写并输出为新的程序集顺手清理掉多余的元数据。有一点你要知道de4dot 对 .NET Reactor 的字符串解密依赖内置的算法模拟器。Reactor 4.9 换了几种流加密模式有的样本跑完字符串还是乱的。这属于正常情况后面第 4 章我会专门说怎么处理这种残留。2.3 32 位和 64 位用哪个先看目标程序集别靠猜包里de4dot.exe和de4dot-x64.exe并存不是随机的。脱壳工具本身的位数不一定要和目标程序集一致但如果目标程序集是 x64 的你最好用 x64 版本的 de4dot。原因有两个一是 x64 版本的工具在解析 x64 PE 文件的导入表时更稳二是某些 .NET Reactor 加固代码包含原生 x64 指令32 位工具对这部分解析有限。你可以在命令行里先查一下目标程序集的位数corflags Test.Rename.exe看输出里的32BITREQ和PE32标志。如果PE32且32BITREQ0那是 AnyCPU两者皆可PE32就是纯 64 位这时我建议直接用de4dot-x64.exe。这步做完工具选型不会翻车。3. 实战脱壳 .NET Reactor 4.9命令行参数、批量处理和输出物验证3.1 最小可用命令一条命令干掉常见壳配置先把最简单的跑通再研究花式参数。在命令行里进入解压目录执行de4dot-x64.exe C:\samples\Test.Rename.exe -o C:\samples\Test.Rename.de4dot.exe参数说明第一个参数是目标程序集路径必须是文件路径不接目录-o指定输出文件路径不写的话默认是原文件名加-de4dot后缀输出路径不能和输入路径相同否则会报错拒绝覆盖跑完之后你会看到一堆日志重点看最后几行如果出现Cleaning和Saving且无 ERROR说明脱壳流程走完了。紧接着做一次验证把输出文件拖进 dnSpy看方法名是否可读、字符串是否明文。这一步不能省脱壳成功与否的判定标准是输出物可读不是工具报没报错。3.2 force 参数当你觉得没脱干净先别怀疑人生.de4dot 有时会因为特征库没命中而跳过某些保护模块这时候输出文件虽然生成了但代码还是花的。常见做法是加--force强制走完整解密流程de4dot-x64.exe C:\samples\Test.Rename.exe -o C:\samples\out.exe --force--force的作用是忽略 de4dot 内部的一些安全性检查强制对所有可疑模块执行解密和反混淆。代价是误脱概率上升如果碰上不是 Reactor 壳的程序集可能会把正常代码改坏。所以我一般只在确认壳是 Reactor 但默认结果不理想时才加这个参数。要注意--force不是万能丸。如果加了 force 字符串还是加密的说明这个样本可能用了 4.9.1 以上版本的加密算法或者把关键函数标记了跳过。这时候先看日志里有没有Skipping method之类的提示。3.3 批量脱壳用循环命令处理一整个目录的样本做样本分析时经常会遇到成批的加壳程序集。逐条手敲命令显然不现实。de4dot 支持直接传目录它会递归处理目录下所有 .exe 和 .dllde4dot-x64.exe C:\malware_samples\2025\packed -o C:\malware_samples\2025\unpacked但这里有个坑输出目录不能是输入目录的子目录否则会边读边写导致文件损坏。我的习惯是建一个完全独立的输出目录然后注意控制台输出的 SUCCESS 或 FAILED 标记。如果想把日志存下来方便后面核对哪些成功哪些失败de4dot-x64.exe C:\samples\dir -o C:\output\dir C:\logs\de4dot_log.txt 21这样批处理的结果会被完整记录之后用 grep 或 findstr 筛出失败的样本单独处理效率比肉眼瞪控制台高多了。3.4 解密参数组合把常用的几个配置焊成固定命令de4dot 的参数很多但日常对付 Reactor 4.9 我基本只用这几个--dont-rename保留原名方便对照原程序集、--keep-names保留某些名字避免破坏反射、--preserve-tokens保留元数据 token 以便和原始程序集做差异对比。我常用的完整命令组合如下de4dot-x64.exe C:\samples\Target.exe -o C:\samples\Target.clean.exe --preserve-tokens --dont-rename参数拆解--preserve-tokens保留原始元数据的 token 值后面做 A/B 对比时能准确对上方法。--dont-rename跳过重命名阶段只脱壳不混淆改名适合需要保留原始方法名做对照的场景。如果你不需要对照想让它顺手把混淆的方法名也重命名为可读形式就卸掉--dont-rename。这个看使用场景没有绝对优劣。4. 常见问题与避坑指南五个脱壳翻车现场复盘4.1 现象程序集直接报错Invalid access to memory location跑 64 位样本时偶发这个错。刚开始我还以为是工具损坏后来反复测试发现主要原因是用 32 位 de4dot.exe 去处理 PE32 程序集导致的内存寻址异常。解决方式很简单换de4dot-x64.exe跑同类样本。如果已经换了还是报错把输入程序集的强名称签名先移除再重试方法是用sn.exe -Vr跳过验证签名sn.exe -Vr C:\samples\Target.exe这里说明一下这个操作只是让 CLR 跳过对程序集强名称签名的验证不是修改文件内容。4.2 现象脱壳完成后代码仍不可读字符串全乱码.NET Reactor 4.9的字符串加密有时候混合了多种算法de4dot 内置的解密器认不全。遇到这种情况先别急着下结论说工具不行。先看日志里有没有Decrypting strings失败或者Unknown string encoding的告警。如果是就把脱壳输出后残留的乱码字符串记录下来在 dnSpy 里手动搜索引用定位到解密函数后手动还原。这活虽然麻烦但常见的编码格式是 Base64 XOR能手工解。如果日志干净但输出还是乱码大概率是加壳时选用了硬件级加密或外部依赖de4dot 不负责这层。4.3 现象脱壳后的程序集运行时崩溃报Method not found这个坑通常出现在资源被解密但部分方法体仍引用壳内私有类型时。de4dot 重写程序集时如果没能完全解析壳的类型引用输出的 IL 会留下悬空引用。解决办法是在脱壳前先把目标程序集的引用程序集都放在同目录下de4dot 解析依赖时能找到它们。另一个常见做法是脱壳后不要直接运行先用 dnSpy 打开检查发现悬空引用再补一个--keep-types参数重新跑一遍。4.4 现象控制台刷屏报ERROR: Invalid PE file八成原因是输入文件本身不是有效 PE或者文件被加密压缩过甚至不是 .NET 程序集。先确认壳类型再谈脱壳别拿脱壳器去解压缩包。可以用 Detect It Easy 扫一下如果是打包器而不是 .NET 保护壳那就该先走 unpack 流程而不是直接用 de4dot。4.5 现象加了--force后输出文件比原文件还大这是反混淆修改了多处内联代码导致的正常膨胀不是错误。.NET Reactor 会把大量方法内联进壳的启动逻辑脱壳时 de4dot 会把这些内联代码还原成标准调用程序集体积变大是合理的。如果体积翻了 3 倍以上检查是不是把资源也重复解密了加--dont-resolve-resources试试。5. 进阶使用把 PDB、Test.Rename 样例和命令行组合成快稳准的脱壳流水线5.1 用包内 Test.Rename 样例做回归验证换配置前先跑基线包里自带Test.Rename.exe和Test.Rename.Dll.dll别当演示文件忽略掉这是 PC-RET 专门用来验证工具可靠性的回归样本。我每次拿到新环境或准备批量处理前都会先跑一遍这个样例de4dot-x64.exe C:\unpacker\Test.Rename.exe -o C:\temp\Test.Rename.out.exe --preserve-tokens跑完看输出的Test.Rename.out.exe能否在 dnSpy 里完整展开所有方法。基线通过后再上真实样本能帮你隔离是工具问题还是样本问题。这个习惯能省下大量排查时间。5.2 输出物对比验证技巧dij 和 token 对照定位残留脱壳是否干净的验证我习惯用--preserve-tokens脱壳后的程序和原始加壳程序做对比。在 dnSpy 里同时打开原文件和输出文件选同一个方法对比 IL。如果两边 IL 结构一致说明这个方法没有被解密壳逻辑还残留着。此时需要回到原程序集找到壳的解密分支看它是如何调度该方法的。这个方法有点土但对付 Reactor 4.9 的混合加密特别有效。很多壳会把部分敏感方法藏在资源段等到运行时再动态加载这类方法在静态脱壳输出里根本不存在。要处理只能靠动态调试配合de4dot 本身不负责这层。5.3 从杂乱到可维护把这套流程固化成两行命令真实项目里你不会每拿到一个样本都重新想一遍参数。我最后分享一下我的个人习惯我会在解压目录里维护一个批处理脚本内容固定为echo off set INPUT%1 set OUTPUT%~n1.de4dot.exe de4dot-x64.exe %INPUT% -o %OUTPUT% --preserve-tokens --dont-rename echo DONE: %OUTPUT%以后拿到新样本只需要拖进去跑一下输出文件名自动跟原文件名走不会覆盖源文件。从那以后我每次处理 .NET Reactor 的程序集都会强制走一遍这个命令再手动检查一遍 dnSpy 里的字符串和方法可读性。稳定可靠的脱壳靠的是一套不依赖运气的流水线而不是靠反复换工具碰运气。希望这份使用笔记能帮你在处理 Reactor 4.9 脱壳的时候少踩几个坑顺利拿到可分析的代码。本文还有配套的精品资源点击获取