This is an experimental proposal, to be taken with a grain of salt.
We know that Sandboxie recently reported several kernel vulnerabilities CVE-205-46713, CVE-2025-46714, CVE-2025-46716,VE-2025-46715, etc., and the RCE ones are not easy to trigger, but the kernel arbitrary read is easy to trigger So, can we speculate that there might be other potential vulnerable drivers that also support kernel arbitrary read?
Currently, Sandboxie's attitude towards kernel drivers is basically a policy of appeasement, but we also need to guard against such issues, dont we?
Yes, if our opponent is a carefully crafted kernel driver specifically designed for us, we have no way to get around it, but if the opponent is just a user-mode program attempting to exploit a tiny driver vulnerability, should we just sit back and wait to be hit?
I believe that our security volume key is currently stored in plaintext in the drive's memory, and in the past, there was no way to prevent the kernel from reading our secret memory, but now there is.
Intel's VT technology allows us to protect our memory space from other kernel drivers from non-malicious, accidental, direct memory accesses in a number of other drivers, and I believe this is sufficient to protect our keys from being stolen by user-mode programs that exploit vulnerabilities like the one mentioned at the beginning.
If you are worried about using VT technology being rejected by MSFT with a signature, rest assured, 360 Total Security and Kaspersky both use similar, and there are even Microsoft's own components:https://learn.microsoft.com/en-us/windows/win32/procthread/isolated-user-mode--ium--processes
We know that Sandboxie recently reported several kernel vulnerabilities CVE-205-46713, CVE-2025-46714, CVE-2025-46716,VE-2025-46715, etc., and the RCE ones are not easy to trigger, but the kernel arbitrary read is easy to trigger So, can we speculate that there might be other potential vulnerable drivers that also support kernel arbitrary read?
Currently, Sandboxie's attitude towards kernel drivers is basically a policy of appeasement, but we also need to guard against such issues, dont we?
Yes, if our opponent is a carefully crafted kernel driver specifically designed for us, we have no way to get around it, but if the opponent is just a user-mode program attempting to exploit a tiny driver vulnerability, should we just sit back and wait to be hit?
I believe that our security volume key is currently stored in plaintext in the drive's memory, and in the past, there was no way to prevent the kernel from reading our secret memory, but now there is.
Intel's VT technology allows us to protect our memory space from other kernel drivers from non-malicious, accidental, direct memory accesses in a number of other drivers, and I believe this is sufficient to protect our keys from being stolen by user-mode programs that exploit vulnerabilities like the one mentioned at the beginning.
If you are worried about using VT technology being rejected by MSFT with a signature, rest assured, 360 Total Security and Kaspersky both use similar, and there are even Microsoft's own components:https://learn.microsoft.com/en-us/windows/win32/procthread/isolated-user-mode--ium--processes