• Advertisement
Sign in to follow this  

[.net] .NET Decompile Protection

This topic is 4482 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

EDIT: Since all applications are compiled to MSIL, they can be easily converted BACK to any .NET language (C#, VB.NET) I'm looking for a program that can convert MSIL to Native Code. This way, if someone trys to decompile it-- they can't because it's converted to native code. Is there program to convert MSIL to Native code? Anything besides Salamander .NET Protector (way over priced!) [Edited by - tmack on October 10, 2005 8:10:35 PM]

Share this post


Link to post
Share on other sites
Advertisement
With Visual Studio comes a community edition of an obfuscator. That is a way of preventing decompilation. However, whatever you do to code, in the end it has to go to the CPU, and therefore will 'allways' be readable. Perhaps in the (near) future CPU will have hardware support for decrypting code before running it...

cheers

Share this post


Link to post
Share on other sites
Quote:
Original post by ernow
With Visual Studio comes a community edition of an obfuscator. That is a way of preventing decompilation. However, whatever you do to code, in the end it has to go to the CPU, and therefore will 'allways' be readable. Perhaps in the (near) future CPU will have hardware support for decrypting code before running it...

cheers


I know.

Obfuscator's do not protect the source code. They are used to make decompiling harder for newbies. It's not much harder for someone who knows what they are doing.

I'm not talking about the way C/C++ is compiled.. or anything. .NET converts the code to MSIL, which can be translated back into C#/VB/etc



Share this post


Link to post
Share on other sites
As long as the CLR is running MSIL you can always read MSIL. MSIL can 'always' be translated into C# or VB or any other CLS compliant language. The only way to stop that is to put decryption technology in the CLR compilers so the msil could be distributed encrypted...

Edit: in a way obfuscaters DO protect source code... ever tried to understand obfucated code?

Cheers

Share this post


Link to post
Share on other sites
I am still learning .net. From what I've read, obfuscaters protect the source code to a certain extent.

I don't find obfuscaters as a proper way to secure a .NET program.

Now, I've been reading about Visual Studio 2005. Right now I'm downloading it via my MSDN subscription.

I was trying to figure out if VS2k5 has better protection.. or am I wasting my time?

I really, seriously, want to know the point of .NET if it can be so easily decompiled.

Share this post


Link to post
Share on other sites
Take a look at this:
http://www.remotesoft.com/salamander/
A web-based version of Salamander's .NET Decompiler.

Look closely at this option:
"de-obfuscate(turn any obfuscated code into recompilable format)"

So NO, I would not say obfuscating the source is secure. I could be wrong, though. But I decompiled at least 5 different .NET applications with no problem.

Share this post


Link to post
Share on other sites
Well, as an exercise, try decompiling an obfuscated app and try to recompile it. That'll be the best way for you to understand that process.

Next, it obviously depends on what you are doing, but another great trick to prevent users from hacking external assemblies that your apps depend on is to sign them with a strong name key and use code access security to demand that all linked assemblies have the key. You cannot get the private key even with a disassembler, so as long as you keep you strong name key file private you can stop code injection, etc..

Hope that helps!

~Graham

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
Original post by tmack
I really, seriously, want to know the point of .NET if it can be so easily decompiled.



Are you serious, or was that just a knee-jerk response?

Share this post


Link to post
Share on other sites
Quote:
Original post by Anonymous Poster
Quote:
Original post by tmack
I really, seriously, want to know the point of .NET if it can be so easily decompiled.



Are you serious, or was that just a knee-jerk response?


I'm very serious. Think of it like this.

I'm developing a very large application with several other people, say 3 or 4 people that.. uhm.. helps you manage a database.

We choose C#.

We build this application, and start selling it- $199. People start buying. The 'warez' people get ahold of it. They decompile it (pass the protections we used with the tools mentioned above). They find all the security holes, disable the application protection and rerelease it under a new name.

We're losing out on thousands and thousands of dollars!!

Why has Microsoft done this? Why haven't they developed a PROPER way to compile the code, that can NOT be decompiled? Or at least give it protection of C/C++.



Share this post


Link to post
Share on other sites
Quote:
Original post by tmack
We build this application, and start selling it- $199. People start buying. The 'warez' people get ahold of it. They decompile it (pass the protections we used with the tools mentioned above). They find all the security holes, disable the application protection and rerelease it under a new name.

We're losing out on thousands and thousands of dollars!!

Why has Microsoft done this? Why haven't they developed a PROPER way to compile the code, that can NOT be decompiled? Or at least give it protection of C/C++.


When have "protections" ever stopped software from being pirated?

Code doesn't need to be decompiled. Crackers got by with disasseblers just fine.

Share this post


Link to post
Share on other sites
Quote:
Original post by smr
Quote:
Original post by tmack
We build this application, and start selling it- $199. People start buying. The 'warez' people get ahold of it. They decompile it (pass the protections we used with the tools mentioned above). They find all the security holes, disable the application protection and rerelease it under a new name.

We're losing out on thousands and thousands of dollars!!

Why has Microsoft done this? Why haven't they developed a PROPER way to compile the code, that can NOT be decompiled? Or at least give it protection of C/C++.


When have "protections" ever stopped software from being pirated?

Code doesn't need to be decompiled. Crackers got by with disasseblers just fine.


I'm not saying they haven't-- I'm saying they can rename the software and make it their own.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Well an obfuscator may not help with small and easy codes, but it can't imagine you get good results with a real program.

One small example from msdn, what does this function do?

private void a(a b) {
while (b.a()) {
a = b.a(true);
a.a();
a(a);
}
}



here is the original source code:

private void CalcPayroll(SpecialList employeeGroup) {
while (employeeGroup.HasMore()) {
employee = employeeGroup.GetNext(true);
employee.UpdateSalary();
DistributeCheck(employee);
}
}


And renaming is not the only thing an obfuscator does.

If you have two totally different methods with different parameters in a class it can make them to overloaded methods with the same name.

It can transform high-level statements (if-then-else) to other statements with the same logic. You write an "if" and the obfuscator turns it into a "while" with a goto.

It encrypts strings. An easy example where this is useful: a program where you have to enter some kind of key to activate the program will have some text pointing you there like "Serial number" or "Registration Key" you can easily search for. This would point you to the code even if it is obfuscated.

and that are only the things I know of ;)


