Decompiling Java

Richard Rodger writes with a review of Godfrey Nolan's Decompiling Java. "I've just put this book down after reading it right through non-stop for four days. I haven't done that with a technical book since Learning Perl. Most techie book these days are quickie grab-bags, and you end up paying for a lot of dead trees that you aren't interested in." Read on for the rest of his review.

Decompiling Java
author	Godfrey Nolan
pages	264
publisher	apress
rating	8/10
reviewer	Richard Rodger
ISBN	1590592654
summary	Learn how decompilation works in order to properly protect your intellectual property.

If you are interested in Decompiling Java, then this book tell you exactly how to do that. There's no fluff and every chapter counts. I can safely concur that Fiachra's observations are indeed correct. You'd better be prepared for some serious hard core details, but then that's what you'd paid for. It is really great to read a book that doesn't end each chapter with a few links to the real material because the author couldn't be bothered to write it up.

So what do you get? As a battle-hardened Java coder of not a few years programming, I wanted to find out about the gory details of bytecodes and how to get at them. Now it's a subject I always knew I should know about, but never took the time to read up on it. Decompiling Java puts all that knowledge into one place.

Here's a quick run-through of the chapters so you know what you're getting:

Ch.1 Introduction
Decompilation isn't just another coding tool - there are other, real world issues like ending up in jail to think about. Godfrey proposes a sort of code-of-honour for decompilers. This book could so easily have been positioned for the fr33ky kod3r skript kiddie market, and I'm glad that the author and publishers took a mature and sensible approach to the subject. I have had to decompile purchased code because of bugs and I'm glad that someone took the time to think about an ethical framework for doing this.

Ch.2 Ghost in the Machine
A good and solid introduction to the JVM and the classfile format. If you're in the market for this book, you probably already know most of this, but a refresher course is always good. For me, it definitely sorted out a lot on internal hand-waving on the subject. Just remember kids, the only thing to fear is fear itself - it's only binary data after all.

Ch.3 Tools of the Trade
Although the author builds his only decompiler later in the book, it nice to get a chapter devoted to the existing toolset and the Java decompiler scene.

Ch. 4 Protecting your Source
For the honest developer, knowing how to decompile code is more about protecting your own source code than breaking someone else's (who wants to read other people's smelly code anyway!). This chapter is one of the most directly practical. I had always assumed that obfuscation was a magic fix that I could apply if necessary. In reality, good obfuscation is just like good encryption (that is, uncommon, difficult to verify, and still subject to lateral attacks). Even compiled bytecode has relatively low entropy, so the value of obfuscation must be considered carefully.

Ch.5 Decompiler Design
This is were it starts getting a wee bit technical. Decompilation, as you can imagine, is a bit of a black art, and there are many ways of doing it. Some of them involve scary maths and some involve scary coding and the rest both. But that's why you don't meet many people who can write decompilers. Godfrey does a great job of taking you on a practical run through this fog of decompilers. At the end of this chapter you will be able to decide for yourself what approach is best suited to your problem domain. Again, this material can be challenging but it's like boot camp: You just gotta.

Ch.6 Decompiler Implementation
If the previous chapter hurt your brain and scared you silly then this chapter will have you weeping for joy. The author takes a practical, effective, and most importantly, understandable approach to actually implementing a compiler. Now, as he freely admits, his design may encounter difficulties with edge effects and infrequently used idioms, but it will take you to the point where you can solve them yourself. I really had to smile at how simple and effective the approach taken here is - instead of the expected multiple passes and mind bending parse tree manipulation, we have a single-pass, source-generating decompiler for Java. You won't follow it all first time, but it does work and you can verify it for yourself. Like I said at the start, you don't get that empty feeling from this book, and this chapter is pretty much why. I bought a book about decompiling Java, and now I can.

