The Joel on Software Discussion Group (CLOSED)

Hi all,

Looking to see if you have any good suggestions on this one: we're planning to ship our Java web app for clients to install and use on their own sites, i.e. they host it. As they'll have access to the files making up the distribution we want to protect our JAR files as much as possible.

I've found a few good obfuscators about (Dasho, ProGuard, among others), but there doesn't seem anything quite "bulletproof" enough for our liking.  Without getting too prescriptive about what "good enough" means, any recommendations here would be much appreciated.

Cheers

Brian

A Jar file is basically a compressed zip file renamed. Whatever files are in there, you would be able to see through opening it with Winzip, or some other compatible apps like WinRar. The only compiled apps are the java class files. They are also zipped up within the jar. Those are already compiled to byte code so you won't get much sense from viewing them.

You do understand how utterly useless the idea of "protecting" jars?
Why bother? What kind of super-secret algorithm do you have there?

Thanks;  yeah I know the JARs contain bytecode, I also know how easily these are decompiled :-)

I'm also familiar with the "why bother" argument, and actually yes I do agree to an extent. I do however feel that the more barriers we can put in place the better. We're the sort of company that's not looking to ship 10,000 units at $20 each, rather 20 units at $10,000, so investigating barriers to reverse engineering are absolutely due diligence, IMO. Basic obfuscation might deter the mildly curious, for example.

Anyway having done my own research I guess I'm just looking to the collective experience of the group here for any further recommendations, I may well have missed something pertinent that's well thought of but not prominent in search results.

Cheers

Brian

"We're the sort of company that's not looking to ship 10,000 units at $20 each, rather 20 units at $10,000, so investigating barriers to reverse engineering are absolutely due diligence"

I would interpret that the other way round - I might see some justification for protecting a mass market application, but at $10K I wouldn't bother.

There exist no effective measures to protect java code. To a certain degree you can achieve your goal with obfuscation tools as you said. However, the first analytical java decompiler is already released  (see website link if interested). In the next versions it will be able to decompile even obfuscated bytecode like it is produced by ZKM for example. So better don't waste your time and effort..

You can't really protect it. If your clients want to reverse engineer your application, they will. You said the obfuscators you searched for are not "bullet-proof". What are you searching for exactly? A "good enough" obfuscator or some other method of preventing your client from reverse engineering your code?

If I were in your place, I would host the application myself. This is the most "bullet-proof" way I can think of. Alternatively, find a tool which would convert your jar and class files to equivalent files of the native operating system (I don't really know about that...it is just a theoretical suggestion). Or migrate to .NET! (Don't take the last one too seriously). Just to show you some possible options, as I don't know your situation exactly.

@Ezani
Class files bytecode doesn't give you much clue on its own right, but it gives you all the clues you like if you use a disassembler!

I'd be interesting in knowing what you actually think the threat is - not much discussing how to secure things if you can't identify the threats and quantify their impact on your business.

Thanks for all the contributions folks.  To answer Arethuza there, I suppose our approach is one of "just in case"; we do need to install this on clients' infrastructure, and actually they'll all be corporates where such tinkering is, granted, not going to result in one of their team releasing a dodgy competing product.

That said, we do have competitors and without getting all alt.black.helicopter about things, I'm not sure I'd agree with a "don't bother at all" route. If the least we can do is make someone wade through meaningless decompiled code, then so be it.

I've come across this (ignore the .Net in the URL, the page contains a Java solution as well), which seems worth checking out:

http://www.arxan.com/software-protection-products/microsoft-NET-GuardIt/

Cheers

Brian

If the existing Java obfuscators aren't bulletproof enough, give up.

Honestly.

Even x86 machine code, even obfuscated machine code like that used in video game DRM schemes (encrypted jump tables, self-rewriting code) isn't bulletproof, as can be seen by the no-CD cracks that appear very quickly.

If your algorithms must be that secret, you're going to be forced to keep it on your own servers, or possibly on some independent device with a self-destructing ROM.  And even those aren't totally safe: unhackable smart-cards were hacked a few years ago...with a hair dryer, and burned-in-chip encryption codes can be read off with an electron microscope.

Trying to have secret code running on someone else's computer is like you want to publish a booklet of how-to directions for some process without giving away how to do it.

Totally agree with Stiver and all the rest of the posters. If it's byte-code Java, you can only do so much with obfuscators and at the Java level, if someone clever and technical really tried, I think he would get the downs-and-ups-and around of your software! The  best steps (as above) :-

1. Host it yourself

2. Encrypt the database

3. Use a native machine-code compiled alternative like C or C++ which is harder to decompile