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
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.
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.
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.