Ch.7 Case Studies
This chapter addresses the "why" of decompiling, returning again to the moral questions raised at the start. It's more food for thought than prescriptive preaching though, which again is refreshing. I have admit to dipping into this chapter while reading the rest of the book - the human interest angle always works a treat!

Of course, no book is perfect. What I think could have helped a bit overall would have been a introductory chapter to bytecode. But it's not a great loss and bytecode is actually pretty simple once you get your head around it. Still it might have lessened the learning curve somewhat.

Decompiling Java is a great addition to that section of your bookshelf dedicated to serious books that will be around for a while. The JVM specification and Java bytecode are not going to change that much, so this book is something you'll be able to use for a long time. Personally the best thing about this book for me was that it took me to the next level. Not many books can do this. As a working coder, I pretty much put things like decompilation into the "too hard, just for academics, and I could never grok it", category. It's great when a book comes along that can can you out of that comfort zone.

---

You can purchase Decompiling Java from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, carefully read the book review guidelines, then visit the submission page.

Better Java Book

[Pingular]

I've read both and I have to say Covert Java [amazon.com] is slightly more in-depth, but perhaps more for people more familiar with Java.

DJ Decompiler and JAD

[Anonymous Coward]

No Java developer should be without DJ Decompiler (which sits on top of JAD, the actual decompiler, command line only). Seriously, this book may be useful, but most people are way below needing to know any of this. If you do need to know it or are just curious, fine.

Oh, and obfuscation, blah, any good IDE (like IntelliJ IDEA) is able to help you work around this junk.

Re:Being able to decompile code....

[tcopeland]

> Is there a good reason why it doesn't?

The Java compiler does some optimization - for example, when given this code:

class Test {
int x = 2 + 2;
}

it does algebraic simplification to reduce that assignment to an aload followed by a iconst_4 instruction. And it does some constant propagation so that this:

class Test {
private static final int X = 2;
int y = X + X;
}

also gets simplified to the aload/const sequence. I guess it's just some choices the compile designers made on which things were more feasible to attack.

Books online

[truthsearch]

Most techie book these days are quickie grab-bags, and you end up paying for a lot of dead trees that you aren't interested in.

And so I suggest a service like O'Reilly's Safari Bookshelf [oreilly.com]. It includes the full text of over 2,000 technical books, many not published by them. No killing trees, far less money than buying books, plus full text search.

Jad...

[david.given]

...is pretty much the standard decompiler where I work. Alas, it's no longer free, as I've just found out when I searched for it's home page [tripod.com], but it works really well. I have, on occasion, used it as a pretty-printer for other people's code. It undoes obfuscation with ease.

I have yet to try it on byte-code produced by non-Java languages, but I'd be interested to see the results...

(It sucks that it's no longer free. The version I've got I installed through Debian, for goodness sake, years ago. Does anyone know any free alternatives that work as well?)

Re:Maintainance nightmare

[nganju]

You've misunderstood. Java obfuscation is an automated process done with a third-party tool that rearranges Java BYTECODE, not source code. The idea being that someone that tries to decompile the BYTECODE will get a bunch of spaghetti. It doesn't take any extra time or energy by the developer, just 5 seconds to run the tool on your .class files.

Sun has this info for free...

[frankvl]

Sun has put the Java bytecode specification [sun.com] online for free..

Reverse engineering in Java is as simple as the compile process itself. Besides there are already free tools available so why bother??

Re:Jad...

[cpereda_yahoo.com]

I use it too and it's still free, you just can't include it in your own product without his permission.

Re:another alternative = encrypted class files

[JavaNPerl]

I believe encryption is probably not worth the effort for most people, it's not much of a hurdle to overcome. Ultimately all custom class loader execution paths will lead to a ClassLoader.defineClass call which can either be intercepted by creating a modified system class loader or by creating a JVMPI agent which listens for JVMPI_EVENT_CLASS_LOAD_HOOK events. If you can prevent these methods from being employed then you're probably operating in a secure environment where encryption would be overkill.

