Home > Books > Gray Hat Python by Justin Seitz – Errata

Gray Hat Python by Justin Seitz – Errata

June 10th, 2009

I found solutions to both of the problems I mentioned in my previous post about Gray Hat Python – everything works fine on my laptop, which runs 32-bit Windows XP.  I’m loving the book so far.  However, I ran across several errors in the code listings, so eventually I found an email address for Mr. Seitz and let him know.  He said he’d send them on to the publisher to post corrections on the book’s web page.  In the mean time, I’ll go ahead and list them out here in case any other readers are struggling.  I’ll update it if necessary as I progress through the book.

Gray Hat Python in the Stacksmash International Testing Laboratory.

Gray Hat Python in the Stacksmash International Testing Laboratory.

So, here we go.

The first code is in Chapter 3.  Everything looks alright until pages 37-38.  If you’ve entered the code as written, and you run the test program, then the program becomes unresponsive as soon as it executes the “attach” function.  The first problem is back on page 31.  In the function

attach(self,pid)

you need to remove the line

self.run()

I think this was needed earlier, but its presence now causes the debugger to hang.

Once that’s removed, then the attach is successful.  However, executing the program now does not give you a dump of the registers as expected.  Now the problem is on page 37, in the function

enumerate_threads(self)

The two lines:

kernel32.CloseHandle(snapshot)
return thread_list

should be indented back so they are at the same indent depth as the line

while success:

If you run the test program again, it successfully dumps the registers (though it doesn’t print the “Finished debugging.  Exiting…” message from the “detach” function, so that’s weird).

On page 41, the test program code suggests that the debugger will run and the event codes will get printed out, and then the debugger will detach.  But the program won’t return from the call to debugger.run(), so it’ll never detach.  You have to kill your program (which kills the program you attached to).

On page 42, there’s another critical problem.  If you copy in the code and run the text program, it crashes with this trace:

Traceback (most recent call last):
  File "C:\eclipse\plugins\org.python.pydev.debug_1.4.5.2727\pysrc\pydevd.py", line 881, in <module>
    debugger.run(setup['file'], None, None)
  File "C:\eclipse\plugins\org.python.pydev.debug_1.4.5.2727\pysrc\pydevd.py", line 710, in run
    execfile(file, globals, locals) #execute the script
  File "C:\Documents and Settings\Brad\workspace\GHP Test Project\src\my_test.py", line 16, in <module>
    debugger.run()
  File "C:\Documents and Settings\Brad\workspace\GHP Test Project\src\my_debugger.py", line 65, in run
    self.get_debug_event()
  File "C:\Documents and Settings\Brad\workspace\GHP Test Project\src\my_debugger.py", line 81, in get_debug_event
    if exception == EXCEPTION_ACCESS_VIOLATION:
UnboundLocalError: local variable 'exception' referenced before assignment

The problem is indentation again.  In the code on page 42, you need to add to the indentation of the lines starting with

if exception = EXCEPTION_ACCESS_VIOLATION:

and ending with

print "Single Stepping."

Those lines all belong inside of the block “if debug_event.dwDebugEventCode == EXCEPTION_DEBUG_EVENT:”.  Once their indentation is fixed, the program will again crash, now with this trace:

Traceback (most recent call last):
  File "C:\eclipse\plugins\org.python.pydev.debug_1.4.5.2727\pysrc\pydevd.py", line 881, in <module>
    debugger.run(setup['file'], None, None)
  File "C:\eclipse\plugins\org.python.pydev.debug_1.4.5.2727\pysrc\pydevd.py", line 710, in run
    execfile(file, globals, locals) #execute the script
  File "C:\Documents and Settings\Brad\workspace\GHP Test Project\src\my_test.py", line 16, in <module>
    debugger.run()
  File "C:\Documents and Settings\Brad\workspace\GHP Test Project\src\my_debugger.py", line 65, in run
    self.get_debug_event()
  File "C:\Documents and Settings\Brad\workspace\GHP Test Project\src\my_debugger.py", line 84, in get_debug_event
    continue_status = self.exception_handler_breakpoint()
TypeError: exception_handler_breakpoint() takes no arguments (1 given)

