

Gray Hat Python: Python Programming for Hackers and Reverse Engineers Review - phn1x
http://hamsterswheel.com/techblog/?p=167

======
thomaspaine

        The entire book is windows specific.

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.

~~~
tptacek
Unfortunately, the debugging interfaces on Linux and OSX are very different
from Win32, and very different from each other.

~~~
mahmud
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 :-)

~~~
tptacek
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.

~~~
mahmud
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 :-)

~~~
tptacek
So basically your whole argument just unraveled.

Immunity is 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.

