Author: Tobias Klein
Publisher: No Starch Press
Pages: 194
ISBN: 978-1593273859
Print: 1593273851
Kindle: B00652XO2I
Audience: Would-be, White hat hackers
Rating: 4
Reviewed by: Harry Fairhead

Before you buy this book thinking that it is all about the gentle and logical art of debugging you need to check the subtitle: A Guided Tour Through the Wilds of Software Security. Published in 2012, is it still relevant?

This is a book about finding vulnerabilities in existing code. Why would you want to do this? The main reason is to fashion exploits that get you inside the software for whatever purpose you might have. The reason given by the author is that you can earn cash and kudos by reporting the bugs you have found. 

I need to say right at the start of this review that I'm not really interesting in earning money by finding or exploiting bugs. The reason I wanted to read this book was for the insight into how I might avoid such bugs in my own code. There is also a long history of books on hacking revealing really useful insights into the way that system software actually works. If you are an expert or wannabe expert on this sort of hacking, then just go and buy the book - it will fit into your personal world and ethos perfectly.

The book is composed of chapters that follow a repetitive diary format. The author outlines some bit of software that he plans to examine and some ideas about how a bug can be uncovered. He then goes on to explain what was found and how it was investigated. At the end the effect of the reported but is explained in great detail along with some follow up information.

The software covered ranges from apps to operating systems although there does seem to be a preference for media players and files. Chapter 1 explains some of the tools and ideas that are essential to the task. This doesn't go into any of the tools enough for you to make use of them. it is basically a list of apps.

Chapter 2 explains how a TiVo media format file can be made to crash the VLC player. The task of finding the bug is made easier by the availability of the source code. If you are new to this game then this is point at which you realize that finding such bugs involves endless hours of reading code, searching for data structures in files and putting it all together. 

Chapter 3 moves on to look at a bug in Solaris - again the source code is available. Chapter 4 moves back to media in the form of FFmpeg and once again the source code can be downloaded. Chapter 5 tackles the WebEx conferencing applications and this time reverse engineering comes into the picture. Chapter 6 deepens the look at reverse engineering with a disassembly of a Windows driver.  Next on to OSX and iOS in the form of an iPhone.

What you need to know is that there is a lot of information not covered by the book. First off, using the tools to disassemble and list interfaces etc is just mentioned in passing, there is some coverage in the appendices but not much; you are simply expected to know how to use them. In addition you are also expected to be an expert coder with C and assembler and to have a reasonably good grasp of the hardware. In short you need to know a lot to follow what is going on.

The thought that if you really do know this much then there are better things to do with your time kept on occurring to me. Seeking bugs in this way is a terrible waste of talent. Perhaps building some tools to automate the discovery of such bugs would be a better occupation.

The book also doesn't explain how to make use of the bugs. Once the author has demonstrated how feeding a particular file to the program causes it to crash with a particular bit pattern on the stack then that's job done. How to use such a crash to take control of the app and the entire machine is not explained - presumably for legal reasons relating to German hacking laws. There are lots of references to videos that the author has made that do explain how to exploit the bugs.

At the end of the day did it teach me to write code that was harder to hack?

Not really as the first defence is to write correct code that doesn't contain the potential for null pointers and stack overflows - which is a tough task but not a revelation. My second thought is that having the code seemed to make the task much easier and I'm still pondering the implications of this.

This is a very technical book in what it expects of its reader. It is, however, written in a conversational style that is easy to read and which covers up the hours of work that must have gone into many of the steps described. If you know a lot about hardware, assembler and C but little about finding this sort of bug then the book will be a revelation to you. However, it really all boils down to - look at the code and see if you can find potential stack overflow or null pointer, then find a way to make it happen. The difficulties are all in having enough understanding to follow through. In practice you are going to have to spend a lot of very boring time looking at disassemblies and wondering what some variable or chunk of code is all about - it doesn't sound like fun.

Finally, five year's after publication does this title still have relevance. Well things have moved on a lot so the case studies may seem unfamiliar and dated. On the other hand as it presents the code the book is self contained and the same principles apply and so does my conclusion.

If you want to get involved in this sort of work, then this is a unique insider view of how it all works.

To keep up with our coverage of books for programmers, follow @bookwatchiprog on Twitter or subscribe to I Programmer's Books RSS feed for new additions to Book Watch and for new reviews.