Think about how much afford is put into a large projekt to make it understandable to a whole team. Naming conventions, well structured programming, a good code documentation, etc.
And now imagine you don't have anything of it. And thats not all, you have someone who wants to hinder you to understand the code.

I realy think a good obfuscator can make MSIL code as vulnerable as machine code.

Share this post


Link to post
Share on other sites
Thanks! Exactly what I was looking for.

My project is being developed by two people, it's the level editor for my game engine... to think about it, it WOULD be nearly impossible to decyper all of the DX code and what not.

Share this post


Link to post
Share on other sites
Quote:
Original post by tmack
Quote:
Original post by Anonymous Poster
Quote:
Original post by tmack
I really, seriously, want to know the point of .NET if it can be so easily decompiled.



Are you serious, or was that just a knee-jerk response?

We build this application, and start selling it- $199. People start buying. The 'warez' people get ahold of it. They decompile it (pass the protections we used with the tools mentioned above). They find all the security holes, disable the application protection and rerelease it under a new name.

We're losing out on thousands and thousands of dollars!!

Why has Microsoft done this? Why haven't they developed a PROPER way to compile the code, that can NOT be decompiled? Or at least give it protection of C/C++.

The purpose of compiling code is *not* to secure/hide/protect/obfuscate it.
The purpose of compiling code is to translate it into something the CPU (or in this case the MSIL layer) can understand and execute.

If they decompile your "protections" and bypass them, your app wasn't secure to begin with. It's the same for machine code; anyone with the right knowledge can decompile it and bypass your protection mechanisms. Obfuscation may make this harder, but it's by no means secure (security by obscurity).

You're better off spending your time on the app itself and not wasting it on your false sense of security.

Share this post


Link to post
Share on other sites
I'm also interested in protecting .NET applications. There was a recent post about this in another forum. Here are some commercial protection packages I've found:

http://www.chosenbytes.com/index.php
http://www.softwarekey.com/
http://www.crypkey.com/index.asp
http://www.oreans.com/
http://www.remotesoft.com/salamander/protector.html
http://thinstall.com/

Some of these companies claim that their security package has never been cracked. Software is cracked all the time, so I'm wondering whether most software security is lightweight and written by the original authors or whether these kinds of security packages are actually used. And if they are, are they really as good as claimed?

There is the option of using hardware dongles (key implemented in attachable device), but a software solution would be much better if it worked well enough. Well enough means that it would be more costly to crack the software than to purchase it.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
Original post by RaIf they decompile your "protections" and bypass them, your app wasn't secure to begin with. It's the same for machine code; anyone with the right knowledge can decompile it and bypass your protection mechanisms. Obfuscation may make this harder, but it's by no means secure (security by obscurity).

You're better off spending your time on the app itself and not wasting it on your false sense of security.


I think you misunderstand the situation.

