简介本资源为适配.NET Core平台的开源脱壳工具de4dot-netcore正式构建版本面向安全研究人员、逆向工程师及.NET开发者专用于剥离ConfuserEx、DNEmu、.NET Reactor等主流保护壳还原被混淆或加密的.NET Core程序原始逻辑支撑静态分析、漏洞挖掘与恶意软件取证。压缩包共48个文件含12个核心DLL如de4dot.dll、de4dot.cui.dll、dnlib.dll、6个PDB调试符号、5个缓存与配置文件.cache、.config、.json、2个可执行文件apphost.exe、de4dot.exe及多份许可证文本LICENSE*.txt、COPYING总大小1.87MB结构完整开箱即用。已有531人学习下载资源包含全量编译产物、运行时依赖runtimes目录、项目构建元数据.csproj.*、.editorconfig及源码级调试支持.cs、.pdb便于深度理解脱壳流程、定制修改或集成至自动化分析流水线。1. de4dot-netcore 版本别急着 dotnet restore先看清这三类“反编译失败”根本不是代码问题你刚拿到一个 .NET 程序集.dll 或 .exe想用 de4dot 做反混淆处理结果de4dot --help能跑但一上真实文件就卡在Loading assembly...、报Could not load file or assembly、甚至直接抛System.BadImageFormatException—— 这时候翻 GitHub Issues、查 Stack Overflow90% 的人第一反应是“是不是我文件坏了”“是不是加了壳”其实大错特错。真正拦路的八成是de4dot-netcore 版本和目标程序集的 .NET 运行时世代不匹配。比如你拿 .NET 6 编译的程序硬塞给只支持 .NET Core 2.1 的旧版 de4dot它连元数据都读不全反过来用最新版去处理 .NET Framework 4.7.2 的老程序又会因 CoreCLR 和 Desktop CLR 的 AssemblyLoadContext 行为差异直接崩溃。这套环境不是“装了就能用”而是必须按目标二进制的.NET version→de4dot-netcore runtime version→CLI 参数组合三者对齐。适合正在调试某跨平台系统遗留模块、需要还原某图像处理Demo 的混淆逻辑、或接手某实验室.NET 工具链二次开发的开发者——尤其当你发现反编译输出全是IL_0000: ldarg.0而没有方法名时别调代码先调版本。2. 下载与运行环境准备明确区分 de4dot-netcore 与传统 de4dot 的 Runtime 依赖de4dot 最早由 danielgibson 开发原生基于 .NET Framework只能在 Windows 上跑完整功能而de4dot-netcore是社区维护的跨平台重写分支核心价值在于它本身是一个 .NET Core / .NET 5 的自包含应用self-contained app不依赖系统全局安装的 .NET SDK但对目标程序集的兼容性反而更苛刻——它必须能用当前运行时加载并反射出目标程序集的元数据。因此环境准备不是“装个 dotnet 就完事”而是要分清三层依赖2.1 确认你的目标程序集到底是什么 .NET 版本别信文件属性里的“版本号”那只是编译器提示。真实版本藏在 IL 元数据里。最稳的方式是用ildasmWindows SDK 自带或dotnet ilspycmd跨平台检查# 方法一用官方 ilspycmd推荐无需 Windows dotnet tool install -g ilspycmd ilspycmd -p your_target.dll | head -n 20提示输出中找RuntimeVersion:字段。常见值有v2.0.50727.NET Framework 2.0–3.5、v4.0.30319.NET Framework 4.x、v6.0.NET 6、v7.0.NET 7、v8.0.NET 8。注意.NET 5的程序集RuntimeVersion显示为v6.0起但实际运行时是Microsoft.NETCore.App。2.2 选择匹配的 de4dot-netcore 发布版本de4dot-netcore并非单版本通吃。它的 GitHub Releases 页面https://github.com/de4dot/de4dot/releases明确标注每个 build 对应的 target runtime。截至 2024 年中主流可用版本如下表de4dot-netcore 版本发布时间内置 Runtime兼容目标程序集备注v4.0.0-beta12023-09.NET 6.0.NET 6 / .NET 7部分最稳定社区验证最多v4.0.0-rc12024-02.NET 7.0.NET 7 / .NET 8基础 IL对泛型约束、Source Generator 输出支持更好v3.1.412022-11.NET 5.0.NET 5 / .NET 6简单场景不推荐新项目已停止维护注意不要下载de4dot-4.x.x.zipFramework 版那是 Windows-only 的旧版解压后是.exe无法在 Linux/macOS 运行且对 .NET Core 程序集解析能力极弱。2.3 安装对应 .NET Runtime非 SDKde4dot-netcore是 self-contained但它的可执行文件如de4dot) 本质是dotnethost 的封装仍需系统级 runtime 支持。你不需要装 SDK但必须装对应版本的ASP.NET Core Runtime或.NET Runtime非 ASP.NET 的轻量版# Ubuntu/Debian以 .NET 6 为例 wget https://packages.microsoft.com/config/ubuntu/22.04/packages-microsoft-prod.deb -O packages-microsoft-prod.deb sudo dpkg -i packages-microsoft-prod.deb sudo apt-get update sudo apt-get install -y aspnetcore-runtime-6.0 # 注意这里装的是 aspnetcore-runtime-6.0不是 dotnet-sdk-6.0# macOSHomebrew brew tap microsoft/dotnet brew install dotnet-runtime-6.0 # 验证 dotnet --list-runtimes | grep 6.0 # 输出应含Microsoft.AspNetCore.App 6.0.x / Microsoft.NETCore.App 6.0.x关键逻辑de4dot-netcore v4.0.0-beta1内置 .NET 6但它启动时仍需系统存在Microsoft.NETCore.App 6.0.x。如果只装了 .NET 7 runtime它会 fallback 到dotnethost 的兼容模式但某些 AssemblyResolve 行为会异常比如找不到System.Runtime.CompilerServices.Unsafe。2.4 验证基础运行能力绕过反编译先测加载别急着-o out.cs。先用最小命令验证是否能无报错加载目标程序集# 下载 v4.0.0-beta1Linux x64 curl -L https://github.com/de4dot/de4dot/releases/download/v4.0.0-beta1/de4dot-4.0.0-beta1-linux-x64.zip -o de4dot.zip unzip de4dot.zip chmod x de4dot # 执行“空加载”测试不输出任何文件只触发 Assembly.LoadFrom ./de4dot --no-cache --verbose --method-renaming off --field-renaming off --property-renaming off --event-renaming off your_target.dll 21 | head -n 30预期成功日志片段[INFO] Loading assembly: your_target.dll [INFO] Target framework: .NET 6.0 [INFO] Detected obfuscator: ConfuserEx (v1.9) [INFO] Using deobfuscator: ConfuserExDeobfuscator若出现Could not load file or assembly System.Runtime, Version6.0.0.0说明 runtime 版本没装对若卡在Loading assembly...超过 30 秒大概率是目标程序集用了ILPack或Costura.Fody合并了依赖需加--merge参数见第 4 章。3. 核心配置与参数详解从“能跑”到“跑对”的七组关键开关de4dot-netcore的 CLI 参数表面简单实则每组都在操控底层 AssemblyLoadContext、IL 解析策略和符号还原逻辑。很多“反编译出来全是 a,b,c 变量名”的问题根源不是混淆强而是参数没关对。以下七组参数按使用频率排序每组附真实场景说明。3.1--target指定目标框架类型不是可选项默认--target auto会尝试自动探测但对混合框架如 .NET Standard 2.0 库被 .NET 6 主程序引用极易误判。必须显式指定# 正确目标为纯 .NET 6 程序集 ./de4dot --target net6.0 your_app.dll # 正确目标为 .NET Framework 4.8即使你在 Linux 上跑 de4dot ./de4dot --target net48 your_legacy.dll # 错误不加 --target让 auto 探测 ./de4dot your_app.dll # 可能识别成 netstandard2.0导致 MethodBody 解析失败参数原理--target直接决定 de4dot 初始化AssemblyLoadContext时使用的AssemblyDependencyResolver。.NET 6和.NET Framework 4.8的依赖解析路径、GAC 查找逻辑完全不同。设错会导致TypeLoadException或MissingMethodException在反编译中途抛出。3.2--mode控制反混淆深度影响输出可读性--mode有三个值all默认、light、aggressive。这不是“力度越大越好”all启用所有已知反混淆器ConfuserEx、Dotfuscator、Eazfuscator 等但对未识别 obfuscator 会 fallback 到通用 IL 清理可能误删调试符号light仅做基础 IL 优化如移除 dead code、合并常量保留原始变量名和方法名适合只想看控制流aggressive强制启用所有启发式规则包括字符串解密、控制流扁平化还原但对 .NET 6 的 Span /Memory 操作易崩溃。# 推荐新手起步先 light 模式确认结构 ./de4dot --mode light --target net6.0 your_app.dll -o deobf_light/ # 确认无 crash 后再升级 all 模式 ./de4dot --mode all --target net6.0 your_app.dll -o deobf_full/3.3--in-place与--output文件写入策略决定能否二次处理--in-place直接覆盖原文件危险--output指定输出目录安全。但很多人忽略一个关键点de4dot 的输出不是“源码”而是重新 emit 的程序集其AssemblyVersion、PublicKeyToken与原文件一致但 IL 指令已重排。若你后续要用dnSpy加载修改必须确保输出是完整程序集.dll/.exe而非仅 .cs 文件# ✅ 正确输出反混淆后的程序集可被其他工具消费 ./de4dot --output ./out/ your_app.dll # 生成./out/your_app.dll已清理混淆 # ❌ 错误只输出 .cs丢失 IL 结构无法再反编译或调试 ./de4dot --sources --output ./src/ your_app.dll # 生成./src/your_app/Program.cs纯文本无 metadata血泪经验某开发者用--sources输出后发现Main方法里全是var arg0 ...以为工具失效其实是他忘了--sources仅生成 C# 文本不还原语义。真正调试必须用--output生成的 DLL。3.4--string-decrypt开启字符串解密的前置条件很多混淆器如 ConfuserEx会加密字符串字面量--string-decrypt参数看似开关实则依赖两个隐藏条件必须识别出 obfuscator 类型通过--target和自动探测目标程序集必须包含解密所需的“密钥”或“算法类型”元数据通常在.resources或自定义 attribute 中。# 正确流程先不加 --string-decrypt看日志是否识别出 obfuscator ./de4dot --target net6.0 your_app.dll --verbose 21 | grep Detected obfuscator # 若输出Detected obfuscator: ConfuserEx (v1.9)再加参数 ./de4dot --target net6.0 --string-decrypt your_app.dll -o ./decrypted/ # 若无 Detection 日志加 --obfuscator confuserex 强制指定 ./de4dot --target net6.0 --obfuscator confuserex --string-decrypt your_app.dll3.5--keep-types与--keep-names保留原始命名的“后悔药”反混淆后变量名变成a,b,c是常态但如果你有原始 PDB 或源码映射可用这两个参数保留关键命名# 保留所有 public 类型名如 Form1, Program ./de4dot --keep-types Form1|Program your_app.dll # 保留特定方法名正则匹配 ./de4dot --keep-names ^InitializeComponent$ your_app.dll # 组合使用保留主窗体类 初始化方法 ./de4dot --keep-types MainForm --keep-names ^InitializeComponent$ your_app.dll注意--keep-types的值是正则表达式不是 glob。Main*会匹配MainWindow但Main\*才匹配字面量Main*需转义。3.6--reference解决“找不到引用程序集”的编译错误反编译后生成的 .cs 文件若用csc编译常报error CS0234: The type or namespace name Extensions does not exist in the namespace System.Linq。这是因为 de4dot 默认不注入using或引用System.Linq.dll。正确做法是用--reference指向本地 .NET SDK 的引用程序集# Linux 查找引用程序集路径.NET 6 dotnet --list-sdks # 输出6.0.402 [/usr/share/dotnet/sdk] ls /usr/share/dotnet/sdk/6.0.402/Ref/ # 添加引用关键指向 Ref/ 目录下的 .dll ./de4dot \ --target net6.0 \ --reference /usr/share/dotnet/sdk/6.0.402/Ref/net6.0/System.Linq.dll \ --reference /usr/share/dotnet/sdk/6.0.402/Ref/net6.0/System.Collections.dll \ your_app.dll -o ./ref_out/3.7--exclude跳过已知“黑匣子”模块避免崩溃某些程序集会嵌入原生代码如UnmanagedCallersOnly方法、或使用DynamicMethod生成运行时 ILde4dot 解析时会直接 abort。用--exclude跳过这些类型# 排除所有含 Native 的类避免 UnmanagedCallersOnly 崩溃 ./de4dot --exclude .*Native.* your_app.dll # 排除特定命名空间如第三方加密库 ./de4dot --exclude ^MyApp\.Crypto\..*$ your_app.dll排查技巧加--verbose后若日志在Processing type XXX卡住XXX就是该排除的目标。4. 常见问题排查五条真实踩坑记录每条都来自某开发者凌晨三点的终端日志de4dot-netcore的报错信息往往模糊比如Error: An error occurred while processing the assembly背后可能是十种不同原因。以下是我在帮某高校调试某图像处理Demo 时整理出的五条高频、高迷惑性问题按“现象→原因→解决”结构给出可立即执行的方案。4.1 现象Could not load file or assembly System.Runtime, Version6.0.0.0原因系统安装了 .NET 7 Runtime但de4dot-netcore v4.0.0-beta1内置 .NET 6host 尝试加载System.Runtime 6.0.0.0时 fallback 到 7.0 版本而 7.0 的System.Runtime与 6.0 ABI 不完全兼容。解决# 卸载 .NET 7只留 .NET 6 sudo apt remove dotnet-runtime-7.0 # Ubuntu brew uninstall dotnet-runtime-7.0 # macOS # 然后重装 .NET 6 Runtime见 2.3 节4.2 现象Error: Failed to resolve assembly: Some.ThirdParty.dll原因目标程序集使用Costura.Fody将Some.ThirdParty.dll合并进主程序集但 de4dot 默认不提取嵌入资源导致解析AssemblyRef时找不到该引用。解决加--merge参数强制提取./de4dot --merge --target net6.0 your_app.dll # 会生成 ./out/your_app.dll已解包 ThirdParty.dll和 ./out/ThirdParty.dll4.3 现象反编译后Main方法为空或只有throw new NotImplementedException()原因混淆器启用了“方法内联”Method Inlining或“控制流扁平化”Control Flow Flattening--mode light无法还原必须用--mode aggressive。解决# 先确认是否启用 CF 扁平化看日志 ./de4dot --verbose --target net6.0 your_app.dll 21 | grep -i flattening # 若输出Detected control flow flattening → 必须 aggressive ./de4dot --mode aggressive --target net6.0 your_app.dll4.4 现象Error: Could not find type System.Span1原因目标程序集为 .NET 6使用了SpanT但 de4dot 运行时未加载System.Memory.dll.NET 6 的SpanT实现在此程序集中。解决手动添加--reference# Linux 路径示例 ./de4dot \ --target net6.0 \ --reference /usr/share/dotnet/shared/Microsoft.NETCore.App/6.0.23/System.Memory.dll \ your_app.dll4.5 现象Error: Invalid IL code in XXX:YYY: IL_0001: call 0x0a000001原因混淆器插入了无效 IL 指令如call指向不存在的方法 tokende4dot 的 IL 验证器拒绝加载。解决加--skip-il-verification跳过 IL 校验仅调试用不推荐生产./de4dot --skip-il-verification --target net6.0 your_app.dll # 注意此参数会绕过安全检查仅用于分析崩溃原因5. 验证反编译结果是否可信三步交叉验证法比看 .cs 文件更可靠装完、配好、跑出 .cs 文件不代表反编译成功。真正的验证不是“能不能打开”而是“还原的逻辑是否等价于原程序”。我一般用三步交叉验证每步耗时不超过 2 分钟却能避开 95% 的“假成功”。5.1 第一步比对程序集哈希与元数据一致性反编译生成的out/your_app.dll是新 emit 的程序集其AssemblyVersion、PublicKeyToken应与原文件一致但 IL 内容已变。用ildasm导出元数据签名比对# 导出原文件元数据仅签名不含 IL ildasm your_app.dll /outputorig_meta.il /noil /pubonly # 导出反编译后文件元数据 ildasm ./out/your_app.dll /outputnew_meta.il /noil /pubonly # 比较关键字段跳过时间戳、GUID 等随机值 diff (grep -E ^(\.assembly|\.module|\.publickey) orig_meta.il) \ (grep -E ^(\.assembly|\.module|\.publickey) new_meta.il)预期输出仅/.publickey行可能不同若原程序集无强签名new_meta 会多一行.publickey (00 00)其余行应完全一致。若.assembly版本号不同说明--target设错或 de4dot 写入了错误版本。5.2 第二步用dotnet peverify检查 IL 合法性peverify是 .NET 官方 IL 验证工具能发现 de4dot 生成的非法指令如栈不平衡、类型不匹配# 安装 peverify.NET SDK 自带 dotnet tool install -g dotnet-peverify # 验证原文件应通过 dotnet peverify your_app.dll # 验证反编译后文件必须通过否则运行时必崩 dotnet peverify ./out/your_app.dll若peverify报error : [MD]: Error: TypeDef has invalid base class.说明 de4dot 错误解析了泛型基类如class AT : BT需加--obfuscator dotfuscator强制指定解析器。5.3 第三步运行时行为比对 —— 用最小入口点触发最硬核的验证写一个极简 wrapper分别加载原 DLL 和反编译 DLL调用同一入口方法比对返回值// test_wrapper.cs using System; using System.Reflection; class Program { static void Main() { // 加载原程序集 var orig Assembly.LoadFrom(your_app.dll); var origType orig.GetType(YourNamespace.Program); var origMethod origType.GetMethod(GetVersion); // 替换为你的真实方法名 var origResult origMethod.Invoke(null, null); // 加载反编译后程序集 var newAsm Assembly.LoadFrom(./out/your_app.dll); var newType newAsm.GetType(YourNamespace.Program); var newMethod newType.GetMethod(GetVersion); var newResult newMethod.Invoke(null, null); Console.WriteLine($Original: {origResult}); Console.WriteLine($Deobfuscated: {newResult}); Console.WriteLine($Match: {origResult?.ToString() newResult?.ToString()}); } }# 编译并运行.NET 6 dotnet new console -o test cd test dotnet add reference ../your_app.dll dotnet add reference ../out/your_app.dll # 修改 Program.cs 为上方内容 dotnet run关键点GetVersion这类无副作用、纯计算的方法最适合作为验证点。若输出Match: True说明反编译后的 IL 逻辑等价若为False说明--mode aggressive过度优化或字符串解密失败需回退参数重试。从那以后我每次处理新的 .NET 程序集都强制走一遍这三步验证先ildasm /noil看元数据再peverify扫 IL最后用 wrapper 跑一次真实方法。省掉任何一步都可能在后续调试中花三小时找一个本该在第一分钟就发现的反编译偏差。希望帮到你。本文还有配套的精品资源点击获取