Fog Creek Software
Discussion Board

Protecting software against disassembling/recoveri

It would be interesting to protect binaries and scripts against disassembling, recovering or easy code readability (in case of a script). As far as I know, there are obfuscators for Java (Microsoft announced it will integrate an obfuscator in .NET) but they don't prevent someone to disassemble the binary, they mostly make it only (very) hard readable. Do you know:

- Does it make sense to do addionally protect an EXE with encoding it?
- What software to use?
- Is it possible to protect scripts like ASP/JSP/PERL? (in this context: I know it's possible to crypt scripts running in Microsoft scripting host since it's version 5 using Script Encoder but this kind of protection is quite lazy)
- How that kind of protection influences performance of the software?
- I've heard that Microsoft is using some kind of protection for e.g. it's Office bundle. Is it true?

Wednesday, November 28, 2001

Generally it only makes sense to obfuscate if you worry about competitors.  And so the point of obfuscation is that it should cost more to deobfuscate than just to reverse-engineer the software.

Well, another benefit to obfuscation is that it compresses code size dramatically.  That makes sense in some applications where you send code over the net.

However, the costs:
- Don't think about trying to debug that mess.  You generally get a report of the names before & after obfuscation, but it's really unwieldy to do so.  Build an unobfuscated version and make sure they act the same.

- Obfuscators are occassionally slightly buggy.  This may bite you when you try making a final build (it only happens near a deadline) and the damn thing just won't build.

Fortunately, there are ways to "jiggle" stuff around so that it works.  You'll find out when you use an obfuscator.

- You have to watch your uses of Reflection APIs, which allow you to call classes at runtime just by having their names in a string.  Your main job in configuring obfuscation, is dealing with this.  Fortunately, static languages like C++ don't have reflection.

- The need for obfuscation decreases when you have a less standard .exe format.  Paranoid Java users need obfuscators because the bytecode format is so well-defined.  But really, it's not really being able to look at the code that matters, but seeing the class structure, with classnames.

forgotten gentleman
Wednesday, November 28, 2001

Hm...just because you can read my code, does that mean you know the thought process I went through writing the code?  The intellectual side of the code is more important to me than the physical side.

You get someone who is good at Assembly (or better yet Machine Code) and you aren't going to stop them from figuring out what your program does or how it does it.  But the why, they can't figure out because that is your thought process.

Justin Rudd
Wednesday, November 28, 2001

There was once a 3D graphics program that had especially strong anti-disassembly/anti-copying defense - it came with a dongle (decryption hardware) which the executable code itself was passed through at runtime - a rather slow process. When the black-hats eventually cracked the system and disabled the dongle, the resulting program ran several times faster than the orignal, paid-for version.

I once fixed a graphics bug in a (non-obfuscated) game executable by patching a new value into an OpenGL call. (doh, now they're going to sue me for violating the license...)

Dan Maas
Thursday, November 29, 2001

Any standard protection scheme is likely to be cracked because the value/workload ratio is much higher than something unique and deliberately unstructured.

See how trivial it is to break most license control schemes at The Academy of Reverse Engineering:

Friday, November 30, 2001

ALL protection schemes will be cracked. After all, the computer still has to be able to understand the code. Running an EXE through a compressor/encryption system only helps a little, since the code to decode it will need to be part of the exe so that the computer can run the thing.

All a cracker needs is a debugger, some assembly language skills, and patience.

All protection schemes do is keep honest people honest, and it WILL annoy your customers. The only market I can think of where protection makes sense is in low volume, high cost vertical markets, where losing one sale can hurt. In more general release, don't bother.

Chris Tavares
Friday, November 30, 2001

> ALL protection schemes will be cracked.

Don't let users access the EXE. Load and run the code only on a protected server machine, not on the client machine.

Christopher Wells
Monday, December 3, 2001

Why bother "protecting" the code if the client won't be able to access it?

Disassembly "protection" is useless.  The only fun part is writing the assembly code involved.  :)

Wednesday, December 5, 2001

*  Recent Topics

*  Fog Creek Home