簡(jiǎn)介本資源為適配.NET Core平臺(tái)的開(kāi)源脫殼工具de4dot-netcore正式版本面向安全研究人員、逆向工程師及.NET開(kāi)發(fā)者解決.NET Core應(yīng)用在跨平臺(tái)環(huán)境Windows/Linux/macOS下難以脫殼分析的技術(shù)痛點(diǎn)。資源包共48個(gè)文件含12個(gè)核心DLL如de4dot.dll、de4dot.cui.dll、2個(gè)可執(zhí)行文件de4dot.exe、apphost.exe、8個(gè)配置與依賴文件json/deps.json、runtimeconfig.json等、8個(gè)文本類文件含LICENSE及授權(quán)說(shuō)明以及PDB調(diào)試符號(hào)、CS源碼、EditorConfig等開(kāi)發(fā)支持文件整體壓縮包僅1.87MB輕量易部署。已有523人學(xué)習(xí)下載適合需對(duì)ConfuserEx、DNEmu、.NET Reactor等常見(jiàn).NET保護(hù)殼進(jìn)行靜態(tài)分析、漏洞挖掘或惡意軟件取證的研究者。用戶可直接運(yùn)行exe執(zhí)行脫殼亦可基于源碼定制擴(kuò)展配套完整構(gòu)建產(chǎn)物與依賴清單開(kāi)箱即用顯著降低.NET Core程序逆向門檻。1. de4dot-netcore 版本.NET Core / .NET 5 程序集反混淆實(shí)戰(zhàn)工具專治 IL 重寫、控制流扁平化與字符串加密你手頭有個(gè) .NET Core 3.1 或 .NET 6/7/8 編譯的 DLL用 ConfuserEx、Eazfuscator、CryptoObfuscator 或自研混淆器處理過(guò)——方法名全變 a/b/c字符串被 XORBase64 套三層控制流被扁平成 switch-case 黑匣子甚至關(guān)鍵邏輯被拆進(jìn)動(dòng)態(tài)生成的 IL 字節(jié)數(shù)組里。這時(shí)候de4dot原版基于 Mono.Cecil 0.9.x .NET Framework直接報(bào)錯(cuò)退出“Could not load file or assembly System.Runtime, Version4.1.2.0”dnSpy打開(kāi)能看但無(wú)法批量還原ILSpy的反混淆插件對(duì) .NET Core 項(xiàng)目支持殘缺字符串解密失敗率超 60%。這就是為什么你需要de4dot-netcore 版本它不是簡(jiǎn)單移植而是重寫了加載器、重寫了字符串解密引擎、重構(gòu)了控制流還原模塊原生支持 .NET Standard 2.0 和 .NET 5 運(yùn)行時(shí)能穩(wěn)定處理netcoreapp3.1、net5.0,net6.0-windows,net7.0-android,net8.0-browserwasm等多目標(biāo)框架編譯的程序集。它不依賴 Mono 運(yùn)行時(shí)不調(diào)用任何 Windows-only APILinux/macOS 下開(kāi)箱即用它也不是“一鍵傻瓜式”而是把每個(gè)混淆特征如ldstr→call string::Decrypt的模式匹配、brfalse.s嵌套深度閾值、ldc.i4指令序列識(shí)別暴露為可調(diào)參數(shù)——適合逆向工程師、安全研究員、合規(guī)審計(jì)人員和需要做二進(jìn)制兼容性驗(yàn)證的 SDK 開(kāi)發(fā)者。如果你正在分析一個(gè)國(guó)密 SM2 加密后嵌入資源的 .NET 8 應(yīng)用注意de4dot-netcore 本身不實(shí)現(xiàn) SM2 解密但它能精準(zhǔn)定位并提取被 SM2 密文包裹的原始字符串字節(jié)這個(gè)版本就是你繞不開(kāi)的起點(diǎn)。2. 核心能力拆解從混淆特征識(shí)別到 IL 重建的四層還原邏輯2.1 混淆器指紋識(shí)別為什么它能自動(dòng)判斷是 ConfuserEx 還是 Eazfuscatorde4dot-netcore 不靠文件名或硬編碼簽名而是通過(guò)三階段指令圖譜比對(duì)實(shí)現(xiàn)混淆器類型判定入口點(diǎn)掃描解析Main方法或ModuleInitializer檢查是否包含call [mscorlib]System.Security.Principal.WindowsIdentity::GetCurrent()ConfuserEx v1.9 典型初始化、call [System.Runtime]System.Runtime.CompilerServices.RuntimeHelpers::InitializeArray()Eazfuscator 2022 資源加載特征字符串操作鏈分析遍歷所有l(wèi)dstr指令統(tǒng)計(jì)其后續(xù)是否緊跟call到疑似解密函數(shù)如DecryptString,Decode,GetResource并提取該函數(shù)的 IL 指令序列哈希SHA-256控制流結(jié)構(gòu)建模對(duì)每個(gè)方法構(gòu)建 CFGControl Flow Graph計(jì)算brtrue.s/brfalse.s分支嵌套深度、switch指令跳轉(zhuǎn)表大小、nop插入密度30% 即標(biāo)記為控制流扁平化。提示--verbose參數(shù)會(huì)輸出每一步的匹配詳情例如Matched ConfuserEx v1.9.0 pattern in method Program.Main$ (score: 0.92)這比原版僅輸出Detected ConfuserEx更具可追溯性。2.2 字符串解密還原如何應(yīng)對(duì) XORRC4SM2 多層嵌套原版 de4dot 對(duì)字符串解密采用“靜態(tài)模擬執(zhí)行”在內(nèi)存中構(gòu)造虛擬棧逐條執(zhí)行l(wèi)dc.i4,xor,call等指令。但 .NET Core 中l(wèi)dstr行為變更常量池引用方式不同、calli指令增多、以及混淆器引入Spanbyte操作導(dǎo)致模擬執(zhí)行崩潰。de4dot-netcore 改用符號(hào)執(zhí)行 模板匹配雙軌策略符號(hào)執(zhí)行軌對(duì)解密函數(shù)入口做輕量級(jí)符號(hào)化僅跟蹤ldarg.0,ldloc,stloc,xor,add等基礎(chǔ)指令生成表達(dá)式樹(shù)((key[0] ^ data[0]) key[1]) ^ data[1]再用 Z3 求解器反推原始字符串模板匹配軌內(nèi)置 27 種常見(jiàn)解密模式含國(guó)密 SM2 的ECPoint.Multiply調(diào)用序列識(shí)別當(dāng)符號(hào)執(zhí)行失敗時(shí)直接匹配 IL 模式并注入預(yù)編譯的 C# 解密邏輯如SM2Decrypt(byte[] cipher, byte[] privateKey)。實(shí)際使用中你只需指定--strings參數(shù)工具會(huì)自動(dòng)選擇最優(yōu)路徑。若遇到自定義 SM2 解密如私鑰硬編碼在byte[]字段中可通過(guò)--strings-decryptor指向你自己的 C# 解密類需實(shí)現(xiàn)IStringDecryptor接口。2.3 控制流扁平化還原從 switch-case 黑匣子到原始 if-else 的映射原理控制流扁平化Control Flow Flattening是 .NET 混淆最頑固的一環(huán)。原版 de4dot 僅支持簡(jiǎn)單switch還原對(duì)while(true) { switch(state) { case 0: ... state 1; break; case 1: ... state 2; break; } }結(jié)構(gòu)束手無(wú)策。de4dot-netcore 引入狀態(tài)機(jī)逆向工程算法定位主循環(huán)識(shí)別br.s label回跳到同一地址的無(wú)限循環(huán)提取狀態(tài)變量追蹤ldloc,stloc,ldc.i4賦值序列確認(rèn)哪個(gè)局部變量為state構(gòu)建狀態(tài)轉(zhuǎn)移圖將每個(gè)case塊視為節(jié)點(diǎn)state N視為有向邊檢測(cè)嵌套結(jié)構(gòu)若某case塊內(nèi)存在另一個(gè)switch則遞歸展開(kāi)為子狀態(tài)機(jī)生成結(jié)構(gòu)化代碼按拓?fù)湫蛑嘏艍K順序用if/else if/else替代switch插入goto僅用于異常跳轉(zhuǎn)。該算法在處理 ConfuserEx 的Flatten模式時(shí)還原準(zhǔn)確率達(dá) 94.7%測(cè)試集128 個(gè)混淆后 .NET 6 程序集遠(yuǎn)高于原版的 61.3%。2.4 類型與元數(shù)據(jù)修復(fù)為什么還原后能直接用 csc 編譯通過(guò)混淆器常刪除public修飾符、重命名泛型參數(shù)T→a、擦除AssemblyVersion導(dǎo)致反編譯后代碼無(wú)法編譯。de4dot-netcore 在 IL 層面做元數(shù)據(jù)語(yǔ)義修復(fù)而非簡(jiǎn)單字符串替換訪問(wèn)修飾符恢復(fù)根據(jù)callvirt/call指令調(diào)用上下文結(jié)合MethodAttributes標(biāo)志位推斷public/private例如callvirt instance void [mscorlib]System.Object::ToString()調(diào)用必為public泛型參數(shù)重建解析GenericParam表匹配constrained.指令約束條件還原where T : class等約束程序集簽名保留不修改PublicKeyToken和Culture僅重寫Version字段為1.0.0.0可選--keep-version保留原版調(diào)試信息注入生成.pdb文件需--pdb參數(shù)包含原始源碼行號(hào)映射使dotnet build時(shí)能準(zhǔn)確定位錯(cuò)誤。這意味著你拿到的還原 DLL不僅能用ildasm查看還能直接丟進(jìn) Visual Studio 作為引用項(xiàng)目編譯無(wú)需手動(dòng)修internal class a這種玄學(xué)命名。3. 快速上手從下載到還原一個(gè) .NET 8 混淆 DLL 的完整流程3.1 下載與環(huán)境準(zhǔn)備跨平臺(tái)運(yùn)行的關(guān)鍵依賴de4dot-netcore 是純 .NET 6 應(yīng)用無(wú)需安裝 Mono 或 .NET Framework。支持 Windows x64/x86、Linux x64/arm64、macOS x64/arm64。# Linux/macOS下載預(yù)編譯二進(jìn)制推薦 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 下載注意不要用瀏覽器直接點(diǎn)避免重定向丟失 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 .注意官方發(fā)布頁(yè)github.com/de4dot-netcore/releases提供win-x64,linux-x64,osx-x64,linux-arm64四個(gè)平臺(tái)包沒(méi)有 .NET Framework 版本也不提供 NuGet 包因涉及反混淆邏輯不符合 NuGet 審核政策。3.2 基礎(chǔ)還原命令三步走清空混淆痕跡假設(shè)你有一個(gè)混淆后的App.dll.NET 8 編譯ConfuserEx v1.9 混淆# 步驟1探測(cè)混淆類型不修改文件只輸出報(bào)告 ./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執(zhí)行默認(rèn)還原字符串控制流類型修復(fù) ./de4dot-netcore --output App_clean.dll App.dll # 步驟3驗(yàn)證還原結(jié)果生成反編譯代碼供人工審查 ildasm App_clean.dll /outputApp_clean.il--output參數(shù)指定輸出路徑若省略則默認(rèn)為App-clean.dll。--detect是安全第一原則——它不寫入任何文件只告訴你“它是什么、有多難、哪些模塊可能失敗”。3.3 高級(jí)參數(shù)定制針對(duì)國(guó)密 SM2 場(chǎng)景的專項(xiàng)配置當(dāng)你面對(duì)一個(gè)用國(guó)密 SM2 加密字符串的 .NET 應(yīng)用常見(jiàn)于政務(wù)、金融類 .NET 8 應(yīng)用標(biāo)準(zhǔn)--strings會(huì)失敗因?yàn)?SM2 解密需私鑰和 ASN.1 解析。此時(shí)需啟用自定義解密器編寫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調(diào)用 de4dot-netcore 并注入解密器./de4dot-netcore \ --strings \ --strings-decryptor ./Sm2Decryptor.dll \ --strings-decryptor-ctor-args 30,41,22,15,99,... \ # 十六進(jìn)制私鑰字節(jié)數(shù)組 --output App_sm2_clean.dll \ App_sm2_obfuscated.dll--strings-decryptor-ctor-args接收逗號(hào)分隔的字節(jié)十六進(jìn)制字符串如30,41,22→new byte[]{0x30,0x41,0x22}避免明文私鑰出現(xiàn)在命令行歷史中。3.4 批量處理與自動(dòng)化用 Bash/PowerShell 腳本處理整個(gè) bin 目錄# Linux/macOS批量還原當(dāng)前目錄下所有 .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 } }提示批量處理時(shí)務(wù)必加--detect先跑一遍過(guò)濾掉未混淆的 DLL如System.*、Microsoft.*避免無(wú)謂耗時(shí)。4. 避坑指南五個(gè)血淚經(jīng)驗(yàn)換來(lái)的常見(jiàn)問(wèn)題排查清單4.1 現(xiàn)象Could not resolve type System.Runtime.CompilerServices.NullableAttribute原因混淆器刪除了NullableAttribute元數(shù)據(jù)而 de4dot-netcore 在解析泛型時(shí)嘗試反射該類型.NET 6 運(yùn)行時(shí)嚴(yán)格校驗(yàn)缺失類型。解決添加--skip-nullable-check參數(shù)跳過(guò)該檢查或用--fix-attributes啟用自動(dòng)屬性修復(fù)推薦后者。4.2 現(xiàn)象字符串還原后出現(xiàn)亂碼如\u0000\u0000原因混淆器使用 UTF-16-BE 編碼但未寫 BOMde4dot-netcore 默認(rèn)按 UTF-8 解碼。解決用--strings-encoding utf-16be顯式指定編碼若不確定先用xxd -g1 App.dll | head -20查看ldstr后緊鄰的字節(jié)序列判斷編碼特征。4.3 現(xiàn)象控制流還原后方法體為空IL 只剩ret原因混淆器將真實(shí)邏輯打包進(jìn)Resource流并用Assembly.GetExecutingAssembly().GetManifestResourceStream()動(dòng)態(tài)加載執(zhí)行de4dot-netcore 默認(rèn)不處理資源流。解決啟用--resources參數(shù)提取所有資源生成Resources/目錄再用--resources-decryptor指向資源解密器如 SM2 解密資源流。4.4 現(xiàn)象Linux 下執(zhí)行報(bào)System.DllNotFoundException: libhostfxr.so原因你下載的是self-contained版本但系統(tǒng)缺少libicu或libssl常見(jiàn)于 Alpine Linux。解決改用framework-dependent版本文件名含-fd并確保已安裝 .NET 6 Runtimesudo apt install dotnet-runtime-6.0Ubuntu或apk add icu-dev openssl-devAlpine。4.5 現(xiàn)象還原后的 DLL 在 .NET 8 環(huán)境下拋BadImageFormatException原因混淆器修改了CorFlags如清除了ILONLY位de4dot-netcore 未重置該標(biāo)志。解決添加--corflags參數(shù)強(qiáng)制重寫為0x00000001ILONLY或用corflags.exe工具后處理corflags App_clean.dll /32BITREQ- /ILONLY。5. 進(jìn)階技巧用 ILDASM 自定義腳本驗(yàn)證還原質(zhì)量建立可信度基線還原不是終點(diǎn)驗(yàn)證才是關(guān)鍵。我見(jiàn)過(guò)太多人拿到*-clean.dll就以為萬(wàn)事大吉結(jié)果一跑就NullReferenceException—— 因?yàn)榛煜髟赾ctor里埋了反調(diào)試邏輯而 de4dot-netcore 默認(rèn)不還原靜態(tài)構(gòu)造函數(shù)怕破壞初始化順序。下面這套驗(yàn)證流程是我過(guò)去三年處理 200 個(gè) .NET Core 混淆樣本沉淀下來(lái)的“可信度基線”5.1 第一層驗(yàn)證IL 指令完整性比對(duì)防刪減用ildasm導(dǎo)出原始與還原 DLL 的 ILildasm App_obfuscated.dll /outputobf.il ildasm App_clean.dll /outputclean.il然后用diff檢查關(guān)鍵指標(biāo)指標(biāo)合格閾值檢查命令不合格含義ldstr指令數(shù)還原后 ≥ 原始 95%grep -c ldstr obf.ilvsgrep -c ldstr clean.il字符串解密失敗大量ldstr未還原call指令數(shù)還原后 ≤ 原始 110%grep -c call obf.ilvsgrep -c call clean.il控制流還原引入冗余跳轉(zhuǎn)brtrue.s數(shù)量還原后 ≤ 原始 30%grep -c brtrue.s obf.ilvsgrep -c brtrue.s clean.il控制流扁平化未充分還原提示brtrue.s是扁平化核心指令若還原后仍高達(dá)原始 80%說(shuō)明--control-flow參數(shù)力度不夠需加--control-flow-depth 8。5.2 第二層驗(yàn)證方法簽名一致性檢查防篡改編寫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})合格標(biāo)準(zhǔn)Missing為空集Added≤ 3 個(gè)通常是 de4dot 注入的__De4DotHelper類。若Missing有public static void Main(string[])說(shuō)明入口點(diǎn)被誤刪需加--keep-entrypoint。5.3 第三層驗(yàn)證運(yùn)行時(shí)行為回歸測(cè)試防邏輯錯(cuò)這才是終極考驗(yàn)。寫一個(gè)最小測(cè)試樁// 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); // 還原后的真實(shí)名 // 調(diào)用同一方法傳相同參數(shù) 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}); } }編譯并運(yùn)行dotnet run --project TestRunner.csproj。只有當(dāng)輸出Match: True時(shí)才證明還原未破壞業(yè)務(wù)邏輯。我曾在一個(gè)金融 SDK 上發(fā)現(xiàn)clean.dll返回null而obf.dll返回有效對(duì)象——追查發(fā)現(xiàn)混淆器在catch塊里做了Environment.Exit(0)de4dot-netcore 未還原該異常處理最終通過(guò)--keep-exception-handlers解決。從那以后我每次拿到還原 DLL都強(qiáng)制走一遍這三層驗(yàn)證先看 IL 指令數(shù)是否合理再比方法簽名是否一致最后跑一個(gè)真實(shí)輸入看輸出是否 match。三關(guān)全過(guò)才敢把它交給開(kāi)發(fā)同事或放進(jìn) CI 流水線。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取