Add support for arm 32/64

[dzonerzy]

I saw that right now there's no arm support I would like to help you develop this, let me know how can I do that

[mahaloz]

Hi @dzonerzy we would love help anywhere we can get it on the project. I see this as a request for two separate things:

1. A request for support of 32bit elf's (arch does not matter)
2. A request for testing of ARM arch compatibility with variable mapping

Background Info

I'll try to briefly describe how our native symbol mapping works when you connect a decompiles:

1. You connect a decompiles and it sends essentially JSONs describing stack vars, reg vars, and function names.

2. The GDB client (running on the arch of choice) uses decomp2dbg pythons lib to convert stack variables and reg variables into convince vars using gdb api

3. The GDB client, once given the symbols of functions and global vars, compiles a small elf using the gcc present on the same system. Shown here:
   

   decomp2dbg/decomp2dbg/clients/gdb/symbol_mapper.py

   Line 143 in 7461be7

   os.system(f"{self._gcc} {fname} -o {fname}.debug")

4. We apply .text segment hacks to that newly compiled ELF where we overwrite the size header of the .text segment (which all assumes 64bit sizes, since we only really do 64bit right now):
   

   decomp2dbg/decomp2dbg/clients/gdb/symbol_mapper.py

   Line 169 in 7461be7

   def _force_update_text_size(self, stream, elf, elf_data, new_size):

5. Finally, the final ELF is ready. We use the add symbol gdb command to add a hacked ELF into the symbols. We redo this entire process every time a break event is hit.

Proposal

I think if you want to add ARM support the first thing to do is test decomp2dbg on an ARM64 machine. Report if it works out of the box or not (it very well may).

After that, take a look at #24, which may be the issue you need to solve. You would use the environment information to determine when to switch 32bit and 64bit compiling on and off.

If you have questions, feel free to ping me here or on our Official Discord listed in the README.

[dzonerzy]

Hi @mahaloz

Now I better understand why it doesn't work in my case, basically , what I'm trying to do is adding symbols to an emulated binary (AArch64 compiled using buildroot) this binary is executed on a Linux machine x86_64 using qiling framework which under the hood uses unicorn engine , qiling allow debugging foreign arch using gdb protocol. What I wanted to do was emulate and debug it using qiling and add missing symbols (stripped binary) using ida pro and decomp2dbg. Wouldn't be easier to just generate some sort of pdb/dwarf instead of compiling a binary on each break?

I already tried decomp2dbg and failed to add symbols with the emulated binary

[dzonerzy]

Hi @mahaloz

I think that manually generate an object file is not actually needed and dependecies on objcopy and gcc could be removed. LIEF would be a better solution in my opinion (https://lief-project.github.io//doc/latest/tutorials/02_pe_from_scratch.html) it allow to dynamically generate binary for both ELF and PE, and support adding symbols too.

I will investigate to see if that's actually possible.

[mahaloz]

I think that manually generate an object file is not actually needed and dependecies on objcopy and gcc could be removed. LIEF would be a better solution in my opinion (https://lief-project.github.io//doc/latest/tutorials/02_pe_from_scratch.html) it allow to dynamically generate binary for both ELF and PE, and support adding symbols too.

@dzonerzy I love the lief project. This looks like an extremely promising candidate to remove some of the worst code in this project.

I would love to move in this direction. For now, I think the easiest way would be to first introduce lief into the setup.py, validate that normal installs work on the last two Ubuntu versions, and then replace the use of gcc.

Objcopy will be a little harder. From what I can tell of lief, it does not look like you can add symbols, but only modify them. I'll have to look more. If you end up wanting to PR for the first thing that would be dope. Otherwise I may be able to start a PR for it this week.

[dzonerzy]

Perfect I'll start fork the project and work on it , also if you check the documentation for LIEF it seems it allow to add both static and dynamic symbols https://lief-project.github.io/doc/latest/api/python/elf.html

[dzonerzy]

I would love to share some details with you but seems like I can't find the discord link in the readme (maybe i'm blind)

[mahaloz]

It's line 13 of the readme: https://discord.gg/wZSCeXnEvR

[mahaloz]

Closing this issue, since the addition of PR #17 and commit 17ddea9, we now can support this use-case. LIEF support will be a new issue #54