That's pretty disappointing to hear since I've already ordered this book and the only instance of Windows I have is a VM that I use for browser debugging. Given the chance I'd probably still buy it, but now I'm not as excited about it getting here.
Windows has a debugging interface? toolhelp, drwatson and the debugging "api" are a joke. Everyone does debugging by circumventing the OS, hooking system calls and patching "protected" memory. Windows debugging is a messy witch-craft, so much so that everyone stood in awe, helpless and hapless when Rustock.C struck; a fine piece of malicious engineering that becomes part of the OS, a rootkit's rootkit that's gotten rid off only by disk formatting and a fresh install :-)
A comment like this makes me think you've never used the Win32 debugging interface or ptrace().
Win32 has one of the nicer debugging interfaces I've worked with. It's a well-documented syscall-level interface to sign up for process exceptions, to enumerate threads, modules, and functions in arbitrary processes, to pause and restart threads, and to read and write from process memory.
What debugger do you know of that hooks system calls and patches "protected" memory? Are you saying that writing CCh to a function prologue constitutes "messy witch-craft"? You know that's how Unix software breakpoints work too, right?
And what does kernel integrity have to do with debugging? Rootkits have been kernel resident since 1996 --- starting with SunOS and amodload.
I have used both, and the win32 API, debugging or otherwise, have often left me baffled and short-changed. Our argument will ultimately break down to source code and its availability. There is also the difference in uses of debugging on win32 vs unix: one is often adversarial while the other is cooperative. It's easy to debug a willing process on Unix and get all the information you want, while in Windows it's easy to debug any process and get as much information as you could.
I know ptrace is horribly broken, and so is the entire GNU debugging chain, down to libopcodes. I haven't touched it since '02 when I went full Lisp, but I had many a nightmare debugging a process that forked other children. The mess got worse with LinuxThreads.
As for rootkits on Unix, you're the security guy, I will let you pretend removing a Unix rootkit is the same as removing a win32 one :-)
And finally, remember that it wasn't long ago that any good Windows debugger had to load under the OS. And by a good debugger I don't mean Immunity or Olly :-)
No Unix debugger as powerful as SoftICE exists that doesn't run "under" the OS; that's the point of SoftICE.
Normal people don't debug with SoftICE. Even kernel developers use kd to debug driver code. You done much kernel debugging with gdb? Oh, here's a fun one: debug a running OpenBSD 2.x kernel. Hope you enjoy /dev/kmem.
You're the whatever-you-are. I'll let you pretend that disinfecting a compromised running kernel is feasible anywhere.
Sorry. I'm sure you're a great guy and you've had lots of experience doing interesting things, but I think you're just dead wrong here, and --- all due respect --- now you're just blowing smoke to cover it.
