('binary' encoding is not supported, stored as-is) In-Reply-To: <3CF1148A.7060301at_private> Hi, This technique was known years ago by random people, note that gdb use it to resolve internal library symbols and put breakpoints on it (since shared libraries are ET_DYN objects, their absolute virtual address is not known at the process launching, thats why we need the linkmap) The link_map can also be really useful in infoleak bugs, possibly for bypassing full random address space protection as implemented by PaX 2.0 + et_dyn.zip and the advised relinking (ET_EXEC to ET_DYN using -shared and creating a valid entry point) . The linkmap can also possibly be used to hijack function calls using hash table poisoning, so that the dynamic linker would fill the .got with your own value at the first function call . You can do with it actually . I wont post the text called 'ELF dynamic linking on x86 LINUX' written by myself where you can find 3 Dynamic linker implementation . (...) B) The link_map structure explained . (...) However this has been distributed in the past to a few person including yourself, but I know for sure that you knew about it before :) Why did you release that ? --------- mayhem >A process image is a collection of one or more >objects mapped into a common >address space. The dynamic linker co-ordinates >symbol resolution, and >effectively communication, between these objects. >The linker uses a link_map >structure to keep track of each object's location >and symbol resolution >data. >The link_map structure is pointed to by a >reserved entry in the GOT of >each object and >retrieved by the dynamic linker when required. >The link_map structures are >also linked together in a doubly linked list. This list is traversed by the >dynamic linker when it attempts to resolve a >symbol.
This archive was generated by hypermail 2b30 : Fri May 31 2002 - 11:31:59 PDT