Exception when not debugger attached to a process

[0xbc]

Hi,

First of all, thanks so much for working on mona support for x64dbg - awesome job!

I got mona up and running successfully in x64dbg, and one of the first commands I tried was pc:

[+] Command used:
!mona pc 100
Creating cyclic pattern of 100 bytes
Aa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab6Ab7Ab8Ab9Ac0Ac1Ac2Ac3Ac4Ac5Ac6Ac7Ac8Ac9Ad0Ad1Ad2A
[+] Preparing output file 'pattern.txt'
<pykd.typePtr object at 0x05AA0770>
<b>********************************************************************************</b>
<b>Traceback (most recent call last):</b>
<b>  File "C:\Users\hax\DOWNLO~1\SNAPSH~1\release\x32\plugins\x64dbgpy\mona.py", line 18398, in main</b>
<b>    commands[cmd].parseProc(opts)</b>
<b>  File "C:\Users\hax\DOWNLO~1\SNAPSH~1\release\x32\plugins\x64dbgpy\mona.py", line 11601, in procCreatePATTERN</b>
<b>    patternfile = objpatternfile.reset()</b>
<b>  File "C:\Users\hax\DOWNLO~1\SNAPSH~1\release\x32\plugins\x64dbgpy\mona.py", line 2454, in reset</b>
<b>    debuggedname = dbg.getDebuggedName()</b>
<b>  File "C:\Users\hax\DOWNLO~1\SNAPSH~1\release\x32\plugins\x64dbgpy\x64dbgpylib.py", line 901, in getDebuggedName</b>
<b>    sImageFile = pykd.loadUnicodeString(ProcessParameters + offset).encode("utf8")</b>
<b>  File "C:\Users\hax\DOWNLO~1\SNAPSH~1\release\x32\plugins\x64dbgpy\pykd.py", line 261, in loadUnicodeString</b>
<b>    raise DbgException("Corrupted UNICODE_STRING structure")</b>
<b>DbgException: Corrupted UNICODE_STRING structure</b>
<b></b>
<b>********************************************************************************</b>

The root cause here seems to be that there was nothing being debugged at the time, and so the pointer returned by getPEBInfo is garbage (which is then used to try and get the name of the process being debugged). I had a bit of a dig around to try and make a fix for this but was a bit unsure how to proceed - ideally I thought there might be a flag to check in x64dbgpylib.Debugger as to whether the debugger is attached to something, but I coudn't see anything (I may just have missed it!)

I also checked getDebuggedPid, which did return a value which I assume is also garbage. I noticed that the equivalent code in windbglib didn't have any extra checks, so I assume that the backend there behaves differently in this case?

Cheers, Ben

[wangray]

So the x64dbg API has a function that can tell you whether there is an active debugger.

In the case of WinDBG, you simply can't run commands without an attached debugger, I think.

This PR is a proposed fix, what do you think: https://github.com/x64dbg/x64dbgpylib/pull/11

[wangray]

But in general, other places in the code will throw an error if you don't have something being debugged. Like modules will also give Corruped UNICODE_STRING if nothing's being debugged. I'm not too concerned about this, but please add some checks using isDebugging if you like.

[mrexodia]

can't we just fully block all mona commands if isDebugging is false?

[wangray]

I guess some commands should be able to run without a running executable, such as cyclic pattern or assemble.

[mrexodia]

Yeah true, perhaps add a bool in command registration whether the command can be run while not debugging (similar to x64dbg commands)? On Fri, 8 Dec 2017 at 23:02, Ray Wang notifications@github.com wrote:

I guess some commands should be able to run without an attached process, such as cyclic pattern or assemble.

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/x64dbg/x64dbgpylib/issues/10#issuecomment-350383450, or mute the thread https://github.com/notifications/unsubscribe-auth/ACWCmTBSLUb2LlAWgmwYKD0NL0jvgSsqks5s-bIDgaJpZM4Qz8Wa .

[0xbc]

Cheers - the fix looks good to me!

I agree adding a flag to command registration would be a good idea - just wondering though what the aim is here re. merging back to upstream mona? As in, is the plan eventually to close the x64dbg fork of mona once it's all working, and in that case, is Peter going to accept API changes like that?

[mrexodia]

I don’t think mona is actually being actively developed anymore but the changes aren’t too invasive, only improvements. On Fri, 8 Dec 2017 at 23:45, Ben Cheney notifications@github.com wrote:

Cheers - the fix looks good to me!

I agree adding a flag to command registration would be a good idea - just wondering though what the aim is here re. merging back to upstream mona? As in, is the plan eventually to close the x64dbg fork of mona once it's all working, and in that case, is Peter going to accept API changes like that?

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/x64dbg/x64dbgpylib/issues/10#issuecomment-350390933, or mute the thread https://github.com/notifications/unsubscribe-auth/ACWCmQUY2O2uwuZRI7sKZxl3SVr4P8buks5s-bvSgaJpZM4Qz8Wa .

[wangray]

I'm not in a hurry to get this merged upstream any time soon — I'm all for making whatever changes we need for x64dbg without worrying what happens with Immunity/WinDBG.

The Immunity and WinDBG backends are rather different, anyways.