News for hackers. Stuff that matters.
Re:Hotpatching a C Function on x86 by reubenmorais on Friday April 01, 2016 @09:01AM (#11404432)
Usually it's done when redesigning/recompiling the target function is not possible. Game modding, restartless updates, instrumentation, etc.
Re:Hotpatching a C Function on x86 by csl on Friday April 01, 2016 @11:10AM (#11405334)
But that would only be possible from the same process space, right? So only applicable for plugins etc.?

What I'd like to see is hotpatching the function for another process, but I guess that's very hard to do with ASLR. Probably doable with some tricks, though.

Edit: Come to think of it, gdb is able to attach to a running process w/o debug symbols and find function addresses. So in other words, I just need to dig into and grok the gdb source.

Re:Hotpatching a C Function on x86 by dreamlayers on Friday April 01, 2016 @11:37AM (#11405589)
The program being modified doesn't need some feature for loading your code as a plugin. You can instead use https://en.wikipedia.org/wiki/DLL_injection
Re:Hotpatching a C Function on x86 by chatmasta on Friday April 01, 2016 @11:15AM (#11405378)
If you are able to recompile the program, you can disable ASLR. For example on iOS it just requires a change to the MACH-O header of the binary. [0]

But I doubt you could disable ASLR of a running process, for somewhat obvious reasons...

[0] https://github.com/peterfillmore/removePIE

Re:Hotpatching a C Function on x86 by dreamlayers on Friday April 01, 2016 @11:46AM (#11405674)
You can similarly disable ASLR via the header in Windows, though there are ways to override that.

ASLR shouldn't be a big problem though. Only the base address of code in each file (executable or library) is changed, and you can easily find it. Functions within one file are not shuffled around. ASLR only exists to stop you from hard-coding function addresses, to make exploits harder.

Re:Hotpatching a C Function on x86 by kazinator on Friday April 01, 2016 @12:21PM (#11406009)
If you want restartless updates, then you plan for it and modularize the software with dynamically loadable modules (think shared library "plugins" or kernel modules).
Re:Hotpatching a C Function on x86 by reubenmorais on Friday April 01, 2016 @12:52PM (#11406344)
You're talking about when you own the source and therefore can redesign/recompile it. I began my comment explicitly ruling those cases out.

Let's say you're Red Hat, and want to release a super critical security fix for some package, but you absolutely cannot restart the affected process. This technique allows you to write some code that redirects functions to fixed versions, patching the process while it runs.

Re:Hotpatching a C Function on x86 by dkopi on Friday April 01, 2016 @03:01PM (#11407578)
If you don't control the code and can't recompile it, you won't be able to add the ms_hook_prologue function property
Re:Hotpatching a C Function on x86 by kazinator on Friday April 01, 2016 @06:31PM (#11409055)
If you don't control the code and are modifying it to do an in-service upgrade of a running binary, then this is a special situation: you're shooting a 2016 re-make of MacGyver targeted at a geek/programmer audience.

If you're Red Hat and you do have the source, but the service cannot be stopped, and yet it must be upgraded, yet you didn't plan this into the software (and yet you didn't write in it in Lisp which could save your ass here) then you're plain stupid. If you're stupid, you're not going to pull off this highly technical, intricate hack, that is looming with pitfalls.

Re:Hotpatching a C Function on x86 by reubenmorais on Friday April 01, 2016 @08:47PM (#11409640)
I mentioned this in another comment, but you don't need the ms_hook_prologue attribute, it's just helpful.
Re:Hotpatching a C Function on x86 by dkopi on Saturday April 02, 2016 @03:49AM (#11410670)
True, you don't usually need the prologue to hook a function, but we're talking about hooking functions that might be called by another thread at the same time. If you just modify the instructions while another thread is running the code, you might crash and burn. The prologue helps by ensuring the first 8 bytes of a function are just a large NOP.
Re:Hotpatching a C Function on x86 by deathanatos on Friday April 01, 2016 @04:29PM (#11408316)
Except the technique presented requires recompiling the target function, doesn't it? (To add all those GCC attributes, and to add the `lea` instruction.)
Re:Hotpatching a C Function on x86 by reubenmorais on Friday April 01, 2016 @08:46PM (#11409639)
The specific technique shown here requires it, but you can also do it generically by overwriting the first 8 bytes of the function and then restoring it later if you want to undo the hook.