C# (Classic .exe, Windows 10, Windows Phone etc.) Protection

[delidolunet]

Hello everyone.

I am a developer who builds applications for Windows 10.

As you know when ou build a C# application it turns its code into IL, which is decompiling and taking a look to source code is pretty easy.

Does anyone know, how can we protect our apps as much as possible, and what are your best tools to protect/decompile those apps.

As I know Smart Assembly was working well for windows 8 apps. And Eziriz .Net Reactor is also supports Windows 10.

What are your comments about that? If you could share your knowledge, I'm sure a everyone will appreciate it including me.

Thanks.

[mr.exodia]

Obfuscators help keeping away the most basic attacks, however you should use a key scheme that requires patching. Probably your app will be released once or twice, but if you don't keep things interesting enough for the guys patching it will not get cracked.

Generally you shouldn't worry too much about people cracking your. If you make it the right price people with enough money will buy it anyway, you don't miss out too much on cracks.

[delidolunet]

Actually I wanted to discuss this not for a paid product, for example for Windows Phone platform there is an instagram client which is better than official instagram application, after that in a few weeks people got it's source code, and publish it with an another name. This was what I don't want to experience.

After Microsoft released .net native, I think decompiling apps will not be this much easy anymore.

Also if you use Eziriz and Smart Assembly kind of softwares to protect your .net apps, they're getting more slower than ever. While .net is not a super-speed platform, putting some extra slowing down factors looks like a bad idea.

Thanks for your thoughts.

[atom0s]

SmartAssembly is not at all a good protection. I used to use it with work related projects and all of the simple drag and drop solutions to unpack SA files now a-days is heartbreaking. Along with that, the SA team does nothing in terms of supporting their product(s) and never responds on their forums to any questions or feedback.

There is honestly not really any good solutions out there to protect your application when it comes to .NET. The most you can do is use something like ConfuserEx, mod it a bunch, and just hope it keeps out the newbies that drag and drop things onto de4dot and similar.

[delidolunet]

Have anyone find out any other solution since then?

Also, Microsoft released .NET Standart, have anyone had some time to dig into it, like protecting and reversing the executable?

[tusk]

Most people would tell you that anything can get cracked, it all depends on the time and skills of the people looking at it

What you can do however, is get rid of the beginners as they will not know how to de-obfuscate your assembly. But remember .Net is intermediate language and can be understood quite easily if they manage to pass this first protection, so IL code can be manipulated then after

And risk of a source thief will always be here in .Net.. until one day they compile in ASM directly
I don't know if .NET Native is functional now, last time I checked, it was just still in development...

[LaDidi]

@delidolunet:
Hi,

You lost your time.
+1 / mr.exodia :

If you make it the right price people with enough money will buy it anyway, you don't miss out too much on cracks.

Regards.

[bongos_man]

there has been a lack of technical specifics so far in this thread, but as LaDidi implied above, i'm afraid if you were hoping things would get better with regard to protecting your code, you were waiting in vain. sorry. there is no one-button solution to protecting .NET software.

to address your question about .NET Standard, the short version is that .NET Standard is irrelevant to your concerns and will not help you to protect your code. the long version: .NET Standard is simply an attempt to harmonize the fragmentation that presently exists with regard to standard library support across .NET implementations. .NET Standard is a mandatory base set of APIs that must be supported by all .NET runtimes, including the full Microsoft .NET Framework, Mono, .NET Core, and other frameworks which subsume .NET implementations, such as the Universal Windows Platform. .NET Standard is effectively an upgrade to the .NET PCL. it has nothing to do with how your code will be compiled, therefore it is irrelevant; constraining your program to only use .NET Standard APIs will not make it harder to reverse engineer. you can read more about .NET library compatibility here.

there are more serious fundamental issues as well.

first, MSIL assemblies are rich in metadata. this is required in order to support the CLR's reflection facilities. even if you aren't using reflection, this data will be included in assemblies, and "obfuscation" tools will not remove them. metadata is also required for generics to work: the compilers for most .NET languages do not statically monomorphize generic code, relying on the JIT to generate code at runtime.

second, MSIL is trivially decompilable. it is easy to reconstruct both data provenance (such as for local variables) and higher-level flow control from instructions for a stack-based architecture--flow analysis is far simpler than on a register-based machine. there is also no need for any sort of complicated analysis to reconstruct function boundaries in the assembly, nor calls to library functions. obfuscation tools again do not help here--even if there were advanced packers that converted MSIL into instructions for a proprietary virtual machine (as exist for native code), they too would be mechanically reversible once understood.

.NET Native improves things for you, but with caveats: reflection will fail unless you explicitly include metadata on your assembly, and since there is no JIT, Reflection.Emit does not work at all. even though .NET Native tries to remove metadata, this is basically impossible to do in full, and the reasons go all the way to fundamentals of programming languages and type theory. if we were to formally model the CLR, its static semantics would have no notion of reflection--it is not part of the CLR's type system; it is a purely dynamic phenomenon. reflection is a feature to enable working with value-level representations of types, but without the concept of dependent types, it is impossible for a type system to express "facts" that depend on value-level terms--this is why neither obfuscators nor .NET Native can completely remove metadata. (in case you're not familiar, languages with dependent types are effectively similar to proof assistants, as in order for type-level assertions about values to be safe, machine-verifiable proofs are often required).

by the way, most of what is true of .NET is also true of the JVM and any other system with reflection or dynamic types. TL;DR: if you're paranoid about people reverse engineering your code, you might sleep better at night by using something else, but the reality is that anyone determined enough and smart enough can eventually figure it out. ;]