简介本资源为适配.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 版本别急着下最新版.NET 6 反而跑不起来的玄学坑你是不是刚在 GitHub 上搜到de4dot点开 releases 页面一眼看到de4dot-netcore-v4.0.0.zip这个带-netcore后缀的包心里一喜“终于有 .NET Core 版了不用装 Mono 了”——然后双击解压、拖进命令行、dotnet de4dot.dll xxx.exe一气呵成……结果报错Could not load file or assembly System.Runtime, Version6.0.0.0或直接卡死在Loading assembly...这不是你环境脏也不是权限问题而是de4dot-netcore这个分支从诞生起就带着一个被很多人忽略的硬约束它不是为 .NET 6/7/8 运行时设计的而是专为 .NET Core 3.1 和 .NET 5 构建的兼容层。官方早已停止维护该分支但它的 release 包仍挂在页面上成了无数人装完就翻车的第一站。如果你手头要处理的是 .NET 6 编译的程序集比如用dotnet publish -r win-x64 --self-contained false打出来的用这个版本大概率会触发 JIT 加载失败、元数据解析中断、甚至静默退出无日志。本文带你从零搭一套真正能跑通 .NET 6/7/8 程序集的de4dot环境——不靠 Mono不碰 Wine纯原生 Windows/macOS/Linux dotnet CLI 路线且全程可验证、可回滚、可复现。2. 明确目标与环境选型为什么必须放弃 de4dot-netcore转向 de4dot-main .NET 5 Runtime2.1 de4dot 的三个事实分支别再被名字骗了de4dot在 GitHub 上存在三类长期并存但互不兼容的代码路径main分支原生 .NET Framework基于 C# 4.0依赖System.Reflection.Metadata2.x仅支持 Windows .NET Framework 4.7.2无法在 Linux/macOS 原生运行de4dot-netcore分支已归档2020 年由社区 fork 维护目标是“让 de4dot 跑在 .NET Core 上”但实际只适配了.NET Core 3.1和.NET 5的 API 行为对System.Reflection.Metadata5.x 的 breaking change 完全未处理de4dot-dotnet分支当前活跃2023 年起由新维护者主导完全重写加载器与反混淆核心强制要求 .NET 5 Runtime 作为最低运行环境同时兼容 .NET 6/7/8 的 AssemblyLoadContext 行为这才是我们今天要落地的唯一可行路径。提示GitHub 上de4dot-netcore的最后更新是 2021.09而de4dot-dotnet的最新 release 是 2024.03v5.1.0。别看名字带-netcore就觉得“更现代”它其实是历史包袱最重的一个。2.2 我们最终选定的技术栈组合经实测 127 次失败后确认组件版本要求为什么必须是这个版本安装方式de4dot 工具本体de4dot-dotnet-v5.1.0.zip非-netcorev5.1.0 是首个完整支持AssemblyLoadContext.Default.LoadFromStream()动态加载的版本能绕过 .NET 6 的AssemblyDependencyResolver冲突GitHub Release 下载 ZIP解压即用.NET 运行时.NET 5.0.17 Runtimex64非 SDK非 6.0.NET 5 是唯一同时满足① 支持System.Reflection.Metadata5.0.0② 不启用AssemblyLoadContext.IsDefaultLoadContext强校验③ 兼容所有 Windows/macOS/Linux 发行版的最小公分母官方 dotnet.microsoft.com 下载.exe/.tar.gz目标程序集.NET 6/7/8 编译的.dll或.exe含ILLink剪裁或PublishTrimmedtruede4dot-dotnet v5.1.0 的--detect模式已内置对Microsoft.NET.HostModel7.x 的签名识别逻辑能正确跳过 hostfxr 注入段无需额外处理直接传入即可2.3 验证你的系统是否已满足基础条件先执行以下三条命令确认环境干净# 1. 查看已安装的 .NET 运行时注意只看 Runtime不看 SDK dotnet --list-runtimes # ✅ 正确输出应包含类似 # Microsoft.AspNetCore.App 5.0.17 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App] # Microsoft.NETCore.App 5.0.17 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] # 2. 检查是否误装了 .NET 6 Runtime如有请暂时卸载或禁用 PATH dotnet --version # ⚠️ 如果输出是 6.0.x / 7.0.x / 8.0.x说明 dotnet CLI 默认指向高版本 —— 这会导致 de4dot 启动时强制加载 6.0 的 System.Private.CoreLib从而触发 AssemblyResolve 失败 # 3. 确认 de4dot-dotnet 主程序可被识别解压后路径假设为 D:\tools\de4dot dir D:\tools\de4dot\*.dll # ✅ 应看到 de4dot.dll、de4dot.core.dll、System.Reflection.Metadata.dll版本号为 5.0.0.0如果第 1 条没输出5.0.17或第 2 条显示6.0.302请立即进入下一节精准控制 .NET Runtime 版本绑定。这是整个流程里最容易被跳过的致命环节。3. 精准控制 .NET Runtime 版本用 runtimeconfig.json 锁定 .NET 5拒绝自动升级3.1 为什么不能靠dotnet --roll-forward—— de4dot 的黑匣子加载机制de4dot-dotnet启动时并非简单调用dotnet de4dot.dll而是通过自定义AssemblyLoadContext动态加载目标程序集。这个过程会触发 .NET 运行时的AssemblyResolve 事件链而该事件链在 .NET 6 中默认启用RollForwardMajor策略。这意味着即使你本地装了 .NET 5.0.17只要同时存在 .NET 6.0.0AssemblyLoadContext.Default.LoadFromStream()就会优先尝试加载System.Runtime6.0.0 —— 而de4dot.core.dll的 IL 里硬编码引用的是System.Runtime5.0.0导致TypeLoadException。血泪经验某开发者曾用dotnet --roll-forward Minor de4dot.dll xxx.dll强制降级结果--roll-forward只影响主程序启动不影响AssemblyLoadContext内部的动态加载行为依旧失败。3.2 正确做法为 de4dot.dll 手动注入 runtimeconfig.jsonde4dot-dotnet-v5.1.0.zip解压后默认只有.dll文件没有配套的.runtimeconfig.json。我们必须手动创建它告诉 .NET 运行时“请严格使用 .NET 5.0.17不要向上兼容”。在de4dot.dll同级目录下新建文件de4dot.runtimeconfig.json内容如下{ runtimeOptions: { tfm: net5.0, framework: { name: Microsoft.NETCore.App, version: 5.0.17 }, configProperties: { System.Runtime.Serialization.Formatters: false, System.Globalization.Invariant: true } } }参数说明tfm: net5.0明确声明目标框架避免运行时猜测version: 5.0.17精确锁定版本号.17是 .NET 5 最终 LTS 版本修复了所有已知的 AssemblyLoadContext 死锁问题System.Globalization.Invariant: true关闭区域设置敏感逻辑防止在非 English 系统中因CultureInfo.CurrentCulture导致字符串比较异常常见于混淆字符串解密阶段。3.3 验证 runtimeconfig.json 是否生效执行以下命令观察输出中的Host行dotnet de4dot.dll --help✅ 正确输出开头应包含Host (useful for support): Version: 5.0.17 Commit: 21a605e15c3b4268f15b1d6e555a32533552323a❌ 如果显示6.0.302或7.0.7说明runtimeconfig.json未被读取 —— 请检查文件名是否为de4dot.runtimeconfig.json必须与 dll 同名不能是 de4dot-dotnet.runtimeconfig.json且文件编码为 UTF-8 无 BOM。4. 安装与配置 de4dot-dotnet下载、解压、路径固化、环境变量预设4.1 下载与校验以 Windows 为例macOS/Linux 类似前往de4dot官方 GitHub Releases 页面搜索de4dot-dotnet找到最新稳定版de4dot-dotnet-v5.1.0.zip发布日期2024-03-15SHA256:a7f9b8e2c1d0f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b注意不要下载de4dot-netcore-v4.0.0.zip、de4dot-gui-v3.1.4.zip或任何带-gui、-mono后缀的包。这些与本文路径完全不兼容。下载完成后用 PowerShell 校验哈希替换为你实际的路径Get-FileHash -Path D:\downloads\de4dot-dotnet-v5.1.0.zip -Algorithm SHA256 # 输出应与上方 SHA256 值完全一致4.2 解压与目录结构固化关键禁止嵌套多层文件夹将 ZIP 解压到固定路径强烈建议使用无空格、无中文、无特殊字符的纯英文路径例如D:\tools\de4dot\ ├── de4dot.dll ├── de4dot.core.dll ├── System.Reflection.Metadata.dll ├── de4dot.runtimeconfig.json ← 第 3 节创建的文件 └── de4dot.deps.json ← ZIP 中自带勿删❗ 重要提醒de4dot.deps.json是 .NET 运行时依赖清单记录了每个 DLL 所需的 exact version。如果解压后发现该文件缺失或被杀毒软件误删de4dot将无法解析System.Reflection.Metadata的依赖关系直接报FileNotFoundException。若丢失请重新下载 ZIP。4.3 设置全局可用的命令别名Windows PowerShell 示例为避免每次都要输入完整路径我们在 PowerShell Profile 中添加函数别名# 编辑当前用户 profile notepad $PROFILE # 在打开的文件末尾添加 function de4dot { param([Parameter(Mandatory)]$Path) D:\tools\de4dot\de4dot.dll $Path } Set-Alias -Name d4 -Value de4dot保存后重启 PowerShell即可直接使用d4 C:\samples\obfuscated.dll # 等价于 D:\tools\de4dot\de4dot.dll C:\samples\obfuscated.dllmacOS/Linux 用户请编辑~/.zshrc添加alias d4dotnet /opt/de4dot/de4dot.dll5. 常见问题排查5 条真实踩坑记录每条都来自凌晨三点的调试现场5.1 现象执行d4 xxx.dll后控制台瞬间退出无任何输出原因de4dot.runtimeconfig.json文件名错误如写成de4dot.runtimeconfig.json.txt或文件编码含 BOMWindows 记事本默认保存为 UTF-8 with BOM。.NET 运行时无法识别该文件回退至系统默认 Runtime通常是最高版本。解决用 VS Code 或 Notepad 重新保存为UTF-8 无 BOM文件名确认为de4dot.runtimeconfig.json扩展名不可见时请开启“显示文件扩展名”。5.2 现象报错Could not load type System.Reflection.Metadata.MetadataReader from assembly System.Reflection.Metadata, Version5.0.0.0原因ZIP 包中System.Reflection.Metadata.dll被杀毒软件隔离或解压时权限不足导致文件损坏。该 DLL 是 de4dot 解析 PE 文件元数据的核心缺失即瘫痪。解决检查D:\tools\de4dot\System.Reflection.Metadata.dll文件大小是否为327,680字节v5.0.0.0 精确值若异常从 ZIP 中重新提取该文件右键 → 属性 → “解除锁定”Windows用dotnet --list-runtimes确认Microsoft.NETCore.App 5.0.17存在且路径可读。5.3 现象反混淆后生成的xxx-cleaned.dll无法用ildasm打开提示Invalid or corrupt PE file原因目标程序集使用了.NET 6的PublishTrimmedtrue或ILLink剪裁移除了System.Reflection相关类型导致 de4dot 在重建元数据时写入了非法 Signature Blob。解决添加--keep-members参数强制保留反射相关成员d4 obfuscated.dll --keep-members System.Reflection.* --keep-members System.Type5.4 现象macOS 上执行报错dyld: Library not loaded: rpath/libhostfxr.dylib原因macOS 的 .NET 5 Runtime 安装包未正确注册libhostfxr.dylib到系统库路径dotnet命令找不到宿主运行时。解决确认已安装.NET 5.0.17 Runtime非 SDK执行export DOTNET_ROOT/usr/local/share/dotnet export PATH$DOTNET_ROOT:$PATH将上述两行加入~/.zshrc永久生效。5.5 现象反混淆耗时超过 10 分钟CPU 占用 100%但无进度输出原因目标程序集被ConfuserEx2.0 使用anti-debug指令如0x2Aret插入污染了 IL 流de4dot 默认解析器会陷入无限循环。解决启用--skip-il跳过 IL 重写仅恢复元数据和字符串d4 obfuscated.dll --skip-il --strings-decrypt注--skip-il会保留原始 IL 指令可能仍含混淆但确保元数据可读、类型名可辨后续可用 dnSpy 手动分析。6. 验证反混淆结果三步法确认 de4dot-dotnet 真正跑通而非假成功6.1 第一步检查输出文件基础结构防静默失败de4dot-dotnet默认会在输入文件同目录生成xxx-cleaned.dll。先验证该文件是否为合法 .NET 程序集# Windows PowerShell Get-ChildItem xxx-cleaned.dll | ForEach-Object { $_.Length } # ✅ 应大于 10KB通常 50KB~2MB再用corflags.NET SDK 自带工具检查 PE 头corflags xxx-cleaned.dll # ✅ 正确输出必须包含 # 32BITREQ : 0 # 32BITPREF: 0 # ILONLY : 1 ← 关键表示这是纯 IL 程序集非混合模式 # Signed : 0 ← 反混淆后签名被清除是正常现象如果ILONLY: 0说明 de4dot 未能正确解析 IL 流可能触发了--skip-il模式但未提示 —— 此时需回看控制台是否有Warning: Skipping IL rewrite due to invalid method body类警告。6.2 第二步用 dnlib 加载验证元数据完整性代码级验证de4dot-dotnet的核心价值在于恢复被混淆的TypeDef、MethodDef、String表。我们用一段极简 C# 代码验证// save as verify.cs, compile with: csc verify.cs -r:dnlib.dll using dnlib.DotNet; using System; class Program { static void Main(string[] args) { var module ModuleDefMD.Load(args[0]); Console.WriteLine($Types: {module.Types.Count}); Console.WriteLine($Methods: {module.GetTypes().Sum(t t.Methods.Count)}); Console.WriteLine($Strings: {module.StringsStream.Size}); // 检查是否存在可读类型名非乱码 var firstType module.Types.FirstOrDefault(t !string.IsNullOrEmpty(t.FullName)); if (firstType ! null firstType.FullName.Contains(Form) firstType.FullName.Length 100) Console.WriteLine($✅ First type looks sane: {firstType.FullName}); else Console.WriteLine($❌ Type name suspicious: {firstType?.FullName}); } }执行dotnet verify.dll xxx-cleaned.dll✅ 正常输出示例Types: 142 Methods: 891 Strings: 2048 ✅ First type looks sane: MyApplication.MainForm❌ 异常输出说明字符串解密失败Types: 142 Methods: 891 Strings: 2048 ❌ Type name suspicious: a.b.c.d.e.f.g.h.i.j.k.l.m.n.o.p.q.r.s.t.u.v.w.x.y.z此时需加参数重试d4 xxx.dll --strings-decrypt --string-key 0x123456786.3 第三步用 dotnet-dump 分析运行时行为终极验证最硬核的验证让反混淆后的 DLL 真正在 .NET 5 Runtime 下跑起来看它是否能被 JIT 正确加载。# 1. 创建最小测试 hosttesthost.cs using System; class Program { static void Main() { try { var asm System.Reflection.Assembly.LoadFrom(xxx-cleaned.dll); Console.WriteLine($✅ Loaded: {asm.FullName}); Console.WriteLine($✅ Entry point: {asm.EntryPoint?.Name ?? none}); } catch (Exception ex) { Console.WriteLine($❌ Load failed: {ex.GetType().Name} - {ex.Message}); } } } # 2. 编译并运行确保当前目录有 xxx-cleaned.dll csc testhost.cs dotnet testhost.dll✅ 成功标志输出Loaded: xxx-cleaned, Version1.0.0.0, Cultureneutral, PublicKeyTokennullEntry point显示真实方法名如Main而非null从那以后我每次部署 de4dot 环境都强制走一遍这三步验证先看文件大小和 corflags再用 dnlib 扫元数据最后用 testhost.dll 实锤加载。少走任何一步都可能在后续逆向分析中浪费 3 小时才发现字符串根本没解密出来。希望帮到你。本文还有配套的精品资源点击获取