Decompiling Java 221
| 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 IntroductionDecompilation 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.
no bytecode intro? (Score:4, Interesting)
another alternative = encrypted class files (Score:5, Interesting)
the details of the paper are:
1999 - Security in Set-Top boxes
European Multimedia, Embedded Systems and Electronic Commerce
EMMSEC '99, Stockholm, SWEDEN
June 21-23, 1999
COPY: (pdf)
http://www.ardiri.com/publications/emmsec9
there was a lot of interest on this topic back in the time
Being able to decompile code.... (Score:5, Interesting)
Anyhow, decompiling the classfile with "javap -c" shows that a couple of instructions get eliminated by dropping the explicit comparison to "true". So the classfile gets smaller, it loads faster, and (unless the JIT compiler is smart enough to do constant propagation on that conditional) it'll run faster, too.
Re:Being able to decompile code.... (Score:1, Interesting)
java obfuscation (Score:1, Interesting)
I find that since everything resolves to a native call you can usually figure out what a coder is doing pretty easily.
In my experience most obfuscation programs are actually used more often then not for reducing code/class sizes and improving efficiency slightly.
Re:What ethical problems? (Score:5, Interesting)
While you are welcome to your delusions, but out here in the real world we have some things called laws. Specifically the Uniform Commercial Code and the Copyright laws.
You will note that I excepted commercial licenses, since those are actual signed contracts and are legally binding.
According to the Uniform Commercial Code if goods are exchanged in regular trade there can't be strings attached; i.e. if it looks like a sale it IS a sale. If I buy a copy of Microsoft Windows from Newegg.com I did just that, I BOUGHT a copy of Windows. That means I can do anything with that copy, including read it. I can even copy it in whole or in part so long as such activity falls under the backup exception written into the law or by Fair Use. Of course any other reproduction is forbidden by the artifical monopoly rights granted to the author by copyright. While I have a lot of problems with how copyrights are currently operated (eternal instead of "limited times" as prescribed by the Constituition) I don't have a major problem with that limitation.
But think about it, what you are saying is that you can sell me a copyrighted work that I am forbidden to read myself. What a load of fetid dingos kidneys! Ford can't forbid me from taking apart a Caddy and not only making, but SELLING plans; but you think your algorithms are so freaking special that you want the government to put me in jail for the crime of reading them? What are you smoking?
Re:What ethical problems? (Score:2, Interesting)
Sure. I was thinking of this as an example when I wrote my last post. I could write a book, and say to you, "Here's my book, it's $5, but if you buy it you can't read chapters 3, 7, or 9." And I'd have no problem with that. If you don't want to pay money for a book whose full contents I say you can't read, then fine - don't buy it. But don't buy it, knowing what terms I've laid out, and then whine later on down the road.
As I stated before, I am 100% for allowing folks to make transactions that they mutually agree upon. If you want to decompile software, buy software that doesn't contain such provisions against decompilation. What's wrong with that?
Re:This is one of the features of Java (Score:2, Interesting)
Why? Well, Java bytecode is a lot more flexible than the Java language. Take exceptions for example. In the language we handle exceptions with try-catch-finally grammar productions. But in the bytecode we have a table that specifes ranges of bytecode addresses that mapped via an exception to a exception handler. The cute thing is that a "range of bytecodes" has nothing to do with control flow; control flow and weave in and out of the range, no restrictions. The handler can even be in the range. And yes, I have seen this happen as a cosmetic bug from a java compiler. But the decompiler has to produce a set of nicely nested grammar productions. Anyway, a range != a try-catch
So even a little automatic tweaking could defeat most of the decompilers out there.
Lots of languages produce Java bytecode on back end as well. Some of the output from these are pretty bizzare.
Re:Maintainance nightmare (Score:3, Interesting)
I had to decompile and patch a ridiculously buggy JDBC driver for a commercial database which had been run through an obfuscator, and ran into that issue. Renaming was rather a hassle, I must say.
I came to the conclusion that they had obfuscated their driver out of shame at the embarrasingly bad code, rather than to protect any intellectual property therein.
Re:What ethical problems? (Score:3, Interesting)