Can executable packers protect .NET based application from decompiling?

[Lauriux1]

I'm not .NET programmer, but I'm plan to learn new programming language and I'm still not sure if I want to choose any .NET based programming language. I have heard that .NET based programming languages can be easily decompiled and today almost any obfuscators can't help to protect or even 'respectfully' increase security level.

My question is, can executable packers (such like a Themida or any other similar) protect or at least increase level of security for .NET based applications?

Or maybe such packers doesn't support .NET based applications?

Or maybe executable packers can't protect because decompilers for .NET just over take 'precompiled' code while code is traveling to the JIT ?

Maybe Microsoft planning to do something about that in the future? Any rumors?

[Niya]

Hmm....can you quickly describe what an executable packer does ?

The thing that makes .Net applications easy to decompile is the fact that .Net EXEs contain lots and lots of meta-data, especially about types. And .Net applications compile to MSIL which is much simpler to understand and decode than ASM.

[Lauriux1]

Hmm....can you quickly describe what an executable packer does ?

http://en.wikipedia.org/wiki/Executable_compression
Of course there is more advanced packers like Themida: http://www.oreans.com/themida.php and similar...

For example, maybe someone knows if VB.NET application can be decompiled with .NET Reflector or with any other .NET related decompiler while application is compressed with 'simple' UPX ?

Also maybe someone knows how works such decompilers like .NET Reflector, they read data from not running application or they 'over take' code while code is traveling to the JIT?

[Niya]

Hmmm....To be honest, I never knew about this type of protection. My research in the past has always focused on obfuscation. Based on the description of how that packer in your second link works, I'd say it looks pretty solid. I wouldn't expect Reflector to be able to decompile that.

However, I can think of one glaring weakness....If the would-be cracker gets even the slightest whiff that your executable is a self-extractor its over. All he'd need to do is obtain the unpacked EXE that is no doubt created when running the app and he can simply run Reflector against that.

I'd have to research this a little more. Its an interesting approach to protection though.

[Shaggy Hiker]

Keep in mind that EVERY program can be decompiled. At some point, they all have to be machine code for the CPU to process them, and machine code can be mapped one to one back to ASM. ASM can probably be turned into something like C, too, since C is not that far removed from ASM, but there are plenty of ASM coders out there (well, not so many, but it only takes one).

The thing that keeps most software safe is the fact that it has no value. If you think about it, you will see that this is true for most software, and the software it is not true for has been cracked. For instance, there are bootleg copies of pretty much everything MS has put out. Is that done by decompiling? Probably not, it's probably just straight up theft. The code itself is not that interesting to most people.

The things that you would normally worry about from somebody decompiling your program would be things that fall into two categories:

1) Things that shouldn't be there, such as passwords, connection strings, key phrases, and the like.

2) Algorithms that are proprietary.


The former is largely a mistake in any language, and the latter is really rare. Which case are you?

[Lauriux1]

However, I can think of one glaring weakness....If the would-be cracker gets even the slightest whiff that your executable is a self-extractor its over. All he'd need to do is obtain the unpacked EXE that is no doubt created when running the app and he can simply run Reflector against that.

I understand, but most compressed executables decompress the original code in memory, not on HDD.
Also I agree that if there is way to pack, then someone can find way to unpack, but such packers like Themida are hard to unpack also you can make some tricks, for example you can 'damage' packer wit an Hex tool and it will be unpackable even if there is an official unpacker.

[Niya]

For instance, there are bootleg copies of pretty much everything MS has put out. Is that done by decompiling?

This is done by relentless individuals who go through line by line of disassembly code in a debugger looking for a simply value to change. It can be a memory address for a procedure that validates keys or some other form of protection. Simply changing this address to jump to somewhere else is all it takes to crack protection. There's nothing a packer can do about that type of cracker.

[Niya]

I understand, but most compressed executables decompress the original code in memory, not on HDD.

Wont make a difference to a determined individual. Its still much easier than trying to decode the compression.

[Lauriux1]

Keep in mind that EVERY program can be decompiled. At some point, they all have to be machine code for the CPU to process them, and machine code can be mapped one to one back to ASM. ASM can probably be turned into something like C, too, since C is not that far removed from ASM, but there are plenty of ASM coders out there (well, not so many, but it only takes one).

I have read much threads here about obfuscators and you always say the same thing...
My answer is, yes, every program can be decompiled but question is not "it can be decompiled or not?", the question is how hard it will be to decompile and how long it will took! For example have you ever saw Photoshop, Skype or Windows 7 almost 100% 'translated' back to Source Code??? I guess no because it would took eternity...

