obfuscator : Java Glossary

1. Consider that you might be paranoid and/or suffering from delusions of grandeur. Is your code really so wonderful it would be worth extensive effort decompiling rather than just writing from scratch? Will it actually harm you if someone steals a method of yours rather than writing it from scratch?
2. Consider legal remedies against those who reuse your code without permission. You might send sniffers (similar to virus scanners) over the net looking for signature DNA in other people’s code that indicates they stole parts of your program.
3. Do your customers want code or a code/support package? They may have almost no interest in getting it from pirates.
4. Consider adding tamper proofing to your code so that if anyone changes the program in the tiniest way it will develop hard to discover bugs. Learn the art of psychological warfare with the pirates. Make the pirate think he has won, then hit him with yet another delayed time bomb. He never knows when the job is done. Throw in red herring code that looks like some complicated security system but which is actually gibberish. Let the pirate waste hours discovering that. Riddle your code with a wide variety of anti-tampering devices. Camouflage them in as many ways as you can think of. The simpler the tampering test, the more it looks like ordinary code. Don’t immediately react to a tampering detection. You want the punishment to come considerably later, via a circuitous, hard to trace, route. Camouflage your punishments as ordinary bugs.
5. You can burn in the CPU serial number at branding time so the code won’t work on any other Pentium III or IV CPU.
   Pentium CPU Serial Number
6. Consider adding snitching code so that if some tampering is detected, you hear about it. You don’t want to flag all your anti-tamper devices so blatantly.
7. Issue frequent updates, preferably with automatic install. If you are Machiavellian, add a early-death gene that triggers if a new update does not arrive in time. The poor pirate has to start over with each new release. This technique is also useful for encouraging deadbeat customers to pay their bills for custom coding. A variant is to automatically change the password 60 days after the install. If the customer has paid, you tell him the new password.
8. If a standalone program needs to check in with Mom once a month for any reason, that will tend to scare off pirates.
9. Use an AOT optimising native code compiler, perhaps in conjunction with an obfuscator. Native code is much harder to decompile than Java bytes codes. If you are serious about obfuscation, this is the only way to fly.
10. Check out on the hacker sites which obfuscation techniques they most dread.
11. essay on unmaintainable code. If you make it so hard to maintain that even you can’t do it, what chance to pirates have?
12. Keep in mind that any off-the-shelf obfuscator is going to be a lot easier to defang than hand-crafted obfuscator strategy.
13. If a project is big enough to be worth stealing, it is almost impossible to understand it even with commented source, without getting some hints from the author. If it is not that big, what’s the huge secret you are hiding?
14. Java is very easy to decompile and defang any simple minded authorisation just by removing the call to the authorisation routine. You need to hide this in JNI and also put into that same JNI code that has practical value so that if it is turned off the program stops working, ideally in a very non-obvious and non-immediate way.
15. I consider it immoral to keep coding tricks secret. Why make others waste time reinventing the wheel? We all benefit if we share source code.
16. The ultimate obfuscation tool is to never let the hacker see the code — run anything critical on a webserver. The most fool proof way of preventing theft is never to give the customer the critical object code. It runs only on a server. This means your customers need 24/7 Internet access to use your app, but for commercial customers such access is becoming more and more common.
17. You can digitally sign your code or registration keys with Sun jar signing or with a tool such an the Transporter. This will slow down hackers too lazy to take apart your code, but it will stop those who try to patch the license files with a binary editor or to create counterfeit ones. If you add additional consistency checks to the license file information and check it as indirectly as possible in as many places as possible and delay failure as innocuously as possible, you will drive the hacker mad.
18. Often all you want is to make it difficult to modify constants burning into the code such as customer registrations, capabilities, customer customisations, customer identification. You are more concerned someone will pirate a copy by burning in now constants without any understanding of the program itself. Obfuscators can hid the information in Strings and make it hard to charge using techniques such as this: XOR each char of every string with a 16-bit random number generated from a known seed. To get the strings back at class load time, repeat the process with the same seed.
19. For low volumes, I hand compile each customer’s individual copy of the application, which hard wires her configuration constants in a thousand places into the byte code. Options she is not currently using are not even present in the code. This is a variant of the DOS technique where I shipped Abundance apps preconfigured with a specific printer driver. If the customer changed printers, she would tell me and I would ship her a new executable.

1. Never break quickly. If someone has to wait a day to find out that their try at hacking didn’t work, they will never figure out what to do.
2. Require updates. If you require frequent updates, they cannot be running a hacked version of the client. We have people go out, ask how things are going, test out the computer, install and uninstall software, look for odd executables.
3. Make purchasing valuable. Technical support is a Good Thing™ for this. I swear some programs don’t include documentation just so you will have to call and register.
4. Make every executable different (in some indistinguishable way, unless you have two side-by-side). If you put a hidden serial number in your code and make people register it, then you know whom to sue when they re-release your code.
5. Look at Vermilion FTP. Evil! (that means fiendishly cunning). The serial number contained assembly code, function tables, and xored keys to mask it all. If you got the 100 character serial number wrong, it just crashed when it couldn’t find the 'connect' function (for example). Normally if a program is considered hard to crack people will start attacking it (for glory and ego-fodder, I imagine). Most people gave up on this one.

   One fellow finally did, after a full year of trying. Released a detailed description of what he did, just so people could understand his Hell (which was forwarded to me, which I read in awe). With Java you could do this with bytecode. Since you can write your own class loaders in Java, the opportunities for confounding the pirates abound.

6. Use an application server. If key parts are on the web, then they would have to hack your server in order to get around your protection. You cannot reverse engineer what you cannot see. Many Internet programs use this.

Many of these are student projects, not full tools.

Ofuscating Files

• Encryption
• Salting. This adding random material before encryption so the same file will scramble to a different text each time. Adobe was able to keep its PostScript Type 1 format secret for many years with a combination of encryption and salting.
• Encoding a field as two different fields. To recover the field you must sum them. You randomly split he value. This makes it hard for the hacker to discover relevant fields.
• Add random nonsense, particularly stuff that looks like the real thing, but is not reliable.
• Change the format of the file frequently. The changes can be automated, each to permute the fields in a different way depending on when the file was created.
• Don’t validate your file all in one place. Simply allow an invalid file to crash the program naturally, preferably after as long a period of running as possible.
• Layer your defenses so that the hacker never knows if he has nailed them all.

Books

	recommend book⇒Decompiling Java
		hardcover
	ISBN13:	978-1-59059-265-6
	publisher:	Apress
	published:	2004-07-23
	by:	Godfrey Nolan
Decompiling and protecting yourself from decompilers using obfuscation.
abe books.co.uk abe books.ca amazon.co.uk amazon.ca abe books.de chapters.indigo.ca amazon.de abe books.com abe books.fr amazon.com amazon.fr barnes and noble.com abe books.it powells.com iberlibro.com sony e-books abe books anz

	recommend book⇒Covert Java: Techniques for Decompiling, Patching, and Reverse Engineering
		paperback
	ISBN13:	978-0-672-32638-7
	publisher:	Sams
	published:	2004-05-13
	by:	Alex Kalinovsky
Learn the art of war, both offense and defence to protect your code from pirates.
abe books.co.uk abe books.ca amazon.co.uk amazon.ca abe books.de chapters.indigo.ca amazon.de abe books.com abe books.fr amazon.com amazon.fr barnes and noble.com abe books.it powells.com iberlibro.com sony e-books abe books anz