generic_fuzzer.py and PyKd startProcess() arguments

[m0t]

With the latest pykd (0.3.1.2) i get the following error running generic_fuzzer.py on Windows

[Thu May 12 17:05:07 2016 1648:1752] Exception: Python argument types in
    pykd.pykd.startProcess(str)
did not match C++ signature:
    startProcess(class std::basic_string<wchar_t,struct std::char_traits<wchar_t>,class std::allocator<wchar_t> > commandline)
    startProcess(class std::basic_string<wchar_t,struct std::char_traits<wchar_t>,class std::allocator<wchar_t> > commandline, unsigned long debugOptions)

I think something must have changed in pykd startProcess() function, as the problem seems to be at pykd_iface.py:248
self.id = pykd.startProcess(self.program, debugChildren=True)

removing debugChildren=True seems to fix this. I need debugChildren but I'm very lazy, so I just downloaded pykd 0.3.0.38 and I'm now happy again, but there's probably a different way to pass that argument now.

[joxeankoret]

Uhm... thanks for reporting! I will talk with pykd's author.

[ussrhero]

startProcess starting pykd 0.3.1.x has changed signature, so the right call will be:
startFlags = ProcessDebugOptions.DebugChildren startProcess(self.program, startFlags)

[joxeankoret]

@ussrhero How can I get which Pkd's version has the user installed? I would like to support both ways. Thanks!

[m0t]

I'm not a python expert, maybe there's an official way, but this seems to work:

import pykd
pykd.version
'0.3.1.2'

[joxeankoret]

Is more than enough for me, I will fix it soon. Thanks @m0t !

[pyoor]

@mot, is this fix working for you under 0.3.1.4? It looks like there is an issue using 'ProcessDebugOptions.DebugChildren' which prevents pykd from breaking in when the timeout is reached. Can you confirm otherwise?

[joxeankoret]

Sorry for being late, these dates are not the best one for me :/

There are many issues with pykd, different versions, different bugs/issues between versions as well as incompatibilities among different versions. For me, the latest fix is working, but it seems that for others (like you @pyoor and another anonymous one) is not working. Really, I'm not sure how to fix that yet :/

[joxeankoret]

PS: An alternate workaround that others proposed is to add another, one more, debugging interface for WinAppDbg, created by @MarioVilas.

[MarioVilas]

I would be really happy with that :D can't do it myself though. I agree that the more interfaces the better, as they all tend to break over time - Microsoft really doesn't like it when other people write debuggers for their OS and the debug APIs break all the time, have incomplete or plain wrong specs, etc. I can't even recall how many times I ended up reverse engineering Windows DLLs just to figure out how to make the debugger work. :P

As far as alternatives go, here are a few more: http://winappdbg.sourceforge.net/#related-projects

[pyoor]

Obviously there are several different ways we can handle this. FOE leverages CDB for crash handling and it seems to be relatively stable. It wouldn't take much to modify their existing implementation for use with nightmare.

https://github.com/CERTCC-Vulnerability-Analysis/certfuzz/blob/master/src/certfuzz/debuggers/msec.py

[hacksysteam]

Guys, I had the same issue and I made it to work.

pykd.startProcess(self.program, pykd.ProcessDebugOptions.BreakOnStart | pykd.ProcessDebugOptions.DebugChildren)

Now, it will break as soon as the process starts and everything goes normal.

Thanks.