.net是真的可执行文件吗？

Question

我在.net中注意到它非常容易逆向工程exe。这是因为.net可执行文件只是.net引擎的指令代码，因此.net是一种解释语言？并且从未执行过本地？

我必须承认，我从未遇到.net代码的任何性能问题，所以这就是我怀疑的原因。

有人可以向我解释一下吗？

感谢到目前为止的答案，有没有人知道为什么微软决定创建这种需要框架的方法，如果我在vb6代码被编译为本机时正确记得。是否有一个非常好的理由让.net代码现在必须通过解释器运行＆gt;

Answer 1

问题应该是什么是“真正的”可执行文件。

可执行.NET程序集以Portable Executable（PE）格式存储，这是用于Windows中可执行文件的文件格式之一。

这是一种包装格式，告诉操作系统执行包含代码的所有必要信息。

从这个意义上说，.NET可执行文件是非常“真实”的exes。

但是，对于.NET程序集，PE格式为extended：

  

微软的.NET Framework有   扩展了PE格式的功能   它支持公共语言   运行。其中包括CLR   标题和CLR数据部分。上   加载二进制文件，OS加载程序产生   通过引用执行到CLR   在PE / COFF IMPORT表中。 CLR   然后加载CLR标题和数据   部分。

     

CLR数据部分包含两个   重要部分：元数据和   中间语言（IL）代码：

     

  

• 元数据包含与程序集相关的信息，包括   装配清单。清单   详细描述了装配   包括唯一身份证明（通过   哈希，版本号等），数据   出口组件，种类繁多   信息（由Common提供支持   类型系统（CTS）），外部   引用和文件列表＆gt;   在集会内。 CLR   环境广泛使用   元数据。

  

• 中间语言（IL）代码是抽象的，与语言无关   满足.NET CLR的代码   通用中间语言（CIL）   需求。术语“中级”   是指IL代码的本质   跨语言和跨平台   兼容。这个中间体   语言，类似于Java字节码，   允许平台和语言   支持常见的.NET CLR。 IL   支持面向对象的编程   （多态，继承，抽象   类型等），例外，事件和   各种数据结构。 IL代码是   组装成.NET PE以执行   由CLR。

  

Answer 2

.Net可执行文件包含MSIL（Microsoft中间语言）字节代码，类似于Java字节码。它们不是本机Intel32代码，如果没有安装.Net框架，则无法运行。除了MSIL之外，还包含大量元数据。您可以使用Ildasm或Reflector来查看.Net可执行文件。

从技术上讲，他们没有解释，但JIT（实时）编译为机器代码。有一种方法可以将它们编译为本机代码，NGen.exe实用程序。有时，JIT代码可以比NGen更快，因为它可以进行运行时分析。

Answer 3

.NET exes是与其他可执行文件类似的PE文件，但它们包含其他部分以包含IL内部。查看this thread中的最后一篇文章，了解更多详情。

Answer 4

.exe文件包含表示IL指令的字节代码。当您启动应用程序时，JIT编译器会将其编译为专门为您的处理器创建的本机代码。

因此，虽然可执行文件不包含本机代码，但执行的是本机代码。由于JIT编译器可以优化特定处理器的代码，因此它有可能比在任何处理器上运行的本机代码更快。

Answer 5

它们是字节码。从理论上讲，字节代码可以比本机代码更快，因此不要将性能带入其中。

Answer 6

不，它们不是正常的可执行文件。它们包含CLI标准中定义的元数据和CIL（通用中间语言）指令（请参阅ECMA-335 - http://www.ecma-international.org/publications/standards/Ecma-335.htm）。

对于正在解释的CIL：.NEt的大部分版本都不解释代码，但是JIT（Just-In-Time）编译它。这意味着当在应用程序运行时第一次使用一段代码时，代码将被编译为本机代码，并且从那里开始使用此本机代码。但这实际上是一个实现细节，例如，据我所知，纯粹解释了Micro框架。

至于你在问题中的编辑：

原因在于，通过在元数据和公共检测集中共同表示代码，可以更容易地以不同的方式在不同语言之间进行互操作。

因为所有语言在幕后都是相同的，常见的“低级”语言，所以它们能够无缝地相互融合。

Answer 7

当你第一次加载.Net程序集时，字节代码（MSIL）被编译为本机机器代码（即时编译），从那时起它就作为本机汇编程序运行。所以.Net程序集不解释，但是当你第一次进行jitted时你会获得很小的性能。但是，jitting的优点是JIT编译器可以为运行程序集的体系结构（CPU指令集等）优化汇编程序，而使用传统的构建时编译（如在C ++中），情况不一定如此。

如果您愿意，可以使用ngen预编译.Net程序集，避免JIT开销。

Answer 8

是的，他们不是“真实的”。您要创建的exes将采用MSIL编码。当你运行你的一个前任时，代码将通过CLR（公共语言运行时）转换为机器代码。

MSIL代码可以轻松反编译。您可以使用.NET Reflector，它是免费的。当您反编译exe ...时，您也可以将代码从C＃转换为VB.NET或C ++等。

并且您也可以尝试Xenocode Postbuild obfuscator它使您的exe文件为Native32并进行模糊处理，如果使用此混淆器，.NET Reflector将无法对您的exe进行反编译。但是，它会让你的前任变大一点：）......

Answer 9

不解释.NET。当代码实际执行时，它是一个本机代码，由于JIT，它已经从MSIL编译。可执行文件包含生成本机代码所需的MSIL指令。

Answer 10

作为一个空闲时间 - mono - 开发人员我倾向于回答你问题的最后一部分（.net代码现在必须通过解释器才有充分的理由吗？）： 是的：便携性