No, you can't :-) The mere idea!! :-)
Obfuscating code to protect it is like putting a big stone in front of your house's door. It won't prevent people from getting in. It will just give them extra work.
The more you obfuscate, the more likely you are to challenge the great hackers who deobfuscate just for fun :-)
I am yet to see obfuscated code I can't deobfuscate (but sure, if you give me obfuscated code in a language I don't understand... it's going to take me some time).
No, I don't. I'm sorry, but I have to disagree... :-)
But, the company I was at was never foolish enough to believe that encrypting scripts made the code safely unreadable to all end users. It does make it unreadable to coldshot users and it lets the hotshot programmer type users know that the copyright owners of the code don't want to share it with them so if they were to actually copy the code they will clearly be aware of taking part in copyright infringement. Which they generally respect (although they might break the encryption just to prove to themselves that they can). The company didn't believe it because the two of us who implemented the encryption taught them that it was impossible - if the script is going to run at all, then Perl has to be able to read it which means that at some point it has to be in readable form. So, they were foolish enough to ask for the impossible but smart enough to accept that it couldn't be done.
I, haX0r
schwern on 2005-04-12T07:07:45
I recall scaring the hell out of a programmer that was relying on Filter::decrypt. He'd thought it was full on encryption rather than just elaborate obfuscation and apparently the company had bought into that, too. I told him I could bust the obfuscation. He didn't believe me so he sent me a simple sample. IIRC my algorithm was something like...
require the code
walk the symbol table looking for globals and subroutines
Data::Dumper the globals
B::Deparse the subroutines
The tricky part was the file-scoped lexical arrays used inside the subroutines. I couldn't quite get padwalker working to grab at them. Instead I just ran the program over and over again with the proper inputs to cause it to print out each element of the arrays.
Then I sent the result back to the poor guy. I think it took less than an hour.
It was an interesting exercise. I'd been saying for years prior that Filter::decrypt was defeatable by B::Deparse but had never actually performed an attack.
Re:I, haX0r
jmm on 2005-04-12T14:00:41
I haven't tried it, but what I figured the easiest method (even before B::Deparse came along) would be to write another filter and name it Filter::Decrypt. It would use the "real" Filter::Decrypt but tee the results before passing them on as its "filtered" output. It's the basic man-in-the-middle attack.Re:I, haX0r
schwern on 2005-04-13T19:49:07
Wow, I never would have thought of that!
Man what the heck is that doing on an O’Reilly site.
I do have to qualify that obscurity is not the devil: there is no need to help an attacker along, regardless how safe you think you are. It’s way foolish to rely on obscurity as the your sole line of defense, though. That’s just asking for trouble.
the vast majority of software pirates won't spend 500 hours reverse engineering and patching a simple $10 shareware application
Every anti-piracy method is based on this assumption. Every one fails because it is not true. It was not true back when it was a bunch of computer nerds copying 5 1/4" floppies using BitNibbler downloaded off a dial-up BBS and its not even remotely true now with your grandma downloading music over BitTorrent.
The vast majority do not need to break the obfuscation. Just one. The Internet takes care of the rest. And there's always somebody who does this sort of thing for fun and is ASTOUNDINGLY good at it.
