Message 3 of 3
03 Jan 18 12:14
Join Date: 31 Dec 2017
Posts To This List: 17
Protecting my driver from BSOD?
What you asked about KeBugCheckEx interception, that is definitely possible. It
was abused for an early-days PatchGuard exploit to continue patching the Windows
Kernel on 64-bit systems, and the method worked because when KeBugCheckEx would
be called, it'd not proceed due to the hook and thus the system would not crash.
However, this was patched by Microsoft and it was never stable or safe. The
Windows Kernel enforces a BSOD crash for a reason... When you mess up in
kernel-mode, the memory becomes broken. When you mess-up in user-mode, the
process has its own virtual memory, and thus the process can just crash and be
started up again. Of course, in kernel-mode this isn't the case because you have
system-wide memory access, and also to memory you cannot access from
user-mode... Belongs to the Windows Kernel.
Don't try and block BSODs. Instead, try to develop good, safe and stable code
which is likely not to cause a bug-check.
Use !analyze -v to find out more details on the BSOD crash with the dump file,
and do some kernel debugging with your driver component to try and discover what
the issue might be (also using the dump file as a resource).
Test, test, test, test and test. Never stop testing. Do not release a
kernel-mode component in any software until you've extensively tested it so much
that your hands are black and blue. Penetration test it as much as possible.
Literally intentionally try to break it as much as possible, then make it stable
by fixing the way you broke it. And do this so much that it becomes really
stable and secure.