No sorry but there is nothing to check, have you seen the linked articles, a process can always write into its own address space hence it can always bypass any user mode hooks. They have implemented it this way because there is simply no way to reliably protect those resources in 64 bit windows, except through using a restricted process token. The caveat with using a restricted process token like sandboxie does is that it breaks pretty much everything so almost no regular application can successfully run under such conditions. What sandboxie does to cope with this situation is it implements a butt load of workarounds and call proxies and emulated API implementations, plus it uses unexported kernel functions and is messing with undocumented kernel structures to do its process token wizardry. Look sure one can try to mitigate this issue, but nothing that can be done to protect a user mode hook is really robust. The problem is not just that you can't to protect a given memory page from being altered by the offending process. If it would be just that one could may be think of something. But the problem is bigger, you see what these hooks ultimately do is to place themselves some ware between a API call of a system library and a syscall invocation to the kernel. Such a syscall is no magic and is nothing special any application can completely bypass system libraries and issue syscalls directly to the kernel. Now normally this is not done because MSFT is changing syscall numbers between larger builds so if an application wants to do its own syscalls it must check the kernel version and have a list of indexes, also it wont be able to operate on any newer/unknown version of the system, but that's a practical limitation not a fundamental one, you just need to keep your malware up to date. So if we want to protect memory pages which contains our user mode hooks we would use for the NtProtectVirtualMemory syscall and of cause hook that function in the ntdll to. So that a process when it attempts to change memory protection on some memory, will first go through our hook that will deny access to pages we have hooks on. But than the malware author will just implement an own MyProtectVirtualMemory function (or MyVirtualAllocEx) independent from the ntdll which issues a syscall to the kernel directly requesting the change in protection and the kernel will oblige, there are no callbacks in the kernel to my knowledge which would allow a driver to filter such requests. Now at this point the magnitude of the issue becomes really apparent, protecting our hooks is not the primary issue at hand, preventing an application from executing own rogue syscall's directly is. And that's if not entirely impossible pretty much entirely impractical. You see a syscall is just a CPU instruction, so we can not hook it. If we really want to block it we need to ensure there will never be a sequence of bytes in executable memory of a given process which is a syscall. To not go to much into details here, in the end it boils down to if we can ensure any application that runs within the supervision of the product will never have memory pages marked as executable and writable at the same time, which admittedly would be good practice but often is not the case. So eider we opt to break any application that requires this like possibly many script engines which generate machine code for better performance, various copy protection and obfuscation schemes, and others... Or we could in theory go with never making memory executable and writable at the same time, even if that's being requested, attach a debugger to the application to catch all memory access violations and than eider set the memory writable and remove the executable flag, or vice versa first scanning it for syscall code and resume execution each time such a situation arises. This is quite impractical, plus it will still break many copy protection schemes as they don't like running under a debugger. Its simply more and more afford for a diminishing return security wise, given that a lot of malware is not that advanced, in the end these companies are selling a product, it just has to be good enough, cheep to maintain and sound great in the marketing materials. So it does not have to be flawless, and there is the possibility of some windows 0 day vulnerability through some unprivileged API that would still make the malware escape the isolation.