Hot Patch

https://github.com/vikasnkumar/hotpatch

by feydr • 15 years ago

44 10 15 years ago

github.com

dlsspy• 15 years ago

Wow. That'd be fun to mix with labrea: http://dustin.github.com/2010/12/03/labrea.html

feydr• 15 years ago

that's pretty cool too!

tptacek3• 15 years ago

This program more or less implements a debugger, using ptrace to attach to its target, suspend it, then trampoline through malloc and dlopen (the routines a program would use to load dynamic libraries on its own behalf). This isn't far from what gdb would do if you used "call" to dlopen a library.

shykes2• 15 years ago

You can in fact use GDB's scripting language to implement this [1] [2].

[1] http://johnnyjacob.wordpress.com/2009/07/07/gdb-scripting-sh...

[2] http://stackoverflow.com/questions/5590897/scripting-in-gdb

bdonlan2• 15 years ago

Unfortunately, it's not race-free - if the target's already inside malloc, Bad Things will happen. A better strategy would be to invoke clone() to spin up a worker thread, somehow finagle a TLS segment good enough to fool libc and dlopen into working Well Enough, and loading the library via this thread (while the main thread is allowed to continue execution).

shykes2• 15 years ago

Instead of malloc, wouldn't it be safer to trigger an int80 straight to the mmap syscall? You only need to overwrite a few instructions, and put them back in place when you're done. Then you have freshly allocated memory pages for your exclusive use, and I'm guessing things get a little simpler.

tptacek3• 15 years ago

If you're going to do something as intrusive as attaching the debugger interface to the process, you could just check to make sure the code isn't in malloc.

saurik• 15 years ago

People here seem to not know of the many existing implementations of this concept, including LCITK[1] and libhijack[2].

[1] https://github.com/planetbeing/lcitk

[2] http://0xfeedface.org/category/tags/libhijack

Hot Patch

Related Stories