If you decompile a "normal" program assambler is as far as you can get.
But with decompiled .net MSIL is only the start. There are programs that translate the code directly to a high-level language like c#. This is a lot more unsecure than even the most simple machine code can get.
It is right that the purpose of compiling is to translate it into a language the CPU understands. But it is like an image you only see as byte code. You can say "hey here is a sequence of blue pixels" but it is nearly impossible to tell what the whole image shows you. You need a programm that converts the bytes to colors. With machine code there don't exist these programs, but with MSIL.

With that in mind it just makes no sense what you write.
First it is NOT "the same for machine code"
And second, how can an app be "secure to begin with"?

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
What about GCC? It has nothing to do with Microsoft... Can it be decompiled too?

Share this post


Link to post
Share on other sites
Quote:
Original post by Anonymous Poster
I think you misunderstand the situation.

If you decompile a "normal" program assambler is as far as you can get.
But with decompiled .net MSIL is only the start. There are programs that translate the code directly to a high-level language like c#. This is a lot more unsecure than even the most simple machine code can get.
It is right that the purpose of compiling is to translate it into a language the CPU understands. But it is like an image you only see as byte code. You can say "hey here is a sequence of blue pixels" but it is nearly impossible to tell what the whole image shows you. You need a programm that converts the bytes to colors. With machine code there don't exist these programs, but with MSIL.

With that in mind it just makes no sense what you write.
First it is NOT "the same for machine code"
And second, how can an app be "secure to begin with"?


Is obfuscated C# code really that much easier to crack than assembly code? Some of the obfuscation, like turning if statements into while loops, can be reversed, but no tool can reclaim the original method and variable names so that the source code can be read and easily understood.

Besides, machine code programs get hacked all the time. On average, a video game released on the market is cracked within two weeks, despite the developers best efforts. Any program you write, no matter what technology you use, can be hacked given that there is a hacker determined enough to do so. And, in most cases, it doesn't take the hackers all that much effort, anyway. So, I don't see why this is such a big problem for .NET, especially given all the other benefits you get with .NET.

And on the subject of those security companies that offer products that have "never been hacked." Thats baloney. They can only say that for one of two reasons: their product isn't in wide-spread use so no one has tried to hack it, or someone has hacked it and they just don't know it. You NEVER announce publicly that something can't get hacked, because as soon as you do someone will decide to prove you wrong. Just ask the Oracle DB people.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Er, no offense to many of the arguments protected, but most of them are technical arguments that don't really hold water when dealing with them in practice.

Someone decompiles, recompiles, sells "their" application. That is technically possible. In reality?

A: No one is going to intentionally buy that product, realizing that it is merely a copy and cannot be supported to any kind of standard. This holds doubly true for a corporation: they aren't stupid and won't risk something of that magnitude just to save $10.00.
B: You are inevitably going to sue them and recoup *way* more than whatever you would have got if you had just licensed the technology out to them.

There are many, many .NET/Java applications out there that contain proprietary code and are closed source. How many of them do you see being sold as duplicate copies of another product?

There is really only *one* true reason where obfuscation for the Java or .NET platform becomes of vital importance, and that is dealing with algorithm rich technology wherein you use this technology to compete with other, similar applications.

For example, if your painting application has a unique, innovative method of performing red eye reduction, your application becomes a target for disassembly and evaluation. Nobody is going to C&P the code into their own application, but they are going to model the general functions of your algorithms when they implement their own, similar functionality.

*That* is what you need to worry about if you're delievering a performant product.

Share this post


Link to post
Share on other sites
Quote:
Original post by Anonymous Poster
There is really only *one* true reason where obfuscation for the Java or .NET platform becomes of vital importance, and that is dealing with algorithm rich technology wherein you use this technology to compete with other, similar applications.

For example, if your painting application has a unique, innovative method of performing red eye reduction, your application becomes a target for disassembly and evaluation. Nobody is going to C&P the code into their own application, but they are going to model the general functions of your algorithms when they implement their own, similar functionality.

*That* is what you need to worry about if you're delievering a performant product.


More specifically, you obfuscate it (or code it in a particular way) such that when you bring up a lawsuit against a company then the third party evaluator can examine the binary and code to determine if they have infringed upon your IP (Dr. Dobbs had a whole series on how some of the testing is performed).

Obfuscating code won't protect it, it won't protect your algorithms, and it won't prevent people from stealing your software. It will stop n00bs though, but then again, once a "crack" is released for software, those n00bs will just download it. It's a sad sad world. This is true of any language and any platform. Even hardware dongles aren't foolproof.

Share this post


