Cool solution, but I'd assume/hope Windows currently has sufficient memory protections to not allow applications to rewrite their own memory - especially if the function was already in a DLL to begin with and not JIT-generated code?
Code segments are not writeble by default on Windows, like on any modern OS, but you can make any memory segment in your own process writable using VirtualProtect. That is not unique to Windows as well, on Linux you could achieve the same with mprotect.
As sibling notes, executable memory is not by default writable. If desired, you can also further disallow any executable memory to me allocated or modified by your process, even via the normal APIs, by calling SetProcessMitigationPolicy with ProcessDynamicCodePolicy.
The most insidious version of this I experienced was when a library changed the FPU settings.
Fortunately, it was sufficient to reset the FPU settings after initializing the library. But it sure took a long time to figure out what happened!
Cool solution, but I'd assume/hope Windows currently has sufficient memory protections to not allow applications to rewrite their own memory - especially if the function was already in a DLL to begin with and not JIT-generated code?
Code segments are not writeble by default on Windows, like on any modern OS, but you can make any memory segment in your own process writable using VirtualProtect. That is not unique to Windows as well, on Linux you could achieve the same with mprotect.
As sibling notes, executable memory is not by default writable. If desired, you can also further disallow any executable memory to me allocated or modified by your process, even via the normal APIs, by calling SetProcessMitigationPolicy with ProcessDynamicCodePolicy.
https://learn.microsoft.com/en-us/windows/win32/api/processt...