Dailydave mailing list archives
My review of Exploiting Software (Hoglund, McGraw)
From: Dave Aitel <dave () immunitysec com>
Date: Thu, 13 May 2004 11:16:07 -0400
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Rootkit.com isn't resolving for me today, but this is the link from amazon, whom you should not buy from due to patent issues. http://www.amazon.com/exec/obidos/tg/detail/-/0201786958/qid=1084454836/sr=8-1/ref=pd_ka_1/102-7962800-6156962?v=glance&s=books&n=507846 It was actually pretty amazing selling Shellcoder's for me, in that Amazon has 100% of the publisher's mindshare. Brick and mortar shops aren't really considered. A lot of this is because Amazon can give instant feedback to the publisher about how many books are selling, presales, etc. They've got all sorts of goodies in their system designed just to capture the attention of the publishers. None of that makes sense to do for the brick and mortal shops, so they kinda get left out in the cold. It's really amazing they're still in business, since their suppliers pretty much could care less about them, which is a bad sign. I notice that Barnes and Nobles didn't even have the author's names correct, which is a sign of how much the publisher cared about them. Amazon's website, with regards to the book, was combed over for every out of place hair. Maybe this was just a single abberation, due to personal relationships, or chance, but I have a feeling that Amazon's been able to utilize their superior developer organization to enable their sales channel to be super-resposive to the customer-base they have that is publishers. In a way, it's that crazy Microsoftian vision of having everyone running interconnected web services. If you can't hook yourself into the Bob The Big Publisher's inventory system directly then you get left out when they go to do projections. Anyways, on to Hoglund's book. Reasons to buy the book: o It has a coherent flow - it feels like it was written by one person rather than a team. One of the things that annoys me about Shellcoder's is that it was not coordinated as well as it could have been, and there are parts of it that contradict other chapters. For example, in chapter 1 or 2 of Shellcoders there's a few examples that use getesp(), which is totally bad form and should never ever ever be used. LSD can use it, because they're LSD, but everyone else should use execve() and not be so lame as to use a getesp(). Writing executable stack locals is weird anyways. But you're not going to see anything like that in Hoglund's book. o It has some great chapters on Rootkits, as you would expect. It goes into depth on trojaning ethernet cards, for example. o It has a great section on writing Win32 debuggers. Useful as a reference or as a quick overview. o It has great screenshots and examples. The code examples are great - IDA plugins, etc. It's hard to teach the tricks of using IDA to find bugs in a book, but this book is closest. o Great index. Weaknesses in the book: o It lacks some of the depth of experience that it should have. For example, the HP-UX decoder is clearly not going to work in the wild. This is a problem with having one or two people write a book of this nature - they just can't be experts at everything, and sometimes it takes an expert to really walk you through the difficulties in exploiting some of the more esoteric architectures. While this is the first place I've publicly seen the inter-quadrant HP-UX jumping explained(with really nice pictures, to boot) it's hard to say that a newbie is going to be able to succesfully use the chapter to write an overflow. How can you write a chapter on MIPS and HPUX without talking about cache coherency? Even my SPARC 5 here has cache coherency issues. (Not sure why, but CANVAS's shellcode does a nanosleep(2) to clear it, since the cache clear instruction appeared to be a nop. I'm drifting here, but you get the point.) o Not enough on Windows or heap exploitation. o "Boron" term applied to multiple concepts. Don't wanna ".Net" this by applying it to everything even remotely similar. o Overused "Attack Patterns". While patterns are useful, you don't want to lock your mind into them - a sure sign of failure in a hacker is failing to generalize more than the enemy. At this point we're into Philosophical nit-picking though. o First chapter really boring. Every time someone has the urge to define "hacker" in a chapter or footnote their editor should cut the chapter. I hope we didn't do that in Shellcoders. In Conclusion: If you're in this game seriously, you should buy this book. It has a lot of things Shellcoder's doesn't even touch on. The inter-segment jumping in HP-UX is clearly explained, which is a feat in and of itself, but it also goes into a lot of background knowledge that someone doing this professionally is going to want to know - using IDA, binary analysis, etc. The focus is, not on exploiting software, but on FINDING exploits in software and writing rootkits and trojans once you've gotten into a host. Not being seven thousand pages long, it's hardly complete, but it's well written, clear, and definately worth it. I wouldn't recommend it for someone just dabbling, though, or a base beginner that doesn't have a specific project in mind. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFAo5E3zOrqAtg8JS8RApe6AJ947mdhUcEsyDD955C1RZtxOMYJowCeL1X7 WsfrC+rxeEFktUSNAXDI1IM= =NU3U -----END PGP SIGNATURE----- _______________________________________________ Dailydave mailing list Dailydave () lists immunitysec com http://www.immunitysec.com/mailman/listinfo/dailydave
Current thread:
- My review of Exploiting Software (Hoglund, McGraw) Dave Aitel (May 13)