作为一名程序员，我不得不一遍又一遍地告诉和呐喊，如果目的是破解/窃取，那么为了诚实，你不应该这样做。如果目的是好的，那么我将分享我的解决方案。

首先，应该确定语言，无论它是不是真实.NET文件。

• 您可以使用“PEiD”工具（或者如果您没有用于“PEiD”的良好自定义签名数据库，则使用“TridNet”）来分析文件并确定语言（即近似值）。

• 使用 CFF Explorer 打开它。如果您没有看到 .NET 目录，那么这是一个本机 dll，而不是 .NET。检查那是什么语言。（有时，使用“依赖项”查看，如果您引用 MSCEERE.DLL，它包含托管代码，如果您引用 MSVCR100.DLL，它包含本地代码。）

现在，似乎有两种可能的情况：

场景 1 - 原始文件不是.NET程序：

• de4dot是为.NET文件制作的。因此，您的可执行文件可能是 shell 打包文件或Win32exe，或者程序不是由.NET语言编写的。例如，Visual C++（即用Delphi 等编写的）与.NETFramework无关，因此您可以丢弃.NET decompiler（Reflector、ILSpy 等）以获得一些代码。在这种情况下，您将不得不走最复杂的路线并返回到逆向（使用 IDA、OllyDbg 或任何其他类似工具，看看您可以在 ASM、+ HexRays Decompiler 中得到什么）。

场景 2 - 原始文件是.NET程序，但已加固：

• 一开始，您可能会尝试解压缩（如果它是用 ie UPX 等打包的），比如Universal Extractor.

• 您可以尝试使用“DNiD”工具查找混淆器名称。

• .exe 文件可能是 .net 程序集，只有在解压后才能读取。

• 使用 jitDumper3/MegaDumper 从运行时转储该 exe（输出将是 c++ 的 .NET 插入），然后使用 de4dot 转储文件（或修复具有无效元数据的转储 exe！您可以尝试“通用修复程序”）。

我同意 T.Todua 的可能原因，但引用的工具有点过时。我建议：

• 对于packer识别，尝试PEiD加上自定义userdb（https://www.aldeid.com/wiki/PEiD）、ExeInfo-PE（http://exeinfo.pe.hu/plugins.htm）和Yara的Packer规则-Rules/rules git 存储库 ( https://github.com/Yara-Rules/rules )
• 对于转储和修复，OllyDumpEx ( https://low-priority.appspot.com/ollydumpex/ ) 和 Scylla Import Reconstructor ( https://github.com/NtQuery/Scylla ) 用于本地 Windows 代码或 dnSpy 用于托管代码 ( https ://github.com/0xd4d/dnSpy )