winappdbg-users — Users of WinAppDbg

Re: [WinAppDbg-users] OO disassembling mode, possible bug in binary search

[Mario V. <mv...@gm...>]

Hi! Sorry for the late reply :( I've been crazy busy and I didn't notice
this one went into the moderation queue.

My replies in line below:

On Tue, Sep 1, 2015 at 4:33 PM, Andreas Greulich <and...@sp...>
wrote:

> Hi guys,
>
> I'm not sure if this mailing list is still active and - if not - if
> there's a dedicated forum to it. Please redirect me if there is such a
> place...
>
> I started using winappdbg recently (I was using PyDbg previously) and kind
> of like it. I have 2 questions though.
>
> One is about the disassembler module - I added distorm3.3 as Python
> module. My main question is if there's a way to access the object-oriented
> variant of distorm instead of the text-oriented one? As it currently is,
> one needs to do text pattern matching on the disassembling lines to find
> out precise values and addressing modes. for instance, if I disassemble a
> CALL instruction, it can return me something like "call 0x12345", but it
> could also return something like "call moduleName!start+0x18aa" if teh
> target happens to be in the starting module. This should make things easier
> to read for humans, but is harder to parse if you need to know the final
> address.
>
> In "pure" distorm3 itself, I can do something like (using
> DecomposeGenerator instead of DecodeGenerator)
>
> for i in  distorm3.DecomposeGenerator(offset, code, distorm3.Decode32Bits):
>   if distorm3.Mnemonics[i.opcode] == "CALL":
>     op = i.operands[0]
>     if op.type == distorm3.OPERAND_IMMEDIATE:
>       target = op.value
>       ...
>
> And so I can get the values directly without regular-expression-kungfu,
> also figuring out precise addressing modes is easier than in the text
> output. Unfortunately, winappdbg's disassemble call seems to only return
> the text variant - it would be neat to have the other variant as well
> (though of course you could just read out data into Pythons memory space
> and then use distorm directly).
>

The problem with this is that I meant the disassembly support to be
independent of which library you use - and therefore the API must be
identical in all cases. Supporting the object oriented interface means I
have to implement an API for that, and then add support for other
disassemblers too (Capstone comes to mind), and honestly I barely have time
to patch bugs, let alone add new features :( so for now your choices are to
use disasm3 directly, or send me a patch to WinAppDbg. I prefer the second
of course! :D


>
> My other issue - I'm not sure if it's a bug - is in the memory search
> function. If I want to search for a "JMP ESI" instruction in binary mode, I
> could do
>
> for addr,val in
> event.get_process().search_hexa("ffe6",self.myStartAddr,self.myEndAddr):
>     print HexDump.hexblock_byte(event.get_process().read(addr,2),addr)
>
> But I don't get the correct result; if I do however
>
> for addr,val in
> event.get_process().search_hexa("ffe6",self.myStartAddr,self.myEndAddr):
>     print
> HexDump.hexblock_byte(event.get_process().read(addr+0x1000,2),addr+0x1000)
>
> I get the correct values. It seems that the search results are offsetted
> by one memory page (0x1000), of course I'm not sure how dependent on the
> very sample examined this is. Same thing with the other variants of the
> search function.
>

I think there was a bug report for this already, if it's the same issue
it's probably fixed already in Github (I stopped using Sourceforge for
source contro, it was just too annoying). If it's not, poke me with a stick
until I fix it ;) here's the link: https://github.com/mariovilas/winappdbg

Cheers!
/Mario

-- 
“There's a reason we separate military and the police: one fights the enemy
of the state, the other serves and protects the people. When the military
becomes both, then the enemies of the state tend to become the people.”

[WinAppDbg-users] OO disassembling mode, possible bug in binary search

[Andreas G. <and...@sp...>]

Hi guys,

I'm not sure if this mailing list is still active and - if not - if there's a dedicated forum to it. Please redirect me if there is such a place...

I started using winappdbg recently (I was using PyDbg previously) and kind of like it. I have 2 questions though.

One is about the disassembler module - I added distorm3.3 as Python module. My main question is if there's a way to access the object-oriented variant of distorm instead of the text-oriented one? As it currently is, one needs to do text pattern matching on the disassembling lines to find out precise values and addressing modes. for instance, if I disassemble a CALL instruction, it can return me something like "call 0x12345", but it could also return something like "call moduleName!start+0x18aa" if teh target happens to be in the starting module. This should make things easier to read for humans, but is harder to parse if you need to know the final address.

In "pure" distorm3 itself, I can do something like (using DecomposeGenerator instead of DecodeGenerator)

for i in  distorm3.DecomposeGenerator(offset, code, distorm3.Decode32Bits):
  if distorm3.Mnemonics[i.opcode] == "CALL":
    op = i.operands[0]
    if op.type == distorm3.OPERAND_IMMEDIATE:
      target = op.value
      ...

And so I can get the values directly without regular-expression-kungfu, also figuring out precise addressing modes is easier than in the text output. Unfortunately, winappdbg's disassemble call seems to only return the text variant - it would be neat to have the other variant as well (though of course you could just read out data into Pythons memory space and then use distorm directly).

My other issue - I'm not sure if it's a bug - is in the memory search function. If I want to search for a "JMP ESI" instruction in binary mode, I could do

for addr,val in event.get_process().search_hexa("ffe6",self.myStartAddr,self.myEndAddr):
    print HexDump.hexblock_byte(event.get_process().read(addr,2),addr)

But I don't get the correct result; if I do however

for addr,val in event.get_process().search_hexa("ffe6",self.myStartAddr,self.myEndAddr):
    print HexDump.hexblock_byte(event.get_process().read(addr+0x1000,2),addr+0x1000)

I get the correct values. It seems that the search results are offsetted by one memory page (0x1000), of course I'm not sure how dependent on the very sample examined this is. Same thing with the other variants of the search function.

Thanks in advance,

Andy

[WinAppDbg-users] Hook all API calls

[Adam B. <br...@bt...>]

Hi all,

I'm trying to use WinAppDbg to build a kind of profile of an application
when it runs.
(The application has no user input; it just runs from start to finish.)

I'd like to "record" (log) each API call including the parameters and, if
possible, the return value.