Still on page 42, you need to add “self” as an argument in the definition of exception_handler_breakpoint(), so it becomes

def exception_handler_breakpoint(self):

Fix this, and your debugger will now execute the soft breakpoint handler correctly (though there’s still no way to detach it; you’ll have to kill it and the process it’s attached to).

Things get kind of bad on page 46.  In the example output in Listing 3-3, it says “[*] Setting breakpoint at: 0x77c4186a” but there was never any code to print that out.  But that’s a minor issue – the bigger problem is that the program doesn’t actually set up breakpoints properly.  If you run the test, it never hits a breakpoint on printf.  The reason for this goes way back in the chapter to page 31:

h_process = kernel32.OpenProcess(PROCESS_ALL_ACCESS,pid,False)

The arguments have been mixed up.  It should be:

h_process = kernel32.OpenProcess(PROCESS_ALL_ACCESS,False,pid)

Somehow the result of this line isn’t used until read_process_memory() and write_process_memory() use it in calls to kernel32.ReadProcessMemory(), which result in the error code for INVALID HANDLE.  If the mistake isn’t corrected, then the original byte is never copied out and the INT3 opcode is never written into the process.

Once that’s been corrected, if you run the test program again, it blows up with this trace:

Traceback (most recent call last):
  File "C:\eclipse\plugins\org.python.pydev.debug_1.4.5.2727\pysrc\pydevd.py", line 881, in <module>
    debugger.run(setup['file'], None, None)
  File "C:\eclipse\plugins\org.python.pydev.debug_1.4.5.2727\pysrc\pydevd.py", line 710, in run
    execfile(file, globals, locals) #execute the script
  File "C:\Documents and Settings\Brad\workspace\GHP Test Project\src\my_test.py", line 17, in <module>
    debugger.run()
  File "C:\Documents and Settings\Brad\workspace\GHP Test Project\src\my_debugger.py", line 67, in run
    self.get_debug_event()
  File "C:\Documents and Settings\Brad\workspace\GHP Test Project\src\my_debugger.py", line 180, in get_debug_event
    elif ec == EXCEPTION_GUARD_PAGE:
NameError: global name 'ec' is not defined

Simple enough.  This one goes back to page 42 again, and “ec” should be replaced with “exception”.  Correct it, and then run the test program again.  It’s successful this time – sort of.  If you can kill it fast enough, you can see that it did in fact place a breakpoint on printf, and that breakpoint successfully caused the debugger to execute the breakpoint handler.  Unfortunately, after that, it goes into an infinite loop of events.  Why?  I think it’s because, while there’s a bp_set() function to insert breakpoints, there is no mechanism to remove breakpoints and return to the program in a sane manner.  It goes back and tries to execute whatever’s next after the INT3 the debugger inserted, which causes an exception the debugger doesn’t handle, forever.

The solution involves a lot of replacing the book code with Seitz’s code that’s available for download from Gray Hat Python’s web page.  In many places, his code differs pretty drastically from the book’s.  He commented it very well, so you can still follow what’s going on – so read his code and absorb his wisdom before you slap it into your own program.

With that done, the first function that has to be changed is exception_handler_breakpoint().  Open up Seitz’s my_debugger.py and replace your exception_handler_breakpoint() with his.  This also requires the addition of a Boolean variable to the debugger class, so within your __init__(self) function, add this:

self.first_breakpoint = True

Run the debugger again and it blows up thusly:

Traceback (most recent call last):
  File "C:\eclipse\plugins\org.python.pydev.debug_1.4.5.2727\pysrc\pydevd.py", line 881, in <module>
    debugger.run(setup['file'], None, None)
  File "C:\eclipse\plugins\org.python.pydev.debug_1.4.5.2727\pysrc\pydevd.py", line 710, in run
    execfile(file, globals, locals) #execute the script
  File "C:\Documents and Settings\Brad\workspace\GHP Test Project\src\my_test.py", line 17, in <module>
    debugger.run()
  File "C:\Documents and Settings\Brad\workspace\GHP Test Project\src\my_debugger.py", line 67, in run
