Page 1 of 1

Making code harder to understand

Posted: Mon Jan 09, 2006 1:20 am
by jaymoore_299
I have a script I'd like to prevent others from ripping off, though it is not so valuable that I'd need it completely secure. What are some ways to make code harder to read/understand?

Posted: Mon Jan 09, 2006 1:38 am
by feyd
That somewhat depends on the code, but basically.. if no compiler is allowed (bytecode), obfuscation is about the only real direction you can go.

Personally, I find obfuscation stupid to do on many levels. Granted there are varied levels of obfuscation. Choosing any combination of the following is obfuscation:
  • Compression. A very common approach that compacts words or phrases in an attempt to reduce overal size. The trade-off is it has to be decompressed to run.
  • Line crushing. Although a form of compression, I single this out because it requires no added code to decrypt. This often involves removing most whitespace, along with comments to make a single, very long line containing code. (the farthest I go, personally)
  • Encryption. Often coupled with compression, this will use an algorithm to transform the code into (often) complete garbage. Trade-off, like compression, requires unencrypted code to decrypt the actual code.

Posted: Mon Jan 09, 2006 7:20 am
by s.dot
Harder to read when someone is looking at the source code?

I guess that's not really possible, unless you give them a hashed or encrypted version of the source code... which really wouldn't make much sense.

I guess just add comments that don't make any sense and use deprecated functions? But that's not suggested.

Posted: Mon Jan 09, 2006 7:32 am
by foobar
Easy: Don't share your source-code.

Costly: Use Zend Encoder to distribute your bytecode rather than the source. You may experience a slight speed increase as well.

Posted: Mon Jan 09, 2006 5:47 pm
by jaymoore_299
I heard of line crushing, encryption, but what is compression? How do you compress and run a php script?

Posted: Mon Jan 09, 2006 10:33 pm
by feyd
without a "native" compiler to rehidrate the encryption or compression, a decrypt or decompress script must be placed around the actual code which is finally eval'd. Here's a rough example:

Code: Select all

$_='!@&#&FAVBB&A(*&FASHDfhasldfhasF&AF&*!#R&F&F&F&V&VLAKJSVJV BHKZXJLVZLXKJVKB LKJSDLFKJLKJL';
/* insert magical decrypt/decompress code here */
eval($u);
Here, $_ is a hypothetical resultant string created by the encryption/compression algorithm, and $u is the "original" code represented by $_ which could be anything (cure for cancer, maybe). The original code isn't actual code yet until it's been interpretted by the language, so eval() is used to do just that.

Now, because the decrypt/decompress will take a certain amount of space, the routine performing the crush has to weigh whether there is any real savings. Generally speaking, the compression ratio will determine whether it's even worth running through (unless forced)