Reading the documentation I can see clear examples of hooking the API, (
http://winappdbg.sourceforge.net/Debugging.html#example-9-intercepting-api-calls),
however, one has to specify the precise API calls

Is it possible to specify ALL API calls and then have a generic pre_ and
post_ callback function?

Many thanks,
Adam

Re: [WinAppDbg-users] single stepping at RtlUserThreadStart

[John H. <jo...@ca...>]

Are you actually holding the main thread while the sub thread finishes execution? If you “start” the thread, then the main thread exits, you’ll probably never see the child thread start because the application exits before the thread gets a chance to start. You’d have to hold the main thread open until the child thread finishes its work.

John


From: Mario Vilas [mailto:mv...@gm...]
Sent: Wednesday, December 17, 2014 9:51 AM
To: win...@li...
Subject: Re: [WinAppDbg-users] single stepping at RtlUserThreadStart

Hi! Honestly, no idea. Sounds like the flags are being cleared. In any case such aggressive single steppubg inside the operating system libraries is bound to fail anyway for any reason... It's best to only do the debugging within the target application rather than everything in the entire process.

Cheers,
-Mario

El miércoles, 17 de diciembre de 2014, Justin Kim <jus...@gm...<mailto:jus...@gm...>> escribió:
Hi WinAppDbg, I am trying to single-step every instruction of all threads from process creation to process termination. My code is as following, and my problem is that it stops receiving single step events when it reaches ntdll!RtlUserThreadStart. Is this expected? Should I be missing some configuration perhaps? Cheers -- Justin

Code:
import sys
from winappdbg import *

class Taint(EventHandler):
    def create_process(self, event):
        module = event.get_process().get_main_module()
        print "[+] Process created: %s" % module.fileName
        print "[+] Thread #%d tracing enabled." % event.get_tid()
        event.debug.start_tracing( event.get_tid() )

    def exit_process(self, event):
        print "[+] Process terminated."

    def create_thread( self, event ):
        print "[+] Thread #%d tracing enabled." % event.get_tid()
        event.debug.start_tracing( event.get_tid() )

    def single_step(self, event):
        thread = event.get_thread()
        pc = thread.get_pc()
        tid = thread.get_tid()
        instruction = thread.disassemble(pc, 0x10)[0]
        address = instruction[0]
        mnemonic = " ".join(instruction[2].split())
        print "[T%d] 0x%08X: %s" % (tid, address, mnemonic)

# main
with Debug(Taint(), True) as debug:
    debug.execv(sys.argv[1:], bFollow=True)
    debug.loop()


Output:
...
[T120] 0x774DBA7B: mov dword [ss:esp+00000084h], 00000040h [ntdll!RtlTimeFieldsToTime+0x3ce]
[T120] 0x774DBA86: mov dword [ss:esp+00000088h], 00000000h [ntdll!RtlTimeFieldsToTime+0x3d9]
[T120] 0x774DBA91: mov dword [ss:esp+0000008Ch], 00000000h [ntdll!RtlTimeFieldsToTime+0x3e4]
[T120] 0x774DBA9C: call 774BBFC0h [ntdll!ZwQueryAttributesFile]
[T120] 0x774BBFC0: mov eax, 0000003Ch [ntdll!ZwQueryAttributesFile]
[T120] 0x774BBFC5: call dword [fs:000000C0h] [ntdll!ZwQueryAttributesFile+0x5]
[T120] 0x774711D8: jmp far 0033h : 774721A4h [0x774711d8]
[T120] 0x774BDE3C: mov dword [ss:esp+04h], eax [ntdll!RtlUserThreadStart]
[+] Process terminated.



--
“There's a reason we separate military and the police: one fights the enemy of the state, the other serves and protects the people. When the military becomes both, then the enemies of the state tend to become the people.”

Re: [WinAppDbg-users] single stepping at RtlUserThreadStart

[Mario V. <mv...@gm...>]

Hi! Honestly, no idea. Sounds like the flags are being cleared. In any case
such aggressive single steppubg inside the operating system libraries is
bound to fail anyway for any reason... It's best to only do the debugging
within the target application rather than everything in the entire process.

Cheers,
-Mario

El miércoles, 17 de diciembre de 2014, Justin Kim <jus...@gm...>
escribió:

> Hi WinAppDbg, I am trying to single-step every instruction of all threads
> from process creation to process termination. My code is as following, and
> my problem is that it stops receiving single step events when it reaches
> ntdll!RtlUserThreadStart. Is this expected? Should I be missing some
> configuration perhaps? Cheers -- Justin
>
> Code:
> import sys
> from winappdbg import *
>
> class Taint(EventHandler):
>     def create_process(self, event):
>         module = event.get_process().get_main_module()
>         print "[+] Process created: %s" % module.fileName
>         print "[+] Thread #%d tracing enabled." % event.get_tid()
>         event.debug.start_tracing( event.get_tid() )
>
>     def exit_process(self, event):
>         print "[+] Process terminated."
>
>     def create_thread( self, event ):
>         print "[+] Thread #%d tracing enabled." % event.get_tid()
>         event.debug.start_tracing( event.get_tid() )
>
>     def single_step(self, event):
>         thread = event.get_thread()
>         pc = thread.get_pc()
>         tid = thread.get_tid()
>         instruction = thread.disassemble(pc, 0x10)[0]
>         address = instruction[0]
>         mnemonic = " ".join(instruction[2].split())
>         print "[T%d] 0x%08X: %s" % (tid, address, mnemonic)
>
> # main
> with Debug(Taint(), True) as debug:
>     debug.execv(sys.argv[1:], bFollow=True)
>     debug.loop()
>
>
> Output:
> ...
> [T120] 0x774DBA7B: mov dword [ss:esp+00000084h], 00000040h
> [ntdll!RtlTimeFieldsToTime+0x3ce]
> [T120] 0x774DBA86: mov dword [ss:esp+00000088h], 00000000h
> [ntdll!RtlTimeFieldsToTime+0x3d9]
> [T120] 0x774DBA91: mov dword [ss:esp+0000008Ch], 00000000h
> [ntdll!RtlTimeFieldsToTime+0x3e4]
> [T120] 0x774DBA9C: call 774BBFC0h [ntdll!ZwQueryAttributesFile]
> [T120] 0x774BBFC0: mov eax, 0000003Ch [ntdll!ZwQueryAttributesFile]
> [T120] 0x774BBFC5: call dword [fs:000000C0h]
> [ntdll!ZwQueryAttributesFile+0x5]
> [T120] 0x774711D8: jmp far 0033h : 774721A4h [0x774711d8]
> [T120] 0x774BDE3C: mov dword [ss:esp+04h], eax [ntdll!RtlUserThreadStart]
> [+] Process terminated.
>
>

-- 
“There's a reason we separate military and the police: one fights the enemy
of the state, the other serves and protects the people. When the military
becomes both, then the enemies of the state tend to become the people.”

[WinAppDbg-users] single stepping at RtlUserThreadStart

[Justin K. <jus...@gm...>]

Hi WinAppDbg, I am trying to single-step every instruction of all threads
from process creation to process termination. My code is as following, and
my problem is that it stops receiving single step events when it reaches
ntdll!RtlUserThreadStart. Is this expected? Should I be missing some
configuration perhaps? Cheers -- Justin

Code:
import sys
from winappdbg import *

class Taint(EventHandler):
    def create_process(self, event):
        module = event.get_process().get_main_module()
        print "[+] Process created: %s" % module.fileName
        print "[+] Thread #%d tracing enabled." % event.get_tid()
        event.debug.start_tracing( event.get_tid() )

    def exit_process(self, event):
        print "[+] Process terminated."

    def create_thread( self, event ):
        print "[+] Thread #%d tracing enabled." % event.get_tid()
        event.debug.start_tracing( event.get_tid() )

    def single_step(self, event):
        thread = event.get_thread()
        pc = thread.get_pc()
        tid = thread.get_tid()
        instruction = thread.disassemble(pc, 0x10)[0]
        address = instruction[0]
        mnemonic = " ".join(instruction[2].split())
        print "[T%d] 0x%08X: %s" % (tid, address, mnemonic)

# main
with Debug(Taint(), True) as debug:
    debug.execv(sys.argv[1:], bFollow=True)
    debug.loop()


Output:
...
[T120] 0x774DBA7B: mov dword [ss:esp+00000084h], 00000040h
[ntdll!RtlTimeFieldsToTime+0x3ce]
[T120] 0x774DBA86: mov dword [ss:esp+00000088h], 00000000h
[ntdll!RtlTimeFieldsToTime+0x3d9]
[T120] 0x774DBA91: mov dword [ss:esp+0000008Ch], 00000000h
[ntdll!RtlTimeFieldsToTime+0x3e4]
[T120] 0x774DBA9C: call 774BBFC0h [ntdll!ZwQueryAttributesFile]
[T120] 0x774BBFC0: mov eax, 0000003Ch [ntdll!ZwQueryAttributesFile]
[T120] 0x774BBFC5: call dword [fs:000000C0h]
[ntdll!ZwQueryAttributesFile+0x5]
[T120] 0x774711D8: jmp far 0033h : 774721A4h [0x774711d8]
[T120] 0x774BDE3C: mov dword [ss:esp+04h], eax [ntdll!RtlUserThreadStart]
[+] Process terminated.

Re: [WinAppDbg-users] Unsuccessful installation on Windows 7 Pro, 32-Bit

[Tony C. <cap...@gm...>]

That seems to have fixed it.
I'm reluctant to upgrade modules out of concern that another python app
will break.

Thanks Mario

On Tue, Nov 25, 2014 at 12:35 PM, Mario Vilas <mv...@gm...> wrote:

> Hi,
>
> From what I see in the traceback I'd say the problem lies with SQLAlchemy.
> Maybe the version you have installed is not the right one? Try upgrading
> with pip install --upgrade sqlalchemy. Another possibility is you have
> installed SQLAlchemy but you're missing the actual database connectors it
> uses underneath.
>
> If all else fails, just skip pip entirely (it's a piece of crap anyway...)
> and install manually with the setup.py script bundled in the winappdbg
> sources.
>
> Cheers!
> -Mario
>
> On Tue, Nov 25, 2014 at 8:19 PM, Tony Cappellini <cap...@gm...>
> wrote:
>
>>
>> After running the msi installer on Windows 7 Pro, 32-Bit , I am unable to
>> successfully
>> import winappdbg or any of its modules.
>>
>> I've deleted the installation directory and reinstalled using pip,
>> but still cannot successfully import winappdbg or its modules.
>>
>> Is there a workaround for this issue?
>>
>> Thanks
>>
>>
>> Python 2.7.6 (default, Nov 10 2013, 19:24:18) [MSC v.1500 32 bit (Intel)]
>> on win32
>> Type "help", "copyright", "credits" or "license" for more information.
>> >>> import winappdbg
>> Traceback (most recent call last):
>>   File "<stdin>", line 1, in <module>
>>   File "C:\Python27\Lib\site-packages\winappdbg\__init__.py", line 254,
>> in <module>
>>     from sql import *
>>   File "C:\Python27\Lib\site-packages\winappdbg\sql.py", line 355, in
>> <module>
>>     class MemoryDTO (BaseDTO):
>>   File "C:\Python27\Lib\site-packages\sqlalchemy\ext\declarative.py",
>> line 1126, in __init__
>>     _as_declarative(cls, classname, cls.__dict__)
>>   File "C:\Python27\Lib\site-packages\sqlalchemy\ext\declarative.py",
>> line 1035, in _as_declarative
>>     **table_kw)
>>   File "C:\Python27\Lib\site-packages\sqlalchemy\schema.py", line 209, in
>> __new__
>>     table._init(name, metadata, *args, **kw)
>>   File "C:\Python27\Lib\site-packages\sqlalchemy\schema.py", line 249, in
>> _init
>>     self._extra_kwargs(**kwargs)
>>   File "C:\Python27\Lib\site-packages\sqlalchemy\schema.py", line 305, in
>> _extra_kwargs
>>     "Invalid argument(s) for Table: %r" % kwargs.keys())
>> TypeError: Invalid argument(s) for Table: ['drizzle_engine',
>> 'mysql_engine', 'mysql_charset']
>> >>>
>>
>>
>> ------------------------------------------------------------------------------
>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
>> with Interactivity, Sharing, Native Excel Exports, App Integration & more
>> Get technology previously reserved for billion-dollar corporations, FREE
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
>> _______________________________________________
>> WinAppDbg-users mailing list
>> Win...@li...
>> https://lists.sourceforge.net/lists/listinfo/winappdbg-users
>>
>>
>
>
> --
> "There's a reason we separate military and the police: one fights
> the enemy of the state, the other serves and protects the people. When
> the military becomes both, then the enemies of the state tend to become the
> people."
>

