(untitled)

Compile-time computing the offset of a function from the start of the binary into a struct to do manual relocations at runtime in gcc how? >inb4 object oriented programming i dont want to refactor 20 times through the lifetime of this codebase(USER WAS WARNED FOR THIS POST, You should always elaborate on your opinions rather than just spilling the soykaf.)

>>40009 OP here, ELF can do it didnt bother saving the password lol

>>40009 I cannot imagine what you could possibly be trying to achieve by this and I pray to God I never have to find out

objdump -WL name_of_exe but if you want relocations at runtime can't you just use a function pointer? switch on an index to get a specific function pointer, or have an array of function pointers if you still want to overwrite the instructions themselves then mmap to make code sections writable could map writeable then executable - or could map the same memory in multiple locations to make it writable at one address and executable at another address function pointer addresses should still work, just paste those in ontop of existing function calls

>>40019 sounds like hot mess to code self modifying stuff this way as they have to check what compiler spewed out with every compilation, unless they are replacing code written as inline assembly as that way it's st least somewhat easier to track on your own

>>40009 >Compile-time computing the offset of a function from the start of the binary into a struct You can get the address of the function the same way you get the address of a variable with the & operator. >void* addr = &my_func; There is no "start of the binary" though because your ELF file is made up of multiple sections like .text .data .bss and the operating system will split them up and put them in different parts of memory. There is also something called address space layout randomization which operating systems do to make it harder for hackers who have exploited a memory corruption vulnerability to find other pieces of the binary they can re-use in their attack (called return oriented programming if you want to learn more about that). >to do manual relocations at runtime The code won't be writable by default because again an attacker can exploit that by overwriting the existing code and running it. You'll have to learn about mprotect to get around that. It's not impossible but it's not a beginners project either.

Compiling-time collecting the function offset is best done as stated above, with "&function". The relocations at runtime would be difficult however, also as stated above. However another option is to specify your own void pointers, and casting them back to function type definitions to call them will allow for you to dynamically set that pointer reference as you need, without the need for write access to your executables memory space. While it's not strictly "relocations", and more reference swapping, it solves this issue in a way that is less fragile. It is less fragile both due to no longer relying on making executable memory spaces writable, but also because now the size of the function can be arbitrary without added effort. To go even further, you can use your function typedefs in order to restrict the allowed functions if desired, such as below: #include <stdio.h> typedef int (*int_op)(int, int); int_op func_ref = NULL; int add(int a, int b) { return a + b; } int mul(int a, int b) { return a * b; } int main(void) { int a, b; a = b = 64; func_ref = &add; printf("%d\n", func_ref(a, b)); func_ref = &mul; printf("%d\n", func_ref(a, b)); return 0; }

not sure about the context, so your needs may vary, but maybe look into a jit, like libgccjit[1], or runtime bytecode manipulation with qbe[2] or llvm[3] (but the latter is _massively_ complex). [1]: https://gcc.gnu.org/onlinedocs/jit/ [2]: https://c9x.me/compile/ [3]: https://llvm.org/

>>40031 >There is no "start of the binary" though because your ELF file is made up of multiple sections like .text .data .bss and the operating system will split them up and put them in different parts of memory. There is also something called address space layout randomization which operating systems do to make it harder for hackers who have exploited a memory corruption vulnerability to find other pieces of the binary they can re-use in their attack (called return oriented programming if you want to learn more about that). This is wrong, ASLR simply means that the base address that an image is loaded at is randomized, not the individual sections of that image. >>40031 >You can get the address of the function the same way you get the address of a variable with the & operator. >void* addr = &my_func; This, in conjunction with a way to get the base address of your image, will let you calculate that offset. The linker usually defines a symbol for that, on linux it is called __ehdr_start, on windows __ImageBase. Example code: https://gcc.godbolt.org/z/z3d45GTas

>>40065 >ASLR simply means that the base address that an image is loaded at is randomized, not the individual sections of that image. You must be confused. That is PIE https://en.m.wikipedia.org/wiki/Address_space_layout_randomization

>>42743 wtf are you smoking? do you not understand what PIE means https://docs.kernel.org/admin-guide/sysctl/kernel.html#randomize-va-space