IDA version 7.6 Python 3.10

decomp2gef ida script seems to fail at Z:\...\IDA\IDA Pro 7.6\plugins\decomp2gef_ida.py: Missing or invalid attribute 'comment' and I seem to be unable to see the decomp2gef plugin being loaded successfully. any ideas?

  bytes   pages size description
--------- ----- ---- --------------------------------------------
   532480    65 8192 allocating memory for b-tree...
   507904    62 8192 allocating memory for virtual array...
   262144    32 8192 allocating memory for name pointers...
-----------------------------------------------------------------
  1302528            total memory allocated

Loading processor module Z:\...\IDA\IDA Pro 7.6\procs\pc.dll for metapc...Initializing processor module metapc...OK
Loading type libraries...
Autoanalysis subsystem has been initialized.
Z:\...\IDA\IDA Pro 7.6\plugins\decomp2gef_ida.py: Missing or invalid attribute 'comment'
Database for file 'redacted' has been loaded.
Hex-Rays Decompiler plugin has been loaded (v7.6.0.210427)
  License: 57-631C-7A2B-72 IDA PRO 7.6 SP1 (99 users)
  The hotkeys are F5: decompile, Ctrl-F5: decompile all.

  Please check the Edit/Plugins menu for more informaton.
Z:\...\IDA\IDA Pro 7.6\plugins\decomp2gef_ida.py: Missing or invalid attribute 'comment'
805EF50: restored microcode from idb
805EF50: restored pseudocode from idb
-----------------------------------------------------------------------------------------
Python 3.10.1 (tags/v3.10.1:2cd268a, Dec  6 2021, 19:10:37) [MSC v.1929 64 bit (AMD64)] 
IDAPython v7.4.0 final (serial 0) (c) The IDAPython Team <[email protected]>
-----------------------------------------------------------------------------------------

Found out about this decomp2gef script and was eager to try it out :)

When trying it out, I encountered this error:

I'm currently using GDB 11.1, IDA 7.6 together with the latest gef.py script freshly pulled from the gef github. Any clue how I could fix this?

This PR aims to address a few issues in decomp2gef

First issue addressed

As of now, if you try to connect decompiler to debug a binary over a remote server via gdbserver, chances are you will encounter the error min() arg is an empty sequence which arises due to the following lines

base_address = min([x.page_start for x in vmmap if x.path == get_filepath()])
...
text_base = min([x.page_start for x in vmmap if x.path == get_filepath()])

This arises due to inconsistency in the exact path of the binary between the remote server and the local binary.

For example, if I try to debug a binary on remote with file path /bin/program with the local binary in /tmp/program, x.path will return /bin/program and get_filepath() will return /tmp/program which does not match and causes the array to be empty.\

Hence a slight modification to compare the file name rather than the absolute path will solve this issue.

base_address = min([x.page_start for x in vmmap if x.path.split('/')[-1] == get_filename()])
...
text_base = min([x.page_start for x in vmmap if x.path.split('/')[-1] == get_filename()])

Second issue addressed

def update_function_data(self, addr):
    ...
    for idx, arg in args.item():
        idx = int(idx, 0)
        expr = f"""(({arg['type']}) {current_arch.function_parameters[idx]}"""
    ...

Within the update_function_data(), we use current_arch.function_parameters to get the registers in which our function arguments are stored and use IDX to match the argument to the respective register/place in memory where the argument is stored.

In x86_64, current_arch.function_parameters = ['$rdi', '$rsi', '$rdx', '$rcx', '$r8', '$r9'] and this works for functions with 6 arguments as current_arch.function_parameters[0] will match argument 1 to $rdi and so on.

The flaw comes when we fail to consider functions with 7 or more arguments where arguments will then be found in the stack.

However we can set this aside, for now, we don't usually encounter more than 7 arguments, right?

The more urgent flaw is when we bring in the X86 architecture.

In x86, current_arch.function_parameters = ['$esp']. This means that beyond the first argument, decomp2gef will break with an IndexError as it tries to access current_arch.function_parameters[1] for the 2nd argument and so on.

I'm not sure if there's a nice way to do this but I essentially redefined current_arch.function_parameters for X86 architectures.

current_arch.function_parameters = [f'$esp+{x}' for x in range(0, 28, 4)]

This allows decomp2gef to work, but I haven't considered implications yet as it may get pretty complicated(?)

I welcome any ideas!!

When connecting GEF to the decompiler, gdb fails to add-symbol-file and throws an error.

BFD: /tmp/tmp3pmay68f.c.debug: invalid string offset 16777215 >= 282 for section '.strtab'

Although this does not break decomp2gef, it causes the debugger to be without a symbol file and hence renders some features unusable.

Sample binary with this behavior: sample_program.zip