Re: [WinAppDbg-users] Unsuccessful installation on Windows 7 Pro, 32-Bit

[Mario V. <mv...@gm...>]

Hi,

>From what I see in the traceback I'd say the problem lies with SQLAlchemy.
Maybe the version you have installed is not the right one? Try upgrading
with pip install --upgrade sqlalchemy. Another possibility is you have
installed SQLAlchemy but you're missing the actual database connectors it
uses underneath.

If all else fails, just skip pip entirely (it's a piece of crap anyway...)
and install manually with the setup.py script bundled in the winappdbg
sources.

Cheers!
-Mario

On Tue, Nov 25, 2014 at 8:19 PM, Tony Cappellini <cap...@gm...>
wrote:

>
> After running the msi installer on Windows 7 Pro, 32-Bit , I am unable to
> successfully
> import winappdbg or any of its modules.
>
> I've deleted the installation directory and reinstalled using pip,
> but still cannot successfully import winappdbg or its modules.
>
> Is there a workaround for this issue?
>
> Thanks
>
>
> Python 2.7.6 (default, Nov 10 2013, 19:24:18) [MSC v.1500 32 bit (Intel)]
> on win32
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import winappdbg
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
>   File "C:\Python27\Lib\site-packages\winappdbg\__init__.py", line 254, in
> <module>
>     from sql import *
>   File "C:\Python27\Lib\site-packages\winappdbg\sql.py", line 355, in
> <module>
>     class MemoryDTO (BaseDTO):
>   File "C:\Python27\Lib\site-packages\sqlalchemy\ext\declarative.py", line
> 1126, in __init__
>     _as_declarative(cls, classname, cls.__dict__)
>   File "C:\Python27\Lib\site-packages\sqlalchemy\ext\declarative.py", line
> 1035, in _as_declarative
>     **table_kw)
>   File "C:\Python27\Lib\site-packages\sqlalchemy\schema.py", line 209, in
> __new__
>     table._init(name, metadata, *args, **kw)
>   File "C:\Python27\Lib\site-packages\sqlalchemy\schema.py", line 249, in
> _init
>     self._extra_kwargs(**kwargs)
>   File "C:\Python27\Lib\site-packages\sqlalchemy\schema.py", line 305, in
> _extra_kwargs
>     "Invalid argument(s) for Table: %r" % kwargs.keys())
> TypeError: Invalid argument(s) for Table: ['drizzle_engine',
> 'mysql_engine', 'mysql_charset']
> >>>
>
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
>
> http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
> _______________________________________________
> WinAppDbg-users mailing list
> Win...@li...
> https://lists.sourceforge.net/lists/listinfo/winappdbg-users
>
>


-- 
“There's a reason we separate military and the police: one fights the enemy
of the state, the other serves and protects the people. When the military
becomes both, then the enemies of the state tend to become the people.”

Re: [WinAppDbg-users] Process Created Callback Bug

[Jan N. <jan...@ne...>]

Hi,

another (mildly related) issue I found is that module.get_filename()
usually seems to return the path to the corresponding dll when invoked
from the load_dll event.
However, for ntdll I only get the filename itself ("ntdll.dll"), but
never the full path to it (e.g. "C:\\windows\\system32\\ntdll.dll").

I can reproduce this issue on XP and Win7 64bit.

On 25.11.2014 18:02, Mario Vilas wrote:
> Ah, then it's my fault alright xD
> 
> I'll try to reproduce the bug, I'll send you a private email if I can't
> and need your input :)
> 
> Thanks!
> 
> On Tue, Nov 25, 2014 at 5:41 PM, Jan Newger <jan...@ne...
> <mailto:jan...@ne...>> wrote:
> 
>     Hey Mario,
> 
>     Yes, the same behaviour seems to trigger for load_dll events as well.
> 
>     If there's anything you want me to do / test in order to track down the
>     issue I'd be happy to help!
> 
>     Thanks!
>     Jan
> 
>     On 11/25/2014 05:31 PM, Mario Vilas wrote:
>     > Hi, sorry for the late reply, I've quite a backlog :(
>     >
>     > The error message seems to be coming from the Win32 API, so I'm not sure
>     > if it's a bug in winappdbg itself or just that some operations can't be
>     > performed while the process is still being initialized when the
>     > create_process event is triggered. Does the bug still occur with other
>     > events?
>     >
>     > On Fri, Nov 14, 2014 at 2:39 PM, Jan Newger <jan...@ne... <mailto:jan...@ne...>
>     > <mailto:jan...@ne... <mailto:jan...@ne...>>> wrote:
>     >
>     >     on top of that, the code also fails if i obtain the module
>     from the
>     >     event object itself, i.e.,:
>     >
>     >
>     >     def create_process(self, event):
>     >         main_module = event.get_module()
>     >         module_start = main_module.get_base()
>     >         module_end = main_module.get_base() + main_module.get_size()
>     >         print "Process started: [%X, %X)" % (main_module_start,
>     >     main_module_end)
>     >
>     >     Above code produces the same error.
>     >
>     >     On 11/14/2014 12:48 PM, Jan Newger wrote:
>     >      > Hi there,
>     >      >
>     >      > I'm using the latest version of WinAppDbg on Win7 32bit
>     with python
>     >      > 2.7.5 with the following simple script:
>     >      >
>     >      >
>     >      > === script start ===
>     >      >
>     >      > import sys
>     >      >
>     >      > from winappdbg import Debug
>     >      > from winappdbg import EventHandler
>     >      >
>     >      > class DebugEventHandler(EventHandler):
>     >      >
>     >      >    def create_process(self, event):
>     >      >      main_module = event.get_process().get_main_module()
>     >      >      main_module_start = main_module.get_base()
>     >      >      main_module_end = main_module.get_base() +
>     >     main_module.get_size()
>     >      >      print "Process started: [%X, %X)" % (main_module_start,
>     >      > main_module_end)
>     >      >
>     >      > def start_debugger(cmd_line):
>     >      >    with Debug(DebugEventHandler(), bKillOnExit=True) as debug:
>     >      >      debug.execv(cmd_line)
>     >      >      debug.loop()
>     >      >
>     >      > def main():
>     >      >    start_debugger(sys.argv[1:])
>     >      >
>     >      > === script end ===
>     >      >
>     >      >
>     >      > Invoking the script like this:
>     >      >
>     >      > python test.py C:\windows\system32\notepad.exe
>     >      >
>     >      > gives me an error saying:
>     >      >
>     >      > "C:\Python27\lib\site-packages\winappdbg\module.py:291:
>     >     RuntimeWarning:
>     >      > Cannot get size and entry point of module notepad, reason: The
>     >     handle is
>     >      > invalid"
>     >      >
>     >      >
>     >      > Btw, is there a publicly available issue tracker somewhere?
>     It seems
>     >      > none is listed on the sourceforge page.
>     >      >
>     >      > Thanks and best regards
>     >      > Jan
>     >
>     >
>     >   
>      ------------------------------------------------------------------------------
>     >     Comprehensive Server Monitoring with Site24x7.
>     >     Monitor 10 servers for $9/Month.
>     >     Get alerted through email, SMS, voice calls or mobile push
>     >     notifications.
>     >     Take corrective actions from your mobile device.
>     >   
>      http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk
>     >     _______________________________________________
>     >     WinAppDbg-users mailing list
>     >     Win...@li...
>     <mailto:Win...@li...>
>     >     <mailto:Win...@li...
>     <mailto:Win...@li...>>
>     >     https://lists.sourceforge.net/lists/listinfo/winappdbg-users
>     >
>     >
>     >
>     >
>     > --
>     > “There's a reason we separate military and the police: one fights
>     > the enemy of the state, the other serves and protects the people. When
>     > the military becomes both, then the enemies of the state tend to
>     > become the people.”
>     >
>     >
>     >
>     ------------------------------------------------------------------------------
>     > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>     > from Actuate! Instantly Supercharge Your Business Reports and
>     Dashboards
>     > with Interactivity, Sharing, Native Excel Exports, App Integration
>     & more
>     > Get technology previously reserved for billion-dollar
>     corporations, FREE
>     >
>     http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
>     >
>     >
>     >
>     > _______________________________________________
>     > WinAppDbg-users mailing list
>     > Win...@li...
>     <mailto:Win...@li...>
>     > https://lists.sourceforge.net/lists/listinfo/winappdbg-users
>     >
> 
> 
>     ------------------------------------------------------------------------------
>     Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>     from Actuate! Instantly Supercharge Your Business Reports and Dashboards
>     with Interactivity, Sharing, Native Excel Exports, App Integration &
>     more
>     Get technology previously reserved for billion-dollar corporations, FREE
>     http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
>     _______________________________________________
>     WinAppDbg-users mailing list
>     Win...@li...
>     <mailto:Win...@li...>
>     https://lists.sourceforge.net/lists/listinfo/winappdbg-users
> 
> 
> 
> 
> -- 
> “There's a reason we separate military and the police: one fights
> the enemy of the state, the other serves and protects the people. When
> the military becomes both, then the enemies of the state tend to
> become the people.”
> 
> 
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
> 
> 
> 
> _______________________________________________
> WinAppDbg-users mailing list
> Win...@li...
> https://lists.sourceforge.net/lists/listinfo/winappdbg-users
> 

