Hi, thanks a lot for your work on ret-sync.
I've been trying to get a decent reverse engineering setup running on mac but so far with no luck.
I've tried using ret-sync on ghidra with gdb and lldb, with the former seemingly connecting and syncing up but hanging if you set a breakpoint using F2 (and anyway always showing "Client program: none") while the latter not being recognized and ignoring bps and all (dialect: unknown client debugger: unknown).
Is anyone using ret-sync on macos successfully?

This could be done in several ways. The issue that made me request this is accidentally loading a 64bit dll in IDA while debugging a 32bit application in windbg. If the plugin could verify that some basic info is matching (CPU, for instance) it could safe time on such issues.

I've found myself using Binary Ninja more and more recently, and really like the way that ret-sync makes x64dbg work with Ghidra. It'd be really useful if the same thing could be done in Binary Ninja. BN supports pure-python plugins, and I am primarily a Python developer so I'm happy to do the dev work. I have no concept of where to start though.

Is there any way you could point me in the correct direction?

Also, thank you for making this to begin with. It's fricken' awesome.

ret-sync never seems to sync with gdb. Screenshot is attached showing ret-sync loaded in both gdb and Ghidra and Ghidra listening on port 9100 but no connection made. I can confirm the java process listed in lsof is Ghidra.

I've been looking around but still haven't found how to connect ret-sync with windbg + ghidra.

After pressing 'start listening' it shows N/A on the debugger option and on the last one.
Will you please help me on setting it up?

[sync] default idb name: ex1 - Copy.exe
[sync] sync enabled
[sync] cmdline: "C:\msys64\usr\bin\python.exe" -u "C:\Program Files\IDA Pro 7.5\plugins\retsync\broker.py" --idb "ex1 - Copy.exe"
[sync] module base 0x400000
[sync] hexrays #7.5.0.201028 found
[sync] broker started
[sync] plugin loaded
[sync] [<] bad hdr '[-] dispatcher path is not properly set, current value: </c/Users/XXXX/Documents/ex/dispatcher.py>'
[sync] [-] Request dropped due to bad header
[sync] broker finished
[sync] idb is disabled

the script seems to search dispatcher.py in my idb folder, whereas dispatcher.py is in plugins folder.

Ghidra plugin constantly says
[<] cmd not implemented: rln
for almost anything, like bbt command, for example.
And for rln command too, of course.

I get a [sync] >> set bp 0x4016a5 message, the breakpoint is set in x32dbg but not in ida.

only source don't know how to programming, i need a compiled exe. thanks.

There are exceptions when I trying to attach the windbg debugger to ida 7.4:

Traceback (most recent call last):
  File "C:/Program Files/IDA Pro 7.4/plugins/SyncPlugin.py", line 805, in cb_broker_on_out
    self.worker.parse_exec(req.strip())
  File "C:/Program Files/IDA Pro 7.4/plugins/SyncPlugin.py", line 596, in parse_exec
    req_handler(hash)
  File "C:/Program Files/IDA Pro 7.4/plugins/SyncPlugin.py", line 508, in req_set_dbg_dialect
    SyncForm.init_hotkeys()
  File "C:/Program Files/IDA Pro 7.4/plugins/SyncPlugin.py", line 1009, in init_hotkeys
    ('F2', self.broker.worker.bp_notice, 'BreakpointToggle'),
AttributeError: 'SyncForm_t' object has no attribute 'broker'```

and one more exception is thrown for some reason while debugging:
```Traceback (most recent call last):
  File "C:/Program Files/IDA Pro 7.4/plugins/SyncPlugin.py", line 805, in cb_broker_on_out
    self.worker.parse_exec(req.strip())
  File "C:/Program Files/IDA Pro 7.4/plugins/SyncPlugin.py", line 599, in parse_exec
    req_handler(hash)
  File "C:/Program Files/IDA Pro 7.4/plugins/SyncPlugin.py", line 217, in req_loc
    self.hexsync.cb_loc(ea)
  File "C:/Program Files/IDA Pro 7.4/plugins\retsync\syncrays.py", line 99, in cb_loc
    func_ea = idaapi.get_func(ea).start_ea
