pancake ([email protected]) wrote [12.01.14 18:26]: > the main problem with using data to put your code is that on serious > systems.. the data is rw-, so you cant execute. > > the relative branch cant always reach data if text is big and absolute > branches fail on PIE bins. > > ldpreload just works on dynamic bins.. > > so.. i just got an idea.. whats mapped in all binaries (on linux?) even if > its pie, static, ...? > > static bins require an elf loader to run, this is /lib/ld-linux.so .. the > patch is hardcodrd in the elf headers so u can patch that path easily to > /lib/ld-hook.so and take glibc's ld.so to be filled with your code and > hotpatch the binary right before jumping to the entrypoint. > > another way to place code in a binary will be to hijack vdso. this shared lib > is hardcoded in the kernel and its preloaded on all binaries. its required to > get the signal and syscall trampolines.. but you can add more code there.. > and use the %gs segment to find the address of the vdso. this can be done in > 3 opcodes. > > the main pb with the second solution is that it depends on linux, and > changing code requires new kernel compilations. > > another thought.. it is possible to get a shared ld.so to enable ld-preload > even on static binaries? :) > > i really have very few time to play with those things right now.. so.. if > anybody tries to implement any of those things please share your experience > here ;) i dont know anybody that tried to do that before and it can open some > new ways for analyzing bins on unix systems.
pancake: I don't know where you got your information about static bins, but they absolutely do not require a loader to run. Loaders are specifically for dynamically linked binaries. It may be the case that GNU gcc/ld will rape your binaries and insert a call to a loader anyway (not sure if it does -- I don't think so, but haven't tested), but that does not define static bins as actually requiring it to run. I can provide static binaries that I assembled from scratch directly to ELF myself (no pass through a linker) that linux will happily run with no complaints whatsoever, and I can assure you there is absolutely no running of a loader. Also, don't be fooled into thinking that ld-linux.so is the required loader either: GNU ld, for example, explicitly supports using alternative loaders via the -I (or --dynamic-linker) command-line switches. Of course you can also patch it directly in the binary after it has been linked as you pointed out. VDSO is, again, only for dynamically linked binaries (you stated "all binaries"). The signal and syscall trampolines are via libc, which obviously implies dynamic linking. If a binary is really a static binary, ld-preload won't work since there won't be a loader run for it, as I pointed out above. At any rate, the problem of adding or splicing functionality into an existing binary is not specific to radare. I don't know of a single debugger/disassembler that even attempts to do all the magic for you (the complications and difficulties in coding something to do this often outweigh the benefits for most developers it would seem). If you are *very* careful with how you do things, and you are very lucky at the same time, you could simply append to the end of the text section and not mess up any other offsets. Then you could just tweak the program section header and be good to go (in theory). This is, however, highly unlikely, and thus various tricks (as others have been suggesting) are needed. I haven't researched what would happen if one tried, but I don't actually see anything in the ELF specs that state there must be one and only one .text section/segment. It might be worthwhile to see what you could do with adding additional code segments/section, though I somehow doubt this would actually be less messy than simply appending to the end of the existing code segment. -- Justin "flux_control" Boffemmyer Cauldron wizard and general mage Source Mage GNU/Linux http://www.sourcemage.org _______________________________________________ radare mailing list [email protected] http://lists.nopcode.org/listinfo.cgi/radare-nopcode.org