[WinAppDbg-users] Unsuccessful installation on Windows 7 Pro, 32-Bit

[Tony C. <cap...@gm...>]

After running the msi installer on Windows 7 Pro, 32-Bit , I am unable to
successfully
import winappdbg or any of its modules.

I've deleted the installation directory and reinstalled using pip,
but still cannot successfully import winappdbg or its modules.

Is there a workaround for this issue?

Thanks


Python 2.7.6 (default, Nov 10 2013, 19:24:18) [MSC v.1500 32 bit (Intel)]
on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import winappdbg
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Python27\Lib\site-packages\winappdbg\__init__.py", line 254, in
<module>
    from sql import *
  File "C:\Python27\Lib\site-packages\winappdbg\sql.py", line 355, in
<module>
    class MemoryDTO (BaseDTO):
  File "C:\Python27\Lib\site-packages\sqlalchemy\ext\declarative.py", line
1126, in __init__
    _as_declarative(cls, classname, cls.__dict__)
  File "C:\Python27\Lib\site-packages\sqlalchemy\ext\declarative.py", line
1035, in _as_declarative
    **table_kw)
  File "C:\Python27\Lib\site-packages\sqlalchemy\schema.py", line 209, in
__new__
    table._init(name, metadata, *args, **kw)
  File "C:\Python27\Lib\site-packages\sqlalchemy\schema.py", line 249, in
_init
    self._extra_kwargs(**kwargs)
  File "C:\Python27\Lib\site-packages\sqlalchemy\schema.py", line 305, in
_extra_kwargs
    "Invalid argument(s) for Table: %r" % kwargs.keys())
TypeError: Invalid argument(s) for Table: ['drizzle_engine',
'mysql_engine', 'mysql_charset']
>>>

Re: [WinAppDbg-users] Process Created Callback Bug

[Mario V. <mv...@gm...>]

Ah, then it's my fault alright xD

I'll try to reproduce the bug, I'll send you a private email if I can't and
need your input :)

Thanks!

On Tue, Nov 25, 2014 at 5:41 PM, Jan Newger <jan...@ne...> wrote:

> Hey Mario,
>
> Yes, the same behaviour seems to trigger for load_dll events as well.
>
> If there's anything you want me to do / test in order to track down the
> issue I'd be happy to help!
>
> Thanks!
> Jan
>
> On 11/25/2014 05:31 PM, Mario Vilas wrote:
> > Hi, sorry for the late reply, I've quite a backlog :(
> >
> > The error message seems to be coming from the Win32 API, so I'm not sure
> > if it's a bug in winappdbg itself or just that some operations can't be
> > performed while the process is still being initialized when the
> > create_process event is triggered. Does the bug still occur with other
> > events?
> >
> > On Fri, Nov 14, 2014 at 2:39 PM, Jan Newger <jan...@ne...
> > <mailto:jan...@ne...>> wrote:
> >
> >     on top of that, the code also fails if i obtain the module from the
> >     event object itself, i.e.,:
> >
> >
> >     def create_process(self, event):
> >         main_module = event.get_module()
> >         module_start = main_module.get_base()
> >         module_end = main_module.get_base() + main_module.get_size()
> >         print "Process started: [%X, %X)" % (main_module_start,
> >     main_module_end)
> >
> >     Above code produces the same error.
> >
> >     On 11/14/2014 12:48 PM, Jan Newger wrote:
> >      > Hi there,
> >      >
> >      > I'm using the latest version of WinAppDbg on Win7 32bit with
> python
> >      > 2.7.5 with the following simple script:
> >      >
> >      >
> >      > === script start ===
> >      >
> >      > import sys
> >      >
> >      > from winappdbg import Debug
> >      > from winappdbg import EventHandler
> >      >
> >      > class DebugEventHandler(EventHandler):
> >      >
> >      >    def create_process(self, event):
> >      >      main_module = event.get_process().get_main_module()
> >      >      main_module_start = main_module.get_base()
> >      >      main_module_end = main_module.get_base() +
> >     main_module.get_size()
> >      >      print "Process started: [%X, %X)" % (main_module_start,
> >      > main_module_end)
> >      >
> >      > def start_debugger(cmd_line):
> >      >    with Debug(DebugEventHandler(), bKillOnExit=True) as debug:
> >      >      debug.execv(cmd_line)
> >      >      debug.loop()
> >      >
> >      > def main():
> >      >    start_debugger(sys.argv[1:])
> >      >
> >      > === script end ===
> >      >
> >      >
> >      > Invoking the script like this:
> >      >
> >      > python test.py C:\windows\system32\notepad.exe
> >      >
> >      > gives me an error saying:
> >      >
> >      > "C:\Python27\lib\site-packages\winappdbg\module.py:291:
> >     RuntimeWarning:
> >      > Cannot get size and entry point of module notepad, reason: The
> >     handle is
> >      > invalid"
> >      >
> >      >
> >      > Btw, is there a publicly available issue tracker somewhere? It
> seems
> >      > none is listed on the sourceforge page.
> >      >
> >      > Thanks and best regards
> >      > Jan
> >
> >
> >
>  ------------------------------------------------------------------------------
> >     Comprehensive Server Monitoring with Site24x7.
> >     Monitor 10 servers for $9/Month.
> >     Get alerted through email, SMS, voice calls or mobile push
> >     notifications.
> >     Take corrective actions from your mobile device.
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk
> >     _______________________________________________
> >     WinAppDbg-users mailing list
> >     Win...@li...
> >     <mailto:Win...@li...>
> >     https://lists.sourceforge.net/lists/listinfo/winappdbg-users
> >
> >
> >
> >
> > --
> > “There's a reason we separate military and the police: one fights
> > the enemy of the state, the other serves and protects the people. When
> > the military becomes both, then the enemies of the state tend to
> > become the people.”
> >
> >
> >
> ------------------------------------------------------------------------------
> > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> > from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> > with Interactivity, Sharing, Native Excel Exports, App Integration & more
> > Get technology previously reserved for billion-dollar corporations, FREE
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
> >
> >
> >
> > _______________________________________________
> > WinAppDbg-users mailing list
> > Win...@li...
> > https://lists.sourceforge.net/lists/listinfo/winappdbg-users
> >
>
>
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
>
> http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
> _______________________________________________
> WinAppDbg-users mailing list
> Win...@li...
> https://lists.sourceforge.net/lists/listinfo/winappdbg-users
>



-- 
“There's a reason we separate military and the police: one fights the enemy
of the state, the other serves and protects the people. When the military
becomes both, then the enemies of the state tend to become the people.”

Re: [WinAppDbg-users] Process Created Callback Bug

[Jan N. <jan...@ne...>]

Hey Mario,

Yes, the same behaviour seems to trigger for load_dll events as well.

If there's anything you want me to do / test in order to track down the 
issue I'd be happy to help!

Thanks!
Jan