Link to post
Share on other sites
Quote:
Original post by Washu
Quote:
Original post by Anonymous Poster
There is really only *one* true reason where obfuscation for the Java or .NET platform becomes of vital importance, and that is dealing with algorithm rich technology wherein you use this technology to compete with other, similar applications.

For example, if your painting application has a unique, innovative method of performing red eye reduction, your application becomes a target for disassembly and evaluation. Nobody is going to C&P the code into their own application, but they are going to model the general functions of your algorithms when they implement their own, similar functionality.

*That* is what you need to worry about if you're delievering a performant product.


More specifically, you obfuscate it (or code it in a particular way) such that when you bring up a lawsuit against a company then the third party evaluator can examine the binary and code to determine if they have infringed upon your IP (Dr. Dobbs had a whole series on how some of the testing is performed).

Obfuscating code won't protect it, it won't protect your algorithms, and it won't prevent people from stealing your software. It will stop n00bs though, but then again, once a "crack" is released for software, those n00bs will just download it. It's a sad sad world. This is true of any language and any platform. Even hardware dongles aren't foolproof.


This is very true. But what I'm looking for something that literly converts your code to native code. It is nearly impossible to decompile the code to a high level language.

I agree obfuscating a peice of software will protect it.. to a certain extent. I can't believe .NET has NO WAY of protecting your source code AT ALL.. a real way. Without all this 'obfuscate' crap.

Is there a way to convert MSIL to NATIVE CODE? Without using Salamander's protector which is way over priced.

Is there any *free* or *cheap* programs that can compile MSIL to NATIVE? I been searching google this whole weekend so far with no results.

I tried NGEN but this is not what I need.

Share this post


Link to post
Share on other sites
Quote:
Original post by tmack
Is there a way to convert MSIL to NATIVE CODE? Without using Salamander's protector which is way over priced.

Is there any *free* or *cheap* programs that can compile MSIL to NATIVE? I been searching google this whole weekend so far with no results.

I tried NGEN but this is not what I need.


How is native code safer? You realize that most programs today that have copy protection are unmanaged (aka native code) and yet they get cracked just as easily. Ngen will do what you want (turn the MSIL into native code), you just need to do it at install time.

Share this post


Link to post
Share on other sites
Quote:
Original post by Washu
Quote:
Original post by tmack
Is there a way to convert MSIL to NATIVE CODE? Without using Salamander's protector which is way over priced.

Is there any *free* or *cheap* programs that can compile MSIL to NATIVE? I been searching google this whole weekend so far with no results.

I tried NGEN but this is not what I need.


How is native code safer? You realize that most programs today that have copy protection are unmanaged (aka native code) and yet they get cracked just as easily. Ngen will do what you want (turn the MSIL into native code), you just need to do it at install time.


But you can't decompile native code BACK TO THE ORIGINAL SOURCE CODE... correct me if I am wrong.


NGEN does turn msil into native code, but I just did it to one of my programs and used .NET Reflector to decompile it and it still shows all the source code.

Share this post


Link to post
Share on other sites
Quote:
Original post by tmack
But you can't decompile native code BACK TO THE ORIGINAL SOURCE CODE... correct me if I am wrong.


NGEN does turn msil into native code, but I just did it to one of my programs and used .NET Reflector to decompile it and it still shows all the source code.

That's because NGEN stores it in the GAC, it doens't overwrite your original executable. As for decompiling to the original source code, no, you can't do that with native code. Then again, most cracks/hacks are made without DECOMPILING THE CODE AT ALL.

Share this post


Link to post
Share on other sites
Quote:
Original post by tmack
But you can't decompile native code BACK TO THE ORIGINAL SOURCE CODE... correct me if I am wrong.

So? You can't decompile MSIL code, as you put it, "BACK TO THE ORIGINAL SOURCE CODE", not even for debug builds.

A good release build has been optimized, the code has been reordered, loops unrolled, common code merged, poor algorithm choices in loops reordered, constants folded in, dead code elimiated, to name a few. Each of these (except perhaps dead code elimiation) makes it harder to reverse engineer.

Compare your source against your compiled release and debug builds, opened using ildasm. (ildasm is in the SDK\v1.1\Bin directory of your install)

Next, assume you use a program like dotfuscator on the release build. Now all your strings are encrypted, your MSIL objects are all overloaded versions of 'a', once those are taken they become overloaded versions of 'b', then 'c', and so on. It's not exactly friendly to reverse engineer.

Compare those dotfuscated (or whatever tool you prefer) results against the release build.

The results are as difficult to reverse engineer as the machine level versions using available tools.

Share this post


Link to post
Share on other sites

This topic is 4482 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Guest
This topic is now closed to further replies.
Sign in to follow this  

  • Advertisement