rizin icon indicating copy to clipboard operation
rizin copied to clipboard

Refactoring `RzBinReloc`

Open Rot127 opened this issue 4 months ago • 0 comments

RzBinReloc is supposed to be a general abstraction for all kind of relocations.

It has some shortcomings we should address. Here an overview of what came up so far:

Existing issues:

  • https://github.com/rizinorg/rizin/issues/5200 (issues with MIPS and contains valuable resources to learn about PLT/GOT/indirect functions etc.)
  • https://github.com/rizinorg/rizin/issues/153

https://github.com/rizinorg/rizin/blob/a47402ad9e5f53325294d2b8edf43b2c9cea172b/librz/include/rz_bin.h#L707-L729

Issues

  • RzBinRelocType is not really the type of the relocation but the number of bits patched (the size). But as enum it has too few values (8, 16, 24, 32, 64). But relocations also patch 22, 13 or any number of bits. It should be a number. Also it doesn't know if the patch location has to be aligned or not. It maybe refers to the width of the value being patched.
  • The type of a relocation should be grouped differently. Currently there seems to be a categorization of relocs into adds a value to a symbol address, sets a constant value, something with vaddr, something with indirect function (see: elf_relocs_conversation.c - reloc_convert_add, reloc_convert_set, reloc_convert_vaddr, reloc_convert_ifunc). I think it would be groupings like patches PLT, patches GOT, patches a constant, patches a symbol address, copies data from a to b. These groupings should be extensible, because arch devs come up with the funniest patching mechanisms for their binaries.
  • The calculation of the patch value is currently limited to Symbol address + ADDEND. But these calculations can be vastly more complex. E.g. updating of indirections in the GOT or PLT. Or the value depends on runtime values. Especially, when for PLT patching. Some "relocs" just copy data, like R_SPARC_COPY.

Rot127 avatar Aug 18 '25 14:08 Rot127