ACCU Home page ACCU Conference Page
Search Contact us ACCU at Flickr ACCU at GitHib ACCU at Google+ ACCU at Facebook ACCU at Linked-in ACCU at Twitter Skip Navigation

Search in Book Reviews

The ACCU passes on review copies of computer books to its members for them to review. The result is a large, high quality collection of book reviews by programmers, for programmers. Currently there are 1918 reviews in the database and more every month.
Search is a simple string search in either book title or book author. The full text search is a search of the text of the review.
    View all alphabetically
Title:
The Shellcoder's Handbook
Author:
Jack Kozi et al.
ISBN:
0-7645-4468-3
Publisher:
Wiley
Pages:
620pp
Price:
£33-99
Reviewer:
Richard Putman
Subject:
unix; security
Appeared in:
16-6
It is forgivable, looking at the main title, to think that this book is a reference for writing bash or korn shell scripts, but in fact 'shellcode' is the name given to the piece of code that is run after gaining control of a vulnerable program. Shellcode is so named because often the injected codes are instructions that will launch a root shell under unix.

If you have ever wondered about the story behind the security holes announced seemingly daily this book will show you why they occur, how the exploits work and the methods that led them to be discovered in the first place.

The book has four parts: the first hundred pages covers an introduction to exploitation on Linux x86 systems, the second hundred looks at Windows and another hundred covering Solaris and HP Tru64 systems. The third part looks at how to discover vulnerabilities with some useful tools and a final more advanced section looks at alternative shellcodes, database and kernel hacking.

There are a number of typos in the text and no errata page has yet appeared on the publisher's website, indeed the links to resources mentioned throughout the book have yet to appear either, although the example code is there for download. The text is well written and structured with a conclusion at the end of each chapter.

Much of the book is assembler, often embedded in C code, or occasionally python scripts and although there is a brief review, you should already be comfortable reading assembler, or be prepared to learn quickly, to enjoy this book.

Many of the ideas are simple - overfilling buffers that are processing user input, but the low-level nature, restricted memory spaces and unknown elements, such as where the code will be executing in memory, often create layers of dependent problems magnifying the complexity. It can take considerable skill and ingenuity to turn a vulnerability into an exploit, not to mention a certain amount of luck, unsurprisingly it is often thought of as a black art.

This book then is essentially a compendium of the techniques and resources used by several clearly experienced hackers; the aim being to teach a creative approach rather than list known exploits. What comes across in the tone of the book is the authors' desire for the reader to succeed and enjoy the challenge as much as they obviously do.

There is quite a bit of hand holding and encouragement early on to get past the point where most people give up but it is also a rich source of information with index and deserves the title 'handbook'.

For programmers who have no interest in creating their own exploits, is there anything in this book? Well yes, the section on vulnerability discovery contains interesting information about the authors' favourite tools; there is a chapter on fuzzing (generating automated test input to discover bugs in your program) and source code auditing showing many common faults in C code. However, the direction of the book is very clear - to subvert a target system.

Writing shellscripts is surprisingly good fun and the book will appeal to those who enjoy tricky programming puzzles and those who want an advanced but accessible low level security perspective on the programs they write and the operating systems they use. Highly recommended.It seems to me you should read this book even if you never intend to crack anyone else's system. You need to understand what you must protect your programs from. Francis