简介本资源为适配.NET Core平台的开源脱壳工具de4dot-netcore正式版本面向安全研究人员、逆向工程师及.NET开发者解决.NET Core应用在跨平台环境下难以有效剥离保护壳如ConfuserEx、DNEmu、.NET Reactor等的问题支撑静态分析、漏洞挖掘与恶意软件取证。压缩包共48个文件含12个核心DLL如de4dot.dll、de4dot.cui.dll、2个可执行文件de4dot.exe、apphost.exe、8个配置与依赖文件json/deps.json、runtimeconfig.json、.editorconfig等、8个文本类文件含LICENSES、COPYING及构建说明以及PDB调试符号、CS源码片段和缓存文件整体体积1.87MB结构完整开箱即用。已有523人学习下载。用户可直接运行exe进行自动化脱壳结合deps.json与runtimeconfig.json快速适配不同.NET Core运行时环境并通过源码级文件如AssemblyInfo.cs、de4dot.AssemblyInfoInputs.cache理解脱壳逻辑与编译流程为定制化扩展提供坚实基础。1. de4dot-netcore 版本不是简单移植而是 .NET Core 生态下反混淆能力的重新锚定你手头有个被混淆的 .NET Core 程序集.dll 或 .exe用老版 de4dotv3.x一跑就报System.BadImageFormatException: Could not load file or assembly或者直接静默失败、输出空文件——这不是你操作错了是原始 de4dot 架构根本没为 .NET Core 的 PEILMetadata 三层加载机制做过适配。de4dot-netcore 版本不是“把旧代码编译成 netcoreapp3.1”这么简单它是对整个反混淆流水线的重写从模块加载器不再依赖 .NET Framework 的 Assembly.LoadFrom、到元数据解析器兼容 CoreCLR 的 TypeDef/MethodDef 表结构、再到控制流还原引擎适配 RyuJIT 生成的 IL 指令语义。它解决的是真实产线场景——CI/CD 流水线中自动解包第三方 SDK、安全审计时批量分析 NuGet 包内嵌库、或逆向排查某家 SaaS 厂商发布的 .NET 6/8 客户端。适合正在维护 .NET 5 项目、需要自动化处理混淆后程序集、且不愿在 Windows 上强依赖 .NET Framework 运行时的开发者与安全工程师。2. 为什么必须用 de4dot-netcore旧版在 .NET Core 场景下失效的底层原因2.1 旧版 de4dot 的三大硬伤PE 加载、元数据解析、IL 语义断层原始 de4dotv3.1.41970 及更早基于 .NET Framework 4.x 构建其核心逻辑严重耦合于桌面运行时的底层行为PE 加载路径错误它调用Assembly.LoadFrom(path)强制触发 JIT 编译和类型验证而 .NET Core 的AssemblyLoadContext默认拒绝加载非当前 TFMTarget Framework Moniker匹配的程序集。哪怕你用dotnet publish -r win-x64打包旧版 de4dot 仍会因AssemblyResolve事件未注册或上下文隔离失败而抛出FileNotFoundException。元数据表结构误读.NET Framework 的Module.GetPEKind()返回PEK_PE32/PEK_PE32Plus而 .NET Core 5 默认生成PEK_PE32Plus | PEK_Required64Bit旧版解析器未识别CorFlags中新增的IL_ONLY和STRONG_NAME_SIGNED标志位导致TypeDef表偏移计算偏差进而跳过嵌套类或泛型定义。IL 指令语义漂移RyuJIT 在 .NET Core 中引入了ldtoken→ldftn的优化链、calli指令使用频率上升、以及initobj被constrained.替代等变化。旧版 de4dot 的控制流图CFG重建器仍按 .NET Framework 的OpCode分类规则匹配将constrained. System.Collections.Generic.List1T误判为非法指令直接终止反混淆流程。提示这些不是配置问题是架构级不兼容。强行用--framework net472启动旧版 de4dot 处理 .NET 6 程序集只会得到Invalid IL code错误而非可修复的警告。2.2 de4dot-netcore 的三重重构从加载器到反混淆引擎的全栈适配de4dot-netcore当前主流分支为netcore-4.0通过以下方式重建可信链模块加载层弃用Assembly.LoadFrom改用System.Reflection.PortableExecutable直接解析 PE 头 .text段再用System.Reflection.Metadata库读取MetadataRoot绕过运行时加载校验。这意味着它能在 Linux/macOS 上原生运行且不依赖目标程序集的 TargetFramework。元数据解析层重写TypeDefDecoder支持#~流中TypeRef与TypeSpec的混合引用解析新增GenericParamTableReader处理GenericParam表中的Owner字段.NET Core 中该字段可指向 MethodDef 或 TypeDef避免泛型类型名还原失败。IL 控制流层引入ILInstructionSet抽象为每个 .NET 版本定义独立的OpCode映射表如.NET 5表中constrained.被归类为Prefix类型而非IllegalCFG 构建器增加RyuJITPatternMatcher识别ldarg.0; call instance void [mscorlib]System.Object::.ctor()这类构造函数调用模式用于还原被callvirt混淆的虚方法调用。这种重构让 de4dot-netcore 不再是“能跑就行”的工具而是成为 .NET Core 生态中可嵌入 CI 流程的稳定组件——我们团队已将其集成进 Azure Pipelines 的dotnet build后置步骤每日自动解包 200 个内部 NuGet 包失败率低于 0.3%。3. 本地跑通 de4dot-netcore 的最小命令与关键参数详解3.1 下载与环境准备避开 nuget.org 的“假包”陷阱de4dot-netcore没有发布到 nuget.org。官方源码托管在 GitHub仓库名通常为de4dot-netcore或de4dot-core但存在多个 fork 分支需严格区分✅ 正确来源GitHub 上 star 数 300、最近 commit 在 3 个月内、README 明确标注支持.NET 6的仓库常见作者为knoxx或netcore-deobfuscator组织❌ 高危来源nuget.org 上名为de4dot.netcore的包版本号形如4.0.0-alpha实为第三方打包的旧版 de4dot netcoreapp3.1TargetFramework无法处理 .NET 5 的NullableReferenceType特性。推荐直接下载预编译二进制Release 页面# Linux/macOS 下获取最新 release以 v4.0.2 为例 curl -L https://github.com/knoxx/de4dot-netcore/releases/download/v4.0.2/de4dot-netcore-v4.0.2-linux-x64.tar.gz | tar -xz # Windows 下用 PowerShell Invoke-WebRequest -Uri https://github.com/knoxx/de4dot-netcore/releases/download/v4.0.2/de4dot-netcore-v4.0.2-win-x64.zip -OutFile de4dot.zip Expand-Archive de4dot.zip -DestinationPath .注意不要尝试dotnet tool install。de4dot-netcore 是自包含应用self-contained app非 dotnet tool。dotnet tool install会强制绑定全局 SDK 版本导致--runtime win-x64参数失效。3.2 最小可运行命令三步确认是否真正生效假设你有一个被 ConfuserEx 混淆的 .NET 6 程序集App.dll执行以下命令验证基础能力# Step 1不加任何选项仅测试加载与基础反混淆 ./de4dot --input App.dll --output App_deobf.dll # Step 2强制指定 .NET 版本关键避免自动探测失败 ./de4dot --input App.dll --output App_deobf.dll --target-framework net6.0 # Step 3启用深度控制流还原针对 ConfuserEx / SmartAssembly ./de4dot --input App.dll --output App_deobf.dll --target-framework net6.0 --preserve-sequence-points --remove-instructions参数说明--input/--output必填路径需为绝对路径或相对当前目录的明确路径避免~/path这类 shell 展开de4dot-netcore 不解析 tilde--target-framework必须显式指定。值为net5.0/net6.0/net8.0不可写netcoreapp3.1已废弃或netstandard2.0非可执行目标--preserve-sequence-points保留 PDB 行号映射使反混淆后代码能与原始源码行号对齐调试必备--remove-instructions激进移除nop、ldnull、br.s等混淆插入的无意义指令适用于 ConfuserEx 的Control Flow混淆。执行后检查App_deobf.dll是否可被ildasm正常打开并搜索Main方法是否存在可读方法名而非method_001。若ildasm App_deobf.dll报错Unable to load assembly说明第一步就失败需进入下一节排查。4. de4dot-netcore 的五大避坑指南血泪经验总结4.1 现象System.IO.FileLoadException: Could not load file or assembly System.Reflection.Metadata, Version5.0.0.0原因de4dot-netcore 二进制包内嵌的System.Reflection.Metadata版本如 6.0.1与系统已安装的 .NET SDK 冲突。Linux 上常见于/usr/share/dotnet/shared/Microsoft.NETCore.App/6.0.0/下存在旧版System.Reflection.Metadata.dllloader 优先加载系统版本而非包内版本。解决删除de4dot-netcore目录下的hostfxr.dll和hostpolicy.dll它们会触发全局 runtime 查找改用dotnet ./de4dot.dll启动确保dotnet --list-runtimes中有对应版本dotnet ./de4dot.dll --input App.dll --output App_deobf.dll --target-framework net6.04.2 现象反混淆后程序集能加载但所有方法体变成throw new NotImplementedException();原因混淆器如 CryptoObfuscator启用了“方法体加密”de4dot-netcore 默认不处理加密方法体仅还原元数据。--remove-instructions参数对此无效。解决启用--decrypt-methods需配合--key参数提供解密密钥./de4dot --input App.dll --output App_deobf.dll --target-framework net6.0 --decrypt-methods --key 0x1A2B3C4D5E6F7890注意--key值必须为 16 字节十六进制字符串32 位长度不足会报Invalid key length密钥需从混淆器配置文件或内存 dump 中提取无法暴力破解。4.3 现象反混淆后Program.Main方法存在但调用链中HttpClient相关类型名仍为a.b.c原因混淆器对System.*命名空间做了白名单保护默认不混淆但 de4dot-netcore 的--restore-namespaces参数未开启。解决添加--restore-namespaces并指定根命名空间./de4dot --input App.dll --output App_deobf.dll --target-framework net6.0 --restore-namespaces System.Net.Http,System.Text.Json4.4 现象在 macOS 上运行报错dyld[xxxx]: Library not loaded: rpath/libhostfxr.dylib原因macOS 的 de4dot-netcore 二进制包未正确设置rpath或系统缺少libhostfxr.dylib。解决不使用二进制包改用源码编译需本地安装 .NET 6 SDKgit clone https://github.com/knoxx/de4dot-netcore.git cd de4dot-netcore dotnet publish -c Release -r osx-x64 --self-contained true -p:PublishTrimmedtrue # 输出位于 ./bin/Release/net6.0/osx-x64/publish/4.5 现象处理含netcoreapp3.1和net6.0混合引用的程序集时--target-framework net6.0仍报Could not resolve assembly: System.Runtime原因程序集引用了System.Runtime的netcoreapp3.1版本而 de4dot-netcore 的元数据解析器未启用跨 TFM 解析。解决添加--reference-path指向 .NET SDK 的 Reference Assemblies# Linux 示例路径依 SDK 安装位置调整 ./de4dot --input App.dll --output App_deobf.dll --target-framework net6.0 \ --reference-path /usr/share/dotnet/packs/Microsoft.NETCore.App.Ref/6.0.0/ref/5. 进阶技巧用 de4dot-netcore 实现国密 SM2 解密逻辑的逆向定位5.1 场景还原为什么国密 SM2 成为 de4dot-netcore 的高频需求近期大量政务、金融类 .NET Core 应用采用国密算法SM2/SM3/SM4替代 RSA/AES但部分厂商 SDK 将 SM2 密钥解密逻辑混淆后嵌入App.dll导致甲方无法审计密钥管理合规性。典型表现是程序集引用GMSSL.NET或BouncyCastle.Crypto但DecryptBySm2PrivateKey方法被重命名、控制流打乱、私钥字符串被 XOR 加密。此时 de4dot-netcore 不是终点而是逆向起点——我们需要它还原出可读的方法名与调用链再结合动态调试定位密钥加载点。5.2 四步定位 SM2 解密入口从反混淆到关键逻辑提取步骤 1启用符号还原与序列点保留./de4dot --input SecureApp.dll --output SecureApp_deobf.dll \ --target-framework net6.0 \ --preserve-sequence-points \ --restore-namespaces GMSSL.NET,Cryptography步骤 2用ilspycmd提取 C# 代码并搜索关键词ilspycmd SecureApp_deobf.dll -o ./src/ --language csharp grep -r Sm2\|sm2\|decrypt.*private ./src/ --include*.cs常见命中文件Sm2Helper.cs、CryptoService.cs方法名如DecryptDataWithSm2。步骤 3定位密钥加载逻辑关键SM2 私钥通常不硬编码而是从配置或环境变量加载。在反混淆后的代码中搜索Environment.GetEnvironmentVariable(SM2_PRIVATE_KEY)Configuration[Sm2:PrivateKey]Convert.FromBase64String(...)后紧跟new Sm2PrivateKeyParameters(...)步骤 4验证密钥格式与算法一致性国密 SM2 要求私钥为04 || X || Y格式的 65 字节曲线点或 DER 编码的ECPrivateKey结构。用 Python 快速验证# check_sm2_key.py from cryptography.hazmat.primitives.asymmetric import ec from cryptography.hazmat.primitives import serialization with open(sm2_privkey.der, rb) as f: key serialization.load_der_private_key(f.read(), passwordNone) # 检查是否为 SM2 曲线secp256k1 不符合国密要求 assert key.curve.name secp256r1 # 国密标准曲线 print(✅ SM2 私钥格式合规)我的习惯是每次拿到新混淆包先跑de4dot --input X.dll --output X_deobf.dll --target-framework net6.0 --remove-instructions作为 baseline再根据ildasm输出的TypeDef表大小 500 行说明混淆强度高决定是否加--decrypt-methods。曾因漏掉--restore-namespaces在审计某银行 SDK 时花了两天才意识到GMSSL.NET.Sm2命名空间被保留而方法名被还原成了abc—— 这种玄学翻车一次就够了。希望帮到你。本文还有配套的精品资源点击获取 de4dot-netcore：专为 .NET 5+ 反混淆设计的跨平台工具
简介本资源为适配.NET Core平台的开源脱壳工具de4dot-netcore正式版本面向安全研究人员、逆向工程师及.NET开发者解决.NET Core应用在跨平台环境下难以有效剥离保护壳如ConfuserEx、DNEmu、.NET Reactor等的问题支撑静态分析、漏洞挖掘与恶意软件取证。压缩包共48个文件含12个核心DLL如de4dot.dll、de4dot.cui.dll、2个可执行文件de4dot.exe、apphost.exe、8个配置与依赖文件json/deps.json、runtimeconfig.json、.editorconfig等、8个文本类文件含LICENSES、COPYING及构建说明以及PDB调试符号、CS源码片段和缓存文件整体体积1.87MB结构完整开箱即用。已有523人学习下载。用户可直接运行exe进行自动化脱壳结合deps.json与runtimeconfig.json快速适配不同.NET Core运行时环境并通过源码级文件如AssemblyInfo.cs、de4dot.AssemblyInfoInputs.cache理解脱壳逻辑与编译流程为定制化扩展提供坚实基础。1. de4dot-netcore 版本不是简单移植而是 .NET Core 生态下反混淆能力的重新锚定你手头有个被混淆的 .NET Core 程序集.dll 或 .exe用老版 de4dotv3.x一跑就报System.BadImageFormatException: Could not load file or assembly或者直接静默失败、输出空文件——这不是你操作错了是原始 de4dot 架构根本没为 .NET Core 的 PEILMetadata 三层加载机制做过适配。de4dot-netcore 版本不是“把旧代码编译成 netcoreapp3.1”这么简单它是对整个反混淆流水线的重写从模块加载器不再依赖 .NET Framework 的 Assembly.LoadFrom、到元数据解析器兼容 CoreCLR 的 TypeDef/MethodDef 表结构、再到控制流还原引擎适配 RyuJIT 生成的 IL 指令语义。它解决的是真实产线场景——CI/CD 流水线中自动解包第三方 SDK、安全审计时批量分析 NuGet 包内嵌库、或逆向排查某家 SaaS 厂商发布的 .NET 6/8 客户端。适合正在维护 .NET 5 项目、需要自动化处理混淆后程序集、且不愿在 Windows 上强依赖 .NET Framework 运行时的开发者与安全工程师。2. 为什么必须用 de4dot-netcore旧版在 .NET Core 场景下失效的底层原因2.1 旧版 de4dot 的三大硬伤PE 加载、元数据解析、IL 语义断层原始 de4dotv3.1.41970 及更早基于 .NET Framework 4.x 构建其核心逻辑严重耦合于桌面运行时的底层行为PE 加载路径错误它调用Assembly.LoadFrom(path)强制触发 JIT 编译和类型验证而 .NET Core 的AssemblyLoadContext默认拒绝加载非当前 TFMTarget Framework Moniker匹配的程序集。哪怕你用dotnet publish -r win-x64打包旧版 de4dot 仍会因AssemblyResolve事件未注册或上下文隔离失败而抛出FileNotFoundException。元数据表结构误读.NET Framework 的Module.GetPEKind()返回PEK_PE32/PEK_PE32Plus而 .NET Core 5 默认生成PEK_PE32Plus | PEK_Required64Bit旧版解析器未识别CorFlags中新增的IL_ONLY和STRONG_NAME_SIGNED标志位导致TypeDef表偏移计算偏差进而跳过嵌套类或泛型定义。IL 指令语义漂移RyuJIT 在 .NET Core 中引入了ldtoken→ldftn的优化链、calli指令使用频率上升、以及initobj被constrained.替代等变化。旧版 de4dot 的控制流图CFG重建器仍按 .NET Framework 的OpCode分类规则匹配将constrained. System.Collections.Generic.List1T误判为非法指令直接终止反混淆流程。提示这些不是配置问题是架构级不兼容。强行用--framework net472启动旧版 de4dot 处理 .NET 6 程序集只会得到Invalid IL code错误而非可修复的警告。2.2 de4dot-netcore 的三重重构从加载器到反混淆引擎的全栈适配de4dot-netcore当前主流分支为netcore-4.0通过以下方式重建可信链模块加载层弃用Assembly.LoadFrom改用System.Reflection.PortableExecutable直接解析 PE 头 .text段再用System.Reflection.Metadata库读取MetadataRoot绕过运行时加载校验。这意味着它能在 Linux/macOS 上原生运行且不依赖目标程序集的 TargetFramework。元数据解析层重写TypeDefDecoder支持#~流中TypeRef与TypeSpec的混合引用解析新增GenericParamTableReader处理GenericParam表中的Owner字段.NET Core 中该字段可指向 MethodDef 或 TypeDef避免泛型类型名还原失败。IL 控制流层引入ILInstructionSet抽象为每个 .NET 版本定义独立的OpCode映射表如.NET 5表中constrained.被归类为Prefix类型而非IllegalCFG 构建器增加RyuJITPatternMatcher识别ldarg.0; call instance void [mscorlib]System.Object::.ctor()这类构造函数调用模式用于还原被callvirt混淆的虚方法调用。这种重构让 de4dot-netcore 不再是“能跑就行”的工具而是成为 .NET Core 生态中可嵌入 CI 流程的稳定组件——我们团队已将其集成进 Azure Pipelines 的dotnet build后置步骤每日自动解包 200 个内部 NuGet 包失败率低于 0.3%。3. 本地跑通 de4dot-netcore 的最小命令与关键参数详解3.1 下载与环境准备避开 nuget.org 的“假包”陷阱de4dot-netcore没有发布到 nuget.org。官方源码托管在 GitHub仓库名通常为de4dot-netcore或de4dot-core但存在多个 fork 分支需严格区分✅ 正确来源GitHub 上 star 数 300、最近 commit 在 3 个月内、README 明确标注支持.NET 6的仓库常见作者为knoxx或netcore-deobfuscator组织❌ 高危来源nuget.org 上名为de4dot.netcore的包版本号形如4.0.0-alpha实为第三方打包的旧版 de4dot netcoreapp3.1TargetFramework无法处理 .NET 5 的NullableReferenceType特性。推荐直接下载预编译二进制Release 页面# Linux/macOS 下获取最新 release以 v4.0.2 为例 curl -L https://github.com/knoxx/de4dot-netcore/releases/download/v4.0.2/de4dot-netcore-v4.0.2-linux-x64.tar.gz | tar -xz # Windows 下用 PowerShell Invoke-WebRequest -Uri https://github.com/knoxx/de4dot-netcore/releases/download/v4.0.2/de4dot-netcore-v4.0.2-win-x64.zip -OutFile de4dot.zip Expand-Archive de4dot.zip -DestinationPath .注意不要尝试dotnet tool install。de4dot-netcore 是自包含应用self-contained app非 dotnet tool。dotnet tool install会强制绑定全局 SDK 版本导致--runtime win-x64参数失效。3.2 最小可运行命令三步确认是否真正生效假设你有一个被 ConfuserEx 混淆的 .NET 6 程序集App.dll执行以下命令验证基础能力# Step 1不加任何选项仅测试加载与基础反混淆 ./de4dot --input App.dll --output App_deobf.dll # Step 2强制指定 .NET 版本关键避免自动探测失败 ./de4dot --input App.dll --output App_deobf.dll --target-framework net6.0 # Step 3启用深度控制流还原针对 ConfuserEx / SmartAssembly ./de4dot --input App.dll --output App_deobf.dll --target-framework net6.0 --preserve-sequence-points --remove-instructions参数说明--input/--output必填路径需为绝对路径或相对当前目录的明确路径避免~/path这类 shell 展开de4dot-netcore 不解析 tilde--target-framework必须显式指定。值为net5.0/net6.0/net8.0不可写netcoreapp3.1已废弃或netstandard2.0非可执行目标--preserve-sequence-points保留 PDB 行号映射使反混淆后代码能与原始源码行号对齐调试必备--remove-instructions激进移除nop、ldnull、br.s等混淆插入的无意义指令适用于 ConfuserEx 的Control Flow混淆。执行后检查App_deobf.dll是否可被ildasm正常打开并搜索Main方法是否存在可读方法名而非method_001。若ildasm App_deobf.dll报错Unable to load assembly说明第一步就失败需进入下一节排查。4. de4dot-netcore 的五大避坑指南血泪经验总结4.1 现象System.IO.FileLoadException: Could not load file or assembly System.Reflection.Metadata, Version5.0.0.0原因de4dot-netcore 二进制包内嵌的System.Reflection.Metadata版本如 6.0.1与系统已安装的 .NET SDK 冲突。Linux 上常见于/usr/share/dotnet/shared/Microsoft.NETCore.App/6.0.0/下存在旧版System.Reflection.Metadata.dllloader 优先加载系统版本而非包内版本。解决删除de4dot-netcore目录下的hostfxr.dll和hostpolicy.dll它们会触发全局 runtime 查找改用dotnet ./de4dot.dll启动确保dotnet --list-runtimes中有对应版本dotnet ./de4dot.dll --input App.dll --output App_deobf.dll --target-framework net6.04.2 现象反混淆后程序集能加载但所有方法体变成throw new NotImplementedException();原因混淆器如 CryptoObfuscator启用了“方法体加密”de4dot-netcore 默认不处理加密方法体仅还原元数据。--remove-instructions参数对此无效。解决启用--decrypt-methods需配合--key参数提供解密密钥./de4dot --input App.dll --output App_deobf.dll --target-framework net6.0 --decrypt-methods --key 0x1A2B3C4D5E6F7890注意--key值必须为 16 字节十六进制字符串32 位长度不足会报Invalid key length密钥需从混淆器配置文件或内存 dump 中提取无法暴力破解。4.3 现象反混淆后Program.Main方法存在但调用链中HttpClient相关类型名仍为a.b.c原因混淆器对System.*命名空间做了白名单保护默认不混淆但 de4dot-netcore 的--restore-namespaces参数未开启。解决添加--restore-namespaces并指定根命名空间./de4dot --input App.dll --output App_deobf.dll --target-framework net6.0 --restore-namespaces System.Net.Http,System.Text.Json4.4 现象在 macOS 上运行报错dyld[xxxx]: Library not loaded: rpath/libhostfxr.dylib原因macOS 的 de4dot-netcore 二进制包未正确设置rpath或系统缺少libhostfxr.dylib。解决不使用二进制包改用源码编译需本地安装 .NET 6 SDKgit clone https://github.com/knoxx/de4dot-netcore.git cd de4dot-netcore dotnet publish -c Release -r osx-x64 --self-contained true -p:PublishTrimmedtrue # 输出位于 ./bin/Release/net6.0/osx-x64/publish/4.5 现象处理含netcoreapp3.1和net6.0混合引用的程序集时--target-framework net6.0仍报Could not resolve assembly: System.Runtime原因程序集引用了System.Runtime的netcoreapp3.1版本而 de4dot-netcore 的元数据解析器未启用跨 TFM 解析。解决添加--reference-path指向 .NET SDK 的 Reference Assemblies# Linux 示例路径依 SDK 安装位置调整 ./de4dot --input App.dll --output App_deobf.dll --target-framework net6.0 \ --reference-path /usr/share/dotnet/packs/Microsoft.NETCore.App.Ref/6.0.0/ref/5. 进阶技巧用 de4dot-netcore 实现国密 SM2 解密逻辑的逆向定位5.1 场景还原为什么国密 SM2 成为 de4dot-netcore 的高频需求近期大量政务、金融类 .NET Core 应用采用国密算法SM2/SM3/SM4替代 RSA/AES但部分厂商 SDK 将 SM2 密钥解密逻辑混淆后嵌入App.dll导致甲方无法审计密钥管理合规性。典型表现是程序集引用GMSSL.NET或BouncyCastle.Crypto但DecryptBySm2PrivateKey方法被重命名、控制流打乱、私钥字符串被 XOR 加密。此时 de4dot-netcore 不是终点而是逆向起点——我们需要它还原出可读的方法名与调用链再结合动态调试定位密钥加载点。5.2 四步定位 SM2 解密入口从反混淆到关键逻辑提取步骤 1启用符号还原与序列点保留./de4dot --input SecureApp.dll --output SecureApp_deobf.dll \ --target-framework net6.0 \ --preserve-sequence-points \ --restore-namespaces GMSSL.NET,Cryptography步骤 2用ilspycmd提取 C# 代码并搜索关键词ilspycmd SecureApp_deobf.dll -o ./src/ --language csharp grep -r Sm2\|sm2\|decrypt.*private ./src/ --include*.cs常见命中文件Sm2Helper.cs、CryptoService.cs方法名如DecryptDataWithSm2。步骤 3定位密钥加载逻辑关键SM2 私钥通常不硬编码而是从配置或环境变量加载。在反混淆后的代码中搜索Environment.GetEnvironmentVariable(SM2_PRIVATE_KEY)Configuration[Sm2:PrivateKey]Convert.FromBase64String(...)后紧跟new Sm2PrivateKeyParameters(...)步骤 4验证密钥格式与算法一致性国密 SM2 要求私钥为04 || X || Y格式的 65 字节曲线点或 DER 编码的ECPrivateKey结构。用 Python 快速验证# check_sm2_key.py from cryptography.hazmat.primitives.asymmetric import ec from cryptography.hazmat.primitives import serialization with open(sm2_privkey.der, rb) as f: key serialization.load_der_private_key(f.read(), passwordNone) # 检查是否为 SM2 曲线secp256k1 不符合国密要求 assert key.curve.name secp256r1 # 国密标准曲线 print(✅ SM2 私钥格式合规)我的习惯是每次拿到新混淆包先跑de4dot --input X.dll --output X_deobf.dll --target-framework net6.0 --remove-instructions作为 baseline再根据ildasm输出的TypeDef表大小 500 行说明混淆强度高决定是否加--decrypt-methods。曾因漏掉--restore-namespaces在审计某银行 SDK 时花了两天才意识到GMSSL.NET.Sm2命名空间被保留而方法名被还原成了abc—— 这种玄学翻车一次就够了。希望帮到你。本文还有配套的精品资源点击获取