AttributeError: 'NoneType' object has no attribute 'start_ea'```

Description

I use ret-sync with gdb. And my gdb and ida are on ther same Destop. So, when I just send ni in gdb, the ida window jump out !!! Then I have to switch back to gdb. What a annoyance !!!

My Solution

First, I just comment the idaapi.jumpto(ea) in SyncPlugin.py, and the annoyance gone.
But there's still sometimes I need to check ida. So I and some code.
SyncPlugin.py

''' this code is in class RequestHandler '''
    def req_loc2(self, hash):
        offset, base = hash['offset'], hash.get('base')
        ea = self.rebase(base, offset)
        if not ea:
            return
        idaapi.jumpto(ea)
''' here I register my function '''
    self.req_handlers = {
            'broker': self.req_broker,
            'loc': self.req_loc,
            'loc2': self.req_loc2,
            'cmd': self.req_cmd,
            'cmt': self.req_cmt,
            'rcmt': self.req_rcmt,
            'fcmt': self.req_fcmt,
            'raddr': self.req_raddr,
            'cursor': self.req_cursor,
            'patch': self.req_patch,
            'rln': self.req_rln,
            'rrln': self.req_rrln,
            'lbl': self.req_lbl,
            'bc': self.req_bc,
            'bps_get': self.req_bps_get,
            'bps_set': self.req_bps_set,
            'modcheck': self.req_modcheck,
            'dialect': self.req_set_dbg_dialect
        }

sync.py

class Loc(gdb.Command):

    def __init__(self, sync):
        gdb.Command.__init__(self, "loc", gdb.COMMAND_OBSCURE, gdb.COMPLETE_NONE)
        self.sync = sync

    def invoke(self, arg, from_tty):
        offset = get_pc()
        if not offset:
            print("<not running>")
            return
        if not self.sync.base:
            print("[sync] process not synced, command is dropped")
            return
        if not self.sync.pid:
            self.sync.pid = get_pid(ctx=self.sync.ctx)
            if self.sync.pid is None:
                print("[sync] failed to get pid")
                return
            else:
                print("[sync] pid: %s" % self.sync.pid)

        self.sync.offset = offset
        mod = self.sync.mod_info(self.sync.offset)
        if mod:
            if VERBOSE >= 2:
                print("[sync] mod found")
                print(mod)

            base, sym = mod

            if self.sync.base != base:
                self.sync.tunnel.send("[notice]{\"type\":\"module\",\"path\":\"%s\"}\n" % sym)
                self.sync.base = base

            self.sync.tunnel.send("[sync]{\"type\":\"loc2\",\"base\":%d,\"offset\":%d}\n" % (self.sync.base, self.sync.offset))
        else:
            print("[sync] unknown module at current PC: 0x%x" % self.offset)
            print("[sync] NOTE: will resume sync when at a known module address")
            self.base = None
            self.offset = None
''' also need to be registered '''
    Loc(sync)

Insert these code properly, and just type loc in gdb, ida cursor will be updated, instead of updating everytime.

Suggestion

Forget about my ugly code. Hope my problem will be solved in future edition.

Is there an ETA for Ghidra 9.2 compatibility now that it is released to the public?
You can update the properties file to be seen as valid, but the configuration phase crashes.
Thanks

Currently, the plugin can create windbg breakpoints directly from IDA (using F2), but there is not way to disable them via IDA.

Also, the created BP does not show up in the IDA GUI, making it difficult to keep track.

I wasn't completely sure because all the breakpoint commands mention over windebug which doesn't exist on mac.

From my short test with IDA, setting breakpoints in IDA doesn't reflect inside lldb so I'm guessing no, but might also just be my setup that's the problem.

Just tried to use ret-sync on a GDB installation that only had Python 2.7 support. Bombed with complaints about line 524:

super().__init(sync, True)
TypeError: super() takes at least 1 argument (0 given)

I have extremely minimal Python fu, but some Googling suggests that the syntax being used there is Python 3-specific. Using the copy of sync.py from this commit (which is the commit before the one that introduced that new syntax) loads fine (I'm yet to use it in anger).

I'm not asking for Python 2.7 support to necessarily be retained -- it is well past its use-by date. It's just that the README still says that Python 2 is supported, and if the intention is that that is no longer the case, it'd be good to get the docs up-to-date.

I have installed everything and got sync'ed. I can step over and both programs are coordinated.

However I am wondering how I can populate labels/comments/var names from Ghidra to x64dbg and viceversa:
1- I opened a file with some changes made from Ghidra but these are not populated into x64dbg.
2- After synchronizing, by setting the comment manually in either program (e.g. by using ";") does not do any synchronization and the comment remains local to the program.
3- If I try to manually execute "cmt Test", "cmt -a 401039 Test", "cmt "Test"", etc from x64dbg I get an error saying "Not enough arguments! At least 2 arguments must be specified"

1 is the most convenient, as I might have a disassembled file with some renaming already and it would be great to have this populated into the debugger.

2 is also nice, as I can make changes as they are both opened, by using the usual options from Ghidra or x64dbg, and get it populated to the other.

3 is not ideal, since I need to use specific commands (instead of e.g. pressing ";" for comment) and it seems to work only while they both are open.

This would ease installation for most people.

That way it will be easier to use.

In some cases, the !bpcmds save commands fails. When it does, I get the following output in IDA, and Windbg hangs.

[-] Sync failed to parse json
 {"type":"bps_set","msg":"censored-base64-sensitive-data"
------------------------------------
\[<] bad hdr '}'
[-] Request dropped due to bad header

Since this only happens once every few attempts, it is a bit tricky to reproduce (failed to do that on purpose so far) and therefore tricky to debug.

I debug a program (with x64dbg) that create a new memory allocation (VirtualAlloc) en drop executable code inside and then jmp to this memory.
Before jump I dump this allocation to file and I load it as new segment in IDA Pro, I set the same address as in x64dbg.
However, ret-sync won't jump inside because it isn't in the module :

[sync] UpdateState(00540585): could not get module base...

(00540585 exist in IDA after creating manually seg/loading bin)

So, before reading all plugin Python code, is any solution to follow code in allocation ?

hi, i'm debugging the windows kernel. but it can't be synchronized. so i create the custom file, .sync.

[ALIASES]
nt=ntoskrnl.exe

, but once i opend ida and load the plugin, it failed. i dont' know where i made fault.Can you give me some help, thanks.

When I 've configured gdb to use ret-sync i've this error:

(gdb) source /home/solace/Téléchargements/ret-sync/ext_gdb/sync.py
/........../sync.py:1031: DeprecationWarning: The SafeConfigParser class has been renamed to ConfigParser in Python 3.2. This alias will be removed in future versions. Use ConfigParser directly instead.
config = configparser.SafeConfigParser({'host': HOST, 'port': PORT, 'context': '', 'use_tmp_logging_file': USE_TMP_LOGGING_FILE})
[sync] configuration file loaded from: /root/.sync
interface: x.x.x.x:zzzz
[sync] init
[sync] 18 commands added
(gdb) quit

So i've just correct it by change SafeConfigParser to ConfigParser.
Is it possible to commit the correction ?

best regards

Most emulators like RPCS3 and pcsx2 feature gdb stubs (example) that allow a gdb client like gdb's or IDA's to debug the emulated guest.

I would like to have an emulator as the "debugger" & sync that with Ghidra.

Can it work with arbitrary gdb stubs this way? Or are the existing GDB tools only for using it with a program that's run/managed by GDB?

If not, I suppose I'd need to write and extension myself, like the one for x64dbg etc. (but presumably in the emulator's own codebase). Any docs/pointers on that or should I just study the existing one's code to figure it out?

Thank you, great plugins!

Traceback (most recent call last):
  File "/Applications/IDA Pro 7.0/ida64.app/Contents/MacOS/plugins/SyncPlugin.py", line 824, in cb_broker_on_out
    self.worker.parse_exec(req.strip())
  File "/Applications/IDA Pro 7.0/ida64.app/Contents/MacOS/plugins/SyncPlugin.py", line 614, in parse_exec
    req_handler(hash)
  File "/Applications/IDA Pro 7.0/ida64.app/Contents/MacOS/plugins/SyncPlugin.py", line 386, in req_rrln
    addr = idc.get_name_ea_simple(sym)
  File "/Applications/IDA Pro 7.0/ida64.app/Contents/MacOS/python/idc.py", line 1888, in get_name_ea_simple
    return ida_name.get_name_ea(BADADDR, name)
  File "/Applications/IDA Pro 7.0/ida64.app/Contents/MacOS/python/ida_name.py", line 258, in get_name_ea
    return _ida_name.get_name_ea(*args)
TypeError: in method 'get_name_ea', argument 2 of type 'char const *'

This is because the IDAPython 2.7 api can't convert type unicode to str implicitly from the api level.

This can be resolved at SyncPlugin.py:385

 addr = idc.get_name_ea_simple(sym)

to

 addr = idc.get_name_ea_simple(str(sym))

Thanks!

I installed the plugin for this two programs, and x32dbg says "sync is now enabled with host 127.0.0.1"
and IDA Says: "[sync] << broker << connected to dispatcher
[sync] << broker << listening on port 57776"

now how do i connected between them?

Ret-sync is a very useful tool, and I've used it before.But when I used it again recently, it didn't work.Please give me a hand
IDA7.5 cannot be used,Did I make a configuration mistake?
Output infomations:
[sync] default idb name: PEhash.exe
[sync] sync enabled
[sync] cmdline: "C:\python39-x64\python.exe" -u "D:\01_Tools\06_IDA7.5\IDA_7.5\plugins\retsync\broker.py" --idb "PEhash.exe"
[sync] module base 0x400000
[sync] hexrays #7.5.0.201028 found
[sync] broker started
[sync] plugin loaded
[sync] << broker << connected to dispatcher
[sync] << broker << beacon not received (possible dispatcher error)
[sync] << broker << received kill notice
[sync] broker finished
[sync] idb is disabled

    # return address for a given idb's symbol
    def req_rrln(self, hash):
        sym, rbase, offset, base = hash['sym'], hash['rbase'], hash['offset'], hash['base']

        rs_log("%s -  0x%x - 0x%x - 0x%x" % (sym, rbase, offset, base))

        addr = idc.get_name_ea_simple(str(sym))
        if addr:
            self.notice_broker("cmd", "\"cmd\":\"%s\"" % addr)
            rs_log("resolved address: %s" % addr)
        else:
            rs_log("could not resolve address for symbol %s" % sym)

This function ignores the base argument from hash['base'] and does not calculate an address based off of the ida base and remote base.

I believe this should change so that the ida base is remove from the address and the remote base is added before returning. This should result in an address that is relative to the remote module.

    # return address for a given idb's symbol
    def req_rrln(self, hash):
        sym, rbase, offset, base = hash['sym'], hash['rbase'], hash['offset'], hash['base']

        rs_log("%s -  0x%x - 0x%x - 0x%x" % (sym, rbase, offset, base))

        addr = idc.get_name_ea_simple(str(sym))
        if addr:
            # rebase the address to remote base
            addr = addr - self.base + hash['base']
            self.notice_broker("cmd", "\"cmd\":\"%s\"" % addr)
            rs_log("resolved address: %s" % addr)
        else:
            rs_log("could not resolve address for symbol %s" % sym)

I used ret-sync to sync ghidra with gdb.
Everything goes right until I try running the program in gdb, then it runs correctly on gdb but ghidra doesn't show anything.
The console says:
[*] retsync init
[>] ret-sync enable
[>] server listening
[>] server started
[<] new_dbg: dbg connect - Linux #1 SMP Debian 5.7.6-1kali2 (2020-07-01) x86_64
dialect: gdb
[x] program unavailable: program_name

Is there a way to fix this?

0: kd> !sync
[sync] No argument found, using default host (127.0.0.1:9100)
[sync] connect failed (check if broker is running)
[sync] probing sync
[sync] TunnelSend: tunnel is unavailable
[sync] sync aborted

dispatcher failed
-> AttributeError("'NoneType' object has no attribute 'enabled'",)

do you have plans for olly1 support?

can we implement our own exported versions of exported functions instead of using the .lib?

Place the downloaded ida plugin in the plugin directory according to the document method. The plugin cannot be seen in ida, and the version is ida 7.3

Currently, the code is designed to work with Qt5 only.

If ret-sync support symbols sync , it will be really great for debugging.
Symbols include function names and some variable names(or static) are important.
https://github.com/ALSchwalm/dwarfexport this project use ida to export dwarf for gdb.
https://github.com/danigargu/syms2elf this project export elf for gdb.
I think there is a better way to use ret-sync to do this job.
Also, pwndbg has a ida_script.py, which has a similar function to this project. But that script can resolve the symbols in IDA.
Don't know if I can do anything to help.

Today I decided to use the Python debug to find out what was going on with this fantastic software.
There is an error when is loading the API (idaapi), IDA has changed the name of dll and how it is making the connection with function, Do you pretend to rewrite the program?

At the moment, it is unclear how one should customize colors.

Having a separate configuration file for colors (and other configuration?) will be much appreciated.

#4 #6 and #9 have been open for months

Hi!

I just tested your amazing plugin and I get this exception after setting a breakpoint in IDA.

It seems like self.base_remote is None.

Exception in ida_kernwin.UI_Hooks dispatcher function: SWIG director method error. Error detected when calling 'UI_Hooks.preprocess_action'
Traceback (most recent call last):
  File "C:/Users/user/AppData/Roaming/Hex-Rays/IDA Pro/plugins/SyncPlugin.py", line 922, in preprocess_action
    self.hooked[action_name]()
  File "C:/Users/user/AppData/Roaming/Hex-Rays/IDA Pro/plugins/SyncPlugin.py", line 629, in bp_notice
    offset = self.rebase_remote(ea)
  File "C:/Users/user/AppData/Roaming/Hex-Rays/IDA Pro/plugins/SyncPlugin.py", line 174, in rebase_remote
    offset = (offset - self.base) + self.base_remote
TypeError: unsupported operand type(s) for +: 'int' and 'NoneType'

WinDBG Log:

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 0x258
[sync] probing sync
[sync] sync is now enabled with host 127.0.0.1
0: kd> !idblist
> currently connected idb(s):
    [0] XXXX.sys
0: kd> !idbn 0
> current idb set to 0

When I try to configure a manual bp (in WinDBG) on the module and then run !sync, I get the following error:

0: kd> !sync
[sync] sync update
[sync] failed to GetModuleByOffset for offset: 0xfffff8022bf31538

Now I have mapped the module manually and now it seems to sync fine.

1: kd> !modmap 0xfffff8022bf30000 0x8000 XXXX.sys
*** WARNING: Unable to verify timestamp for XXXX.sys

Would it be possible to fix it?

EDIT: After several attemps, multiple debug restarts, etc, the plugin constantly fails, sometimes preventing setting breakpoints (exception above), and at other times memory addresses do not match IDA / Windbg (maybe wrong rebase). Now, even modmap doesn't work (AddSyntheticModule failed).

Thanks!

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 ?

The Logitech updater application listens on the same port that ret-sync does on Windows.

We should consider changing the default port.

Maybe the author changed the API name?

i'm using linux

I cannot get the client program to not say n/a in ghidra

Would it be possible, doable, simple, to add an "add break point" feature where on add a break point in ghidra/s decompiled view or listing and then have the break added in x64dbg/some debugger ?

When gdb runs the bbt command, it sends a [sync] rln command to the Ghidra module which calls rebase(rbase, raddr) to get the final address to resolve the symbol. rebase then calls imageBaseLocal.addNoWrap(raddr - rbase), but because gdb sets rbase always to 0, raddr - rbase is the final address already, so adding the base causes the wrong address to be returned by rebase.

I just cloned and got ret-sync added to Ghidra OK.

I am also running gdb 7.9.1 and when I type in source sync.py, I get:

sync.py:1: Error in sourced command file:

(I am on Windows 10, with python 2.7.6.) Is there min. GDB version I should be running? Or is the script only good on UNIX boxes?

Atm ret-sync supports highlighting the current EIP pointer in the IDA View window (assembly). It would be nice to have it highlight the current line in the Pseudocode window (output of HexRays decompiler) when HexRays is available.

Indeed IDA already knows how to link the assembly with a line in the decompiled code as when we hit F5 the cursor is on the right line corresponding to the assembly.

However I am not sure changing the colour of one line in the Pseudocode is something provided by IDA Pro yet though so may need to ask them first to add support for that before we can implement this feature in ret-sync.

I have add a .sync file in my .idb directoty. When i start retsync plugin ,it also find this .sync file.But when i enter cmd 'sync' in gdb,it prints "Python Exception <class 'gdb.error'> Can't determine the current process's PID: you must name one.: ".

gdb

ida pro output window

.sync file

Hi, thanks for this great plugin!

I am trying to get lldb setup with either ghidra or IDA Pro (don't assume you want to make a Hopper plugin, do you? :))

I setup lldb to load the extension and can start the sync which then gives me a debug message:

[*] retsync init
[>] server started
[x] fail to parse json request: org.json.JSONException: JSONObject["dialect"] not found.
<< {"msg": "dbg connect - Darwin Kernel Version 19.4.0: Wed Mar  4 22:28:40 PST 2020; root:xnu-6153.101.6~15/RELEASE_X86_64", "type": "new_dbg"}
[x] program unavailable: <myprogram>

I tried this with a IDA Pro installation and it's working really well, just with ghidra it can't manage to find the program for some reason. Same setup as in IDA

The binary I am trying to load is a loader program for a library that I want to debug. I double-checked that process name is identical

Tried both, self-built and the extension from the dist/ that was already there but same behaviour

Hello, I recently noticed your excellent work, but when I try to use ida to connect to gdb on a LAN server, I cannot run the program with alt+F5 in ida, and the output window will display "idb" isn't enabled, can't go". When I ran this program in gdb, ida did not respond, as if I was not connected. But "set debugger dialect to gdb, enabling hotkeys" is indeed displayed in the output window. I want to ask what is wrong here?

IDA output window：

[sync] sync enabled
[sync] cmdline: "C:\ProgramData\Miniconda3\python.exe" -u "C:\Program Files\IDA 7.5\plugins\retsync\broker.py" --idb "shellcode_x64"
[sync] module base 0x400000
[sync] hexrays #7.5.0.201028 found
[sync] broker started
[sync] << broker << dispatcher not found, trying to run it
[sync] << broker << dispatcher now runs with pid: 8680
[sync] << broker << connected to dispatcher
[sync] << broker << dispatcher msg: add new client (listening on port 54837), nb client(s): 1
[sync] << broker << dispatcher msg: new debugger client: dbg connect - Linux #67~18.04.1-Ubuntu SMP Tue Jan 5 22:01:05 UTC 2021 x86_64
[sync] set debugger dialect to gdb, enabling hotkeys
[sync] idb isn't enabled, can't go
[sync] << broker << dispatcher msg: dispatcher stopped
[sync] << broker << server.loop
[sync] broker finished
[sync] idb is disabled
Flushing buffers, please wait...ok
Unloading IDP module C:\Program Files\IDA 7.5\procs\pc64.dll...

  bytes   pages size description
--------- ----- ---- --------------------------------------------
   524288    64 8192 allocating memory for b-tree...
    65536     8 8192 allocating memory for virtual array...
   262144    32 8192 allocating memory for name pointers...
-----------------------------------------------------------------
   851968            total memory allocated

Loading processor module C:\Program Files\IDA 7.5\procs\pc64.dll for metapc...Initializing processor module metapc...OK
Loading type libraries...
Autoanalysis subsystem has been initialized.
Database for file 'shellcode_x64' has been loaded.
Hex-Rays Decompiler plugin has been loaded (v7.5.0.201028)
  License: 55-2FD4-F731-D2 P.Y.G Team, Personal license (1 user)
  The hotkeys are F5: decompile, Ctrl-F5: decompile all.
  Please check the Edit/Plugins menu for more informaton.
IDAPython Hex-Rays bindings initialized.
[sync] default idb name: shellcode_x64
[sync] found config file: user_conf(host='10.168.1.29', port=9234, alias=None, path='C:\\Users\\hp\\Desktop\\tfctmp\\ctfzone_pwn\\.sync')
[sync] sync enabled
[sync] cmdline: "C:\ProgramData\Miniconda3\python.exe" -u "C:\Program Files\IDA 7.5\plugins\retsync\broker.py" --idb "shellcode_x64"
[sync] module base 0x400000
[sync] hexrays #7.5.0.201028 found
[sync] broker started
[sync] plugin loaded
[sync] << broker << dispatcher not found, trying to run it
[sync] << broker << dispatcher now runs with pid: 15292
[sync] << broker << connected to dispatcher
[sync] << broker << dispatcher msg: add new client (listening on port 55085), nb client(s): 1
[sync] << broker << dispatcher msg: new debugger client: dbg connect - Linux #67~18.04.1-Ubuntu SMP Tue Jan 5 22:01:05 UTC 2021 x86_64
[sync] set debugger dialect to gdb, enabling hotkeys
[sync] idb isn't enabled, can't go

GDB:

(pwn) root@sc-ThinkPad-T14-Gen-1:~/pwn$ gdb findshellcode -qReading symbols from findshellcode...(no debugging symbols found)...done.
[sync] configuration file loaded from: /home/qsp/.sync
       interface: 10.168.1.29:9234
[sync] init
[sync] 18 commands added
gdb-peda$ sync
[sync] initializing tunnel to IDA using 10.168.1.29:9234...
[sync] sync is now enabled with host 10.168.1.29

I am currently emulating an ISA in QEMU, while a custom gdb port (written for said ISA) is connected via localhost:1234. When I issue the sync command I receive the following error:

[sync] pid: 42000
Python Exception <class 'gdb.error'> Not supported on this target.:

The Readme indicated an issue with /proc/mappings, but I have not been able to resolve this issue. I am using Ghidra by the way