#1 楼
没有任何反反向工程保护的反向工程.net是微不足道的。定义等）使恢复与原始代码几乎相似的源代码成为可能，从而简化了逆向工程过程。由于这种混淆非常普遍，因此请查看发布于
.NET恶意软件是否通常被编译成本机映像并被混淆，或者通常只是被混淆的.NET代码？怀疑恶意软件作者是否希望将.net转换为本地代码。
我猜想某人使用.net恶意软件的原因是因为它可以在许多平台上运行而无需关心处理器体系结构，因此在.net恶意软件中，他们肯定希望CIL在那里。
还要考虑不同的语言s .net支持。
评论
我怀疑恶意软件作者是否希望将.net之类的内容转换为本地代码。好吧，我不太确定，本地化而不是托管可能会有一些优势。当然，处理器体系结构起着重要的作用，但是，如果您不针对过于奇特的设备，则可以假设仅使用通用指令集，就可以实现可移植性。此外，我认为实际上有可能将每个引用编译为本机格式，这应该使应用程序免费。这篇文章绝对使我好奇，我必须尝试一下！
– dna
2013年6月10日16:30
@dna我同意。我不应该这样说，这样做可能会有一些优势，我现在想不起来。也许这些可以帮到你：symantec.com/connect/blogs/…defcon.org/images / defcon-15 / dc15-presentations /…
– nomilk
2013年6月10日16:37
感谢您的链接。我确实同意您的观点，依靠CLR是最简单，最可移植的方法-尤其是因为它也可以针对非Windows操作系统。这篇文章仍然很有趣，ntcore.com / files / netint_native.htm。它引入了本机加载程序，因为我猜-尚未阅读所有内容-是.NET 3.5本机映像。然而作者本人却说：这只是一团糟。将框架与应用程序一起交付，并欺骗ngen以定位较旧的CPU。没有评论，但仍然很有趣！
– dna
2013年6月10日19:19
@dna Thx以获得信息；）
– nomilk
2013年6月10日19:34
#2 楼
通常，字节码比编译后的代码更易于逆向工程。它（通常）包含更多的元数据，并使用理想化的计算模型。一个好的混淆器会使这变得困难得多，但仍不及考虑到逆向工程编写的本机代码那么复杂。这是因为字节码语言被设计为更高级别，更安全，更可移植，因此它们所允许的“技巧”不如实际处理器多。在Wikipedia上了解.NET的CIL有多么简单，而MS在其.NET SDK中提供了反汇编程序。更高级别的工具仅需Google即可。#3 楼
请注意，.NET代码也可以按照MS在将MSIL编译为本地代码中的文章中所述编译为本地映像。出于明显的安全原因，通常使用此代码：
代码更难进行逆向工程
运行时无需JIT编译器
评论
好东西，谢谢大家。那么，.NET恶意软件通常是被编译成本机映像并被混淆了，还是通常只是被混淆了.NET代码？
–zer
2013年6月10日上午10:58
我从未分析过.NET恶意软件。但是，我很确定您可以在两种格式下找到它们，可能在本机二进制文件中可以找到更多格式。但这只是有根据的猜测。
– dna
2013年6月10日15:16
评论
我将让其他人将.NET与Java进行比较，但是如果未故意混淆字节码（例如，通过Dotfuscator），则与非托管代码相比，逆转绝对容易。比较dotPeek和Hex-Rays的结果。与x86架构相比，VM的“有机增长”要少得多（阅读：更简洁），并且托管二进制文件包含更多的元数据。至于.NET与Java，我发现.NET IL通常比Java字节码更容易反编译。例如，在Java字节码中管理本地语言的方式更加复杂（例如，双字类型占用两个插槽）；异常处理程序块的结束偏移必须手动计算，因为它不包含在元数据中；如果在没有调试信息的情况下编译代码，则可能需要计算局部变量的范围；从Java 5开始，终于内联了代码块。我肯定还有其他一些小麻烦，尽管.NET当然也有它自己的地方。