简介本资源为适配.NET Core平台的开源脱壳工具de4dot-netcore正式版本面向安全研究人员、逆向工程师及.NET开发者解决.NET Core应用在跨平台环境Windows/Linux/macOS下难以脱壳分析的技术痛点。资源包共48个文件含12个核心DLL如de4dot.dll、de4dot.cui.dll、2个可执行文件de4dot.exe、apphost.exe、8个配置与依赖文件json/deps.json、runtimeconfig.json等、8个文本类文件含LICENSE及授权说明以及PDB调试符号、CS源码、EditorConfig等开发支持文件整体压缩包仅1.87MB轻量易部署。已有523人学习下载适合需对ConfuserEx、DNEmu、.NET Reactor等常见.NET保护壳进行静态分析、漏洞挖掘或恶意软件取证的研究者。用户可直接运行exe执行脱壳亦可基于源码定制扩展配套完整构建产物与依赖清单开箱即用显著降低.NET Core程序逆向门槛。1. de4dot-netcore 版本.NET Core / .NET 5 程序集反混淆实战工具专治 IL 重写、控制流扁平化与字符串加密你手头有个 .NET Core 3.1 或 .NET 6/7/8 编译的 DLL用 ConfuserEx、Eazfuscator、CryptoObfuscator 或自研混淆器处理过——方法名全变 a/b/c字符串被 XORBase64 套三层控制流被扁平成 switch-case 黑匣子甚至关键逻辑被拆进动态生成的 IL 字节数组里。这时候de4dot原版基于 Mono.Cecil 0.9.x .NET Framework直接报错退出“Could not load file or assembly System.Runtime, Version4.1.2.0”dnSpy打开能看但无法批量还原ILSpy的反混淆插件对 .NET Core 项目支持残缺字符串解密失败率超 60%。这就是为什么你需要de4dot-netcore 版本它不是简单移植而是重写了加载器、重写了字符串解密引擎、重构了控制流还原模块原生支持 .NET Standard 2.0 和 .NET 5 运行时能稳定处理netcoreapp3.1、net5.0,net6.0-windows,net7.0-android,net8.0-browserwasm等多目标框架编译的程序集。它不依赖 Mono 运行时不调用任何 Windows-only APILinux/macOS 下开箱即用它也不是“一键傻瓜式”而是把每个混淆特征如ldstr→call string::Decrypt的模式匹配、brfalse.s嵌套深度阈值、ldc.i4指令序列识别暴露为可调参数——适合逆向工程师、安全研究员、合规审计人员和需要做二进制兼容性验证的 SDK 开发者。如果你正在分析一个国密 SM2 加密后嵌入资源的 .NET 8 应用注意de4dot-netcore 本身不实现 SM2 解密但它能精准定位并提取被 SM2 密文包裹的原始字符串字节这个版本就是你绕不开的起点。2. 核心能力拆解从混淆特征识别到 IL 重建的四层还原逻辑2.1 混淆器指纹识别为什么它能自动判断是 ConfuserEx 还是 Eazfuscatorde4dot-netcore 不靠文件名或硬编码签名而是通过三阶段指令图谱比对实现混淆器类型判定入口点扫描解析Main方法或ModuleInitializer检查是否包含call [mscorlib]System.Security.Principal.WindowsIdentity::GetCurrent()ConfuserEx v1.9 典型初始化、call [System.Runtime]System.Runtime.CompilerServices.RuntimeHelpers::InitializeArray()Eazfuscator 2022 资源加载特征字符串操作链分析遍历所有ldstr指令统计其后续是否紧跟call到疑似解密函数如DecryptString,Decode,GetResource并提取该函数的 IL 指令序列哈希SHA-256控制流结构建模对每个方法构建 CFGControl Flow Graph计算brtrue.s/brfalse.s分支嵌套深度、switch指令跳转表大小、nop插入密度30% 即标记为控制流扁平化。提示--verbose参数会输出每一步的匹配详情例如Matched ConfuserEx v1.9.0 pattern in method Program.Main$ (score: 0.92)这比原版仅输出Detected ConfuserEx更具可追溯性。2.2 字符串解密还原如何应对 XORRC4SM2 多层嵌套原版 de4dot 对字符串解密采用“静态模拟执行”在内存中构造虚拟栈逐条执行ldc.i4,xor,call等指令。但 .NET Core 中ldstr行为变更常量池引用方式不同、calli指令增多、以及混淆器引入Spanbyte操作导致模拟执行崩溃。de4dot-netcore 改用符号执行 模板匹配双轨策略符号执行轨对解密函数入口做轻量级符号化仅跟踪ldarg.0,ldloc,stloc,xor,add等基础指令生成表达式树((key[0] ^ data[0]) key[1]) ^ data[1]再用 Z3 求解器反推原始字符串模板匹配轨内置 27 种常见解密模式含国密 SM2 的ECPoint.Multiply调用序列识别当符号执行失败时直接匹配 IL 模式并注入预编译的 C# 解密逻辑如SM2Decrypt(byte[] cipher, byte[] privateKey)。实际使用中你只需指定--strings参数工具会自动选择最优路径。若遇到自定义 SM2 解密如私钥硬编码在byte[]字段中可通过--strings-decryptor指向你自己的 C# 解密类需实现IStringDecryptor接口。2.3 控制流扁平化还原从 switch-case 黑匣子到原始 if-else 的映射原理控制流扁平化Control Flow Flattening是 .NET 混淆最顽固的一环。原版 de4dot 仅支持简单switch还原对while(true) { switch(state) { case 0: ... state 1; break; case 1: ... state 2; break; } }结构束手无策。de4dot-netcore 引入状态机逆向工程算法定位主循环识别br.s label回跳到同一地址的无限循环提取状态变量追踪ldloc,stloc,ldc.i4赋值序列确认哪个局部变量为state构建状态转移图将每个case块视为节点state N视为有向边检测嵌套结构若某case块内存在另一个switch则递归展开为子状态机生成结构化代码按拓扑序重排块顺序用if/else if/else替代switch插入goto仅用于异常跳转。该算法在处理 ConfuserEx 的Flatten模式时还原准确率达 94.7%测试集128 个混淆后 .NET 6 程序集远高于原版的 61.3%。2.4 类型与元数据修复为什么还原后能直接用 csc 编译通过混淆器常删除public修饰符、重命名泛型参数T→a、擦除AssemblyVersion导致反编译后代码无法编译。de4dot-netcore 在 IL 层面做元数据语义修复而非简单字符串替换访问修饰符恢复根据callvirt/call指令调用上下文结合MethodAttributes标志位推断public/private例如callvirt instance void [mscorlib]System.Object::ToString()调用必为public泛型参数重建解析GenericParam表匹配constrained.指令约束条件还原where T : class等约束程序集签名保留不修改PublicKeyToken和Culture仅重写Version字段为1.0.0.0可选--keep-version保留原版调试信息注入生成.pdb文件需--pdb参数包含原始源码行号映射使dotnet build时能准确定位错误。这意味着你拿到的还原 DLL不仅能用ildasm查看还能直接丢进 Visual Studio 作为引用项目编译无需手动修internal class a这种玄学命名。3. 快速上手从下载到还原一个 .NET 8 混淆 DLL 的完整流程3.1 下载与环境准备跨平台运行的关键依赖de4dot-netcore 是纯 .NET 6 应用无需安装 Mono 或 .NET Framework。支持 Windows x64/x86、Linux x64/arm64、macOS x64/arm64。# Linux/macOS下载预编译二进制推荐 wget https://github.com/de4dot-netcore/releases/download/v2.0.0/de4dot-netcore-linux-x64.zip unzip de4dot-netcore-linux-x64.zip chmod x de4dot-netcore # WindowsPowerShell 下载注意不要用浏览器直接点避免重定向丢失 Invoke-WebRequest -Uri https://github.com/de4dot-netcore/releases/download/v2.0.0/de4dot-netcore-win-x64.zip -OutFile de4dot.zip Expand-Archive de4dot.zip -DestinationPath .注意官方发布页github.com/de4dot-netcore/releases提供win-x64,linux-x64,osx-x64,linux-arm64四个平台包没有 .NET Framework 版本也不提供 NuGet 包因涉及反混淆逻辑不符合 NuGet 审核政策。3.2 基础还原命令三步走清空混淆痕迹假设你有一个混淆后的App.dll.NET 8 编译ConfuserEx v1.9 混淆# 步骤1探测混淆类型不修改文件只输出报告 ./de4dot-netcore --detect App.dll # 输出示例 # Detected ConfuserEx v1.9.0 (score: 0.98) # Strings: encrypted with custom XORBase64 # Control flow: flattened (depth: 5) # Anti-debug: present (IsDebuggerPresent check) # 步骤2执行默认还原字符串控制流类型修复 ./de4dot-netcore --output App_clean.dll App.dll # 步骤3验证还原结果生成反编译代码供人工审查 ildasm App_clean.dll /outputApp_clean.il--output参数指定输出路径若省略则默认为App-clean.dll。--detect是安全第一原则——它不写入任何文件只告诉你“它是什么、有多难、哪些模块可能失败”。3.3 高级参数定制针对国密 SM2 场景的专项配置当你面对一个用国密 SM2 加密字符串的 .NET 应用常见于政务、金融类 .NET 8 应用标准--strings会失败因为 SM2 解密需私钥和 ASN.1 解析。此时需启用自定义解密器编写Sm2Decryptor.cs需 .NET 6 SDKusing System; using System.Security.Cryptography; using Org.BouncyCastle.Crypto.Parameters; using Org.BouncyCastle.Crypto.Engines; using Org.BouncyCastle.Crypto.Modes; using Org.BouncyCastle.Crypto.Paddings; public class Sm2Decryptor : IStringDecryptor { private readonly byte[] _privateKey; // 32-byte SM2 private key public Sm2Decryptor(byte[] privateKey) _privateKey privateKey; public string Decrypt(byte[] encryptedData) { var sm2Engine new SM2Engine(); var keyParam new ECPrivateKeyParameters(SM2, new BigInteger(1, _privateKey)); sm2Engine.Init(false, keyParam); var decrypted sm2Engine.ProcessBlock(encryptedData, 0, encryptedData.Length); return Encoding.UTF8.GetString(decrypted); } }编译为Sm2Decryptor.dlldotnet new classlib -n Sm2Decryptor -f net6.0 # 将上述代码放入 Class1.cs添加 NuGet 包 BouncyCastle.NetCore dotnet add package BouncyCastle.NetCore --version 1.8.9 dotnet build -c Release调用 de4dot-netcore 并注入解密器./de4dot-netcore \ --strings \ --strings-decryptor ./Sm2Decryptor.dll \ --strings-decryptor-ctor-args 30,41,22,15,99,... \ # 十六进制私钥字节数组 --output App_sm2_clean.dll \ App_sm2_obfuscated.dll--strings-decryptor-ctor-args接收逗号分隔的字节十六进制字符串如30,41,22→new byte[]{0x30,0x41,0x22}避免明文私钥出现在命令行历史中。3.4 批量处理与自动化用 Bash/PowerShell 脚本处理整个 bin 目录# Linux/macOS批量还原当前目录下所有 .dll for dll in *.dll; do if [[ $dll ! de4dot-netcore ]] [[ $dll ! *-clean.dll ]]; then echo Processing $dll... ./de4dot-netcore --output ${dll%.dll}-clean.dll $dll 2/dev/null if [ $? -eq 0 ]; then echo ✓ $dll - ${dll%.dll}-clean.dll else echo ✗ Failed on $dll fi fi done# Windows PowerShell同理但用 Get-ChildItem Get-ChildItem *.dll | Where-Object { $_.Name -notmatch de4dot|clean } | ForEach-Object { $out $_.Name -replace \.dll$, -clean.dll Write-Host Processing $($_.Name)... -NoNewline .\de4dot-netcore.exe --output $out $_.FullName 2$null if ($LASTEXITCODE -eq 0) { Write-Host ✓ -ForegroundColor Green } else { Write-Host ✗ -ForegroundColor Red } }提示批量处理时务必加--detect先跑一遍过滤掉未混淆的 DLL如System.*、Microsoft.*避免无谓耗时。4. 避坑指南五个血泪经验换来的常见问题排查清单4.1 现象Could not resolve type System.Runtime.CompilerServices.NullableAttribute原因混淆器删除了NullableAttribute元数据而 de4dot-netcore 在解析泛型时尝试反射该类型.NET 6 运行时严格校验缺失类型。解决添加--skip-nullable-check参数跳过该检查或用--fix-attributes启用自动属性修复推荐后者。4.2 现象字符串还原后出现乱码如\u0000\u0000原因混淆器使用 UTF-16-BE 编码但未写 BOMde4dot-netcore 默认按 UTF-8 解码。解决用--strings-encoding utf-16be显式指定编码若不确定先用xxd -g1 App.dll | head -20查看ldstr后紧邻的字节序列判断编码特征。4.3 现象控制流还原后方法体为空IL 只剩ret原因混淆器将真实逻辑打包进Resource流并用Assembly.GetExecutingAssembly().GetManifestResourceStream()动态加载执行de4dot-netcore 默认不处理资源流。解决启用--resources参数提取所有资源生成Resources/目录再用--resources-decryptor指向资源解密器如 SM2 解密资源流。4.4 现象Linux 下执行报System.DllNotFoundException: libhostfxr.so原因你下载的是self-contained版本但系统缺少libicu或libssl常见于 Alpine Linux。解决改用framework-dependent版本文件名含-fd并确保已安装 .NET 6 Runtimesudo apt install dotnet-runtime-6.0Ubuntu或apk add icu-dev openssl-devAlpine。4.5 现象还原后的 DLL 在 .NET 8 环境下抛BadImageFormatException原因混淆器修改了CorFlags如清除了ILONLY位de4dot-netcore 未重置该标志。解决添加--corflags参数强制重写为0x00000001ILONLY或用corflags.exe工具后处理corflags App_clean.dll /32BITREQ- /ILONLY。5. 进阶技巧用 ILDASM 自定义脚本验证还原质量建立可信度基线还原不是终点验证才是关键。我见过太多人拿到*-clean.dll就以为万事大吉结果一跑就NullReferenceException—— 因为混淆器在cctor里埋了反调试逻辑而 de4dot-netcore 默认不还原静态构造函数怕破坏初始化顺序。下面这套验证流程是我过去三年处理 200 个 .NET Core 混淆样本沉淀下来的“可信度基线”5.1 第一层验证IL 指令完整性比对防删减用ildasm导出原始与还原 DLL 的 ILildasm App_obfuscated.dll /outputobf.il ildasm App_clean.dll /outputclean.il然后用diff检查关键指标指标合格阈值检查命令不合格含义ldstr指令数还原后 ≥ 原始 95%grep -c ldstr obf.ilvsgrep -c ldstr clean.il字符串解密失败大量ldstr未还原call指令数还原后 ≤ 原始 110%grep -c call obf.ilvsgrep -c call clean.il控制流还原引入冗余跳转brtrue.s数量还原后 ≤ 原始 30%grep -c brtrue.s obf.ilvsgrep -c brtrue.s clean.il控制流扁平化未充分还原提示brtrue.s是扁平化核心指令若还原后仍高达原始 80%说明--control-flow参数力度不够需加--control-flow-depth 8。5.2 第二层验证方法签名一致性检查防篡改编写sigcheck.pyPython 3.8import subprocess import re def get_method_signatures(dll_path): result subprocess.run( [ildasm, dll_path, /text], capture_outputTrue, textTrue, encodingutf-8 ) sigs [] for line in result.stdout.split(\n): m re.search(rmethod\s(public|private|protected)\s([^\s])\s(\w\.\w)\((.*?)\), line) if m: sigs.append(f{m.group(1)} {m.group(2)} {m.group(3)}({m.group(4)})) return set(sigs) obf_sigs get_method_signatures(App_obfuscated.dll) clean_sigs get_method_signatures(App_clean.dll) print(fOriginal methods: {len(obf_sigs)}) print(fClean methods: {len(clean_sigs)}) print(fMissing: {obf_sigs - clean_sigs}) print(fAdded: {clean_sigs - obf_sigs})合格标准Missing为空集Added≤ 3 个通常是 de4dot 注入的__De4DotHelper类。若Missing有public static void Main(string[])说明入口点被误删需加--keep-entrypoint。5.3 第三层验证运行时行为回归测试防逻辑错这才是终极考验。写一个最小测试桩// TestRunner.cs using System; using System.Reflection; class Program { static void Main() { var asm Assembly.LoadFrom(App_obfuscated.dll); var cleanAsm Assembly.LoadFrom(App_clean.dll); // 找到被混淆的类如 ConfuserEx 常命名为 a var obfType asm.GetType(a); var cleanType cleanAsm.GetType(YourNamespace.YourClass); // 还原后的真实名 // 调用同一方法传相同参数 var obfResult obfType.GetMethod(DoWork).Invoke(null, new object[] { test }); var cleanResult cleanType.GetMethod(DoWork).Invoke(null, new object[] { test }); Console.WriteLine($Obf: {obfResult}, Clean: {cleanResult}); Console.WriteLine($Match: {obfResult?.Equals(cleanResult) ?? false}); } }编译并运行dotnet run --project TestRunner.csproj。只有当输出Match: True时才证明还原未破坏业务逻辑。我曾在一个金融 SDK 上发现clean.dll返回null而obf.dll返回有效对象——追查发现混淆器在catch块里做了Environment.Exit(0)de4dot-netcore 未还原该异常处理最终通过--keep-exception-handlers解决。从那以后我每次拿到还原 DLL都强制走一遍这三层验证先看 IL 指令数是否合理再比方法签名是否一致最后跑一个真实输入看输出是否 match。三关全过才敢把它交给开发同事或放进 CI 流水线。希望帮到你。本文还有配套的精品资源点击获取