Fog Creek Software
Discussion Board




Decompiling .class files. Is it an issue?

Well, that's the question, I am curious to know:

1) How good java ofuscators and java decompilers are? Who is winning the battle? Who will win?

2) Are there developers who really do care about it? And get so worried that it makes them say something like "Hey, wait a minute! Let's go to other developing language: I do not want my source code being so easy to get for curious/crackers"? Or, in real world, this is not even a thought (not considering paranoiacs)?

Ross Sampere
Tuesday, June 08, 2004

Security through obfuscation is always a bad idea. 

To relate a personal story, I once ran into a bug using a 3rd party MS-SQL JDBC library (a pretty popular one at that).  Using a free Java decompiler, it was pretty easy to go find the bug and email the company, pretending I hadn't decompiled their software but instead sending them code examples of how to reproduce the bug, and innocently saying "gee, I don't know why, but it kind of seems like it's not calling RecordSet.Close()..."

While I was in there, it also became pretty apparent where there licensing security was.  And how to circumvent it.  And mind you, this code was obfuscated.  All the classes, methods, and local variables had had their names reduced to "a" or "b" where possible.

The lesson here is that obfuscation is a good deterrent, because for 5 minutes of your time, you cost your would-be cracker many extra hours of deciphering.  But it is *not* security, and it won't stop people from pirating your software or reverse engineering it for their own purposes.

So yeah, it's an issue, depending on what you're writing and who your target audience is...having said that, I wouldn't stop using Java or .NET because of it.  But you do have to be aware of the risks, especially of storing sensitive information (like encryption keys, etc) in client-side source code.

Joe
Tuesday, June 08, 2004


I have decompile numerous Java programs.  Many come across pretty cleanly, others are a pain in the...


Anyway (and this is an idea that I'm trying to convince my coworkers of), as a software developer, I make a point of *not* stealing other peoples' code, info, ideas, etc.

I figure that if I want people to buy my ideas/code instead of stealing them, I should do the same.

KC
Tuesday, June 08, 2004

The nice thing about a Java decompiler is that you can get the tokens translated back to Java (and english) so you can really see what is going on inside the code.

Some posts have pointed out this is really the only way to learn how to do stuff.

The problem with decompilation (besides the piracy and trade-secret problem) is that much of the detail that you need to understand WHY the code is done that way is left behind in the comments, and in the names of things, which can be obfuscated.

So a decompiler can't tell you the whole story, most times.  I don't know at this point if that is enough to protect trade secrets.

AllanL5
Tuesday, June 08, 2004

Is there a good java to native code compiler out there?

the artist formerly known as prince
Tuesday, June 08, 2004

Just to be clear, I wasn't advocating cracking software :)  Just that you have to take your target audience into account when doing things on the honor system.

Of course there are also laws in place for this kind of thing.  Generally, if someone reverse engineers your software, and uses it maliciously against you or otherwise breaks your licensing agreement, you can and should sue their pants off.

Joe
Tuesday, June 08, 2004

Obfuscators work rather well.  Renaming all class names with xyzzy like syntax and methods with similar makes reversed engineering very difficult.

Now, if you were looking for a method which accessed some device driver (like talking to a security dongle), this would help very little.

The main point of obfuscation is to make sure that someone doesn't make your code theirs.  Its also a minor pain when trying to export objects and interfaces for others to use.

hoser
Tuesday, June 08, 2004

To answer the original question, yes, the fact that Java exposes your code is an issue that ISV's quietly take into account.

Of course, the more important issue is the poor response time, and that generally overwhelms the other. Nevertheless, code exposure sits right there at the Number 2 spot.

isv
Tuesday, June 08, 2004

"Obfuscators work rather well"

Yes, they work well at obfuscating code.  But I disagree that they make reverse engineering "very difficult."  At best, they make it "less easy."

Joe
Tuesday, June 08, 2004

Add 10 layers of stuff that makes things "less easy", and all of a sudden you're at "very difficult".

I have a four character PIN attached to my debit card, for security. Pretty lousy security eh? And none of those characters are letters! Just numbers!!! Can you imagine that eh?

Edward
Tuesday, June 08, 2004

I've been wondering how most people ship web products based on scripting languages, say like PHP.  Do they just not bother obfuscating the code?  Anybody know what fogbugz does?

christopher baus (www.baus.net)
Wednesday, June 09, 2004

http://www.joelonsoftware.com/articles/fog0000000026.html

X
Wednesday, June 09, 2004

Edward...we don't have 10 layers.  We have 2.  1 is to decompile the code, which any 13yo can do w/ the free software that's out there.  The other is to sift through the obfuscated code, which takes some extra time, but isn't exactly rocket science.

Also, we're talking about client-side software here, where the bits are readily available.  The difference with your ATM example, is that you have both a hardware token that only you possess, and a secret key that is not written anywhere on the associated ATM card (even if it is only 4 digits).  So the combination makes it pretty safe...  You just can't do that in software (well, you can use a hardware dongle, but clearly that's impractical for most applications).

Joe
Wednesday, June 09, 2004

> I've been wondering how most people ship web products based on scripting languages, say like PHP. 

There's not much they can do. On the other hand, server products are usually necessarily exposed to the world, so it's easy for infringers to get caught. That is, where the server product is expensive to buy.

isv
Wednesday, June 09, 2004

There are a couple different types of obfuscation, some of which are vastly more effective than others. The simplest kind of obfuscation, which has already been mentioned, renames all of the class/method names and turns them into nonsense, like "aaa.bbb()".

That's somewhat effective, but the problem is that you can still decompile the code into it's original structure. The variable names are ambiguious, but it's not impossible to figure out the code.

A much more advanced form of obfuscation actually moves around the class's bytecode instructions. So, normally, a decompiler can recognize patterns in the bytecode. When it sees a certain pattern it says "Aha! I found a for loop." or "Aha! I found an if-else statement." Decompilers use pattern recognition algorithms to regenerate the source code. There are a few obfuscators on the market which actually peform transformations on the instructions in the bytecode, making it incredibly difficult for decompilation software to recognize the patterns anymore. In these cases, the decompilers usually either emit incorrect code, or they quit trying.

Then again, a persistent hacker could dig right into the binary class files and monkey around with the instructions themselves. But it's hard to get a big picture for what's going on in the code if you're looking at obfuscated symbol names _AND_ rearranged bytecode instructions.

Usually, it's easier just to write your own code at that point.

Benji Smith
Wednesday, June 09, 2004

I nearly forgot....there are some obfuscators which encrypt all of the strings in the source code, decrypting them at runtime.

They don't use strong encryption, so the decryption is pretty efficient. And they don't NEED strong encryption because the main point of encrypting the strings is so that a hacker can't just grep the binaries for the words "license" and "registration".

Benji Smith
Wednesday, June 09, 2004

*  Recent Topics

*  Fog Creek Home