I’ve been considering playing with some Flash, and I wanted to use the FlexBuilder plugin for Eclipse on Linux to play around with some ActionScript / Flex. The install was painless enough, but on booting the thing up I noticed a status message in the bottom corner of the screen saying ‘FlexBuilder trial will expire in 14 days’.
It would be lovely if we could go ahead and fix that. Unfortunately, section 2.1.3 (b)(3) of the EULA explicitly prohibits ‘reverse engineering, decompiling, disassembling or otherwise attempting to discover the source code of the subject’, so we can’t.
Annoying trial messages plague a lot of commercial software though. It might be worth looking at some general ways to remove them on software with less restrictive EULAs.
You will need:
- JAD – I used the statically linked version
and if you want to create Flex projects on Linux you will need:
- FlexBuilder
- Eclipse 3.3
Step 1: Finding the source of the message
The quickest way to find the source of a message like ‘This software expires in 20 days’ is to grep the provided JARs for that text:
find /usr/local/install_folder -name "*.jar" | (while read name do mkdir /tmp/jars cd /tmp/jars echo $name jar xf $name grep -r "expires in" . cd .. rm -r jars done)
That’ll tell you roughly which JAR you care about.
Step 2: Extract the JAR
cd /tmp mkdir working cd working jar xf /usr/local/install_folder/subfolder/interesting.jar
You can then look at the filenames of the extracted class files to see which look interesting. It stands to reason that if you were going to put an expiration date in your software you’d obfuscate it, possibly with a little ASN. (Well, stands to reason and you may already have drawn a blank fiddling the dates in any XML files you might have found).
Step 3: Decompile the class
You’ll hopefully have downloaded jad and put it somewhere in your path. Typing ‘jad Annoying.class’, for example, will generate Annoying.jad, the decompiled file. jad may complain that the version of a subclass is ’49.0′, which is more recent than it supports. We’re not too worried about that.
Step 4: Edit the code
It should be obvious, looking at the decompiled code, which lines it is that are generating the message and / or any irritating dialog boxes. If it’s not, you may have selected the wrong file. Try again.
Step 5: Recompile the code
The trickiest part of recompiling decompiled code is getting the classpath right. Fortunately:
find /usr/local/e3.3/ /usr/local/install_folder/ -name "*.jar" | tr /\\n/ /:/; echo . > /tmp/classpath.txt
does a pretty decent job. You can then type something like:
javac -cp `cat /tmp/classpath.txt` com/evil/corp/annoyance/Annoying.java
which will generate a fresh Annoying.class.
Step 6: Rebuild the JAR
All that remains is to reassemble the JAR:
jar cf /usr/local/install_folder/subfolder/interesting.jar *
Conclusion
There are a couple of things to conclude from all this. The first is that Java isn’t the greatest obfuscation technology in the world, but then it was never really intended to be. The second is that software wants to be free.
I wonder if they do gluten free porridge.
