将 C# 编译为本机? [英] Compiling C# to Native?

问题描述

我想我对将 .NET 字节码编译为本机代码感到有些困惑，或者我对最终结果感到困惑.因此，请耐心等待我尝试整理我认为我理解的内容，以便您帮助我弄清楚我缺少什么.

I think I'm somewhat confused about compiling .NET byte-code to native code, or maybe I'm confused about the end result. So please bear with me as I try to sort through what I think I understand so you can help me figure out what I'm missing.

我想做的是将我用 C# 编写的应用程序编译成常规的本机代码，就像我用 C 编写的那样.我的推理与性能无关，而是带有某种程度的保护.我知道我的最终目标并非不可能(甚至真的那么难以规避)，但我只是觉得逆转 x86 组装比逆转 Reflector 给我的东西更困难.

What I'd like to do is compile my application written in C# down to regular native code like I'd get if I had written it in C. My reasoning has nothing to do with performance, but rather with some degree of protection. I understand that my end-goal is not impossible (or even really that difficult) to circumvent, but I just feel like reversing x86 assembly is more difficult than reversing what Reflector gives me.

现在，如果我将我的 C# 应用程序放入 Reflector，我基本上可以取回我的源代码.通常，当我将我的非托管 C/C++ 应用程序放入 IDAPro 并使用 HexRays 反编译器时，我不会得到相同程度的反编译，我不得不求助于 x86 反汇编来理解逻辑流程.据我了解，如此出色的反编译来自 Reflector，因为应用程序位于 MSIL 中，而不是 HexRays 尝试反编译的更简洁的本机代码.

Right now if I throw my C# application into Reflector, I basically get my source-code back. Typically when I throw my unmanaged C/C++ applications into IDAPro and use the HexRays decompiler, I don't quite get the same degree of decompilation back and I have to resort to wading through x86 disassembly to understand the logic flow. It's my understanding that such great decompilation comes from Reflector due to the application being in MSIL instead of the more terse native code that HexRays tries to decompile.

我不担心仍然需要 .NET 运行时的客户端机器，我并没有试图规避这些.我想在我的程序上运行像 upx 这样的普通软件混淆程序，但将其作为 .NET 二进制文件执行失败.

I have no concerns about the client machine still needing the .NET runtimes, I'm not trying to circumvent any of that. I would like to run normal software obfuscation programs like upx on my program, and doing it as a .NET binary fails.

这是我对 的理解这个 相关问题 ngen 做了我想要的.我试过使用 ngen.但是在将输出文件从 C:Windowsassemblies...applicationName.ni.exe 目录复制到我可以双击的地方后，尝试运行它会产生一个错误不是有效的 Win32 应用程序".此外，当我将 applicationName.ni.exe 扔进 Reflector 时，我得到的输出与仅从 applicationName.exe 得到的输出相同.由于 applicationName.ni.exe 应该是本机代码，我预计 Reflector 会出错，但事实并非如此.如果这是我应该这样做的方式，为什么 Reflector 仍然给我这么好的反编译?

It was my understanding from this related question that ngen does what I want. I've tried using ngen. But after copying the output file from the C:Windowsassemblies...applicationName.ni.exe directory to somewhere I can double-click, and trying to run it produces an error about it not being "a valid Win32 application". Further, when I toss the applicationName.ni.exe into Reflector, I get the same output as I did from just the applicationName.exe. Since applicationName.ni.exe is supposed to be native code, I expected Reflector to error out, but it didn't. If this the way I'm supposed to do this, why did Reflector still give me such a great decompilation?

所以，再次总结一下我的主要问题:如何将我的 .NET 程序编译成 Reflector 不容易反编译的本机二进制文件?或者有哪些最佳实践可以保护用 .NET 语言编写的产品免受新手逆向工程师的攻击?

So, just to summarize my main question again: How can I compile my .NET program into a native binary that Reflector won't so easily decompile? Or what's some best practices for protecting a product written in a .NET language from newbie reverse-engineers?

如果我需要不同的工具，我更喜欢免费的，而不是像 Codewall 这样的工具.

If I need a different tool, I'd prefer something free and not something like Codewall.

谢谢！

更新:我知道我正在寻找的内容可能会限制语言的某些功能，例如反射，但我认为我可以接受.我的代码没有任何明确的 Assembly.Load 调用或任何类似的调用.但是这些就不能被 GetProcAddress/LoadLibrary 调用替换吗?

UPDATE: I understand that what I'm looking for might limit some of the features of the language like Reflection, but I think I'm fine with that. None of my code does any explicit Assembly.Load calls or anything of the sort. But couldn't those just be replaced with GetProcAddress/LoadLibrary calls anyway?

推荐答案

我刚刚在 VS2015 上验证了 .Net Native &Windows 8.1(如果配置正确，请检查 .proj 以进行验证)并为特定架构构建(可能是矫枉过正，尚未验证)，将生成一个本机文件，该文件将为您提供更难进行逆向工程您正在寻找的代码，我无法通过 DotPeek(来自 JetBrains 的免费 .Net 反编译器)读取 .dll.

I just validated .Net Native on VS2015 & Windows 8.1 (when configured correctly, examine .proj to validate) and building for a particular architecture (may be overkill, haven't validated), will produce a native file which will give you the "harder to reverse engineer" code you are looking for which for me was unabled to read .dll via DotPeek(free .Net decompiler from JetBrains).

这篇关于将 C# 编译为本机?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！