Customer Reviews

Decompiling Java

5 star:		(5)
4 star:		(1)
3 star:		(1)
2 star:		(2)
1 star:		(1)

 

 

What I hoped to learn from the book was an understanding of modern Java decompilation techniques. With respect to this expectation, Nolan's book is a disappointment.

His implementation, though simple, will decompile only the most simple of byte code. Nolan points out that it is difficult to recover all legal control structures offered by Java, but is not so clear about the fact that this will never be possible with his approach (i.e. using syntactical analysis).

A stable decompiler which is able to produce clean code must do some control flow and structural analysis. The book gives no account here.

Regarding the other topics of the book such as obfuscation, legal issues, tool selection and case studies, there are more concise and cheaper books. Simply refer to Amazon's "Customers who bought this book also bought ...".

Decompilers are something of a black box to most programmers. Not unlike compilers. Actually Nolan shows us that the 2 are very similar in their lexical methods.

In the specific case of Java, this book may well cause unease in the reader, if you program in Java and are worried about protecting your source code. After all, it probably has proprietary methods that are not covered by any patents you might have. While you can copyright the source, Nolan points out that this may not stop someone from decompiling and reimplementing your "secret" methods.

The book shows that the big problem with Java bytecode is that decompilers for it have a far easier time than decompilers for actual assembly code, whatever the specific hardware for the latter. The basic reason is that the bytecode retains extra information that a decompiler can use, whereas assembly does not have this. Like the fact that the bytecode separates data from instructions. A vital simplification to a decompiler.

Nolan shows countermeasures. At the source code level, there are several good obfuscation techniques, described well enough for you to try. And these may be better than buying a commercial decompiler.

Also, Nolan suggests fully compiling your Java into specific assembly binaries. One for each combination of microprocessor and operating system that you need to support. More work. But it makes a decompilation far harder. Besides, these days, you may only have to support a few combinations. The hardware may be a Pentium or a Sparc or an IBM cpu. If a Pentium, then you might only support a recent linux or Microsoft OS on top of it. If a Sparc, then you need only support a recent Solaris. While for an IBM cpu, the only choice is AIX or Apple's OS.

If you're looking at a book on this topic, you may know something about the subject already. You even may have used one of the various decompilers available on the web, perhaps been shocked at the accuracy of the results, and were left wondering a) how it worked and b) how to stop it. You get coherent, comprehensive answers to both. There are three kinds of books about computer security: those that detail the exploitation of weaknesses, those that detail how to fix them, and those that do both. Decompiling Java manages to fall in that last category, so far as its possible for inherently insecure Java code.

Over the course of seven long chapters, Nolan discusses in depth the history of decompilation and reverse engineering (both the legal and illegal kinds), the construction of the Java Virtual Machine, the layout of Java classfile, the various types of obfuscation and code protection techniques (including the creation of a simple obfuscator), and, most importantly and uniquely, the design and implementation of an original decompiler. The book ends with a briefer discussion of a number of case studies.

There's always a danger that hardcore computer books will be deadly dull; thankfully, that's not the case here. The style is light and often amusing. The most difficult chapter is the one detailing the implementation of the decompiler -- it's an especially information-dense chapter that I had to take a few pages at a time. On the other hand, the chapter does show bit-by-bit the construction of a working decompiler, so I suppose it was worthwhile.

If you're interested in writing your own decompiler or in looking at the techniques the existing ones use, this is the book for you. Similarly, if you're interested in developing your own obfuscation solution or selecting in an educated way between the commercial obfuscators and code protection schemes out there, this book discusses them in greater depth than any other resource. Finally, if you're just a low-level software geek like me, you'll find plenty of interesting concepts and ideas to chew over.

"Decompiling Java" is an interesting piece of work. In just 250 or so pages, you'll go through legalities related to decompiling Java code, learn the basics of Java's class file format, get a brief run-down of tools available for decompiling and obfuscating Java code, all the way through different methods employed by obfuscation tools. Finally, Nolan goes through the design of a basic Java decompiler implementation using JLex and CUP open source compiler compiler tools.

The brevity of the book is both its best and worst characteristic. It's great because I certainly wouldn't have wanted a bible on copyright and patent laws in different parts of the world, but it's unfortunate because the topic you're interested in is bound to be slightly too superficial or detached from the rest of the book. For example, I would've liked to read a lot more about the actual class file format and the internals of a JVM in the book itself instead of having to read from a specification on the web. On the other hand, the author managed to light some bulbs in my head along the way and I actually enjoyed reading his text - especially the chapter about creating a decompiler using JLex and CUP (which I've also found a bit too intimidating to actually look into).

In summary, "Decompiling Java" is a good overview of decompilation in Java and it has a couple of real gems inside, but if you're looking for a manual for dissecting class files or the JVM, it might not the book you're looking for.

