Compiling C# to Native?

Question

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?

Solution 1

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).

Solution 2

That's not how ngen.exe works. It merely runs the JIT compiler up front to generate the .ni.exe or .ni.dll module. That binary file does not contain metadata, only the machine code generated from the IL for the method bodies. The CLR still must find the original assembly. Only then can it determine that there is an ngen-ed image available so that it can use the machine code from it rather than generate it from the assembly's IL.

Ngen.exe speeds up the warm startup time of your app, that's all.

My usual advice to anybody that might be interested in disassembling my assemblies is to point them to sourceforge.net. It has terabytes of source code, written and maintained by programmers that are usually better than me. Sometimes even with good comments. If your obfuscator doesn't work well then shop around for a better one. There are many.

Solution 3

Yesterday, at Build 2014, Microsoft announced .NET Native. According to the FAQ, "... Initially, we are focusing on Windows Store apps with .NET Native. In the longer term we will continue to improve native compilation for all .NET applications."

Solution 4

If you want to protect your code, an obfuscator is the typical approach. Dotfuscator has been in an arms race with reflector for a while and we use it on our products. In practice, however, a skilled human can easily read obfuscated code.

Compiling to native code defeats the purpose of having a managed language. The main benefit is to allow the target runtime to JIT the IL into something that is optimally palatable for the target CPU. If you want otherwise, you would use something like the ahead-of-time option in mono.

Solution 5

Spoon (previously Xenocode) has a product that might fit your needs. We use it for a WPF based installer UI so we don't have to bootstrap .net in order to load the setup program itself.

View more solutions

Comments

[Chris Marisic]

On the code protectors/obstufactors most of them are commercial and moderately expensive if your not a software development company however even the top tier commercial ones can have tons of problems with your code actually working right after it does it's thing.

[Ant Waters]

I need a similar functionality, also for security reasons. My C# application needs to decrypt a config file that is distributed separately to each user (each file being different). The problem of course is that the code and algorithm for the decryption need to be in the C#, which is a risk if it can be recreated so easily. I'm stumped for an alternative solution to this.

[mrduclaw]

Doesn't Dotfuscator just obfuscate variable names so that it's more difficult to read? And I get that I won't be receiving the run-time optimizations, and I'm OK with that. My main purpose in using C# was the ease and beauty of the language's syntax and libraries, the nifty optimizations came second.

[mrduclaw]

None of my code explicitly uses Reflection, and I'm OK without it. Barring some limitations on the language itself, is this possible?

[mrduclaw]

Thank you! That's exactly the explanation I was looking for with regard to what ngen is doing. Do you have any suggestions on a good, free, obfuscator?

[user1703401]

I only know good and free disassemblers. A disassembler has to be free, asking money for it defeats the purpose of using one. Good obfuscators cost money. Visual Studio comes with one, Dotfuscator. I never heard of a company that sells a product based on cracked source code that was protected by Dotfuscator. That suggests it works well.

[mrduclaw]

This looks fantastic, it's just a little more expensive than I'd like since I'm just a lone developer and not doing this for a company.

[mrduclaw]

Oh no, my algorithms aren't doing anything fancy. It's somewhere in between academic curiosity and IP concerns. I think a decent (but free) obfuscator would probably suit me fine for my IP concerns, but I do have a custom code packer that I've written previously that I would like to use on my .NET applications as well. Any suggestions for an obfuscator?

[dkackman]

Indeed the price can be a bit prohibitive. It works well though. Not sure if there are any open source or other alternatives out there. Another downside is it results in very large executable but the environment virtualization is pretty slick.

[MSalters]

You know it, but the hypothetical C#-to-native compiler can't really assume it.

[zezba9000]

"Compiling to native code defeats the purpose of having a managed language" --This is not true.

[Daniel Kmak]

Free for 30 days of use.*

[Eldar Zeynalov]

But how can it be used in VS2013? I don't have VS2015 license so I want to use .Net Native in VS2013

[IInspectable]

One feature of managed .NET languages is, that they can be verifiably safe. Compiling verifiably safe IL to native code doesn't lose this specific feature. Also, what you describe as the "main benefit" does not even exist in reality (not even 5 years after you initially wrote this answer): While possible in theory, .NET's JIT compiler is extremely conservative, and the only noteworthy optimization that has happened since its inception is improved code throughput. No work has been done on optimizing the emitted native code.

[Admin]

@EldarZeynalov Maybe you should look at VS2015 Community Edition?

[mrduclaw]

Great! Six years later and my dreams have finally come true. ;)

[Eric Eskildsen]

Note that this is for Windows 10 Universal apps, not WPF or WinForms. I.e., Windows 8.1 and above.

[Reversed Engineer]

Maybe then having a managed language defeats the purpose of having machine code after all, namely speed and power - the computer itself's raison d'être

[Redoman]

@EricEskildsen, so you can't compile to native for WPF/WinForms?

[Eric Eskildsen]

@jj_ With .NET Native? Not that I know of. That said, there may be other ways to compile WPF/WinForms to native today -- I haven't checked that space in a while.

[Redoman]

@EricEskildsen Yeah, Delphi is one (and its correspondent open source project Lazarus).

[Kurt Fitzner]

This looks like work based on IL2C at csnative.codeplex.com (that link might go away soon with the codeplex shutdown)