On 11/25/2014 05:31 PM, Mario Vilas wrote:
> Hi, sorry for the late reply, I've quite a backlog :(
>
> The error message seems to be coming from the Win32 API, so I'm not sure
> if it's a bug in winappdbg itself or just that some operations can't be
> performed while the process is still being initialized when the
> create_process event is triggered. Does the bug still occur with other
> events?
>
> On Fri, Nov 14, 2014 at 2:39 PM, Jan Newger <jan...@ne...
> <mailto:jan...@ne...>> wrote:
>
>     on top of that, the code also fails if i obtain the module from the
>     event object itself, i.e.,:
>
>
>     def create_process(self, event):
>         main_module = event.get_module()
>         module_start = main_module.get_base()
>         module_end = main_module.get_base() + main_module.get_size()
>         print "Process started: [%X, %X)" % (main_module_start,
>     main_module_end)
>
>     Above code produces the same error.
>
>     On 11/14/2014 12:48 PM, Jan Newger wrote:
>      > Hi there,
>      >
>      > I'm using the latest version of WinAppDbg on Win7 32bit with python
>      > 2.7.5 with the following simple script:
>      >
>      >
>      > === script start ===
>      >
>      > import sys
>      >
>      > from winappdbg import Debug
>      > from winappdbg import EventHandler
>      >
>      > class DebugEventHandler(EventHandler):
>      >
>      >    def create_process(self, event):
>      >      main_module = event.get_process().get_main_module()
>      >      main_module_start = main_module.get_base()
>      >      main_module_end = main_module.get_base() +
>     main_module.get_size()
>      >      print "Process started: [%X, %X)" % (main_module_start,
>      > main_module_end)
>      >
>      > def start_debugger(cmd_line):
>      >    with Debug(DebugEventHandler(), bKillOnExit=True) as debug:
>      >      debug.execv(cmd_line)
>      >      debug.loop()
>      >
>      > def main():
>      >    start_debugger(sys.argv[1:])
>      >
>      > === script end ===
>      >
>      >
>      > Invoking the script like this:
>      >
>      > python test.py C:\windows\system32\notepad.exe
>      >
>      > gives me an error saying:
>      >
>      > "C:\Python27\lib\site-packages\winappdbg\module.py:291:
>     RuntimeWarning:
>      > Cannot get size and entry point of module notepad, reason: The
>     handle is
>      > invalid"
>      >
>      >
>      > Btw, is there a publicly available issue tracker somewhere? It seems
>      > none is listed on the sourceforge page.
>      >
>      > Thanks and best regards
>      > Jan
>
>
>     ------------------------------------------------------------------------------
>     Comprehensive Server Monitoring with Site24x7.
>     Monitor 10 servers for $9/Month.
>     Get alerted through email, SMS, voice calls or mobile push
>     notifications.
>     Take corrective actions from your mobile device.
>     http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk
>     _______________________________________________
>     WinAppDbg-users mailing list
>     Win...@li...
>     <mailto:Win...@li...>
>     https://lists.sourceforge.net/lists/listinfo/winappdbg-users
>
>
>
>
> --
> “There's a reason we separate military and the police: one fights
> the enemy of the state, the other serves and protects the people. When
> the military becomes both, then the enemies of the state tend to
> become the people.”
>
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
>
>
>
> _______________________________________________
> WinAppDbg-users mailing list
> Win...@li...
> https://lists.sourceforge.net/lists/listinfo/winappdbg-users
>

Re: [WinAppDbg-users] Process Created Callback Bug

[Mario V. <mv...@gm...>]

Hi, sorry for the late reply, I've quite a backlog :(

The error message seems to be coming from the Win32 API, so I'm not sure if
it's a bug in winappdbg itself or just that some operations can't be
performed while the process is still being initialized when the
create_process event is triggered. Does the bug still occur with other
events?

On Fri, Nov 14, 2014 at 2:39 PM, Jan Newger <jan...@ne...> wrote:

> on top of that, the code also fails if i obtain the module from the
> event object itself, i.e.,:
>
>
> def create_process(self, event):
>    main_module = event.get_module()
>    module_start = main_module.get_base()
>    module_end = main_module.get_base() + main_module.get_size()
>    print "Process started: [%X, %X)" % (main_module_start, main_module_end)
>
> Above code produces the same error.
>
> On 11/14/2014 12:48 PM, Jan Newger wrote:
> > Hi there,
> >
> > I'm using the latest version of WinAppDbg on Win7 32bit with python
> > 2.7.5 with the following simple script:
> >
> >
> > === script start ===
> >
> > import sys
> >
> > from winappdbg import Debug
> > from winappdbg import EventHandler
> >
> > class DebugEventHandler(EventHandler):
> >
> >    def create_process(self, event):
> >      main_module = event.get_process().get_main_module()
> >      main_module_start = main_module.get_base()
> >      main_module_end = main_module.get_base() + main_module.get_size()
> >      print "Process started: [%X, %X)" % (main_module_start,
> > main_module_end)
> >
> > def start_debugger(cmd_line):
> >    with Debug(DebugEventHandler(), bKillOnExit=True) as debug:
> >      debug.execv(cmd_line)
> >      debug.loop()
> >
> > def main():
> >    start_debugger(sys.argv[1:])
> >
> > === script end ===
> >
> >
> > Invoking the script like this:
> >
> > python test.py C:\windows\system32\notepad.exe
> >
> > gives me an error saying:
> >
> > "C:\Python27\lib\site-packages\winappdbg\module.py:291: RuntimeWarning:
> > Cannot get size and entry point of module notepad, reason: The handle is
> > invalid"
> >
> >
> > Btw, is there a publicly available issue tracker somewhere? It seems
> > none is listed on the sourceforge page.
> >
> > Thanks and best regards
> > Jan
>
>
>
> ------------------------------------------------------------------------------
> Comprehensive Server Monitoring with Site24x7.
> Monitor 10 servers for $9/Month.
> Get alerted through email, SMS, voice calls or mobile push notifications.
> Take corrective actions from your mobile device.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk
> _______________________________________________
> WinAppDbg-users mailing list
> Win...@li...
> https://lists.sourceforge.net/lists/listinfo/winappdbg-users
>



-- 
“There's a reason we separate military and the police: one fights the enemy
of the state, the other serves and protects the people. When the military
becomes both, then the enemies of the state tend to become the people.”

Re: [WinAppDbg-users] Process Created Callback Bug

[Jan N. <jan...@ne...>]

on top of that, the code also fails if i obtain the module from the 
event object itself, i.e.,:


def create_process(self, event):
   main_module = event.get_module()
   module_start = main_module.get_base()
   module_end = main_module.get_base() + main_module.get_size()
   print "Process started: [%X, %X)" % (main_module_start, main_module_end)

Above code produces the same error.

On 11/14/2014 12:48 PM, Jan Newger wrote:
> Hi there,
>
> I'm using the latest version of WinAppDbg on Win7 32bit with python
> 2.7.5 with the following simple script:
>
>
> === script start ===
>
> import sys
>
> from winappdbg import Debug
> from winappdbg import EventHandler
>
> class DebugEventHandler(EventHandler):
>
>    def create_process(self, event):
>      main_module = event.get_process().get_main_module()
>      main_module_start = main_module.get_base()
>      main_module_end = main_module.get_base() + main_module.get_size()
>      print "Process started: [%X, %X)" % (main_module_start,
> main_module_end)
>
> def start_debugger(cmd_line):
>    with Debug(DebugEventHandler(), bKillOnExit=True) as debug:
>      debug.execv(cmd_line)
>      debug.loop()
>
> def main():
>    start_debugger(sys.argv[1:])
>
> === script end ===
>
>
> Invoking the script like this:
>
> python test.py C:\windows\system32\notepad.exe
>
> gives me an error saying:
>
> "C:\Python27\lib\site-packages\winappdbg\module.py:291: RuntimeWarning:
> Cannot get size and entry point of module notepad, reason: The handle is
> invalid"
>
>
> Btw, is there a publicly available issue tracker somewhere? It seems
> none is listed on the sourceforge page.
>
> Thanks and best regards
> Jan

[WinAppDbg-users] Process Created Callback Bug

[Jan N. <jan...@ne...>]

Hi there,

I'm using the latest version of WinAppDbg on Win7 32bit with python 
2.7.5 with the following simple script:


=== script start ===

import sys

from winappdbg import Debug
from winappdbg import EventHandler

class DebugEventHandler(EventHandler):

   def create_process(self, event):
     main_module = event.get_process().get_main_module()
     main_module_start = main_module.get_base()
     main_module_end = main_module.get_base() + main_module.get_size()
     print "Process started: [%X, %X)" % (main_module_start, 
main_module_end)

def start_debugger(cmd_line):
   with Debug(DebugEventHandler(), bKillOnExit=True) as debug:
     debug.execv(cmd_line)
     debug.loop()

def main():
   start_debugger(sys.argv[1:])

=== script end ===


Invoking the script like this:

python test.py C:\windows\system32\notepad.exe

gives me an error saying:

"C:\Python27\lib\site-packages\winappdbg\module.py:291: RuntimeWarning: 
Cannot get size and entry point of module notepad, reason: The handle is 
invalid"


Btw, is there a publicly available issue tracker somewhere? It seems 
none is listed on the sourceforge page.

Thanks and best regards
Jan

[WinAppDbg-users] Windows Error 299 in CreateToolhelp32Snapshot?

[Michael A H. <mah...@ra...>]

Hello,

I'm attempting use WinAppDbg to capture exceptions using a script that 
fuzzes offline client files.  Sulley is the fuzzing framework and I'm 
debugging 32-bit applications on Windows 7 Professional, 64-bit. 

My script mutates a file with a Sulley-generated test string, calls the 
target application using subprocess.Popen, then kicks off a child thread 
that attaches the debugger to the process.  The primary thread runs 
time.sleep(user_selected_timeout) and then calls process.terminate() 
followed by process.wait().

After waiting for the debug thread to join, the mutated file is 
overwritten with a "clean" copy and the cycle starts again with a new 
mutation.  Here is the function that the debug thread calls:

def debug_app(pid):

        with Debug(my_event_handler, bKillOnExit = True) as debug:

                try:
                        debug.attach(pid)
                        debug.loop()
                finally:
                        debug.stop()