Re:Being able to decompile code....

[AuMatar]

While I hate defending Java in any form, the two should be equivalent on a machine level. To see if a value is true (non-zero), you can do two things- subtract 0 and see if the result is 0, or AND it with 0xFFFF... To see if two things are both the same value, you subtract the two and check if the result is 0. The two are an equal number of instructions (and both test and cmp are quick instructions). On an asm level:

mov eax, isLoggable
cmp eax, 0 ;could also use test eax, 0xFFFFFFFF
jnz skip_if ;if using test, do a jz skip_if ;etc
skip_if: ;both branches continue here

A check to true only changes the cmp to 1 instead of 0. It won't run any faster.

Doesn't work

[lycono]

This approach to "security" in Java is so trivially easy to circumvent that its worthless.

There are a number of papers and articles detailing why this type of approach to "IP security" is so misguided. One such article is here: http://www.javaworld.com/javaworld/javaqa/2003-05/ 01-qa-0509-jcrypt.html [javaworld.com]

The crux is that at some point in time, you have to deliver the encrypted class to the JVM in an unencrypted format. Intercepting this delivery is incredibly easy (no expert knowledge required, the details for doing so are detailed in the article above), at which time someone can just write the unecrypted class file out to disk (or wherever they wish). Voila! All your IP are belong to us.

Nothing beats decompiling hacker code...

[RZ-1]

that was aimed to foil decompilers.

Its starts off with public variable names like:
public int YOU_DECOMPILING_NOOB =-1;
public int NO_SKILLZ_4U=100;

and then the obfusticator kicks in:
where a1 and al(with an L) are switched around.
The variable and method names look similar.

if (a1.b1.x.y == al.b1.xl.y2){
a1.v1.x.y &= al.b1.x1.y2 >> 0x4c;
a1.b1.x( al.b1.x2 );
}

Ouch! Also, I think every decompiler has some weaknesses and isn't able to undo all code. I know Jad has some limitations. Unfortunately, I wasn't able to get the source of the code that broke the decompilers ;)

Re:Better Java Book

[Pingular]

'Fraid I don't have both of the books to hand at the moment, but have a look at these reviews/book descriptions if you like:
Decompiling Java:
Writing for those who want to learn Java by decompilation, Nolan, a specialist in web site optimization, explains how to turn partially compiled Java bytecodes back into source code so that readers can see what the original programmer was thinking. Early chapters unravel the Java classfile format and show how Java code is stored as bytecode and executed by the JVM. Later chapters focus on how to write a Java decompiler, and a final chapter offers case studies.
Both Java and .NET use the idea of a "virtual machine," or VM. And while VMs are useful for some purposes, they undermine the security of your source code, because creation can be reversed, or "decompiled." Which makes this one-of-a-kind book extremely useful: you must understand decompilation, to properly protect your intellectual property.
For example, how secure is your code after you run an obfuscator? The book will answer questions like this, and provide more thorough information about Java byte codes and the Java Virtual Machine (JVM) than any other book on the market. This book redresses the imbalance by providing insights into the features and limitations of today's decompilers and obfuscators, and offering a detailed look at what JVM's actually do.
This is a fantastic in-depth book on decompilers and code obfuscation tools for Java. It covers the structure of Java code files, the opcodes, and the all of the tools required to decompile classes, and to obfuscate existing code. It's an invaluable reference for anyone who has to deploy Java in a non-secure environment, or for those that want to learn how the language really works.
There is a lot of code to pour though, and there are no illustrations. I think the text could have used some illustrations, but that's not a big sticking point for me.
If you are a serious Java gearhead you should have a look at this book. And if you have a specific interest in either de-compiling some Java or obscuring your deployed Java bytecode then this is a must have.
Covert Java:
"Covert Java" provides a fascinating and look at behind the scenes Java development tactics that are usually the domain of seasoned veterans. Definitely a read for those who want to master Java.
--Floyd Marinescu, Author, EJB Design Patterns; General Manager & founder of TheServerSide Communities.
As a Java developer, you may find yourself in a situation where you have to maintain someone else's code or use a third-party's library for your own application without documentation of the original source code. Rather than spend hours feeling like you want to bang your head against the wall, turn to Covert Java: Techniques for Decompiling, Patching, and Reverse Engineering. These techniques will show you how to better understand and work with third-party applications. Each chapter focuses on a technique to solve a specific problem, such as obfuscation in code or scalability vulnerabilities, outlining the issue and demonstrating possible solutions. Summaries at the end of each chapter will help you double check that you understood the crucial points of each lesson. You will also be able to download all code examples and sample applications for future reference from the publisher's website. Let Covert Java help you crack open mysterious codes!

