Add Support for shared librairies.

[0xMirasio]

Hello. Tested on binary it work perfect, great tools!
But when i test on shared libraries started with another binary, after connecting to the server, the tool won't work.
(no decompilation, breakpoints have offset errors) .
I know original behavior is to start the server on binary and use the connect while debugging the binary with gdb. But in my situation I can't debug the libraries without starting the linked main binary before.
(Maybe adding muliple server syncing ? Decomp2dbg can't export ida decompiled code on gdb because shared librairies is extern but maybe adding another syncing server on shared lib IDA instance + syncing correctly when jumping on shared lib can work)

[mahaloz]

Hi @0xMirasio thanks for using d2d!

If I am getting this right, the use case you are talking about is one where you want both decompilation output inside the main binary being debugged and inside the shared libraries it uses, right?

As a solution to this scenario, would you be willing to open another instance of IDA, start decomp2dbg on there, an then connect it as well? Currently, we have the ability to load multiple decompiler outputs into one debugger but the problem becomes the main base address which all things are based off.

I think the solution to this problem will be:

1. Full normal support for multi-decompiler connections
2. Kill decompiler panes on bad output (so it always looks like 1 in case of libs)
3. Add optional args for specifying a forced base address for decompiler loads

[0xMirasio]

Hello, thank for your response.
Indeed, i tried to start the server on the shared lib then connect when i jumped to shared code on gdb. But no decompilation unfortunately. Also, offset are broken (that's normal). If i understand correctly, the software try to use ida.decompile() at 0x7ffffxxxxxxx adress but won't find it in shared lib .text segment mapped to X -Y . Maybe i can try to add option in GUI to ask for a base adress for this problem ?

[mahaloz]

@0xMirasio alright, so here is the plan:
For now, so you can use it with only 1 binary at a time, I've started this PR: #42

You will now be able to configure the base address we load symbols at like so:

decompiler connect ida --base-addr 0x7ffff0000000

[mahaloz]

@0xMirasio alright, the PR is just about ready to land. Would you be able to checkout into that branch and play with it a little? I tested it with only connecting and IDA instance that had libc decompiled, then I mapped it to the virtual address space and it worked. In this approach we can still only have 1 ida open at a time and connected.

decompiler connect ida --base-addr 0x00007ffff7452000

then break in libc_start_main or something.

Still need to make it not freak out when you are in an address space outside its known addrs. You may need to find your libc load location with vmmap or the like.

[mahaloz]

@0xMirasio actually, its in master now; use the command like the README shows here:
https://github.com/mahaloz/decomp2dbg#advanced-usage

If you find any bugs let me know, and if you are happy with the new feature close the issue :)

[0xMirasio]

Hi again @mahaloz .
Seem there is still problems.
Here are some details :

vmmap-> 0x7ffff7800000     0x7ffff7972000 r-xp   172000 0      /opt/quest/lib64/libvtwrap.so.2.0.0

_parse_special_tag function -> 0x00007ffff78d96f0

d2d server start on libvtwrap on port 3661
gdb args : decompiler connect ida --host 127.0.0.1 --port 3661 --base-addr-start 0x7ffff7800000 --base-addr-end 0x7ffff7972000

Output of gdb when step in:

[+] Connected to decompiler!
pwndbg> si
0x00007ffff78d96f5 in std::_Sp_counted_ptr<vintela::AsdAuthClient*, (__gnu_cxx::_Lock_policy)2>::_M_destroy() () from /opt/quest/lib64/libvtwrap.so.2.0.0
[*] NO DECOMP PRESENT
Traceback (most recent call last):
  File "/opt/tools/pwndbg/pwndbg/commands/__init__.py", line 131, in __call__
    return self.function(*args, **kwargs)
  File "/opt/tools/pwndbg/pwndbg/commands/__init__.py", line 225, in _OnlyWhenRunning
    return function(*a, **kw)
  File "/opt/tools/pwndbg/pwndbg/commands/context.py", line 270, in context
    result[target].extend(func(target=out,
  File "/home/thibault/.local/lib/python3.10/site-packages/decomp2dbg/clients/gdb/pwndbg_client.py", line 63, in context_gdecompiler
    banner = [pwndbg.ui.banner(pane_title, target=target, width=width)] if with_banner else []
  File "/opt/tools/pwndbg/pwndbg/ui.py", line 37, in banner
    title = title.upper()
AttributeError: 'NoneType' object has no attribute 'upper'

Did i miss something ? Will debug in this afternoon, maybe there is still offsets problems.

[0xMirasio]

Adress are correct but it point to the wrong area, weird

[mahaloz]

@0xMirasio interesting, ok a few things:

1. Are you sure you picked the correct last base address? As in the the last address of the last mapped region of your target, since vmmap will usually show a few regions of the same binary
2. Confirm you are using master pwndbg?
3. When you say the address is correct, do you mean the symbols imported correctly but the decompilation is just not printing correctly?

I've pushed more changes to main to help you with this crash. You should now see a more explicit address printed out when you error at this same place. The address printed out should be an offset... if it's not, that means PIE analysis failed. This should also fix the crash you see on the screen about the banner.

[0xMirasio]

Pretty sure about last base adress/start addr. I'm not sure i have latest pwndbg, will see tomorrow.
3 : Indeed the decompiled output is completely incorrect, it point to code that isn't the libraries.
will try the debug fix .

[0xMirasio]

Really weird, so decompiled adress is okay, it correspond to the adress of the function i want. (_parse_special_tag)
When i try disassemble 0x7ffff78d96f0,+5 or disassemble _parse_special_tag,+5 it point to the good ASM code but name is completely broken. There is no decompilation also.

here are some info :

Also i tested on several libs from the same project, i have the same error

[mahaloz]

@0xMirasio I think I just fixed the bug. Try on main now. It was a PIE detection mismatch from your library to your main binary. What I believe was happening was the main binary you were debugging was a no-PIE, but ofc the library was PIE,,, so it always though the offsets were absolute addrs. Try it out now and lmk :)

[0xMirasio]

Hello Back. Seem the adress is correct but decompilation don't work. Also i removed base-addr-start/end and i have the same adress given by client (weird?).

[mahaloz]

Alright, looks like it's time for me to stop blind debugging. @0xMirasio could you:

1. Send me the main binary you are debugging
2. The library you are loading in IDA
3. The gdb commands you are using to get to a point where the decompilation does not work

I'll look at it some point this week.

[0xMirasio]

Hello. Can't send neither librairie neither binary as the software is my companie private data. I will try to debug from my side but unfortunately i cant give you my sample (sorry).

[0xMirasio]

I'm going to try to trigger the bug via other non private sample, and send you if I can retrigger it.

[mahaloz]

@0xMirasio No problem, but yeah, if you can trigger it another way, that would be great. I would recommend libc if you know a way to trigger the bug.

[mahaloz]

Closing this issue since remote debugging is now supported (allowing for custom address range assigning); however, you still can't decompile and debug two things simultaneously. This support must be added at some point to accomplish shared lib debugging. Deferring to #43.