This will work for up to a few hundred cycles.  Then I get the following 
error:

Exception in thread Thread-XX:

Traceback (most recent call last):
        File "C:\python27\lib\threading.py", line 808, in 
__bootstrap_inner
                self.run()
        File "C:\python27\lib\threading.py", line 761, in run 
                self.__target(*self.__args, **self.__kwargs)
        File "fuzz_something.py", line 109, in debug_Acrobat
                debug.attach(pid)
        File "C:\python27\lib\site-packages\winappdbg\debug.py", line 260, 
in attach
                aProcess.scan_modules()
        File "C:\python27\lib\site-packages\winappdbg\module.py", line 
1056, in scan_modules 
                dwProcessId) as hSnapshot:
        File "C:\python27\lib\site-packages\winappdbg\win32\kernel32.py", 
line 4207, in CreateToolhelp32Snapshot
                raise ctypes.WinError()
        WindowsError: [Error 299] Only part of a ReadProcessMemory or 
WriteProcessMemory request was completed

Has anyone seen this and know how to deal with it?

M Horkan

Re: [WinAppDbg-users] Using WinAppDbg to run Python code in target process

[Nam N. <na...@bl...>]

Fabio,

Do I understand it right that your shellcode is:

mov eax, PyGILState_Ensure
call eax
push <python code>
mov eax, PyRun_SimpleString
call eax
mov eax PyGILState_Release
call eax

The return value from PyGILState_Ensure is stored in EAX after the call. Therefore, you can insert an extra PUSH EAX instruction right after the first "call eax" instruction. That'll setup the stack for the PyGILState_Release at the end.

Cheers,
Nam

On Feb 4, 2014, at 10:43 AM, Fabio Zadrozny <fa...@gm...> wrote:

> Hi All,
> 
> I just recently came upon WinAppDbg and I think it's a really nice tool. 
> 
> I'm the PyDev author (http://pydev.org/) and I was thinking about using it to execute attach the PyDev debugger to a running process.
> 
> The idea would be running something as:
> 
> import sys
> sys.path.append(r'path/to/pysrc')
> import pydevd
> pydevd.settrace()
> 
> So, in order to do that I'd do something as:
> 
> PyGILState_Ensure()
> PyRun_SimpleString("python code")
> PyGILState_Release()
> 
> So, I was wondering how that'd be done using WinAppDbg... 
> 
> I did try to design some Python code using WinAppDbg (which is below), which actually runs some code in the console (just a print for now) in the target process, but crashes right afterwards -- I'm really not well versed on shellcode, and it was mostly based on the inject_dll from the Process, so, I was wondering if this is really the best way and if so, if someone can help me do that properly...
> 
> Thanks,
> 
> Fabio
> 
> ---------------------------------------- test code -------------------------
> from winappdbg import Process, HexDump, win32
> import struct
> 
> def run_python_code(pid):
>     process = Process(pid)
>     
>     # Lookup it's modules.
>     process.scan_modules()
>     
>     p_gil_start = process.resolve_label('PyGILState_Ensure')
>     p_run = process.resolve_label('PyRun_SimpleString')
>     p_gil_end = process.resolve_label('PyGILState_Release')
>     
>     python_code = 'print "m2"'
>     
>     code = ''
> 
>     # Shellcode follows...
> 
>     # mov eax, PyGILState_Ensure
>     code += '\xb8' + struct.pack('<L', p_gil_start)
> 
>     # call eax
>     code += '\xff\xd0'
> 
>     # push python code 
>     code += '\xe8' + struct.pack('<L', len(python_code) + 1) + python_code + '\0'
> 
>     # mov eax, PyRun_SimpleString
>     code += '\xb8' + struct.pack('<L', p_run)
> 
>     # call eax
>     code += '\xff\xd0'
> 
>     # mov eax, PyGILState_Release
>     code += '\xb8' + struct.pack('<L', p_gil_end)
> 
>     # call eax
>     code += '\xff\xd0'
>     
>     
>     process.inject_code(code, 0);
> 
> 
> ------------------------------------------------------------------------------
> Managing the Performance of Cloud-Based Applications
> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
> Read the Whitepaper.
> http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk_______________________________________________
> WinAppDbg-users mailing list
> Win...@li...
> https://lists.sourceforge.net/lists/listinfo/winappdbg-users

Re: [WinAppDbg-users] Using WinAppDbg to run Python code in target process

[Fabio Z. <fa...@gm...>]

Hi Mario,

I think I found an issue there: PyGILState_Ensure() actually returns an int
which has to be passed to PyGILState_Release() later on. Still, I don't
really know how to do this in shellcode... Do you have any pointers on how
to do that?

Thanks,

Fabio


On Tue, Feb 4, 2014 at 5:48 PM, Fabio Zadrozny <fa...@gm...> wrote:

> Hi Mario,
>
> I tried that, but it still didn't work properly (it's still crashing
> afterwards).
>
> Just for completeness, I'm attaching the sources for what I'm testing in
> the e-mail (Python 2.7).
>
> Also, is there any way of doing this without writing shell code? (I'd like
> it to be compatible with a 64 bit process too).
>
> Thanks for taking a look at that :)
>
> --
> Fabio
>
>
> On Tue, Feb 4, 2014 at 5:25 PM, Mario Vilas <mv...@gm...> wrote:
>
>> Hi!
>>
>> I haven't looked at it into detail, but I'd say the problem is the
>> shellcode simply doesn't return - so after the last "call eax" instruction
>> is executed, it just start running whatever happens to be in memory
>> afterwards.
>>
>> So try adding a ret instruction at the end (\xc3 if I recall correctly)
>> and see if that works. If not, let me know and I'll take a deeper look. :)
>>
>> Cheers!
>> -Mario
>>
>>
>> On Tue, Feb 4, 2014 at 7:43 PM, Fabio Zadrozny <fa...@gm...> wrote:
>>
>>> Hi All,
>>>
>>> I just recently came upon WinAppDbg and I think it's a really nice tool.
>>>
>>> I'm the PyDev author (http://pydev.org/) and I was thinking about using
>>> it to execute attach the PyDev debugger to a running process.
>>>
>>> The idea would be running something as:
>>>
>>> import sys
>>> sys.path.append(r'path/to/pysrc')
>>> import pydevd
>>> pydevd.settrace()
>>>
>>>  So, in order to do that I'd do something as:
>>>
>>> PyGILState_Ensure()
>>> PyRun_SimpleString("python code")
>>> PyGILState_Release()
>>>
>>> So, I was wondering how that'd be done using WinAppDbg...
>>>
>>> I did try to design some Python code using WinAppDbg (which is below),
>>> which actually runs some code in the console (just a print for now) in the
>>> target process, but crashes right afterwards -- I'm really not well versed
>>> on shellcode, and it was mostly based on the inject_dll from the Process,
>>> so, I was wondering if this is really the best way and if so, if someone
>>> can help me do that properly...
>>>
>>> Thanks,
>>>
>>> Fabio
>>>
>>> ---------------------------------------- test code
>>> -------------------------
>>> from winappdbg import Process, HexDump, win32
>>> import struct
>>>
>>> def run_python_code(pid):
>>>     process = Process(pid)
>>>
>>>     # Lookup it's modules.
>>>     process.scan_modules()
>>>
>>>      p_gil_start = process.resolve_label('PyGILState_Ensure')
>>>     p_run = process.resolve_label('PyRun_SimpleString')
>>>     p_gil_end = process.resolve_label('PyGILState_Release')
>>>
>>>     python_code = 'print "m2"'
>>>
>>>     code = ''
>>>
>>>     # Shellcode follows...
>>>
>>>     # mov eax, PyGILState_Ensure
>>>     code += '\xb8' + struct.pack('<L', p_gil_start)
>>>
>>>     # call eax
>>>     code += '\xff\xd0'
>>>
>>>     # push python code
>>>     code += '\xe8' + struct.pack('<L', len(python_code) + 1) +
>>> python_code + '\0'
>>>
>>>     # mov eax, PyRun_SimpleString
>>>     code += '\xb8' + struct.pack('<L', p_run)
>>>
>>>     # call eax
>>>     code += '\xff\xd0'
>>>
>>>     # mov eax, PyGILState_Release
>>>     code += '\xb8' + struct.pack('<L', p_gil_end)
>>>
>>>     # call eax
>>>     code += '\xff\xd0'
>>>
>>>
>>>     process.inject_code(code, 0);
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Managing the Performance of Cloud-Based Applications
>>> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
>>> Read the Whitepaper.
>>>
>>> http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> WinAppDbg-users mailing list
>>> Win...@li...
>>> https://lists.sourceforge.net/lists/listinfo/winappdbg-users
>>>
>>>
>>
>>
>> --
>> "There's a reason we separate military and the police: one fights
>> the enemy of the state, the other serves and protects the people. When
>> the military becomes both, then the enemies of the state tend to become the
>> people."
>>
>>
>> ------------------------------------------------------------------------------
>> Managing the Performance of Cloud-Based Applications
>> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
>> Read the Whitepaper.
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
>> _______________________________________________
>> WinAppDbg-users mailing list
>> Win...@li...
>> https://lists.sourceforge.net/lists/listinfo/winappdbg-users
>>
>>
>