Why read a book. Just download Jode

[JPyObjC Dude]

I have been decompiling Java regularily. Just get Jode Jode [sourceforge.net] Its very simple and effective. As long as the writers are not using ubfuscation tools, the code is fully readable in it's original form sans commenting.

Re:on this topic, does anyone know how to:

[pcal]

• View source of the html page that contains the applet
• Find the <applet> tag for the applet. This will tell you how the classfiles are getting loaded.
• In the typical case, the applet will be packaged in a jar which is referenced in the 'archive' attribute of the tag. Download this and decompile away.
• If the tag only specifies a 'codebase', you may have to download individual classfiles from the webserver yourself.
• For more info, details on the applet tag are at:

http://java.sun.com/docs/books/tutorial/applet/app letsonly/html.html [sun.com]

Re:Jad...

[posisoft]

DJ is 'only' a JAD front-end

Re:This is one of the features of Java

[johnmckeon]

You can't arbitrarily get at source code on someone's web server. Do you think eBay would want you seeing the passwords to their database servers?

I think he's referring to an old bug on IIS that would allow you to view the contents of a file on the server. I believe it was a sample ASP that MS included to demonstrate come capability of ASPs.

I'm sure there are a few servers around that still have that enabled, but I'm sure most had that thing fixed 3-4 years ago.

Good obfuscation WORKS

[JavaRob]

The simplest version of cracking a Java program is using JAD to decompile the source, making a few changes in source (like changing the license check to always return "full enterprise version" instead of "time-limited demo"), compiling your altered class, replacing it the JAR, and running the app.

Most obfuscators will make this track impossible, by doing things like using language keywords (while, for, if, and so on) for class/method/variable names, so that when you decompile the thing it cannot be recompiled. They also mix stuff around in the classfile enough so that figuring out what method is doing what becomes non-trivial -- stupid things mostly (like naming methods l1(), ll(), I1(), Il(), etc.), plus a few tricks to stop JAD from fully decompiling the class.

Enough of these little things add up to make the work involved in altering the decompiled class excessive and difficult.

The more sophisticated Java cracker doesn't bother. They decompile enough source to get their bearings, then edit the appropriate bytecode directly, with a classfile editor. Fortunately, most people with this level of experience can just pay for the frickin software they want.

I'm actually not obfuscating my Java code yet, but I'm going to start... it's just too easy to crack Java code without it. yGuard obfuscator [yworks.com] is pretty decent LGPL one, that can run as an Ant task.

Re:no bytecode intro?

[pjt33]

More details aren't hard to find: the JVM specification [sun.com] is fairly readable and available from the Sun website.

Re:Doesn't work

[r7]

> "security" in Java is so trivially easy to circumvent

Are you confusing encryption with obfuscation? If not I agree that class-level encryption has no ROI.

Obfuscation, on the other hand, is an excellent tool for protecting IP. I use Proguard http://proguard.sourceforge.net/ [sourceforge.net] via Ant and am happy with the result, having tried to grok the resulting byte code (using jad...) Good luck trying to work with that!

R7