[*] Exception address: 0x77c4186a
[*] Hit user defined breakpoint.
    self.get_debug_event()
  File "C:\Documents and Settings\Brad\workspace\GHP Test Project\src\my_debugger.py", line 205, in get_debug_event
    continue_status = self.exception_handler_breakpoint()
  File "C:\Documents and Settings\Brad\workspace\GHP Test Project\src\my_debugger.py", line 162, in exception_handler_breakpoint
    self.write_process_memory(self.exception_address, self.breakpoints[self.exception_address])
  File "C:\Documents and Settings\Brad\workspace\GHP Test Project\src\my_debugger.py", line 120, in write_process_memory
    c_data = c_char_p(data[count.value:])
TypeError: string or integer address expected instead of tuple instance

This is because in the code on page 44, you have:

self.breakpoints[address] = (address, original_byte)

That shouldn’t be a pair.  It should be:

self.breakpoints[address] = (address, original_byte)

After fixing this, run the test again and it blows up again like so:

Traceback (most recent call last):
  File "C:\eclipse\plugins\org.python.pydev.debug_1.4.5.2727\pysrc\pydevd.py", line 881, in <module>
    debugger.run(setup['file'], None, None)
  File "C:\eclipse\plugins\org.python.pydev.debug_1.4.5.2727\pysrc\pydevd.py", line 710, in run
    execfile(file, globals, locals) #execute the script
  File "C:\Documents and Settings\Brad\workspace\GHP Test Project\src\my_test.py", line 17, in <module>
    debugger.run()
  File "C:\Documents and Settings\Brad\workspace\GHP Test Project\src\my_debugger.py", line 67, in run
    self.get_debug_event()
  File "C:\Documents and Settings\Brad\workspace\GHP Test Project\src\my_debugger.py", line 205, in get_debug_event
    continue_status = self.exception_handler_breakpoint()
  File "C:\Documents and Settings\Brad\workspace\GHP Test Project\src\my_debugger.py", line 167, in exception_handler_breakpoint
    self.context = self.get_thread_context(h_thread=self.h_thread)
TypeError: get_thread_context() got an unexpected keyword argument 'h_thread'

That’s because Seitz’s version of get_thread_context() has different arguments than the book’s.  So copy Seitz’s get_thread_context() over yours.

Another run of the modified debugger yields another failure:

Traceback (most recent call last):
  File "C:\eclipse\plugins\org.python.pydev.debug_1.4.5.2727\pysrc\pydevd.py", line 881, in <module>
    debugger.run(setup['file'], None, None)
  File "C:\eclipse\plugins\org.python.pydev.debug_1.4.5.2727\pysrc\pydevd.py", line 710, in run
    execfile(file, globals, locals) #execute the script
  File "C:\Documents and Settings\Brad\workspace\GHP Test Project\src\my_test.py", line 17, in <module>
    debugger.run()
  File "C:\Documents and Settings\Brad\workspace\GHP Test Project\src\my_debugger.py", line 67, in run
    self.get_debug_event()
  File "C:\Documents and Settings\Brad\workspace\GHP Test Project\src\my_debugger.py", line 209, in get_debug_event
    continue_status = self.exception_handler_breakpoint()
  File "C:\Documents and Settings\Brad\workspace\GHP Test Project\src\my_debugger.py", line 168, in exception_handler_breakpoint
    self.context.Eip -= 1
AttributeError: 'bool' object has no attribute 'Eip'

Here the context hasn’t been set correctly, because the book’s call to get_thread_context() within get_debug_event() still uses different arguments from Seitz’s version of get_thread_context().  So, overwrite your get_debug_event() with Seitz’s, and finally, the debugger breaks on printf and then the program continues executing.

Moving on to hardware breakpoints, if you put add the code up to page 51 and run it, here’s what you get:

