Book Reviews

The following book reviews are the copyright of their respective authors and no part should be reproduced without the express permission of the author. Publishers and Authors of the books reviewed may reproduce the whole or extracts of a review for their book. To request copyright permission please email

All the reviews herein are the opinions of the reviewer and are not necessarily the views of Birmingham Perl Mongers and its members. If you feel a review or comment has been made in error, please contact to rectify the situation.

Other Books

Static Link:

Exploiting Software - How To Break Code
Title:Exploiting Software - How To Break Code
Author(s):Greg Hoglund & Gary McGraw
Publisher:New Riders
Reviewer:Bob Wilkinson

This book covers some of the reasons why computer are vulnerable to attack, with the reasonable premise that to be able to avoid attacks, it is necessary to know how they are implemented. I have developed on internet-facing applications for more than 5 years, and so have some prior knowledge of the subject area.

The introductory chapter, "Software - The Root of The Problem", discusses broadly the range of problems which can be encountered. The history of software is chronicled. Examples are given of broken software which has been written, used, then exploited. Future trends in computing are also predicted.

The next chapter, "Attack Patterns", did not tell me much which isn't fairly common knowledge. Terms are defined, a simple buffer overflow exploit is explained, and an exploit to work around Microsoft's C++ compiler is described.

The "Reverse Engineering and Program Understanding" chapter, gave some useful examples, though most of them involved the use of the IDA debugger under Windows (aside: this will run under Wine on Linux too). This chapter did give me a few hints, and I would probably refer to the book were I starting to use one of the debuggers mentioned.

The next three chapters, "Exploiting Server Software", "Exploiting Client Software" and "Crafting Malicious Input", all focused on the software which is most prone to attack, that which presents a public-facing interface. Reading the chapters gives a good insight into the nature of potential attacks, and will aid the developer in knowing what assumptions to avoid. Exploits against Solaris are studied, and then various means of exploiting a wide range of server software are described. There were 4 consecutive pages of (some of the) entry points in to various Microsoft DLLs, which I didn't really appreciate. Some of the examples given in "Crafting Malicious Input" are more interesting, though there is little depth.

The next chapter, "Buffer Overflow", covers the most well-known class of exploits. Much existent code contains these programming oversights. A thorough discussion of the problem may yield fewer in future, though writing code in languages with more programmer-friendly memory management than C would probably eliminate most of them. The chapter is 90 pages long, and discusses the problem quite deeply. Buffer overflows on a number of different systems are analysed.

The final chapter is entitled "Rootkits", and discusses what they are, and how you might detect if your computer system has been infiltrated. Attacks against various hardware components are mentioned, and an analysis of removal of security from NT is lengthily covered.

The book is 453 pages long and the typeface is large, which always worries me a little. I can find no factual fault with any of the information, and noticed very few typographical mistakes.

Yet, while superficially impressed, I didn't feel that once I had finished the book, that I had learned a great deal. I didn't like the 3 or 4 pages of code examples, which are of little benefit unless a similar solution on the same platform is required. I found the writing style not bad, but not particularly engaging.

I would hesitate to recommend it, unless as an introduction to reverse engineering. There will be people who can learn from some of the chapters I didn't enjoy much. I wouldn't say it was bad, it is just that I think much of the information is covered elsewhere, and probably better.

Bob Wilkinson, 2004-05-21