Re: [WinAppDbg-users] Using WinAppDbg to run Python code in target process

[Fabio Z. <fa...@gm...>]

import time
import os
print os.getpid()
if __name__ == '__main__':
    while True:
        time.sleep(1)
        print '..'

Re: [WinAppDbg-users] Using WinAppDbg to run Python code in target process

[Mario V. <mv...@gm...>]

Hi!

I haven't looked at it into detail, but I'd say the problem is the
shellcode simply doesn't return - so after the last "call eax" instruction
is executed, it just start running whatever happens to be in memory
afterwards.

So try adding a ret instruction at the end (\xc3 if I recall correctly) and
see if that works. If not, let me know and I'll take a deeper look. :)

Cheers!
-Mario


On Tue, Feb 4, 2014 at 7:43 PM, Fabio Zadrozny <fa...@gm...> wrote:

> Hi All,
>
> I just recently came upon WinAppDbg and I think it's a really nice tool.
>
> I'm the PyDev author (http://pydev.org/) and I was thinking about using
> it to execute attach the PyDev debugger to a running process.
>
> The idea would be running something as:
>
> import sys
> sys.path.append(r'path/to/pysrc')
> import pydevd
> pydevd.settrace()
>
>  So, in order to do that I'd do something as:
>
> PyGILState_Ensure()
> PyRun_SimpleString("python code")
> PyGILState_Release()
>
> So, I was wondering how that'd be done using WinAppDbg...
>
> I did try to design some Python code using WinAppDbg (which is below),
> which actually runs some code in the console (just a print for now) in the
> target process, but crashes right afterwards -- I'm really not well versed
> on shellcode, and it was mostly based on the inject_dll from the Process,
> so, I was wondering if this is really the best way and if so, if someone
> can help me do that properly...
>
> Thanks,
>
> Fabio
>
> ---------------------------------------- test code
> -------------------------
> from winappdbg import Process, HexDump, win32
> import struct
>
> def run_python_code(pid):
>     process = Process(pid)
>
>     # Lookup it's modules.
>     process.scan_modules()
>
>      p_gil_start = process.resolve_label('PyGILState_Ensure')
>     p_run = process.resolve_label('PyRun_SimpleString')
>     p_gil_end = process.resolve_label('PyGILState_Release')
>
>     python_code = 'print "m2"'
>
>     code = ''
>
>     # Shellcode follows...
>
>     # mov eax, PyGILState_Ensure
>     code += '\xb8' + struct.pack('<L', p_gil_start)
>
>     # call eax
>     code += '\xff\xd0'
>
>     # push python code
>     code += '\xe8' + struct.pack('<L', len(python_code) + 1) + python_code
> + '\0'
>
>     # mov eax, PyRun_SimpleString
>     code += '\xb8' + struct.pack('<L', p_run)
>
>     # call eax
>     code += '\xff\xd0'
>
>     # mov eax, PyGILState_Release
>     code += '\xb8' + struct.pack('<L', p_gil_end)
>
>     # call eax
>     code += '\xff\xd0'
>
>
>     process.inject_code(code, 0);
>
>
>
>
> ------------------------------------------------------------------------------
> Managing the Performance of Cloud-Based Applications
> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
> Read the Whitepaper.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
> _______________________________________________
> WinAppDbg-users mailing list
> Win...@li...
> https://lists.sourceforge.net/lists/listinfo/winappdbg-users
>
>


-- 
“There's a reason we separate military and the police: one fights the enemy
of the state, the other serves and protects the people. When the military
becomes both, then the enemies of the state tend to become the people.”

[WinAppDbg-users] Using WinAppDbg to run Python code in target process

[Fabio Z. <fa...@gm...>]

Hi All,

I just recently came upon WinAppDbg and I think it's a really nice tool.

I'm the PyDev author (http://pydev.org/) and I was thinking about using it
to execute attach the PyDev debugger to a running process.

The idea would be running something as:

import sys
sys.path.append(r'path/to/pysrc')
import pydevd
pydevd.settrace()

So, in order to do that I'd do something as:

PyGILState_Ensure()
PyRun_SimpleString("python code")
PyGILState_Release()

So, I was wondering how that'd be done using WinAppDbg...

I did try to design some Python code using WinAppDbg (which is below),
which actually runs some code in the console (just a print for now) in the
target process, but crashes right afterwards -- I'm really not well versed
on shellcode, and it was mostly based on the inject_dll from the Process,
so, I was wondering if this is really the best way and if so, if someone
can help me do that properly...

Thanks,

Fabio

---------------------------------------- test code -------------------------
from winappdbg import Process, HexDump, win32
import struct

def run_python_code(pid):
    process = Process(pid)

    # Lookup it's modules.
    process.scan_modules()

    p_gil_start = process.resolve_label('PyGILState_Ensure')
    p_run = process.resolve_label('PyRun_SimpleString')
    p_gil_end = process.resolve_label('PyGILState_Release')

    python_code = 'print "m2"'

    code = ''

    # Shellcode follows...

    # mov eax, PyGILState_Ensure
    code += '\xb8' + struct.pack('<L', p_gil_start)

    # call eax
    code += '\xff\xd0'

    # push python code
    code += '\xe8' + struct.pack('<L', len(python_code) + 1) + python_code
+ '\0'

    # mov eax, PyRun_SimpleString
    code += '\xb8' + struct.pack('<L', p_run)

    # call eax
    code += '\xff\xd0'

    # mov eax, PyGILState_Release
    code += '\xb8' + struct.pack('<L', p_gil_end)

    # call eax
    code += '\xff\xd0'


    process.inject_code(code, 0);

Re: [WinAppDbg-users] WinAppDbg 1.5 is out!

[John H. <jo...@ca...>]

Woot! Now, I just need a project that requires WinAppDbg to test out the x64 support. =)

Thanks for the awesome tool, Mario.

From: Mario Vilas [mailto:mv...@gm...]
Sent: Friday, December 20, 2013 10:50 AM
To: win...@li...
Subject: [WinAppDbg-users] WinAppDbg 1.5 is out!

What is WinAppDbg?
==================

The WinAppDbg python module allows developers to quickly code instrumentation
scripts in Python under a Windows environment.

It uses ctypes to wrap many Win32 API calls related to debugging, and provides
an object-oriented abstraction layer to manipulate threads, libraries and
processes, attach your script as a debugger, trace execution, hook API calls,
handle events in your debugee and set breakpoints of different kinds (code,
hardware and memory). Additionally it has no native code at all, making it
easier to maintain or modify than other debuggers on Windows.

The intended audience are QA engineers and software security auditors wishing to
test / fuzz Windows applications with quickly coded Python scripts. Several
ready to use utilities are shipped and can be used for this purposes.

Current features also include disassembling x86/x64 native code, debugging
multiple processes simultaneously and produce a detailed log of application
crashes, useful for fuzzing and automated testing.


What's new in this version?
===========================

In a nutshell...

 * full 64-bit support (including function hooks!)
 * added support for Windows Vista and above.
 * database code migrated to SQLAlchemy, tested on:
   + MySQL
   + SQLite 3
   + Microsoft SQL Server
   should work on other servers too (let me know if it doesn't!)
 * added integration with more disassemblers:
   + BeaEngine: http://www.beaengine.org/
   + Capstone: http://capstone-engine.org/
   + Libdisassemble: http://www.immunitysec.com/resources-freesoftware.shtml
   + PyDasm: https://code.google.com/p/libdasm/
 * added support for postmortem (just-in-time) debugging
 * added support for deferred breakpoints
 * now fully supports manipulating and debugging system services
 * the interactive command-line debugger is now launchable from your scripts
   (thanks Zen One for the idea!)
 * more UAC-friendly, only requests the privileges it needs before any action
 * added functions to work with UAC and different privilege levels, so it's
   now possible to run debugees with lower privileges than the debugger
 * added memory search and registry search support
 * added string extraction functionality
 * added functions to work with DEP settings
 * added a new event handler, EventSift, that can greatly simplify coding a
   debugger script to run multiple targets at the same time
 * added new utility functions to work with colored console output
 * several improvements to the Crash Logger tool
 * integration with already open debugging sessions from other libraries is now
   possible
 * improvements to the Process and GUI instrumentation functionality
 * implemented more anti-antidebug tricks
 * more tools and code examples, and improvements to the existing ones
 * more Win32 API wrappers
 * lots of miscellaneous improvements, more documentation and bugfixes as usual!


Where can I find WinAppDbg?
===========================

Project homepage:
-----------------

    http://winappdbg.sourceforge.net/

Download links:
---------------

 Windows installer (32 bits)
   http://sourceforge.net/projects/winappdbg/files/WinAppDbg/1.5/winappdbg-1.5.win32.msi/download

 Windows installer (64 bits)
   http://sourceforge.net/projects/winappdbg/files/WinAppDbg/1.5/winappdbg-1.5.win-amd64.msi/download

 Source code
   http://sourceforge.net/projects/winappdbg/files/WinAppDbg/1.5/winappdbg-1.5.zip/download

Documentation:
--------------

 Online
   http://winappdbg.sourceforge.net/doc/v1.5/tutorial
   http://winappdbg.sourceforge.net/doc/v1.5/reference

 Windows Help
   http://sourceforge.net/projects/winappdbg/files/WinAppDbg/1.5/winappdbg-1.5-tutorial.chm/download
   http://sourceforge.net/projects/winappdbg/files/WinAppDbg/1.5/winappdbg-1.5-reference.chm/download

 HTML format (offline)
   http://sourceforge.net/projects/winappdbg/files/WinAppDbg/1.5/winappdbg-1.5-tutorial.chm/download
   http://sourceforge.net/projects/winappdbg/files/WinAppDbg/1.5/winappdbg-1.5-reference.chm/download

 PDF format (suitable for printing)
   http://sourceforge.net/projects/winappdbg/files/WinAppDbg/1.5/winappdbg-1.5-tutorial.pdf/download
   http://sourceforge.net/projects/winappdbg/files/WinAppDbg/1.5/winappdbg-1.5-reference.pdf/download

Acknowledgements
================

Acknowledgements go to Arthur Gerkis, Chris Dietrich, Felipe Manzano, Francisco
Falcon, @Ivanlef0u, Jean Sigwald, John Hernandez, Jun Koi, Michael Hale Ligh,
Nahuel Riva, Peter Van Eeckhoutte, Randall Walls, Thierry Franzetti, Thomas
Caplin, and many others I'm probably forgetting, who helped find and fix bugs
in the almost eternal beta of WinAppDbg 1.5! ;)

