编译C＃到本机？ [英] Compiling C# to Native?
问题描述
我认为我对于将.NET字节代码编译为本地代码有些困惑，或者我对最终结果感到困惑。所以请与我一起，因为我试图排序通过我认为我明白，所以你可以帮助我弄清楚我失踪了。
d喜欢做的是编译我的应用程序写在C＃下降到常规本机代码像我会得到，如果我写在C中。我的推理与性能无关，而是有一定程度的保护。我知道我的最终目标是不可能的（或甚至真的很难）规避，但我只是觉得逆转x86程序集比逆转反射器给我更难。
现在如果我把我的C＃应用程序到反射器，我基本上得到我的源代码回来。通常情况下，当我把我的非托管C / C ++应用程序到IDAPro并使用HexRays反编译器，我不会得到相同程度的反编译，我不得不求助于wading通过x86反汇编了解逻辑流程。这是我的理解，这样伟大的反编译来自反射器由于应用程序在MSIL而不是更简洁的本地代码HexRays尝试反编译。
我不担心客户端计算机仍然需要.NET运行时，我不想绕过任何问题。我想在我的程序上运行正常的软件混淆程序，例如 upx ，并且做为一个.NET二进制文件失败。
所以，只是总结我的主要问题：我编译我的.NET程序成一个本机二进制反射器不会那么容易反编译？
如果我需要一个不同的工具，我宁愿选择一些免费的工具，不像 Codewall 。
谢谢！ p>
更新：我明白我所寻找的可能会限制某些语言的功能，如Reflection，但我认为我很好接着就，随即。我的代码没有任何明确的 Assembly.Load 调用或任何排序。但是不能那些只是被 GetProcAddress / LoadLibrary 调用替换
我只是在 VS2015 上验证 .Net Native Windows 8.1 （配置正确，检查.proj以验证）和构建特定体系结构（可能过分，未验证），将生成一个本机文件，将给您更难反向工程代码，我无法通过 .dll 通过 DotPeek （JetBrains的免费网络反编译器）读取
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.
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.
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.
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.
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:\Windows\assemblies\...\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?
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?
If I need a different tool, I'd prefer something free and not something like Codewall.
Thanks!
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?
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屋！
