Decompiling .NET Assembly
-
I had been work with.NET since 1.0 beta, and the issue of .NET code being easily decompilable still bug me today. I understand that no program is crack-safe and there are tools to make it harder to understand the decompiled .NET code. I am not asking for ways to 'protect' my code, instead, I just want to express a general mis-understanding on this matter. People often said that new games are cracked the same day they are relased, those game are written in native code, so .NET developer should just drop the subject of code protected since native code are still being cracked, not to metion managed code. I think this is incorrect. Cracking a program is very different than decompiling your program and obtain debuggable source code. Cracking involve skipping instructions, this process is relatively easy and most importantly, it doesn't expose your source code. With .NET code, anyone can decompile your code into re-compilable and debuggable code. The difference is needless to say. Now, I do agree that the value of a software isn't really in the implementation. I don't give a shit on people cracking my program, but it just doesn't feel right to release something where others can obtain your code easily.
Well, at some point, your program is in memory and it is therefore possible to get a memory image of the assembly code. As to:
EscapeKey wrote:
it just doesn't feel right to release something where others can obtain your code easily.
I take it you're not an open source fan? ;P But seriously, I agree to the extent that I want to find the intersection between minimum effort to protect the code and maximum code protection. Basically, I don't want to go out of my way, but I also want to ensure that someone will have to at least minimally go out of their way. So, along those lines, and as it solves another problem as well, I've been looking at NetZ, because it zips the assemblies into one exe (which solves the problem of having a whole slew of assemblies hanging out with the exe) and, for example, the NetZ loader can be obfuscated and the zipped files could be encrypted or password protected. To me, that seems like a minimal effort on my part, like zipping up your pants. It's not all hanging out there in the breeze for everyone to look at. :~ Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh Smith -
Err. Native programs can be decompiled, too - straight into assembler. Cracking isn't just a matter of skipping instructions - you have to have the "source" and understand it. Anyone can then recompile this source into a program. I see no difference.
krism42 wrote:
Err. Native programs can be decompiled, too - straight into assembler
This is true, however it does take a high degree of technical competence to be able to do anything with the results. However for C# there are online decompilers that will give you workable source code in seconds http://www.remotesoft.com/salamander/[^]
-
krism42 wrote:
Err. Native programs can be decompiled, too - straight into assembler
This is true, however it does take a high degree of technical competence to be able to do anything with the results. However for C# there are online decompilers that will give you workable source code in seconds http://www.remotesoft.com/salamander/[^]
MrEyes wrote:
However for C# there are online decompilers that will give you workable source code in seconds http://www.remotesoft.com/salamander/\[^\]
Nice, but a bit tool pricey at $1099 a pop. :omg:
We made the buttons on the screen look so good you'll want to lick them. Steve Jobs
-
I had been work with.NET since 1.0 beta, and the issue of .NET code being easily decompilable still bug me today. I understand that no program is crack-safe and there are tools to make it harder to understand the decompiled .NET code. I am not asking for ways to 'protect' my code, instead, I just want to express a general mis-understanding on this matter. People often said that new games are cracked the same day they are relased, those game are written in native code, so .NET developer should just drop the subject of code protected since native code are still being cracked, not to metion managed code. I think this is incorrect. Cracking a program is very different than decompiling your program and obtain debuggable source code. Cracking involve skipping instructions, this process is relatively easy and most importantly, it doesn't expose your source code. With .NET code, anyone can decompile your code into re-compilable and debuggable code. The difference is needless to say. Now, I do agree that the value of a software isn't really in the implementation. I don't give a shit on people cracking my program, but it just doesn't feel right to release something where others can obtain your code easily.
EscapeKey wrote:
I had been work with.NET since 1.0 beta, and the issue of .NET code being easily decompilable still bug me today.
Me too. Why, just the other day, i saved myself hours by decompiling a 3rd-party library to resolve an omission in the documentation. It was easy... easier than searching through the docs to begin with! And that just made me uneasy - this job isn't supposed to be fun and stress-free, it's supposed to be a constant stream of frustration!! :rolleyes:
---- Scripts i’ve known... CPhog 1.8.2 - make CP better. Forum Bookmark 0.2.5 - bookmark forum posts on Pensieve Print forum 0.1.2 - printer-friendly forums Expand all 1.0 - Expand all messages In-place Delete 1.0 - AJAX-style post delete Syntax 0.1 - Syntax highlighting for code blocks in the forums
-
krism42 wrote:
Err. Native programs can be decompiled, too - straight into assembler
This is true, however it does take a high degree of technical competence to be able to do anything with the results. However for C# there are online decompilers that will give you workable source code in seconds http://www.remotesoft.com/salamander/[^]
MrEyes wrote:
This is true, however it does take a high degree of technical competence to be able to do anything with the results.
Make the test and decompile an assembly which has been obfuscated properly and then try to understand the code (I would assume understanding the code is needed to change it). Although it might not be as hard as understanding assembler its still veeeerrrrryyyyy time consuming. I've gone through this involuntary when I once tried to track down an exception I got from some 3rd party component (small hint: it has to do with diagrams and is being advertised here on CP). Robert
-
krism42 wrote:
Err. Native programs can be decompiled, too - straight into assembler
This is true, however it does take a high degree of technical competence to be able to do anything with the results. However for C# there are online decompilers that will give you workable source code in seconds http://www.remotesoft.com/salamander/[^]
MrEyes wrote:
This is true, however it does take a high degree of technical competence to be able to do anything with the results.
Heh... Not as much as you might think. :-O
---- Scripts i’ve known... CPhog 1.8.2 - make CP better. Forum Bookmark 0.2.5 - bookmark forum posts on Pensieve Print forum 0.1.2 - printer-friendly forums Expand all 1.0 - Expand all messages In-place Delete 1.0 - AJAX-style post delete Syntax 0.1 - Syntax highlighting for code blocks in the forums
-
Well, at some point, your program is in memory and it is therefore possible to get a memory image of the assembly code. As to:
EscapeKey wrote:
it just doesn't feel right to release something where others can obtain your code easily.
I take it you're not an open source fan? ;P But seriously, I agree to the extent that I want to find the intersection between minimum effort to protect the code and maximum code protection. Basically, I don't want to go out of my way, but I also want to ensure that someone will have to at least minimally go out of their way. So, along those lines, and as it solves another problem as well, I've been looking at NetZ, because it zips the assemblies into one exe (which solves the problem of having a whole slew of assemblies hanging out with the exe) and, for example, the NetZ loader can be obfuscated and the zipped files could be encrypted or password protected. To me, that seems like a minimal effort on my part, like zipping up your pants. It's not all hanging out there in the breeze for everyone to look at. :~ Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh SmithI saw your name on the NetZ site Marc because I have been looking at it too. I think that its not a bad way to do it and its alot more affordable than the other ones. I think I am going to make a simple .targets file so that it can be included by msbuild (.NET 2.0) and then it will automatically be in the compressed format. My company is looking at moving to .NET and we are going to be looking at all of the various things around this, obfuscating/protecting and licensing. So either I will get to play with all of the various code protectors soon or they will just say to leave it alone and not to worry about it. But protecting their IP is something that they will want to do, I am sure.
Steve Maier, MCSD MCAD MCTS
-
Well, at some point, your program is in memory and it is therefore possible to get a memory image of the assembly code. As to:
EscapeKey wrote:
it just doesn't feel right to release something where others can obtain your code easily.
I take it you're not an open source fan? ;P But seriously, I agree to the extent that I want to find the intersection between minimum effort to protect the code and maximum code protection. Basically, I don't want to go out of my way, but I also want to ensure that someone will have to at least minimally go out of their way. So, along those lines, and as it solves another problem as well, I've been looking at NetZ, because it zips the assemblies into one exe (which solves the problem of having a whole slew of assemblies hanging out with the exe) and, for example, the NetZ loader can be obfuscated and the zipped files could be encrypted or password protected. To me, that seems like a minimal effort on my part, like zipping up your pants. It's not all hanging out there in the breeze for everyone to look at. :~ Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh SmithMarc Clifton wrote:
To me, that seems like a minimal effort on my part, like zipping up your pants. It's not all hanging out there in the breeze for everyone to look at. :~
Now that's a mental image I didn't need :~
Ryan
"Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
-
Marc Clifton wrote:
To me, that seems like a minimal effort on my part, like zipping up your pants. It's not all hanging out there in the breeze for everyone to look at. :~
Now that's a mental image I didn't need :~
Ryan
"Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
Ryan Binns wrote:
Now that's a mental image I didn't need
I try to provide entertainment in these posts. :) Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh Smith -
EscapeKey wrote:
I had been work with.NET since 1.0 beta, and the issue of .NET code being easily decompilable still bug me today.
Me too. Why, just the other day, i saved myself hours by decompiling a 3rd-party library to resolve an omission in the documentation. It was easy... easier than searching through the docs to begin with! And that just made me uneasy - this job isn't supposed to be fun and stress-free, it's supposed to be a constant stream of frustration!! :rolleyes:
---- Scripts i’ve known... CPhog 1.8.2 - make CP better. Forum Bookmark 0.2.5 - bookmark forum posts on Pensieve Print forum 0.1.2 - printer-friendly forums Expand all 1.0 - Expand all messages In-place Delete 1.0 - AJAX-style post delete Syntax 0.1 - Syntax highlighting for code blocks in the forums
Shog9 wrote:
this job isn't supposed to be fun and stress-free, it's supposed to be a constant stream of frustration!!
FrustrationStream fs = new FrustrationStream();
while( fs.Read() )
{
--shog.LifeSpan;
++shog.GrayHairs;
}
// TODO: Figure out why this line never executes...
fs.Close();:josh: My WPF Blog[^]
-
I had been work with.NET since 1.0 beta, and the issue of .NET code being easily decompilable still bug me today. I understand that no program is crack-safe and there are tools to make it harder to understand the decompiled .NET code. I am not asking for ways to 'protect' my code, instead, I just want to express a general mis-understanding on this matter. People often said that new games are cracked the same day they are relased, those game are written in native code, so .NET developer should just drop the subject of code protected since native code are still being cracked, not to metion managed code. I think this is incorrect. Cracking a program is very different than decompiling your program and obtain debuggable source code. Cracking involve skipping instructions, this process is relatively easy and most importantly, it doesn't expose your source code. With .NET code, anyone can decompile your code into re-compilable and debuggable code. The difference is needless to say. Now, I do agree that the value of a software isn't really in the implementation. I don't give a shit on people cracking my program, but it just doesn't feel right to release something where others can obtain your code easily.
There's probably something clever you could do in terms of encrypting your MSIL with something like PGP so the dll code only gets decrypted when it is loaded by the application that is meant to use it??
'--8<------------------------ Ex Datis: Duncan Jones Merrion Computing Ltd
-
Marc Clifton wrote:
To me, that seems like a minimal effort on my part, like zipping up your pants. It's not all hanging out there in the breeze for everyone to look at. :~
Now that's a mental image I didn't need :~
Ryan
"Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
Exactly the same thoughts here. :~
Cheers, Vikram.
"whoever I am, I'm not other people" - Corinna John.
-
I saw your name on the NetZ site Marc because I have been looking at it too. I think that its not a bad way to do it and its alot more affordable than the other ones. I think I am going to make a simple .targets file so that it can be included by msbuild (.NET 2.0) and then it will automatically be in the compressed format. My company is looking at moving to .NET and we are going to be looking at all of the various things around this, obfuscating/protecting and licensing. So either I will get to play with all of the various code protectors soon or they will just say to leave it alone and not to worry about it. But protecting their IP is something that they will want to do, I am sure.
Steve Maier, MCSD MCAD MCTS
If you are looking into ways to distribute/trade (p2p in nature) software licenses over internet (and code protection as well), maybe you can find interesting info by having a look at this[^]. I am the owner of the site so this may sound a little promoting, but the info is better not let unknown, the judgement is yours anyway ... It requires the user to install a security server on their machine to decode the assembly before loading them into the memory. After a user download the assemblies the producer can let them try them for a fixed period of time and afterwards the user need to order a set of access tokens from the producer, which can be further traded/shared by the user as he/she wish. The .Net softwares and the mp3 music samples at the above mentioned site are processed in such a way, you can try it out if you find it interesting regards
-
If you are looking into ways to distribute/trade (p2p in nature) software licenses over internet (and code protection as well), maybe you can find interesting info by having a look at this[^]. I am the owner of the site so this may sound a little promoting, but the info is better not let unknown, the judgement is yours anyway ... It requires the user to install a security server on their machine to decode the assembly before loading them into the memory. After a user download the assemblies the producer can let them try them for a fixed period of time and afterwards the user need to order a set of access tokens from the producer, which can be further traded/shared by the user as he/she wish. The .Net softwares and the mp3 music samples at the above mentioned site are processed in such a way, you can try it out if you find it interesting regards
By the looking over your article and site, you are not using the .NET licensing hooks that are in place, it seems that you are just writing your own thing. To have some app that needs to be installed and it pulls down the code over a socket everytime is not a solution for alot off places. People on laptops or companies that limit traffic in and out are not going to just allow your traffic to go thru.
Steve Maier, MCSD MCAD MCTS
-
By the looking over your article and site, you are not using the .NET licensing hooks that are in place, it seems that you are just writing your own thing. To have some app that needs to be installed and it pulls down the code over a socket everytime is not a solution for alot off places. People on laptops or companies that limit traffic in and out are not going to just allow your traffic to go thru.
Steve Maier, MCSD MCAD MCTS
In fact the secured assembies and media data can be anywhere on the internet, including the local machine. Usually they need to be downloaded only once, if they are not contained in the installation package initially or if an update is needed. Or one can simply copy the code images to a local position. The technology we developed provides a unified data access control mechanism, not just .Net assemblies [edit]Oh, by the way the 'socket' used in the article refers to a component adaptor, not the network Socket![edit] Regards -- modified at 13:45 Tuesday 29th August, 2006
-
I had been work with.NET since 1.0 beta, and the issue of .NET code being easily decompilable still bug me today. I understand that no program is crack-safe and there are tools to make it harder to understand the decompiled .NET code. I am not asking for ways to 'protect' my code, instead, I just want to express a general mis-understanding on this matter. People often said that new games are cracked the same day they are relased, those game are written in native code, so .NET developer should just drop the subject of code protected since native code are still being cracked, not to metion managed code. I think this is incorrect. Cracking a program is very different than decompiling your program and obtain debuggable source code. Cracking involve skipping instructions, this process is relatively easy and most importantly, it doesn't expose your source code. With .NET code, anyone can decompile your code into re-compilable and debuggable code. The difference is needless to say. Now, I do agree that the value of a software isn't really in the implementation. I don't give a shit on people cracking my program, but it just doesn't feel right to release something where others can obtain your code easily.
This is the proverbial elephant in the corner. Most .NET code is used inside enterprises, be it tools or ASP.NET. When pushing it out to customers, though, I've yet to find a satisfactory answer. Despite all the vaunted claimes of obfuscators, they suck. Big time. I took some "well obfuscated" code and had working classes in less than ten seconds. Granted, debugging them could be tricky, but it's no more difficult than debugging the STL that ships with Visual Studio. Heck, it's easier than debugging the last nightmare application I worked on--for one the decompiled .NET app had variables that were neutral, not completely misleading. Besides, who cares? I need a class to do X. I decompile another app, yank out the class that does that and wala, I'm good to go. [EDIT: Two problems I ran into are patching and testing. Create an app, obfuscate it, release it, make changes.... Ah crap.]
Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
-
Well, at some point, your program is in memory and it is therefore possible to get a memory image of the assembly code. As to:
EscapeKey wrote:
it just doesn't feel right to release something where others can obtain your code easily.
I take it you're not an open source fan? ;P But seriously, I agree to the extent that I want to find the intersection between minimum effort to protect the code and maximum code protection. Basically, I don't want to go out of my way, but I also want to ensure that someone will have to at least minimally go out of their way. So, along those lines, and as it solves another problem as well, I've been looking at NetZ, because it zips the assemblies into one exe (which solves the problem of having a whole slew of assemblies hanging out with the exe) and, for example, the NetZ loader can be obfuscated and the zipped files could be encrypted or password protected. To me, that seems like a minimal effort on my part, like zipping up your pants. It's not all hanging out there in the breeze for everyone to look at. :~ Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh SmithSince you bring up NetZ, I saw a post a while back about a similar product for native apps that encapsulated the target app in it's own "soft" environment that optionally combined the external registry/disk with an internal registry/disk thereby isolating the target app from the external environment. Do you know of what I speak?
Silence is the voice of complicity. Strange women lying in ponds distributing swords is no basis for a system of government. -- monty python Might I suggest that the universe was always the size of the cosmos. It is just that at one point the cosmos was the size of a marble. -- Colin Angus Mackay
-
This is the proverbial elephant in the corner. Most .NET code is used inside enterprises, be it tools or ASP.NET. When pushing it out to customers, though, I've yet to find a satisfactory answer. Despite all the vaunted claimes of obfuscators, they suck. Big time. I took some "well obfuscated" code and had working classes in less than ten seconds. Granted, debugging them could be tricky, but it's no more difficult than debugging the STL that ships with Visual Studio. Heck, it's easier than debugging the last nightmare application I worked on--for one the decompiled .NET app had variables that were neutral, not completely misleading. Besides, who cares? I need a class to do X. I decompile another app, yank out the class that does that and wala, I'm good to go. [EDIT: Two problems I ran into are patching and testing. Create an app, obfuscate it, release it, make changes.... Ah crap.]
Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
Joe Woodbury wrote:
I took some "well obfuscated" code and had working classes in less than ten seconds.
This is why my current switching-to-.NET plan is to use C++/CLI. I intend to do user interfaces in managed code to get the benefit of the modern RAD designer in VS2005, but to keep as much of the applications' code native as possible. I hope that'll make the apps reasonably hard to disassemble, yet I would get the use of a much more modern IDE (than my C++Builder 5) with good visual form-designing capabilities. So, I'm wondering if anyone reading this has tried out such a scenario? I'm in the middle of this switch-over, so I still have time to find alternatives if my 'brilliant' plan has some fundamental flaw -- what a shock that would be. :-D
-
Joe Woodbury wrote:
I took some "well obfuscated" code and had working classes in less than ten seconds.
This is why my current switching-to-.NET plan is to use C++/CLI. I intend to do user interfaces in managed code to get the benefit of the modern RAD designer in VS2005, but to keep as much of the applications' code native as possible. I hope that'll make the apps reasonably hard to disassemble, yet I would get the use of a much more modern IDE (than my C++Builder 5) with good visual form-designing capabilities. So, I'm wondering if anyone reading this has tried out such a scenario? I'm in the middle of this switch-over, so I still have time to find alternatives if my 'brilliant' plan has some fundamental flaw -- what a shock that would be. :-D
-
I use reflector to browse my c++/clr build and it seems that all native calls are translated into managed code as well.
So far I'm building my native code as static libraries, which link just fine into a managed project. I'm not sure how much overhead is added by the "IJW" translation for calls from my managed code into my unmanaged-code static library. I seem to remember that Kate Gregory had an article about that, and I must go dig it up soon and read it again.