Exetools  

Go Back   Exetools > General > General Discussion

Notices

Reply
 
Thread Tools Display Modes
  #1  
Old 09-01-2015, 07:53
delidolunet delidolunet is offline
Friend
 
Join Date: May 2012
Posts: 18
Rept. Given: 7
Rept. Rcvd 10 Times in 2 Posts
Thanks Given: 2
Thanks Rcvd at 2 Times in 2 Posts
delidolunet Reputation: 10
C# (Classic .exe, Windows 10, Windows Phone etc.) Protection

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.
Reply With Quote
  #2  
Old 09-01-2015, 08:10
mr.exodia mr.exodia is offline
Retired Moderator
 
Join Date: Nov 2011
Posts: 784
Rept. Given: 490
Rept. Rcvd 1,122 Times in 305 Posts
Thanks Given: 89
Thanks Rcvd at 714 Times in 333 Posts
mr.exodia Reputation: 1100-1299 mr.exodia Reputation: 1100-1299 mr.exodia Reputation: 1100-1299 mr.exodia Reputation: 1100-1299 mr.exodia Reputation: 1100-1299 mr.exodia Reputation: 1100-1299 mr.exodia Reputation: 1100-1299 mr.exodia Reputation: 1100-1299 mr.exodia Reputation: 1100-1299
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.
Reply With Quote
The Following 5 Users Say Thank You to mr.exodia For This Useful Post:
delidolunet (09-23-2015), Kurapica (09-01-2015), ontryit (09-01-2015), TechLord (09-01-2015), tonyweb (10-08-2016)
  #3  
Old 09-23-2015, 11:39
delidolunet delidolunet is offline
Friend
 
Join Date: May 2012
Posts: 18
Rept. Given: 7
Rept. Rcvd 10 Times in 2 Posts
Thanks Given: 2
Thanks Rcvd at 2 Times in 2 Posts
delidolunet Reputation: 10
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.
Reply With Quote
  #4  
Old 09-24-2015, 02:04
atom0s's Avatar
atom0s atom0s is offline
Family
 
Join Date: Jan 2015
Location: 127.0.0.1
Posts: 423
Rept. Given: 26
Rept. Rcvd 128 Times in 65 Posts
Thanks Given: 54
Thanks Rcvd at 817 Times in 301 Posts
atom0s Reputation: 100-199 atom0s Reputation: 100-199
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.
Reply With Quote
  #5  
Old 10-08-2016, 14:57
delidolunet delidolunet is offline
Friend
 
Join Date: May 2012
Posts: 18
Rept. Given: 7
Rept. Rcvd 10 Times in 2 Posts
Thanks Given: 2
Thanks Rcvd at 2 Times in 2 Posts
delidolunet Reputation: 10
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?
Reply With Quote
  #6  
Old 10-08-2016, 19:12
tusk tusk is offline
Friend
 
Join Date: Jun 2016
Posts: 36
Rept. Given: 0
Rept. Rcvd 0 Times in 0 Posts
Thanks Given: 9
Thanks Rcvd at 19 Times in 12 Posts
tusk Reputation: 0
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...
Reply With Quote
  #7  
Old 10-10-2016, 14:30
LaDidi LaDidi is offline
VIP
 
Join Date: Aug 2004
Posts: 213
Rept. Given: 2
Rept. Rcvd 11 Times in 10 Posts
Thanks Given: 53
Thanks Rcvd at 44 Times in 26 Posts
LaDidi Reputation: 11
@delidolunet:
Hi,

You lost your time.
+1 / mr.exodia :
Quote:
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.
Reply With Quote
  #8  
Old 10-11-2016, 01:10
bongos_man bongos_man is offline
Friend
 
Join Date: Aug 2016
Posts: 25
Rept. Given: 0
Rept. Rcvd 4 Times in 3 Posts
Thanks Given: 4
Thanks Rcvd at 25 Times in 14 Posts
bongos_man Reputation: 4
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. ;]
Reply With Quote
Reply

Tags
c sharp, decompile, protection

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
(Q) .NET App Source Code Protection (Silverlight, Windows Phone, Windows 8) delidolunet General Discussion 7 08-02-2013 10:33
Windows Drivers (.sys) packing/protection pp2 General Discussion 8 04-15-2005 11:49


All times are GMT +8. The time now is 21:02.


Always Your Best Friend: Aaron, JMI, ahmadmansoor, ZeNiX, chessgod101
( 1998 - 2024 )