Open Sourcr Obfuscators

Engines, Libraries and Tools Tools Discussion
#1

Hey Guys,

Seems like there are quite a few. Any particualr recommendations or cautions? Im looking at Open source becaus e im playing with the dies of building some kind of tool chain that would both licesne protect and obfuscate in one step…

#2

ProGuard’s my fav!

#3

Yep, Proguard gets my vote as an ok open source obfuscator. 5/10 for optimisation though - it can’t cope optimising what the FAQ calls ‘complex methods’… keeps throwing stack overflow exceptions. I use Joga for optimisation instead.

Edit: a friend of mine has his own company, selling software he has written in java and after doing some extensive tests he absolutely swears by Zelix Klassmaster but it’s not open source, and costs $299

#4

http://jarg.sf.net (albeit a bit dated, its rather neat)

The “problem” with obfuscators is that they can generate code, which cannot be written in java, but is valid accordingly to the jvm specs. So it may not work on all vms equally well.

For example if you decompile jarg/joga-ed classes you might get stuff like:

for(int super=0;super<5;super++)
or
int this=5;

And other stuff which totally doesnt make any sense :slight_smile:

#5

ProGuard is nice, downside is if you need it for a mobile (which wants to preverify classes) you have to create a temp package, obfuscate, then unpack again.

I have also used Jode and it is nice as well. IIRC it also had a funny feature where it obfuscated by keeping the method names but rearranging them.
Kinda evil if you think about it.

#6

I use yGuard, which comes with an Ant task, and is rather easy to use, yet powerful

Lilian :slight_smile:

#7

Basic assumptions I make when decompiling someone’s code:

  1. You don’t want me to see it, so you won’t have put effort into making them make sense. Even colleagues struggle to come up with method and variable names that are as clear as one wants ;), so I’m assuming that yours are not much use to me.

  2. If you thought you were gaining anything by obfuscating it, I’m assuming you’re the kind of person who puts even less effort into intelligent names :P. Maybe you were just going for classfile compression, but probably not.

So, my toolchain is setup to delete all the method and variable names as the first step automatically, giving them logical inferred names instead (which IMHO are easier to keep track of during the refactoring process). To be honest, if I’m decompiling something where I expect the names to be good I usually just javap it instead (it’s usually to salvage a lost interface or rewrite a class from scratch/earlier version but with same names).

I think you’ll find that’s pretty common. shift-alt-t is the decompilers best friend :wink:

#8

I am perplexed as to why there are so many different obfuscators for Java - with most performing the exact same set of optimisations.
Why are so many people determined to re-invent the wheel?!..

An existing [L]GPL project needs to be adopted as the defacto standard, with an extensible plugin framework, and preferably based upon the ASM API (superior scalability to BCEL).
Hopefully such a project would then become the focal point of all bytecode optimisation development, and would eliminate all this duplication of effort that currently exists.

Proguard might be a suitable base-project; it already has a plugin framework, and is GPL.
The only problem with proguard, is its core design is not ideal, and would need refactoring onto the ASM API.

#9

What boat did you get off from?
You do not know me, how I code or anything else about me yet you think you can judge me because I use an obfuscator?

Here are some clues:

One benefit of obfuscating is to make your code unreadable to others. Not really a blocker to anyone willing to read your code but every bit counts.
This does NOT mean my naming is poor or anything like that. I have no idea where you get off presuming that crap.

Second, obfuscation removes dead code.
Should not happen but in some circumstances, it is not really that bad.
Expecially in my area, it can help a lot.

Third, it reduces class size. By a lot.
Always good but in my line of buisiness, the mobile area, VERY important.
I have seen 50% size reduction and basically speaking, it can mean getting your app on a phone or not.

Talk about arrogant and presumptuous.

#10

I wasn’t referring to you in particular, I was referring to the many people whose obfuscated code I’ve decompiled. It’s a gross generalization, but so far seems pretty accurate. Some of the comments were also tongue-in-cheek - many people fail to use good method names even when they’re trying to.

It doesn’t make your code unreadable to others. In most cases, it makes the code no worse than any badly written code (e.g. I’ve seen real source code where variables are named “one”, “two”, “three”, and “red”, “orange”, “yelllow” when those words have nothing to do with the actual algroithm or program, as well as “myvariable1”, “myvariable2”, etc).

I specifically excepted classfile compression - and mobile dev was the main use case at the top of my head when I wrote that.

If you like :). Feel free to PM me any amount of arrogant and presumptuous comments :P. HAND!