BSOD On Win 10 1909 x64 with Riot Vanguard

Mattiwatti / EfiGuard

Disable PatchGuard and Driver Signature Enforcement at boot time

GNU General Public License v3.0

1.84k stars 342 forks source link

BSOD On Win 10 1909 x64 with Riot Vanguard #13

Closed nerded1337 closed 4 years ago

nerded1337 commented 4 years ago

Hi,

I have a driver that is loaded at boot time. In a win10 pro computer, the driver BSOD right after having booted on EfiGuard.

Here is the stack.

Seems like KiSwInterruptDispatch is an Hyper-V addon in PatchGuard. I found a relatively interesting pdf talking about it https://blog.tetrane.com/downloads/Tetrane_PatchGuard_Analysis_RS4_v1.01.pdf.

Do you think that their solution would work ? I'm not very confident at this low level, but I can try to implement it.

The bugcheck is occuring at the last line in this screen:

Im not sure but rdi seems to be the pointer to the PatchGuard structure, which is not initialized, resulting in

fffff802747a9a67 f7879409000000001000 test dword ptr [rdi+994h],100000h ds:00000000`00000994=????????

What do you think ?

nerded1337 commented 4 years ago

Just checked in a windows 10 home, the problem doesn't exists. Seems like it is related to entreprise edition.

Mattiwatti commented 4 years ago

This problem is actually related to Vanguard, the anti-cheat driver for Riot's Valorant. It's not related to Windows Home vs Enterprise. Most likely you do not have Vanguard installed on Home, which would explain the difference. Vanguard uses int 20h as a brute force method of bringing down a Windows 10 system if PatchGuard was not initialized.

I fixed this crash a few days ago in this commit. (Note: this is a different fix than the one proposed in your PDF, because Tetrane focused on disabling a running PatchGuard, whereas EfiGuard prevents PatchGuard from initializing.)

There is no binary release yet that includes this fix, because I hope to include fixes for some other unrelated issues in the upcoming release. I don't have an ETA for the next release yet, so meanwhile you can use the following driver binary: EfiGuardDxe-222d5e3.zip.

Let me know if this fixes your crash. I'll leave this issue open for now (at least until the next release is out) so that it's easier to find.

nerded1337 commented 4 years ago

I actually have vanguard on my win10 home, with no crash so far, using the same exact EfiGuard binaries as on the entreprise... Which I compiled something like 15 days ago

Mattiwatti commented 4 years ago

Is it up to date? This "check" (for lack of a better description) was added to Vanguard fairly recently as far as I'm aware. If it is, then I have no explanation for the difference in behaviour. But the bugcheck is definitely caused by Vanguard, as you can see in your stacktrace which implicates vgk.sys.

nerded1337 commented 4 years ago

Yeah the bugcheck is caused by Vanguard, both computer had the game updated from yesterday patch. Btw I installed win10 home to check whether I was crazy or not, the bug disappeared...

nerded1337 commented 4 years ago

From https://sudonull.com/post/102713.

When viewing the KiFilterFiberContext from the Windows 10 Technical Preview, we noticed a slight change. All the old planning methods have remained the same. However, a new one has appeared, which so far certainly returns STATUS_HV_FEATURE_UNAVAILABLE. After a little digging, we found the KiSwInterruptDispatch function, inside which the decryption and the context check call are obviously going on. Obviously, the ability to check contexts at the request of the Hyper-V hypervisor will be added. Under certain conditions, a synthetic interrupt will come from the hypervisor, the handler of which will check the integrity of the kernel.

Don't you think this is related to Hyper-V being enabled by default on win10 entreprise?

Mattiwatti commented 4 years ago

The hypervisor-related return status only gives an indication of the potential intended 'client' of the int 20h ISR: the Hyper-V hypervisor. But this ISR exists on all versions of Windows 10 and is always installed, and nothing prevents a third party driver (here: Vanguard) from calling it. Your bugcheck is definitely caused directly by Vanguard's vgk.sys and is not related to Hyper-V. Again, see the stacktrace for proof of this.

nerded1337 commented 4 years ago

Thanks for the detailed explanations, I'm still curious about my computer not bugchecking while booting on the older version of EfiGuard. Anyway, I rebuilt the latest version, thanks again for what you are doing!