Traceback (most recent call last):
  File "C:\eclipse\plugins\org.python.pydev.debug_1.4.5.2727\pysrc\pydevd.py", line 881, in <module>
    debugger.run(setup['file'], None, None)
  File "C:\eclipse\plugins\org.python.pydev.debug_1.4.5.2727\pysrc\pydevd.py", line 710, in run
    execfile(file, globals, locals) #execute the script
  File "C:\Documents and Settings\Brad\workspace\GHP Test Project\src\my_test.py", line 17, in <module>
    debugger.bp_set_hw(printf_address,1,HW_EXECUTE)
  File "C:\Documents and Settings\Brad\workspace\GHP Test Project\src\my_debugger.py", line 249, in bp_set_hw
    context.Dr0 = address
UnboundLocalError: local variable 'context' referenced before assignment

This is another indentation error on page 48.  All the lines from

if available == 0:

up to and including

kernel32.SetThreadContext(h_thread,byref(context))

have to be indented once; they belong within the “for thread_id in self.enumerate_threads():” block.  Once that’s fixed, everything works just fine.  And there’s nothing wrong with the memory breakpoint section, so that’s the end of Chapter 3.  If I find anything more as I move through the book, I’ll update this post with it.

Categories: Books
  1. zeroone
    June 17th, 2009 at 12:34 | #1

    I want to get the book-gray hat python.
    would you give me a pdf. please post to my email,thanks!

  2. Brad
    June 17th, 2009 at 18:13 | #2

    @zeroone
    Nope. But amazon.com has it for 34% off the list price!

  3. June 30th, 2009 at 11:21 | #3

    Hi!

    Found your errata on the nostarch website. Nice job. Did you get to chapter 4. I’m having some trouble with printf_random.py

    Cheers,

    Otto

  4. Brad
    June 30th, 2009 at 14:45 | #4

    @otto
    I did start chapter 4, and I’m having trouble as well. I’ve been corresponding with Mr. Seitz about it. It’s a strange problem. I’ll update the post here when we figure it out.

  5. June 30th, 2009 at 20:41 | #5

    @Brad
    Thanks for the quick reply. Good to know I’m not the only one…

  6. July 1st, 2009 at 06:37 | #6

    Back at the start you mention it does not print [*] Finished debugging. Exiting…

    I had a similar problem, it would print the stack once and crash again. I changed the my_test code to only print the stack if thread_context–that way if get_thread_context is not false it won’t crash. This does get me two stack traces and prints the exit code. Now to figure out why though my stack traces are all 0x0s. I am still on 64 bit vista.

    Best!

  7. Brad
    July 1st, 2009 at 06:57 | #7

    @Matteius
    Good luck with that (sincerely) – the book says it’s tested on Win32, so as soon as I ran into trouble, I just abandoned any effort to run it on 64-bit Vista.

  8. July 1st, 2009 at 21:05 | #8

    Found this blog awhile ago, it was a lot of help to make it through the first 4 chapters. Thanks.

  9. SANDEEP MEHANDRU
    August 12th, 2009 at 22:41 | #9

    Hi,

    I have been working on a security project involving python.
    One of the use-cases, was to make use of ctypes.Union.

    To learn about ctypes.union I tried a sample from a python material.
    Howvere, i satrted to get an error. I valdiated the syntax from the python docs.
    But after correction , I am still reciveing the error.

    Please help me.
    I making use of the following python interpretor –> python 2.5.1

    Following is the python script code for defining and making use of a ctypes.Union:

    from ctypes import *

    class BARLEY_AMOUNT(Union):
    _fields_ = [
    (“barley_long”, c_long),
    (“barley_int”, c_int),
    (“barley_char”, c_char * 8),
    ]

    value = raw_input(”Enter amount of barley to put in beer vat:”)
    my_barley = BARLEY_AMOUNT(int(value))
    print “Barely amount as long: %ld” % my_barley.bareley_long
    print “Barely amount as int: %ld” % my_barley.barley_int
    print “Barely amount as long: %ld” % my_barley.barley_char

    Following is the error,that I am receiving:
    Traceback (most recent call last):
    File “C:\Python\src\chapter1-unions.py”, line 8, in
    class BARLEY_AMOUNT(Union):
    File “C:\Python\src\chapter1-unions.py”, line 16, in BARLEY_AMOUNT
    my_barley = BARLEY_AMOUNT(int(value))
    NameError: name ‘BARLEY_AMOUNT’ is not defined

    I have reached a dead end. Please help me on this.

  10. August 14th, 2009 at 15:50 | #10

    @Brad Did you ever get passed Chapter 4.1? This is what I’m seeing:

    printf_random:
    Counter: 2227248
    Counter: 2227248
    Counter: 2227248
    Counter: 2227248

    printf_loop:
    Loop iteration 0!
    Loop iteration 1!
    Loop iteration 2!
    Loop iteration 3!
    Loop iteration 4!
    Loop iteration 5!

    My setup is a Mac OS X host system w/ Windows XP Pro SP3 guest running in Parallels. All testing is on the Win XP guest OS.

  11. Brad
    August 14th, 2009 at 15:54 | #11

    @Jon
    I’m afraid not. That’s exactly what I get, and I can’t figure out why. I exchanged emails with Justin but we never came up with anything, and then I got busy studying for the CISSP. That’ll be Monday, and then I can get back to relevant/fun things like this.

  12. August 14th, 2009 at 17:12 | #12

    @Jon
    Thought this would help. Looked up a nice method in pydbg, dbg.dump_context(). I added this to printf_random.py

    parameter_addr = dbg.context.Esp + 0x8
    print dbg.dump_context()

    And got the following output:
    CONTEXT DUMP
    EIP: 77c4186a push byte 0x10
    EAX: 0021fb88 ( 2227080) -> 0! (stack)
    EBX: 00000000 ( 0) -> N/A
    ECX: 0021fc98 ( 2227352) -> ..!…………………`….R…R……..!…….!………..!……….G..j..w………………..x…………R….!……………..x…….j..w………….h…….R…….R……`….R………………`…….`…..!…..<U..p……….. ………………..`….R…R……..!…….!………..!……….G..j..w………………..x…………R….!……………..x…….j..w………….h…….R…….R……`….R………………`…….`…..!…..<U..p……….. ..!…………………`….R…R……..!…….!………..!……….G..j..w………………..x…………R….!……………..x…….j..w………….h…….R…….R……`….R………………`…….`…..!…..<U..p……….. 0! (stack)
    EBP: 0021fb8c ( 2227084) -> ..!………..!………..!.j..w..!.0.!…!…!.p.!..w..0.!.j..w..!…!…!…!…..d………….!.x…..!………..!.d…….%.1ld.!.p%………………JY..,_…………!…………. Y..p%…………!..V….!……………!………j..w..!…!….. (stack)
    ESP: 0021fb80 ( 2227072) -> :…….0.!…!………..!………..!.j..w..!.0.!…!…!.p.!..w..0.!.j..w..!…!…!…!…..d………….!.x…..!………..!.d…….%.1ld.!.p%………………JY..,_…………!…………. Y..p%…………!..V….!……………!………j..w (stack)
    +00: 1d1aba3a ( 488290874) -> N/A
    +04: 00a9c994 ( 11127188) -> Loop iteration 4! (heap)
    +08: 0021fc30 ( 2227248) -> ……….!…………. Y..p%…………!..V….!……………!………j..w..!…!…….!………..!…………………`….R…R……..!…….!………..!……….G..j..w………………..x…………R….!……………..x…….j..w…. (stack)
    +0c: 0021fbbc ( 2227132) -> p! (stack)
    +10: 1d1aaa9a ( 488286874) -> N/A
    +14: 1d1aa8e0 ( 488286432) -> N/A

    Counter: 2227248

    So, it seems the variable (and the whole string) is on the heap versus the stack. To grab it, one will need to dereference the memory location again, read in the string, rip out the variable and then replace… I’m trying it out right now.

  13. August 14th, 2009 at 17:13 | #13

    @Brad
    Stop studying for the CISSP, this is better ;) (former CISSP #26339).

  14. August 14th, 2009 at 19:18 | #14

    Here’s my blog post on it. I didn’t think I could explain everything in the comments adequately…

    http://blog.cykyc.org/2009/08/gray-hat-python-chapter-41-love.html

  15. AH
    August 23rd, 2009 at 15:47 | #15

    check page 149,
    if driver_handle:

    else:

    will always open the dev even if it’s invalid..a quick work arround is:
    if driver_handle > 0: #since driver_handle returns -1 when dev is invalid.

    else:

  16. Sami
    October 10th, 2009 at 10:32 | #16

    I am still stuck in the 3rd Chapter. I was able to do the first step, running the process. I am not able to run the process and attach to it as shown in the second step of the exercise. It is not recognizing PROCESS_ALL_ACCESS for some reason.
    I compare the code line by line, and even used the code from the book’s website. It seems to be a system issue rather than a type in the code, but I’m running a 32-bit XP on this machine. I’m using a laptop that came with windows pre-installed and I’m starting to wonder if the reason is the image of windows my employer puts on these laptops.

    Please help with any suggestions or ideas. Thanks very much. This is the error I get:
    Enter the PID of the process to attach to: 4740
    Traceback (most recent call last):
    File “C:\Documents and Settings\sami\workspace\Gray Hat Python\src\my_test.py”, line 11, in
    debugger.attach(int(pid))
    File “C:\Documents and Settings\sami\workspace\Gray Hat Python\src\my_debugger.py”, line 84, in attach
    self.h_process = self.open_process(pid)
    File “C:\Documents and Settings\sami\workspace\Gray Hat Python\src\my_debugger.py”, line 78, in open_process
    h_process = kernel32.OpenProcess(PROCESS_ALL_ACCESS,False,pid)
    NameError: global name ‘PROCESS_ALL_ACCESS’ is not defined

  17. John
    October 13th, 2009 at 05:19 | #17

    Have you checked if you have imported the “my_debbuger_defines module”. The one that you can download from the books homepage?

    from my_debugger_defines import * #Imports everything from my_debugger_defines module

    That’s where the constant PROCESS_ALL_ACCESS is defined:
    PROCESS_ALL_ACCESS = 0x001F0FFF #Definition of PROCESS_ALL_ACCESS

  18. Brad
    October 14th, 2009 at 02:39 | #18

    @Sami
    What John said.

  19. Sami
    October 15th, 2009 at 14:22 | #19

    Thanks John. I had downloaded the files and replaced my_debugger.py but never thought my_debugger_defines module might be missing something; not sure why I assumed that but anyway it has worked except that when I click again I keep getting the same message ‘Press a key to continue…’. According to the book, it is supposed to exit on the second time. I’m wondering if anybody had the same issue.

    Thanks very much for your response, it was very helpful indeed.

  20. Brad
    October 16th, 2009 at 13:44 | #20

    @Sami
    Did you comment out the two lines specified on p. 33?

  21. LaVey
    February 9th, 2010 at 09:51 | #21

    I still had problems getting the kernel32.OpenProcess() to return a handle, stepping retunred a 0 and extended error 57, googling found some more info here: http://nsylvain.blogspot.com/2008/01/winverwin32winnt-mayhem.html
    The solution that worked for me was to change the constant PROCESS_ALL_ACCESS to the following:

    PROCESS_ALL_ACCESS = (0x000F0000 | 0x00100000 | 0xFFF)

    (found here: http://acme-labs.org.uk/galleries/44/0000/2237/lecture.pdf)

    Hth someone :D

  22. Greg
    February 26th, 2010 at 15:15 | #22

    the issue with Chapter 4.1, besides any issues in printf_random.py, is actually in printf_loop.py. printf is called with 1 argument and not 2, so trying to read / modify the second argument while debugging doesn’t do any good. changing the % to a , in the call to printf causes the printf statement to get the format string and the number, instead of Python doing the formatting and then passing the resulting string.

  23. Sean
    April 4th, 2010 at 14:24 | #23

    @Greg
    Indeed, the problem is in the printf_loop.py. It took me a bit, but once I thought about it enough I realized I should take a better look at the loop and not the debugger.

    You can grab the source for the book–which is far more accurate–from its website:
    http://www.nostarch.com/ghpython.htm

    This should save a lot of trouble. :)

  24. JP
    April 8th, 2010 at 15:55 | #24

    I’ve been working on finishing up the code on page 36-37(chapter 3), I’ve already made the changes regarding kernel32.CloseHandle, etc. I’m having an issue with some of the thread_entry fields (important ones like th32OwnerProcessID, and th32ThreadID) containing 0. Has anyone encounter similar problems?

  25. JP
    April 18th, 2010 at 10:59 | #25

    Did anyone get the soft breakpoints to work based on the code from p. 43,44,45?

  26. Thanh Lam
    July 16th, 2010 at 20:47 | #26

    Thanks for sharing the errors. That’s very helpful. The No Starch Press Website now has the updates on the errors.

    I just want to point out from my own experience when I removed the line self.run(). The debugger attached to the process then went directly to exit — it displayed the message:
    “[*] Finished debugging. Exiting…”

    I put the line back in and it works as described in the book. Just thought others may want to know. I don’t see how to send this feedback to No Starch Press. If you still have Mr. Seitz, could you send it to my email address? Thanks again!

  27. Thanh Lam
    July 16th, 2010 at 21:05 | #27

    @SANDEEP MEHANDRU
    Some how the capital class name BARLEY_AMOUNT was the problem, I think. I have the name all lower case and it works fine. I don’t see why BARLEY_AMOUNT doesn’t work and barley_amount works either. However, I’m just a python beginner myself.

  28. diwakar wagle
    August 24th, 2010 at 21:42 | #28

    The attach proces was successful.During the thread enumeration while running my_test.py gave following error:
    Traceback (most recent call last):
    File “C:\Python31\my_test.py”, line 11, in
    for thread in list:
    TypeError: ‘bool’ object is not iterable

    Does anyone know what’s wrong with that?

  29. johan
    November 16th, 2010 at 13:36 | #29

    Hi,

    using eclipse and pydev, I can’t seem to grasp what’s the problem

    import immlib

    ImportError: no module named debugger ??

    commenting import debugger in immlib.py doesn’t seem to help.

    Anyone has an idea ?

    thanks in advance.

  30. Mike
    March 11th, 2011 at 07:39 | #30

    Brilliant collection of errata…I had found most and corrected them myself, through trial and error.

    Definitely recommend grabbing the actual code from no-starch, which has very few errors. I love python, but its dependency on spacing makes it difficult for publishing in a book, especially if the typesetters don’t realize indentation is supporting.

  31. Brad
    March 11th, 2011 at 09:25 | #31

    Ha, good point on the printing. I’d never thought of that as a disadvantage of Python.

  32. March 13th, 2011 at 08:33 | #32

    in page 42 replace: “self.context = self.get_thread_context(h_thread=self.h_therad)
    with this line (works for me)
    self.context = self.get_thread_context(thread_id=debug_event.dwThreadId)

  33. bb
    April 3rd, 2011 at 13:21 | #33

    @JP
    I am having the same problems. Aren’t we setting the thread_id and h_thread to None in the get_thread_context declaration? What is the purpose of this? I am stuck in an infinite loop on the ‘while success:’ line.

  34. ikdme
    May 30th, 2011 at 08:22 | #34

    Please i have gone to the books website but i can’t seem to find a link to the source code. I’m stuck. Can any one help Please

  35. August 23rd, 2011 at 18:59 | #35

    Hello,

    First of all, thanks for your job on these mistakes, it helped me to realize that the printed version of the book I received from Nostarch is updated whereas the ebooks versions, from where I copied the code, are not… =)
    Anyway, this book is just awesome and it shows the huge power of this snaky language.

    Peace!

  36. Ronnie
    September 6th, 2011 at 04:38 | #36
  37. firefive
    September 28th, 2011 at 02:30 | #37

    HI:
    I run the Chapter 4.2,but the return is as below,why the ESI not points to the “AAAAAAAAAAA” string

    Enter the Process ID: 5608
    0x1e001759 mov edx,[eax+0x10] from thread 5136 caused access violation
    when attempting to read from 0x41414151

    CONTEXT DUMP
    EIP: 1e001759 mov edx,[eax+0x10]
    EAX: 41414141 (1094795585) -> N/A
    EBX: 00000002 ( 2) -> N/A
    ECX: 1e20e858 ( 505473112) -> $@enable() -> NoneEnable automatic garbage collection.isenabled() -> statusReturns true if automatic garbage collection is enabled.collect([generation]) -> nWith no arguments, run a full collection. The optional argu (python27.dll.data)
    EDX: 41414141 (1094795585) -> N/A
    EDI: 00000000 ( 0) -> N/A
    ESI: 1e20e858 ( 505473112) -> $@enable() -> NoneEnable automatic garbage collection.isenabled() -> statusReturns true if automatic garbage collection is enabled.collect([generation]) -> nWith no arguments, run a full collection. The optional argu (python27.dll.data)
    EBP: 0021fef8 ( 2227960) -> $@enable() -> NoneEnable automatic garbage collection.isenabled() -> statusReturns true if automatic garbage collection is enabled.collect([generation]) -> nWith no arguments, run a full collection. The optional argu (python27.dll.data)
    ESP: 0021feac ( 2227884) -> -H1TxgX TvaaTx8″|!|!Xt3??t[xONNJN”Tx!`?3P! (stack)
    +00: 1e00182d ( 503322669) -> N/A
    +04: 00000000 ( 0) -> N/A
    +08: 009e3148 ( 10367304) -> @pkm ml)@55=C:\gs\cP#(E (((((((((((((((((((((((((( (heap)
    +0c: 7854f1c3 (2018832835) -> N/A
    +10: 00bb6710 ( 12281616) -> Xj0X@%g8u1 xsnw^isNumberTypegPg0 xn1isSequenceTypehg@ (heap)
    +14: 00000000 ( 0) -> N/A

    disasm around:
    0x1e001751 jnz 0x1e001739
    0x1e001753 pop esi
    0x1e001754 ret
    0x1e001755 mov eax,[ecx]
    0x1e001757 jmp 0x1e001761
    0x1e001759 mov edx,[eax+0x10]
    0x1e00175c mov [eax+0x8],edx
    0x1e00175f mov eax,[eax]
    0x1e001761 cmp eax,ecx
    0x1e001763 jnz 0x1e001759
    0x1e001765 ret

    stack unwind:
    1e031358
    1d001160
    7c817077

    SEH unwind:
    0021ffe0 -> 1d0015d5: mov edi,edi
    ffffffff -> 7c839ad8: push ebp

  38. pankaj
    December 25th, 2011 at 16:09 | #38

    hi
    I m working with chapter 4 , but error is in No pydbg module . so please tell me what is the procedure to setup…
    thanks

  39. David Birch
    April 28th, 2012 at 16:57 | #39

    I can’t get this to work for the life of me, and I’ve downloaded the current site’s code. Can you send me your working version please?

  40. Saurav
    May 13th, 2013 at 06:53 | #40

    Hi,

    I am having issue in attaching the debugger to the process. showing
    “debugger instance has no attribute ‘attach'”
    tried removing self.run() but the above error shows up again. Can anyone help me on this?

  41. lwang
    May 29th, 2013 at 02:44 | #41

    @Saurav Can you give more info about this?

  42. July 29th, 2013 at 12:26 | #42

    Thanks for your work, m8. The number of errors when reaching page 47 is fucking overwhelming. It’s sad that a technical book can be sold with all these errors. I hope the next chapters won’t be the same…

  43. March 5th, 2014 at 19:35 | #43

    Hi guys, I know this thread is old but hopefully someone can respond to me. I am trying to get section 3.4.1 to work. I have checked and rechecked my code and even the updates on the site and seem to be missing something.
    Enter the PID of the process to attach to: 4332
    [*] Address of printf: 0x76bec5b9
    Traceback (most recent call last):
    File “C:\Users\Derek\workspace\Gray Hat Python\src\my_test.py”, line 18, in
    debugger.bp_set(printf_address)
    File “C:\Users\Derek\workspace\Gray Hat Python\src\my_debugger.py”, line 237, in bp_set
    if not self.breakpoints.has_key(address):
    AttributeError: debugger instance has no attribute ‘breakpoints’

    this is my error. Can someone please help as I don’t want to move on until I find this issue. FYI, I just got my book and it has all the fixes from the site so I’m thinking there is another issue I’m missing.

Comments are closed.