rizin
rizin copied to clipboard
Refactoring `RzBinReloc`
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
RzBinRelocTypeis 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 likepatches 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, likeR_SPARC_COPY.