Book review: Rootkits by Hoglund and Butler

I've just finished reading Rootkits: Subverting the Windows Kernel. Overall I enjoyed it but I'm in two minds about its usefulness...

The book covers "hacking" the Windows kernel using various techniques to get your code inside the kernel and, once there, various other techniques to keep others from knowing you're there. Once you have this kind of code in the kernel of someone's machine you can do lots of damage; or, of course, you can gather information for security forces, or protect the machine from other rootkits...

The book doesn't come with source code but instead refers to real rootkits that are available for download on The subject matter is very interested and quite a few times I found myself thinking "wow, if the virus writers start doing this on a large scale then we're in big trouble". I guess that's the point of the book. It can be read at many levels and there's enough information in there to scare a manager into taking security more seriously... I liked the way that the code and concepts were presented. It's not a "for dummies" book, it doesn't hold your hand, it skims through the "tricks" and techniques at quite a fast pace and if you wanted to write your own rootkit then you'd have to put in a lot more work to do so; which is good... My virus checker instantly spotted the exe signatures of the rootkits that I built from the source on the web site which makes them safer for use as study aids... Overall the book feels a lot like the old style "cook book" coding books that I used to read when I was first learning C; there are lots of little techniques that you can take further. This book just whets your appetite.

Chapter one explains the hows and whys of rootkits. If you have code in the kernel you can manipulate what the kernel reports on its internal status and thereby hide your presence. Don't want your process to show up on the task list? Just monitor the calls that taskmon uses and remove your process (and remember to add the process time to some other process..) Don't want your log file to be discovered? Just subvert the filesystem and hide that file. Etc.

Chapter two builds a simple driver and shows you how to load it into the kernel. This is quite a good intro into building a driver and getting the environment set up. Once we can load a driver the next thing to do is hide the driver inside the loader executable as a resource, the idea being that one file is easier than two...

Chapter three presents a quick intro into the hardware. It covers the x86 access control concepts, memory pages, address translation, descriptor tables, call gates and interrupts. This is background reading for the next chapter...

Chapter four covers hooking API calls. It starts with hooking in user mode, something that is well documented, and moves on to hooking in kernel mode, something that is far less well documented. The details on user mode hooking can only really be considered as an overview, if you're interested in this stuff you should continue with Programming Applications for Windows by Jeffrey Richter. Next we move on to kernel mode hooking. This is the kind of thing that the SysInternals Regmon and Filemon tools use to do their work. There's more detail here, and sample code and a link to a downloadable example that hooks the kernel and hides processes from task manager. Next we're hooking interrupts, and finally we're hooking other drivers; again there's more sample code.

Chapter five covers runtime patching. We're now into the realm of direct binary modification of the code that runs. This is the kind of stuff that crackers may use to avoid your copy protection (I expect I just hosed this articles Google ads with that ;) ). The chapter covers how to locate the function call that you want to patch when it's not exported by looking for unique bytes in the function signature and how to safely patch in a detour to your own code. Once again there are source examples to download.

Chapter six deals with layered drivers; the Windows driver model is very flexible, allowing drivers stacks to be built by layering one driver on top of another. The stack processes the request and each layer can modify the request, or response, if it wishes to. This chapter features a detailed explanation of how to craft a keyboard sniffer. This is a non trivial project and the code and commentary includes lots of hints and tips that would be useful for writing more legitimate drivers. Next we're on to file filter drivers and it's at this point that I feel the book loses its edge. There's no code to download for the file filter driver and the discussion is more theoretical than the keylogger commentary. There's more code in the text but since you can't grab something that runs it's less use as a learning aid, IMHO.

Chapter seven talks about direct kernel object manipulation. API hooks are relatively easy for anti-virus and rootkit detection programs to find. If you don't want to be found then it's "better" to modify kernel data structures directly... There's an example of hiding a process by removing it from the kernel's list of processes. Examples of increasing a processes' access rights and adding SIDs to a process and examples of faking the Windows event viewer. This chapter was less interesting to me as I'm not actually interested in using this knowledge for devious reasons and this stuff had less legitimate uses, IMHO.

Chapter eight covers hardware manipulation. We're into the realms of modifying the firmware on a network card, or hacking the BIOS. Most of the coverage is from a very high level, though we do drop down to some code examples for accessin the keyboard controller directly. Again I wasn't especially interested in the subject matter.

Chapter nine deals with networking and provides some examples of accessing the network from within your driver. Starting with TDI we're shown how to use the TCP/IP stack from within a driver. Next we're on to raw sockets and finally we look at writing our own NDIS protocol driver.

Chapter ten is a, relatively slim, chapter on detecting rootkits. It suggests how to find out if there's something hiding in your kernel by looking for hooks and modifications etc. I think, perhaps, this would have been better if it had been presented alongside the 'how to hack' information, rather than as an afterthought at the end.

The book's a good read. If you are interested in doing bad stuff then you've probably already found much more information on the web, but this stuff is presented in a "cook book", tutorial style, and you can read it in the bath ;). The book is useful even if you have no interest in writing code to subvert the Windows kernel. It has lots of interesting stuff in there and, if you're interested in writing drivers, it's a bit easier to get into than the "normal" driver writing books; it's less formal and gives a whirlwind tour through what's possible rather than providing a solid description of how to do it properly. Due to the fact that the goal of the book is not to teach you how to write a device driver it gets to touch on lots of interesting snippets. From a security perspective the book is certainly an eye opener. If you're in the business of computer security you have to understand this stuff to stand a chance at being able to protect yourself and your clients from it.

If you have a Windows system, you'll probably want to run this now...



Just in case you're looking for something small to program on your journey into Windows kernel programming... How about a driver to allow sniffing of IrDA traffic? I think it'd be an NDIS 'shim' (do they call it an Intermediate driver?) that would sit in the IrDA stack and pass all frames up to a user-level program.

Without a software sniffer it's a real pain when troubleshooting or investigating IrDA comms, for instance when trying to work out what's at fault here, or with the two issues here One has to use an extra serial dongle and also restrict the comms to 9600 bps--as it’s a pain to handle the bit rate change, or above 115.2kbps impossible. I can handle the user-level app, maybe including a port of Linux's irdadump, but know nought about kernel-level coding.

I can't guarantee it'd be as popular as your Bluetooth post, but /I'd/ be eternally grateful. :-)



Is it something you'd pay money for?


Thinking about this some more. If the IrDA is a network driver can you not use Ethereal to look at the frames in the same way that you would with ethernet traffic? The Ethereal faq mentions that it supports both IrDA Link Access Protocol and IrDA Link Management Protocol.

Leave a comment