Currently support for using the attach command is shaky with PIE binaries, and requires the strict process of launching a new gdb instances, attaching to the target process id, and then connecting to decomp2dbg. Attempting to attach again after this will cause the attached-to binary to have a new base address, and I assume this prevents decomp2dbg from functioning properly as I lose symbols after that. On my local system, disconnecting and reconnecting doesn't fix this (if done before or after the binary is attached to for the second time).

I suggest to add instruction for those who want to use this tool in wsl.

1. run ./install.sh --ida /mnt/c/xxx/IDA/plugins to install
2. listen to 0.0.0.0:3662 in IDA
3. add an Inbound Rules for port 3662 in Windows Firewall, private or domain network
4. run decompiler connect ida 192.168.xxx.xxx(LAN IP) 3662 in gdb to connect

Previously, we force text_size to 0xFFFFFF with a nasty hack which only works on 64 bit binaries.

This means that 32-bit binaries will throw a .strtab offset error or something along those times most of the time which is rather ugly.

Hence we implement a bit check on the binary and enforce the hack if binary is 64-bit. We should definitely implement a nicer method that caters to 32-bit binaries when possible, but until then these will suffice to preserve sanity.

addresses #14 !!

Addresses #15, took a while to debug but on comparing queued_sym_sizes to sym_info_list, they seemed to be correct and match accordingly.

I tested this PR against very basic 32 and 64 bit binaries, which both seems to give me the appropriate symbol sizes upon calling readelf.

Do have a look! Unfortunately, does not fix #14 :(

decomp2gef actually does have a single dependency which I did not realize was a dependency: sortedcontainers. It's needed to create a fast and memory-friendly mapping for non-native symbols in gef. We should decide if we want to make decomp2gef dependent of some python packages, or try to replace the functionality of SortedDict.

As brought up by @caprinux (in #3), we don't support the ability to specify ports or ips for connecting GEF over. Currently, it's hardcoded to 3662.

To allow for this, we will need a fundamental change in architecture for the server-side, since we need a way to specify port and IP.

• we can now supper every variable shown in a decompiler (including the ones assigned to a variable)
• functions args are being deprecated in favor of setting them through either register vars or stack vars
• refactored some janky type setting code

Closes #38

Here is a simple example I tested on decomp2dbg v3.1.3 and ida7.5:

#include <stdio.h>

int main()
{
    int a = 1;
    int b;
    scanf("%d",&b);
    int c = a + b;
    printf("%d\n",c);
    return 0;
}

the disassembled result of ida is:

int __cdecl main(int argc, const char **argv, const char **envp)
{
  int v4; // [rsp+Ch] [rbp-14h] BYREF
  int v5; // [rsp+10h] [rbp-10h]
  int v6; // [rsp+14h] [rbp-Ch]
  unsigned __int64 v7; // [rsp+18h] [rbp-8h]

  v7 = __readfsqword(0x28u);
  v5 = 1;
  __isoc99_scanf(&unk_2004, &v4, envp);
  v6 = v4 + v5;
  printf("%d\n", (unsigned int)(v4 + v5));
  return 0;
}

when I executed to __isoc99_scanf(&unk_2004, &v4, envp);, I tried to show the value of v5, but it is different from $rbp - 0x10

Is this a bug or did I do something wrong?

The binary ninja plugin manager supports plugins that exist in subfolders. All it would take would be to tag and cut a release (or using release_helper) and let me know on this issue and I can add it. Then subsequent releases automatically notify us and we update the plugin manager accordingly.

Note that I haven't looked at the current import hierarchy but because the plugin manager doesn't necessarily install things to the global namespace it might require some tweaks to how imports are done.

After sourcing decomp2dbg in my gdbinit I have the commands available but it's not possible anymore to use tab-completion to look for help or alike. This happens with a naked gdb with source ~/.decomp2dbg.py as only entry.

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)

For now, we will only support IDA since we have a clear-cut way to both get every struct and also know when they have been updated. This may also be possible in Binja, but out of question for future Ghidra support... that one will have to wait.

IDA Changes

In IDA we need to utilize finding all ordinal numbers, which represents each custom struct in IDA. After that, we can use idc.print_decls("1", 0) for each number to get a nice C representation of the struct. Now that we have a string that has the C-definition of the struct we need to do things in the core.

The changes all take place in the server. It's possible this may change the old API.

Client Changes

Assuming we now have a series of structs that are represented in C, we actually need to compile them into an object file and then add them with the classic add-symbol-file we use on the backend for other things. The trick though is adding this symbol file before we add the big one with all the global symbols here: https://github.com/mahaloz/decomp2dbg/blob/57983617d9a14f1f2ed7b54ee07bd15f14075c45/decomp2dbg/clients/gdb/symbol_mapper.py#L243

Since both symbol files will be loaded into the same place, there will be an overlapping main function. We either need to bake structs directly into the first file we create, or we need to make a new way to add native-struct through the symbol mapper.