[WinAppDbg-users] WinAppDbg 1.5 is out!

[Mario V. <mv...@gm...>]

What is WinAppDbg?
==================

The WinAppDbg python module allows developers to quickly code
instrumentation
scripts in Python under a Windows environment.

It uses ctypes to wrap many Win32 API calls related to debugging, and
provides
an object-oriented abstraction layer to manipulate threads, libraries and
processes, attach your script as a debugger, trace execution, hook API
calls,
handle events in your debugee and set breakpoints of different kinds (code,
hardware and memory). Additionally it has no native code at all, making it
easier to maintain or modify than other debuggers on Windows.

The intended audience are QA engineers and software security auditors
wishing to
test / fuzz Windows applications with quickly coded Python scripts. Several
ready to use utilities are shipped and can be used for this purposes.

Current features also include disassembling x86/x64 native code, debugging
multiple processes simultaneously and produce a detailed log of application
crashes, useful for fuzzing and automated testing.


What's new in this version?
===========================

In a nutshell...

 * full 64-bit support (including function hooks!)
 * added support for Windows Vista and above.
 * database code migrated to SQLAlchemy, tested on:
   + MySQL
   + SQLite 3
   + Microsoft SQL Server
   should work on other servers too (let me know if it doesn't!)
 * added integration with more disassemblers:
   + BeaEngine: http://www.beaengine.org/
   + Capstone: http://capstone-engine.org/
   + Libdisassemble: http://www.immunitysec.com/resources-freesoftware.shtml
   + PyDasm: https://code.google.com/p/libdasm/
 * added support for postmortem (just-in-time) debugging
 * added support for deferred breakpoints
 * now fully supports manipulating and debugging system services
 * the interactive command-line debugger is now launchable from your scripts
   (thanks Zen One for the idea!)
 * more UAC-friendly, only requests the privileges it needs before any
action
 * added functions to work with UAC and different privilege levels, so it's
   now possible to run debugees with lower privileges than the debugger
 * added memory search and registry search support
 * added string extraction functionality
 * added functions to work with DEP settings
 * added a new event handler, EventSift, that can greatly simplify coding a
   debugger script to run multiple targets at the same time
 * added new utility functions to work with colored console output
 * several improvements to the Crash Logger tool
 * integration with already open debugging sessions from other libraries is
now
   possible
 * improvements to the Process and GUI instrumentation functionality
 * implemented more anti-antidebug tricks
 * more tools and code examples, and improvements to the existing ones
 * more Win32 API wrappers
 * lots of miscellaneous improvements, more documentation and bugfixes as
usual!


Where can I find WinAppDbg?
===========================

Project homepage:
-----------------

    http://winappdbg.sourceforge.net/

Download links:
---------------

 Windows installer (32 bits)

http://sourceforge.net/projects/winappdbg/files/WinAppDbg/1.5/winappdbg-1.5.win32.msi/download

 Windows installer (64 bits)

http://sourceforge.net/projects/winappdbg/files/WinAppDbg/1.5/winappdbg-1.5.win-amd64.msi/download

 Source code

http://sourceforge.net/projects/winappdbg/files/WinAppDbg/1.5/winappdbg-1.5.zip/download

Documentation:
--------------

 Online
   http://winappdbg.sourceforge.net/doc/v1.5/tutorial
   http://winappdbg.sourceforge.net/doc/v1.5/reference

 Windows Help

http://sourceforge.net/projects/winappdbg/files/WinAppDbg/1.5/winappdbg-1.5-tutorial.chm/download

http://sourceforge.net/projects/winappdbg/files/WinAppDbg/1.5/winappdbg-1.5-reference.chm/download

 HTML format (offline)

http://sourceforge.net/projects/winappdbg/files/WinAppDbg/1.5/winappdbg-1.5-tutorial.chm/download

http://sourceforge.net/projects/winappdbg/files/WinAppDbg/1.5/winappdbg-1.5-reference.chm/download

 PDF format (suitable for printing)

http://sourceforge.net/projects/winappdbg/files/WinAppDbg/1.5/winappdbg-1.5-tutorial.pdf/download

http://sourceforge.net/projects/winappdbg/files/WinAppDbg/1.5/winappdbg-1.5-reference.pdf/download

Acknowledgements
================

Acknowledgements go to Arthur Gerkis, Chris Dietrich, Felipe Manzano,
Francisco
Falcon, @Ivanlef0u, Jean Sigwald, John Hernandez, Jun Koi, Michael Hale
Ligh,
Nahuel Riva, Peter Van Eeckhoutte, Randall Walls, Thierry Franzetti, Thomas
Caplin, and many others I'm probably forgetting, who helped find and fix
bugs
in the almost eternal beta of WinAppDbg 1.5! ;)

Re: [WinAppDbg-users] Bugfix process.search_regexp (Win XP, py 2.7)

[Mario V. <mv...@gm...>]

Nice find! :)

I've committed the patch to the SVN trunk:
http://sourceforge.net/p/winappdbg/code/1291/

Cheers!
-Mario


On Mon, Dec 9, 2013 at 1:11 PM, Chris Dietrich <li...@cj...> wrote:

>
> Hey,
>
> I experienced a bug in WinAppDbg Process's search_regexp (1.5 beta 6)
> and wanted to share the fix. The bug manifests as:
>
>   File "C:\Python27\lib\site-packages\winappdbg\search.py", line 621, in
> search_process
>     buffer = process.read(process, address, block_size)
> TypeError: read() takes exactly 3 arguments (4 given)
>
>
> And here is how I fixed it:
>
> ; search.py, line 621
> -                buffer = process.read(process, address, block_size)
> +                buffer = process.read(address, block_size)
>
> ; search.py, line 353
>     def find(self, buffer, pos = None):
> +        if not pos:    # make sure pos is an int
> +            pos = 0
>         match = self.regexp.search(buffer, pos)
>         if match:
>             start, end = match.span()
>             return start, end - start
>         return -1, 0
>
>
> Thanks for a great tool, by the way!
>
> Chris
>
>
> ------------------------------------------------------------------------------
> Sponsored by Intel(R) XDK
> Develop, test and display web and hybrid apps with a single code base.
> Download it for free now!
>
> http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
> _______________________________________________
> WinAppDbg-users mailing list
> Win...@li...
> https://lists.sourceforge.net/lists/listinfo/winappdbg-users
>



-- 
“There's a reason we separate military and the police: one fights the enemy
of the state, the other serves and protects the people. When the military
becomes both, then the enemies of the state tend to become the people.”

[WinAppDbg-users] Bugfix process.search_regexp (Win XP, py 2.7)

[Chris D. <li...@cj...>]

Hey,

I experienced a bug in WinAppDbg Process's search_regexp (1.5 beta 6)
and wanted to share the fix. The bug manifests as:

  File "C:\Python27\lib\site-packages\winappdbg\search.py", line 621, in
search_process
    buffer = process.read(process, address, block_size)
TypeError: read() takes exactly 3 arguments (4 given)


And here is how I fixed it:

; search.py, line 621
-                buffer = process.read(process, address, block_size)
+                buffer = process.read(address, block_size)

; search.py, line 353
    def find(self, buffer, pos = None):
+        if not pos: 	# make sure pos is an int
+            pos = 0
        match = self.regexp.search(buffer, pos)
        if match:
            start, end = match.span()
            return start, end - start
        return -1, 0


Thanks for a great tool, by the way!

Chris