Java Glossary : obfuscator

Java definitions: 0-9 A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

You are here : home : Java Glossary : O words : obfuscator.

obfuscator

A tool to mechanically replace all variable and method names with random meaningless names. The process is sometimes called shrouding. This makes it harder to reverse engineer class files. Obfuscators won't stop an even mildly determined pirate. Before you throw up your hands in despair:

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?
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.
Do your customers want code or a code/support package? They may have almost no interest in getting it from pirates.
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.
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
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.
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.
If a standalone program needs to check in with Mom once a month for any reason, that will tend to scare off pirates.
Use an optimising native code compiler, perhaps in conjunction with an obfuscator. Native code is much harder to decompile than Java bytes codes.
Check out on the hacker sites which obfuscation techniques they most dread.
essay on unmaintainable code. If you make it so hard to maintain that even you can't do it, what chance to pirates have?
Keep in mind that any off-the-shelf obfuscator is going to be a lot easier to defang than hand-crafted obfuscator strategy.
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?
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.
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.
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.
You can digitally sign your code or registration keys with Sun jar signing or with a tool such an the Wrapper. 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.
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.
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.

This list is derived from David Waite's art of Psychological warfare:

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.
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.
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.
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.
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.
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.

Some Obfuscators work on the source code, and others on the class files.

Many of these are student projects, not full tools.

Obfuscators
Tool	Alive?	Notes
2LKit	Y
BLOAT	Y	works on class files. Primarily an optimiser.
Chainkey	Y	Licencing keys, with configurable copy protection, how accurate, how severe.
Condensity	Y	$195.00 USD for pro edition and $795.00 USD for developer edition. They don't tell you on the website the difference.
CShred	?	Company there, unsure of product.
Creama	N	Unfortunately the young Dutch author Hanpeter van Vliet died of cancer.
DashO	Y	$895.00 USD Dash-O obfuscation edition, $1695.00 USD Dash-O Pro, $1995.00 USD Dash-O Embedded, $2995.00 USD Dash-O Power Pack.
Elixir	Y
HashJava	N
HoseMocha	N	Uses a simple trick to confuse the Mocha reverse engineering tool by inserting an unreachable bogus opcode. Too unsophisticated for today.
Jarg	Y	jar creating tool that compacts and obfuscates.
Java Code Protector	Y	Works with Chainkey.
JAX	Y	IBM/Alphaworks jar creating tool that compacts and obfuscates.
JBuilder	Y	JBuilder is an IDE with an obfuscate option on the compiler.
JChain	Y	free for the first year
JCloak	Y	by Force 5
JCMP	Y	Free. It allows you to compress public names as well.
Jobe	N
Jopt	Y	primarily an optimiser
JProof	Y
JPresto	Y	$520.00 USD to $1950.00 USD
JODE	Y	Java Optimize and Decompile Environment
JShrink	Y	Eastridge technology's obfuscator. Jshrink removes unnecessary symbolic information from Java .class files, resulting in files that load faster and yield less information when decompiled
JZipper	Y	by Vegatech
klassMaster	Y	by Zelix. It is somewhat cleverer than average. It: Obfuscates class, field and method names. Obfuscates control flow. Encrypts String literals. It has fewer bugs than the competition.
Marvin Obfuscator	Y	free. Obfuscated code usually isn't recompilable. Processes any application, Applet or servlet. Resulting code is compatible with any Java Virtual Machine. Generates a compact jar file. Removes package information; scrambles class names, method names, field names. Encrypts string constants. Removes unnecessary classes. Removes all debug information. 100% Pure Java. Tested on JDK 1.2, 1.3 and 1.4beta.
Metamata Toolsuite	?	company still there, but unsure of product.
Obfuscate	Y	by Jamm Consulting. née Monmouth Obfuscate. Little brother to ObfuscatePro.
ObfuscatePro	Y	by Jamm Consulting. Sometimes called Neil's obfuscator. full featured product. ObfuscatePro is a Java bytecode obfuscator that allows you to customize the obfuscation by specifying classes to exclude from the obfuscation. For the classes that you wish to exclude, you can specify whether to preserve the method and/or the field names in addition to the class name. This is useful for classes that use RMI and/or localization since the class names and the method names need to be preserved for these items. Big brother to Obfuscate
Proguard	Y	free, GPL open Source, shrinker and obfuscator. Grew out of Retroguard.
Retroguard	Y	Open Source
SourceGuard	N	by 4thpass. Commercial product. No longer being supported. Does not work with Java 1.4.
Semantic Designs Java Obfuscator	Y	$100.00 USD
ShroudIt	Y	$90.00 USD and $180.00 USD licences.
Visiblock	?	by Visionary Solutions. company still there, but unsure of product.
YGuard	Y	by Yworks. Free. Integrates with Ant. Allows creating patches to old obfuscated code.

Learning More

Covert Java: Techniques for Decompiling, Patching, and Reverse Engineering

0-672-32638-8

Alex Kalinovsky

Learn the art of war, both offense and defence to protect your code from pirates.

The Meurrens List ¤ dark room ¤ decompiler ¤ disassembler ¤ Douglas Low essays ¤ Elliotte Rusty Harold and Joseph Bank ¤ Eric Lafortune's list of Obfuscators ¤ One-Trick Optimiser ¤ shrouder

home	Canadian Mind Products
	mindprod.com IP:[24.87.56.253]
	Your IP:[80.134.30.163]
	You are visitor number 5969.
	Please send errors, omissions and suggestions
	to improve this page to Roedy Green.
	You can get a fresh copy of this page from:	or possibly from your local J: drive mirror:
	http://mindprod.com/jgloss/obfuscator.html	J:\mindprod\jgloss\obfuscator.html