Interesting framing that hooking functions is considered “rogue” by Microsoft, or something you’re “not authorized” to do, when Microsoft themselves makes the detours library and never framed it like this before.
Also, missing from this explanation: hooks are usually applied per process, from user space. The code pages in a dynamic library are CoW’d from the shared page when you write to them to apply a patch.
Does the Windows Update work similarly, or does it somehow modify the original, shared page, affecting all processes? Does a hook in a single process disable hot patching on the entire system?
They've also used Detours within Windows itself. The auto super resolution (AutoSR) feature works by dxgi.dll detouring specific calls in user32.dll, in-process, to virtualize certain monitor metrics. I found this out because it was broken for a while on Windows 11 ARM64 when it couldn't handle PAC-enabled function prologs and enabling it would just crash programs by corrupting user32 functions.
No. API Sets use forwarding within the loader and are largely transparent to regular/delayed binding and GetProcAddress(). That would be fine. This is overwriting the prologue of the function in user32.dll similar to any other user-space hooking library.
Hooking code you don’t own is typically playing with fire. Because Microsoft wrote the code, they’re generally in a better position to understand when it is safe to do so.
At a previous job I wrote a docker build for patching individual Java class files on top of a monolithic docker image. This was not runtime patching, but allowed a single layer that was only a few kilobytes to be deployed quickly in emergency situations.
Interestingly, it had similar constraints and checked them at build time: it could not be a public ABI change and only one patch at a time.
The world could use more hot patching. Now that AI upends computer security, getting software patched in a timely fashion is more important than ever, and having to reboot/restart the process or computer to get those updates is more of a problem than it was before.
I don't understand the joke. My background is worked at Ksplice a long time ago, patching the Linux kernel for security fixes without having to reboot.
If your hotpatching library is competent, then it does everything atomically. Either by suspending all threads first and temporarily resuming them while they're executing any affected instructions, or by just using atomics when possible.
So much effort to reinvent half of Common Lisp. They haven’t gotten to the part where redefining a class causes all existing class instances to be lazily upgraded to the new class layout.
What happens if two consecutive updates try to hot patch the same function? Wouldn’t this be completely within the realm of possibility and be a pure Microsoft issue with no one else involved?
Any idea of how that's done? In particular, how do multiple systems synchronize the installation of their hooks?
I've made my own hooking library that lets multiple plug-ins hook the same function, but it only works decently because it has this central library synchronizing access.
If you use OBS, a game capture works the same way, it hooks the DirectX (or whatever API) functions to grab the rendered scene directly. It often has issues picking up overlays because there isn't really any synchronisation, just whatever made the last detour fires first. Like the sibling commit says, you can stack detours, it's only an issue for OBS if something that runs after it renders more things to the screen.
There is a setting to make it pick up overlays, which works reasonably well, I'm not entirely sure how it's implemented.
What an overlay does is hook the 'present' function, does more drawing, then calls the base 'present' function. It's easy enough to detect when a draw call happens during a call to 'present', that tells you that an overlay is active.
Then you're faced with the problem of how deep your hook is, you either want it to run early (before other hooks), or late (after other hooks but before actual function). When you're trying to capture the overlay, you want your hook to run late.
The cop-out is to hook D3DKMTPresent instead and hope nobody else hooked it.
Detours rewrites instructions at the start of the detoured function. Why should it know or care whether the instructions it's overwriting happen to be ones written by a previous detour? Why would you need to synchronize?
Doesn't the Microsoft implementation work by having nop instruction as the first instruction of the function, which can then be patched to a jump to the patched code, that finally jumps back to the original function past the NOP?
Naive implementation of this scheme doesn't allow stacking.
If you have the standard two-byte backwards jump pointing to a longer jump instruction, you also have another happy case for overriding it (just change the long jump).
Meanwhile, the Microsoft Detours library supports detouring other kinds of instructions at the beginning of a function. It's not exclusively for the 'two byte nop and blank space' thing.
1) Thread A could read the original instructions immediately before thread B replaces them. Thread A’s trampoline would contain the original instructions, not the instructions from thread B, so it would bypass thread B’s hook.
2) Thread A reads original instructions while thread B is replacing them, such that it reads part of an original instruction and part of a replaced instruction. Thread A’s trampoline would have nonsensical instructions.
It's been at least 20 years, and Microsoft's blogging platform still doesn't support previous/next post links. Makes it goddamn hard to read the prior series about hot patching if it's not at the top of the blog.
>There is a race condition: The prescan may show that all the functions are safe to patch, but then somebody might patch a function after the prescan completes. In that case, the patcher will get halfway through and then discover the rogue-patched function, and now it’s kind of stuck. It can’t continue forward, and it can’t reliably roll back (because the rollback is probably also going to fail because the patch got overpatched). You’re stuck with a binary in memory that is half-patched, and who knows what’ll happen now.
Interesting framing that hooking functions is considered “rogue” by Microsoft, or something you’re “not authorized” to do, when Microsoft themselves makes the detours library and never framed it like this before.
Also, missing from this explanation: hooks are usually applied per process, from user space. The code pages in a dynamic library are CoW’d from the shared page when you write to them to apply a patch.
Does the Windows Update work similarly, or does it somehow modify the original, shared page, affecting all processes? Does a hook in a single process disable hot patching on the entire system?
They've also used Detours within Windows itself. The auto super resolution (AutoSR) feature works by dxgi.dll detouring specific calls in user32.dll, in-process, to virtualize certain monitor metrics. I found this out because it was broken for a while on Windows 11 ARM64 when it couldn't handle PAC-enabled function prologs and enabling it would just crash programs by corrupting user32 functions.
This has been a thing since the whole Windows MinWin project.
https://en.wikipedia.org/wiki/MinWin
https://techcommunity.microsoft.com/blog/windowsosplatform/o...
Detours like technology is used in API Sets, to redirect legacy DLLS into the new refactored ones.
https://learn.microsoft.com/en-us/windows/win32/apiindex/win...
No. API Sets use forwarding within the loader and are largely transparent to regular/delayed binding and GetProcAddress(). That would be fine. This is overwriting the prologue of the function in user32.dll similar to any other user-space hooking library.
Why would they need runtime patching instead of just replacing the legacy DLLs with ones that redirect to the new ones?
I was mistaken, the redirection workflow, takes another approach.
https://learn.microsoft.com/en-us/windows/win32/apiindex/api...
Hooking code you don’t own is typically playing with fire. Because Microsoft wrote the code, they’re generally in a better position to understand when it is safe to do so.
It is perfectly safe to hook any code as long as you can guarantee no thread is currently executing the instructions you're replacing.
Safety means more than torn writes
At a previous job I wrote a docker build for patching individual Java class files on top of a monolithic docker image. This was not runtime patching, but allowed a single layer that was only a few kilobytes to be deployed quickly in emergency situations.
Interestingly, it had similar constraints and checked them at build time: it could not be a public ABI change and only one patch at a time.
Was it for the log4shell vulnerability? I did something similar there.
The world could use more hot patching. Now that AI upends computer security, getting software patched in a timely fashion is more important than ever, and having to reboot/restart the process or computer to get those updates is more of a problem than it was before.
Agreed, it would be nice if it was more straightforward to set up self hosted hot patching on arbitrary Linux distros
Super easy to override software on nixos.
I genuinely cannot tell if you're joking.
I don't understand the joke. My background is worked at Ksplice a long time ago, patching the Linux kernel for security fixes without having to reboot.
Windows parallel DLL loading also defensively disables itself for a process if it finds some NT DLL functions have been hooked https://stackoverflow.com/questions/42789199/why-there-are-t...
If your hotpatching library is competent, then it does everything atomically. Either by suspending all threads first and temporarily resuming them while they're executing any affected instructions, or by just using atomics when possible.
In which case there is no race condition.
So much effort to reinvent half of Common Lisp. They haven’t gotten to the part where redefining a class causes all existing class instances to be lazily upgraded to the new class layout.
What happens if two consecutive updates try to hot patch the same function? Wouldn’t this be completely within the realm of possibility and be a pure Microsoft issue with no one else involved?
Detouring can be done for already detoured functions. Just look at Steam Overlay vs other systems that hook into Direct3D, they can coexist.
Any idea of how that's done? In particular, how do multiple systems synchronize the installation of their hooks?
I've made my own hooking library that lets multiple plug-ins hook the same function, but it only works decently because it has this central library synchronizing access.
If you use OBS, a game capture works the same way, it hooks the DirectX (or whatever API) functions to grab the rendered scene directly. It often has issues picking up overlays because there isn't really any synchronisation, just whatever made the last detour fires first. Like the sibling commit says, you can stack detours, it's only an issue for OBS if something that runs after it renders more things to the screen.
There is a setting to make it pick up overlays, which works reasonably well, I'm not entirely sure how it's implemented.
What an overlay does is hook the 'present' function, does more drawing, then calls the base 'present' function. It's easy enough to detect when a draw call happens during a call to 'present', that tells you that an overlay is active.
Then you're faced with the problem of how deep your hook is, you either want it to run early (before other hooks), or late (after other hooks but before actual function). When you're trying to capture the overlay, you want your hook to run late.
The cop-out is to hook D3DKMTPresent instead and hope nobody else hooked it.
Detours rewrites instructions at the start of the detoured function. Why should it know or care whether the instructions it's overwriting happen to be ones written by a previous detour? Why would you need to synchronize?
Doesn't the Microsoft implementation work by having nop instruction as the first instruction of the function, which can then be patched to a jump to the patched code, that finally jumps back to the original function past the NOP?
Naive implementation of this scheme doesn't allow stacking.
If you have the standard two-byte backwards jump pointing to a longer jump instruction, you also have another happy case for overriding it (just change the long jump).
Meanwhile, the Microsoft Detours library supports detouring other kinds of instructions at the beginning of a function. It's not exclusively for the 'two byte nop and blank space' thing.
1) Thread A could read the original instructions immediately before thread B replaces them. Thread A’s trampoline would contain the original instructions, not the instructions from thread B, so it would bypass thread B’s hook.
2) Thread A reads original instructions while thread B is replacing them, such that it reads part of an original instruction and part of a replaced instruction. Thread A’s trampoline would have nonsensical instructions.
It's been at least 20 years, and Microsoft's blogging platform still doesn't support previous/next post links. Makes it goddamn hard to read the prior series about hot patching if it's not at the top of the blog.
There actually used to be links, but they broke every time the blog platform was moved and eventually were taken out.
Missed opportunity for Microsoft to rewrite the whole blog in React Native.
It’s like mixing two different hot sauces, ymmv.
Or loading two different TSRs in DOS
That one used to be "fun" to track down, especially since most of them were coded in Assembly.
Don't cross the streams.
>There is a race condition: The prescan may show that all the functions are safe to patch, but then somebody might patch a function after the prescan completes. In that case, the patcher will get halfway through and then discover the rogue-patched function, and now it’s kind of stuck. It can’t continue forward, and it can’t reliably roll back (because the rollback is probably also going to fail because the patch got overpatched). You’re stuck with a binary in memory that is half-patched, and who knows what’ll happen now.
Ehh :) scenarios like this are the best