Do you think it is right when you spend hours of coding and in final comes an 'copy & paste' prgrammer and with such tool like a .NET Reflector in few seconds extracts your Source Code....

[Lauriux1]

Wont make a difference to a determined individual. Its still much easier than trying to decode the compression.

Yes, you can 'rip' it from memory to, but some packers use 'smarter' protection to increase level of security. It is not about possible or not possible it is, it is all about how hard it will be to decompile and how long it will took. Because obfuscators in our days are relatively easy to break.

[Shaggy Hiker]

I haven't seen the source code for any of those because nobody would make any money by showing me the source code (and I'm not nearly bored enough to look even if it was out there).

What's the point of decompiling? There is one guy on here who stated a very valid reason for wanting to keep his code in a compiled .exe, but his was a rare case. In his case, he was making some highly proprietary programs that people could, and would, steal. Most of us don't do that. Pretty nearly anything worthwhile that I have written has been posted or given away if I found anybody who might benefit from it (I don't randomly spam forums with Hello World programs, of course, but if the code looks useful as a standalone, and is uncommon, then I have posted it). I can't really imagine a scenario where I would create something that would be sufficiently public that a person might encounter it and want to decompile it without also knowing that they could just ask me for the source code.

I suppose that if I was writing software to sell commercially, I wouldn't want somebody to take the program change a few lines, then re-sell it, but I'm not selling anything, so that isn't a problem. Furthermore, in many countries, such outright theft is actionable. The only real question is whether or not it will cost more to go after the thief than you can possibly get from them. If the thief has made so much money that you could recover the cost of a suit, then you might as well sue. If the thief has made so little money that you couldn't possibly recover the cost of the suit, then what they took must not have really been worth much.

[Lauriux1]

I'm not sure how exactly such decompilers like a .NET Reflector works, but, I'm sure that IF they are able to 'over take' code while code is traveling to the JIT, then non packer or obfuscators can help us! Sad things. And what Microsoft was thinking...

[Shaggy Hiker]

Yes, you can 'rip' it from memory to, but some packers use 'smarter' protection to increase level of security. It is not about possible or not possible it is, it is all about how hard it will be to decompile and how long it will took. Because obfuscators in our days are relatively easy to break.

In all cases, it is just a matter of a stronger lock on the door. If the lock is flimsy, it better not be protecting much of anything. If you put a stronger lock on it, the lock can still be broken, it will just take more effort.

When it comes to code, I really can't imagine anything that would require such a lock, with the exception of some specialized, proprietary, narrowly-focused, software, such as something that performed stock trades, actuarial evaluations, and things like that. Frankly, I'm glad I never work on anything like that. The more clever the thing I work on, the more I would like to give it away.

[Shaggy Hiker]

I'm not sure how exactly such decompilers like a .NET Reflector works, but, I'm sure that IF they are able to 'over take' code while code is traveling to the JIT, then non packer or obfuscators can help us! Sad things. And what Microsoft was thinking...

I wasn't going to relate this story, as it is old, but it comes to mind whenever anybody talks about how insecure .NET is:

If you are old enough, you may remember when Wolfenstein 3D came out. That was a revolutionary game, if ever I saw one. The first version was shareware, technically, but was really freeware. The point was that people would be so enamored of the free version that they would buy the pay versions. That worked really well, because the game was awesome for the time (there were LOTS of books written explaining how it was done, too, so they weren't keeping it a secret).

If you ever played the non-free version, you may have found a hidden level with a maze in it. In the very heart of the maze was a 3D word. The point behind the word was that there was going to be a contest where the first N people who called in with the word would win some prize. The contest never got off the ground, because people hacked the .exe and extracted the word rather than playing the game to get it. That .exe was a machine language file compiled from C or C++. MS had NOTHING to do with that program being hacked. Furthermore, the coders behind that all became fabulously wealthy, despite giving away all of their tricks. What they tried to hide, they failed to hide. What they gave away made them rich.

[Lauriux1]

@Shaggy Hiker

Business programmers also don't like when someone steals code and re-sell it. Also even if you are almos 100% sure that someone has stolen your code, you still have to prove that and it is time and time is money... Or what about if someone has stolen not full your code, but just the part of it and adapted for their purposes, then it may be hard to prove in such case that it is stolen.
Some people code just because it is hobby and sometimes they also don't like when someone steals their ideas. Remember that not only code can be stolen, but idea also.
If there is such things like .NET Reflector and bunch of obfuscators and other bunch of de-obfuscators, then it clear that there is people which are in need to steal and other which are in need to protect code. You can't just ignore that because it is the fact.

[Niya]

I suppose code isn't nearly as valuable as the guy who wrote it as he is the only one who fully understands it and can manipulate it at will.

[Lauriux1]

@Shaggy Hiker

Yes, I have played Wolfenstein.

Also there is people who are using code for good purposes an other for bad. For example if someone has written Remote Administration Tool, then someone can decompile it and make it to the 'stealth' Trojan Horse.

[ForumAccount]

Nothing is secure in this day and age, but for the sake of the thread did you look at .netshrink?

Pick any language you want, it won't be secure. If it were, don't you think software giants such as Microsoft would have found it to stop people from stealing every single piece of software they've ever created?

[Shaggy Hiker]

@Shaggy Hiker

Business programmers also don't like when someone steals code and re-sell it. Also even if you are almos 100% sure that someone has stolen your code, you still have to prove that and it is time and time is money... Or what about if someone has stolen not full your code, but just the part of it and adapted for their purposes, then it may be hard to prove in such case that it is stolen.
Some people code just because it is hobby and sometimes they also don't like when someone steals their ideas. Remember that not only code can be stolen, but idea also.
If there is such things like .NET Reflector and bunch of obfuscators and other bunch of de-obfuscators, then it clear that there is people which are in need to steal and other which are in need to protect code. You can't just ignore that because it is the fact.

I agree with all your points, but not your conclusion. Still, it's just a matter of perspective. We agree that there is no absolutely safe solution, so it is just a matter of how difficult you want to make it. You want to make it more difficult, I have no interest in making it more difficult, and that's pretty much the difference between our positions.

One thing I would say is that if a person steals some code and changes it enough that it is not recognizably the same, is that still theft? That's a question that goes well beyond software to include ALL creative acts. I seem to remember that when John Cage wrote 4'33" of Silence, in which the musicians sat silently for the whole duration, and some other composer tried to write a song that was also silence, but was a different duration, there was a lawsuit over the plagiarism of the original piece. There have been more comprehensible suits over sampling of melodies in derived works, and there was even the lengthy battle between Lotus and Borland over whether Quattro Pro was a theft of Lotus 1-2-3 (eventually, it was determined that Microsoft was the winner, since the other two were both marginal players by the time the suit was resolved in favor of Lotus). How much change does there have to be before a work can be considered 'new', especially considering that we are all painting with the same pallet? Frankly, I don't want to deal with it.

When I see a program, if I like the program, I am thinking about how I would write such a thing. If I wanted to, I could mimic the interface perfectly (as long as it doesn't require any art skills, cause I don't have those), yet the code behind the interface would be entirely mine, because I didn't see their code. In that case, the program would look the same, but the code would not be related. In such a case, it would be hard to say that the idea was not stolen, yet the code most certainly was not stolen. I'm not sure what the courts would make of such a thing. The code would still be original, creative, content, but the interface....would be clearly duplicated. Very odd.

In any case, you are just putting a lock on the door. You can choose how strong a lock to use, and your decision is probably going to be the right one. I just wouldn't place the blame on Microsoft because they chose one size of lock over another for one particular language. All of the locks can be compromised, and you have already noted that you can add a stronger lock after the fact, but even that could still be compromised. It's just a decision that MS made for .NET. Since VS also includes an unmanaged C/C++ compiler, they didn't even opt for a one-size-for-all lock within Visual Studio.

[Chris001]

Packers are not going to help you, just like obfuscators.

A few years ago a freeware Usenet client was released, named Unzbin. According to the author the source code was going to be released soon, but after four months they stopped development and the source code was never released.

When I opened the executable in Reflector I found out that it was packed with MPRES, which does not have the option to unpack the executable. It took me only 3 seconds to find an unpacker with Google. After that I could open the unpacked executable in Reflector and see all the code.

Packers will only increase the level of security as long as nobody creates an unpacker.

[Shaggy Hiker]

Packers will only increase the level of security as long as nobody creates an unpacker.

Don't tell Green Bay!

[Lauriux1]

Packers are not going to help you, just like obfuscators.

Packers will only increase the level of security as long as nobody creates an unpacker.

So, actually they help!

You can 'damage' packer and it will be unpackable even if there is an unpacker. Also you can try to hide packers ID then atacker will be unable to know what packer was used.

Packing part is OK, but if there is .NET decompilers which can make something like a 'detour' for code while code is traveling to the JIT then sad things...

P.S.
In same way people are hiding malware.

[Shaggy Hiker]

Packing part is OK, but if there is .NET decompilers which can make something like a 'detour' for code while code is traveling to the JIT then sad things...

Even if they can't they can always make a detour for the code AFTER the JIT, at which time the code is the same as any other program from any language that compiles down to machine code. Therefore, moaning about being able to decompile MSIL is kind of pointless, because most hacking occurs from decompiling ASM, which MSIL will have to become anyways.

By the way, while it is true that you can destroy a compressed file by altering a few bytes randomly, what's the point? At that point, the program is unusable by EVERYBODY,so you might as well just create a garbage file instead.

[Evil_Giraffe]

My answer is, yes, every program can be decompiled but question is not "it can be decompiled or not?", the question is how hard it will be to decompile and how long it will took! For example have you ever saw Photoshop, Skype or Windows 7 almost 100% 'translated' back to Source Code??? I guess no because it would took eternity...

I guess no because the source code isn't nearly as valuable as a cracked exe.

[Lauriux1]

...destroy a compressed file by altering a few bytes randomly...

Of course not randomly! I already have done that before and everything was working fine. I was just interested if packing can protect (increase security level) against such tools like a .NET Reflector because it is just unfair that anyone can get your source code just by clicking few mouse keys...

[Shaggy Hiker]

Which brings up another point. Once cracked, the security is utterly useless these days. In other words, once the lock has been broken once, it is the same as having no lock at all. It wasn't always this way. Since you are old enough to know Wolfenstein, you are probably aware of the early security on wireless (WEP). For a few years, that was fair security. Then somebody cracked it, and now you can get a WEP cracker on the web with ease, so WEP is no longer fair security. You don't need to see the source code, and you don't need to know anything about WEP, yet you can still crack it simply because somebody else did and shared it. Similarly, if you have anything in your code that you really want to protect, then once it has been stolen one time, it is pretty much open to everybody these days.

That isn't strictly true, of course. In the case of the vast majority of software: Once it has been stolen the first time, everybody knows it was never worth stealing in the first place.

[Shaggy Hiker]

Of course not randomly! I already have done that before and everything was working fine. I was just interested if packing can protect (increase security level) against such tools like a .NET Reflector because it is just unfair that anyone can get your source code just by clicking few mouse keys...

My source code isn't valuable, only my mind is.

[ForumAccount]

My source code isn't valuable, only my mind is.

Currently working on a hack for Shaggy's mind, will post source code when done. Preliminary results show that Shaggy's thought distribution is:

• 80% Llamas
• 15% How to feed Llamas
• 5% What was I doing?

[Shaggy Hiker]

Darn, he's getting close.

[Lauriux1]

My source code isn't valuable, only my mind is.

Sometimes value is not only about the money.

For example when i was programming in VB6, I was never bothering to protect my applications. I know VB6 applications are also not secure, but there is no easy way to decompile VB6 application back to pure source code (at least not to 100%). Sad but .NET based applications are even more insecure than VB6 applications.

[Lauriux1]

P.S.
How good is VB.NET for big programs, because VB6 was pretty unstable for big programs, does in this case VB.NET is more stable?

[ThomasJohnsen]

This thread made me think about the good old C64 days of 6510 machine code programming. Programmers (if you would call them that at the time) would make self-changing code, create parts of code that seemingly did something completely different then what it actually did, pack/scramble code in inventive ways and use many other loopholes to prevent others from reading/understanding their code.
Almost all software for the C64 was available cracked before it was ever released in shops though, so their efforts were all futile; however creative they might have been.

[Shaggy Hiker]

P.S.
How good is VB.NET for big programs, because VB6 was pretty unstable for big programs, does in this case VB.NET is more stable?

How big is big? I never ran into any issues with VB6, but the largest program I wrote in that language only had about 70 forms, and was a single user program, so I have never really considered it all that big. On the other hand, it hit an Access DB, and THAT was notoriously unstable. It worked ok for the number of users we had, as long as the network didn't go down while somebody was using the program, but again, that was an Access issue, not related to the language.

I don't know that there is any practical limitation on the size of a program written in any modern language. The computer doesn't look at the number of lines of code and say, "Phew, I'm gonna forget where I was at by about line 100,000." Therefore, the stability probably has more to do with how well the source code is organized. In that regard, .NET is most certainly better than VB6 was, simply because .NET is OO. Of course, people can go overboard with OO designs and cause themselves all kinds of maintenance trouble, but if they know better than to do that, then OO does allow for better organized code. An additional feature is the better designed IDE. You could do some things in VB6 that allowed you to focus on just one part of some code, but .NET goes even further, especially with the use of Regions and partial classes. By judicious use of those IDE features, you can really get the code organized in some logical fashion.

On the other hand, .NET has full support for multithreading. That opens up a real can of worms (nematamorpha, to be precise). Once you get into serious mutlithreading, you can tie yourself into knots with interesting race conditions. Therefore, you can make a worse mess in .NET than you were ever able to in VB6, though that kind of becomes a discussion of whether infinity^2 is greater than infinity.

[Evil_Giraffe]

My source code isn't valuable, only my mind is.

Your mind doesn't know the difference between a reference and a pointer, so, maybe not so valuable?

[Grimfort]

My mind has pointers to pointers to pointers, which all point at google. Grim - AKA GoogleCoder...

[Lauriux1]

Currently working on a hack for Shaggy's mind, will post source code when done. Preliminary results show that Shaggy's thought distribution is:

• 80% Llamas
• 15% How to feed Llamas
• 5% What was I doing?

.MIND Reflector

[Shaggy Hiker]

Your mind doesn't know the difference between a reference and a pointer, so, maybe not so valuable?

Oooo, you're going THERE!

Well....I've got nothing.

[skywola]

If someone wants to de-compile any of my applications they are welcome to it . . . considering the amount of time required, and that it would be a nightmare for them to try to create an application that has the same functionality but does not break copyright, they can have at it. As for obfuscators, packers, etc., as far as I am concerned, they are marketed by slick marketers who play on fears . . .

Crackers are few and far between nowdays, as opposed to the old days of Fravia and Greythorne . . . Ah, those were the days . . .
.

[Lauriux1]

If someone wants to de-compile any of my applications they are welcome to it . . . considering the amount of time required...

If your applications are based on .NET and not protected with an packer or obfuscator, then it won't take much time to decompile your application, only few mouse clicks.

...and that it would be a nightmare for them to try to create an application that has the same functionality but does not break copyright...

Even if you are almos 100% sure that someone has stolen your code, you still have to prove that and it is time and time is money... Or what about if someone has stolen not full your code, but just the part of it and adapted for their purposes, then it may be hard to prove in such case that it is stolen.

Every program can be decompiled, but 'normal' appication 'convert' back to the source code would took eternity while .NET based application 'convert' back to the pure source code would took only few mouse clicks. And it is not right, programer should decide by himself if he want's to release his source code or not. And I think that Microsoft should somehow solve that problem because it is just a big gap! Then what is the goal to have applications in EXE format if it is only easter egg with script inside, then just remove compiler from interpreter and distribute applications in pure source code as a script...

[Shaggy Hiker]

The point was to come up with a language that could be written against one OS, but would be able to run against any hardware/OS combination. In that way, the point was to compete against the vision that was early Java: Write once, run anywhere. To do that, the language has to compile to an intermediate language that is then compiled to the machine lanuage of the target processor using a JIT compiler written for that processor. In practice, that didn't really happen. For one thing, Apple abandoned the Motorola CPU in favor of Intel, which means that pretty much all desktop systems now use the Intel x86 instruction set. Furthermore, there was never any great effort made by MS to build JIT compilers for non-Windows OS, though others have done so for Linux with the Mono project. Apple came up with other means of running Windows programs.

In that way, .NET really did act like Java: Lots of promise, little realization of the initial goals, and now the goal posts have moved.

I don't know that there is any sound reason for .NET to still end up as MSIL, and there are packages out there that do compile it down to machine code. Perhaps that's the direction it ought to go.

I am curious, though. I've written a fair amount of code, and there isn't any piece that I'd really object to somebody else using. Many pieces I would be quite happy if people wanted to use. On the other hand, my situation is only one fairly common case: I don't write code that is sold for money. So what I am curious about is hearing from somebody who would mind if only a piece of a larger program was stolen. After all, stealing the entire program doesn't require having the source code. That much has certainly been proven ad nauseum. The only time the source code would matter would be for stealing some piece of it that is less than the whole thing. So, is there such a case where one piece is effectively more valuable than the whole?