Can't sync IDA & WinDbg Preview

[hex64dbg]

Hi,

I followed the following instructions :

• Installed the IDA plugin (IDA 7.2) and launched it, I have the following output in the console

[sync] default idb name: win32kfull.sys
[sync] sync enabled
[sync] cmdline: "C:\Python27\python.exe" -u "C:\Program Files\IDA 7.2\plugins\retsync\broker.py" --idb "win32kfull.sys"
[sync] module base 0x1c0000000
[sync] hexrays #7.2.0.181105 found
[sync] broker started
[sync] plugin loaded
[sync] << broker << connected to dispatcher
[sync] << broker << listening on port 55368

• Compiled WinDbg extension and placed in "C:\Users\user\AppData\Local\Microsoft\WindowsApps" (using WinDbg Preview)
• .load sync
[sync] DebugExtensionInitialize, ExtensionApis loaded
• !sync

[sync] No argument found, using default host (127.0.0.1:9100)
[sync] sync success, sock 0x348
[sync] probing sync
[sync] sync is now enabled with host 127.0.0.1
[sync] recv: connection closed
[sync] sync is off

But there is no more output in the IDA console. How can I troubleshoot this issue please ?

[bootleg]

Hi hex64dbg,

To troubleshot the issue you can enable JSON log in rsconfig.py (IDA retstync plugin)

ret-sync/ext_ida/retsync/rsconfig.py

Line 110 in ac41c81

DEBUG_JSON = False

To this:

# enable/disable logging JSON received in the IDA output window
DEBUG_JSON = True

# global log level (console output)
LOG_LEVEL = logging.DEBUG

Also you can enable extra debugging for dispatcher and broker in the rsconfig.py file:

# enable/disable broker and dipatcher exception logging to file
LOG_TO_FILE_ENABLE = True

It will generate a log file in your %tmp% folder if an exception is triggered (like retsync.dispatcher.py.err)

Just as a guess, it seems dispatcher encounters an issue and crash without warning its broker(s). Hopefully log file will tell us more.

[hex64dbg]

Thanks a lot for the help.

I followed you instructions. Here is the IDA ouptut

[sync] plugin loaded
[sync] parse_exec -> [sync]{"type":"broker","subtype":"msg","msg":"connected to dispatcher"}
[sync] << broker << connected to dispatcher
[sync] parse_exec -> [sync]{"type":"broker","subtype":"notice","port":"52989"}
[sync] << broker << listening on port 52989

Then in WinDbg

0: kd> .load sync
[sync] DebugExtensionInitialize, ExtensionApis loaded
0: kd> !sync
[sync] No argument found, using default host (127.0.0.1:9100)
[sync] sync success, sock 0x344
[sync] probing sync
[sync] sync is now enabled with host 127.0.0.1
[sync] recv: connection closed
[sync] sync is off

And there is still no output in IDA. A log file was generated in the %tmp% folder "retsync.broker.py.err", but it's empty.

So I think the issue is on the WinDbg side. The WinDbg extension was compiled with VS2019, x64 configuration. Maybe you could provide pre-built binaries, like for the other extensions ?

I also tried Ghidra and there is also an issue, this confirms the problem lies with WinDbg. Can I enable verbose extension debugging in WinDbg like in IDA ?

Here is the Ghidra output

*] retsync init
[>] programOpened: ntoskrnl.exe
    imageBase: 0x140000000
[>] xxxxxxx programActivated: ntoskrnl.exe
    local addr: 140000000, remote: unknown

The plugin windows always shows "status: idle", even after I !sync from WinDbg

Thanks for your time.

[bootleg]

So I think the issue is on the WinDbg side. The WinDbg extension was compiled with VS2019, x64 configuration. Maybe you could provide pre-built binaries, like for the other extensions ?

Regarding this point, I don't get it, Windbg extensions are provided as well on the pipeline, see:

https://dev.azure.com/bootlegdev/ret-sync-release/_build/results?buildId=78&view=artifacts&type=publishedArtifacts

update: The UI has changed a little, under "related" tab, one should click on 6 published. Not very intuitive. Sorry for that

From:

[sync] plugin loaded
[sync] parse_exec -> [sync]{"type":"broker","subtype":"msg","msg":"connected to dispatcher"}
[sync] << broker << connected to dispatcher
[sync] parse_exec -> [sync]{"type":"broker","subtype":"notice","port":"52989"}
[sync] << broker << listening on port 52989

It seems the dispatcher is definitely implied here, you should receive more message from him.

What you experience here, reminds me of the symptoms from :
#32

Would it be possible that the port 9100 (or another one if you've redefined it), is already used? Possibly by a zombie Python process ? There may be a common issue that I don't fully get so far.

[hex64dbg]

Regarding this point, I don't get it, Windbg extensions are provided as well on the pipeline, see:

https://dev.azure.com/bootlegdev/ret-sync-release/_build/results?buildId=78&view=artifacts&type=publishedArtifacts

Sorry I missed that, but it didn't solve the issue.

Would it be possible that the port 9100 (or another one if you've redefined it), is already used?

Exactly ! That process is Logitech G HUB and it uses the same port indeed.

Everything is settled, thank you for the support.