Ask HN: To obfuscate or not to obfuscate Java bytecode? | Hacker News Reader

Ask HN: To obfuscate or not to obfuscate Java bytecode?

5 pointscwg5 comments

What is your take on bytecode obfuscation, specifically obfuscating a Java / Swing app that will have a trial version publicly available for download?

I know that obfuscation is not 'safe', and that there's always a way to decompile Java bytecode. But still, I have the feeling that I should do something to discourage enterprising users to decompile our code.

I have experimented with some Java bytecode obfuscators, and for whatever reason, they make the end result crash a lot. Now, I could probably dive into the inner workings of these obfuscators and somehow make it work, but it got me thinking: Does obfuscation actually make sense?

My thinking is that decompilation would be interesting to two groups of people: Those who want to crack the licensing mechanism, and the competition.

For the first group, I know there's probably nothing that will stop them. I have other means in place to discourage casual piracy, but I know there's no absolute security, and I don't plan to enforce that strictly (for the cost of unnerving paying users).

For the second group, my hunch is that it probably doesn't matter as well. If competitors can gain an advantage by looking at my (decompiled) source code, probably my business model is not robust enough, and I should rather be outperforming them, and stay ahead of the game.

What is your take on obfuscation? Does it make sense, and when so?

All your input is very appreciated!

Some background: We are working on a desktop application developed in Java / Swing, which is geared towards the enterprise market. Since the potential market is quite large and diverse, we want to make our app available as a trial version for download from our website.

I think the goal of obfuscation should be to keep honest people honest. In the case of Java bytecode, I think they're already honest. You don't see people casually decompiling bytecode, because it's a royal PITA and the resulting source is usually pretty unreadable anyway.

If someone really, really wants to reverse-engineer your object code, they'll find a way to. If it's important to your business that they not...I'd find a way to make it less important to your business.

Obfuscation to protect source code, implementation details, etc. I believe is very rarely warranted. Most applications have fairly mundane implementations, with much of the differentiator being fit and finish of the whole. Even having the source code directly, rather than having to disassemble it, wouldn't be a huge risk IMO - any entity profiting from it will clearly be culpable of copyright violation.

It's easy to get paranoid about the value of source code. The fact is, most mature codebases are sufficiently scruffy that even their developers wouldn't want to start from that codebase if they were to create a competitor. And when you're not familiar with a body of source, it takes a lot of work to understand its architecture and how it's put together; so then the risk is even lower.

Obfuscation as a speedbump to cracking has more to say for it. If the obfuscation badly affects stability, I'd suggest only using it for a handful of core modules, code that lies on the critical path for most useful application uses. Obviously, it's important that the code isn't something trivial, like a boolean license check. It would have to be a module that would be non-trivial to reimplement and re-link into the application.

But of course I'd suggest other things, like baking in some kind of internet dependencies.

If you can get it working safely, I'd recommend obfuscating. It's easier to remove it later than to add it when your full source is out in the wild. Getting the genie back in the box is impossible.

Yes, some will find a way to get at it, but there is no reason to make it stupidly easy for everyone else. Your competent competitors would probably rather write their own code than sniff through obfuscated code, but they might be quite happy to have your full source at hand when solving problems. Also, very little is stopping someone from simply lifting your code, making a few changes and releasing it as their own, for 10 bucks less than yours. It happens, I assure you.

As an alternative, you might consider writing some portion of your app in a language that generates Java bytecode. Languages such as JRuby generate bytecode that currently cannot be fully decompiled.

This is a little different approach as the bytecode code isn't mangled as an afterthought.

http://jimlawless.wordpress.com/2010/03/07/jruby-as-a-java-o...

There are actually three ways other than obfustaction to protect your Java bytecode. I humbly suggest that you check out my article "Protect Your Java Code - Through Obfuscators And Beyond":

http://www.excelsior-usa.com/articles/java-obfuscators.html

Reply on news.ycombinator.com