This book starts off with great promise. There is a historical survey and a survey of available products. Then the Java equivalents of Lex & Yacc appear and you start to wonder if the author has accidentally set out to write a compiler rather than a decompiler. Strangely but truly, these tools are used to build an ultra-simplified decompiler for some subset of Java. It can't handle much more than straight-line code. Sure, it'll do loops. Sort of. But just add a "break" statement and you'll break the decompiler. How about exception handlers? Nope. Oh well. See other reviewers' comments on how it pushes-and-pops strings. No flow graph is ever built. No abstract syntax tree. If you've read a compiler textbook, you know more about the subject of this book than the author does. (IIRC, he admits this in the text. As another "reviewer" pointed out, the author was a journalist before becoming an expert on decompiling. You do the math.)

I think the author learned a lot by writing this book, which is great. And it's great that others can learn the basics from it too. But in the overall scheme of things, this is like a high-school course in decompiling. (Arguably, you could call it 'Decompiling 101' but that would mostly be rhetorical.) Someone interested in this obscure topic is likely to want to dig deeper than this book can go ... say, to be able to decompile some actual Java code, not just simplified examples in a subset of the language.)

I was tempted to give this book one more star because it's the only mass-market book on the subject of decompiling. But I was also tempted to give it one less star on the basis of its content. So it's somewhere between 1.5 Stars and 2.5 Stars. YMMV.

Better suggestions include buying the following from Amazon:
- Books on the Java Virtual Machine by Bill Venners and Joshua Engels.
- Books on decompilation and reverse engineering: "Covert Java", "Reversing".
- Books on optimizing compilers: there are lots of these. On that is particularly relevant is Steven Muchnick's book because includes a section on Structure Analysis ... those half-dozen pages (with code) get you a heckuva lot closer to a real decompiler than the one developed in this book.
- Online documents: Christina Cifuentes' thesis, papers by Laurie Hendren's group, etc., etc.
- The open source java decompiler, Jode.

Go Forth, and Reverse!

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.

This is indeed (as other reviews wrote) a nice book about decompiling Java if you want to know how to write a very simple decompiler, but you need to keep in mind that the author uses a HORROR design/implementation.

The problem is this:

* You can download the sourcecode from the publisher website (so you can check my critism below yourself), but this code even doesn't have a license somewhere in the download archive!! Mr. Noulan seems not to be a pro.

* The author introduces a Class to XML converter, and tell the reader that the XML is the intermediate language. The problem is that in normal compiler design the intermediate language add something (else it's useless), for example the Intermediate language can be independ from the source language, but the Class to XML converter does not. It is just an another representation of the same data so it can be omited (but yeah it looks cool, saying that your compiler does something with XML) Maybe the author want to ride the XML 'hype'?

* The author knows how to write a simple Java decompiler, but he don't know how to write nice Java code. For example he uses different stacks in the decompiler, but he only pushes and pops strings from/on it. He then parse the string to retrieve the data he need (if the string contains integer, he parse the integer). As a result his sourcecode is filled with .toString() calls to create the string and .indexOf, substring, etc. to parse it back later (and he assume this always goes OK). What a mess. Has Mr. Nolan ever read a real compiler design book? If he did, he would choose to use a AST Tree. I need to make a note: maybe this String mess was needed to keep the code size (for printing in the book) small.

* The String mess is one thing, coding the whole compiler directly in the entire CUP parser file is something else!! What a great professional design. NOT!

So this is a nice book if you want to know something about how a decompiler could look like, but please don't use his ideas ever in a real (de)compiler!

I've just put this book down after reading it right through nonstop
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.

Well, 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
becuase the author could 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 afor 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 schene.

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 elses (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 deocmpilers. Godfrey does a great job of taking you on a
practical run through this fog of decompilers. At the end of this
chapter you wil 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!

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.

The book lacks focus, cohesivness, and has an awkward style which caused me to lose focus reading it. It feels as though it was written during Java's infancy, and somehow shoehorned into the current Java vernacular. I'd recommend "Covert Java" by Alex Kalinovsky instead.

I do not believe (previous review) that: "The book lacks focus, cohesivness, and has an awkward style which caused me to lose focus reading it."

I used to commission articles from Godfrey Nolan for Ireland's leading daily newspaper. At the time, I co-edited its computing and communications section.

Godfrey's copy was always well-presented - something any editor values. Not only was it free of spelling and grammatical mistakes, it was also:

* Tightly written, with no waffle;
* Clear and readable;
* Well-structured, with a strong, attention-grabbing lead and an inverted pyramid build-up;
* Accurate and perceptive.

So, I would be very surprised if this book did not share these strengths.