The LSTAR MSR can be intercepted using a hypervisor to trap on reads and writes. It is the most common and efficient way to hook syscalls in most modern x86 operating systems. However contrary to what I’ve read online, this unfortunately comes at the cost of many potential detection vectors for the hypervisor if not properly dealt with. Using a few clever tricks in privileged code, we can reliably determine if a hook on the LSTAR MSR is present or not, that is, if proper precautions have not already been implemented in the hypervisor. Starting in Windows 10 1903 build 18362, Microsoft added several LSTAR hook detection techniques.

One of the simpler LSTAR hook detections was not given the meme “errata” name, perhaps it was not good enough 🙁 – so let’s call it KiErrata420Present (possibly not that far off from what Microsoft calls it internally?).

I have outlined the detection below:

KiErrata420Present: cli ; disable interrupts mov r9d, 0C0000082h ; mov ecx, r9d ; rdmsr ; read LSTAR MSR value shl rdx, 32 ; or rax, rdx ; store LSTAR value in rax lea rdx, [rdi+87Ah] ; store temp LSTAR value in rdx read from pg context mov rbx, rax ; rbx = original LSTAR value mov rax, rdx ; rax = temp LSTAR value shr rdx, 32 ; wrmsr ; write temporary LSTAR MSR value mov r14d, 20000h ; lea rax, [rdi+87Ch] ; rax = stub to execute syscall mov rsi, 0A3A03F5891C8B4E8h ; rsi = constant to obfuscate pg context pointer test [rdi+994h], r14d ; test if should store pg check data? jnz short trigger_syscall ; if nz, skip tracing mov r8, gs:KPCR.CurrentPrcb ; lea rdx, [rdi+rsi] ; mov rcx, [rdi+4C0h] ; mov [rcx], rdx ; mov rcx, [rdi+4C8h] ; store pg check related data mov [rcx], r8 ; mov rcx, [rdi+4D0h] ; mov [rcx], r9 ; mov rcx, [rdi+4D8h] ; mov qword ptr [rcx], 112h ; trigger_syscall: call KeGuardDispatchICall ; dispatch call to syscall instruction stub test [rdi+994h], r14d ; test if pg check should be traced? jnz short restore_lstar ; if nz, skip tracing mov rax, [rdi+4C0h] ; mov [rax], rsi ; mov rax, [rdi+4C8h] ; mov [rax], r13 ; wipe pg check related data mov rax, [rdi+4D0h] ; mov [rax], r13 ; mov rax, [rdi+4D8h] ; mov [rax], r13 ; restore_lstar: mov rdx, rbx ; restore original LSTAR value mov rax, rbx ; shr rdx, 32 ; mov ecx, 0C0000082h ; wrmsr ; write original LSTAR MSR value sti ; reenable interrupts

This check is indeed very simple. It temporarily overwrites the system’s LSTAR MSR value with its own temporary syscall handler, and restores the original LSTAR MSR value afterwards. How do I know this for sure? Let’s dig in further to find out.

First off let’s figure out what temporary value is written to the LSTAR MSR:

lea rdx, [rdi+87Ah] ; store temp LSTAR value in rdx read from pg context mov rbx, rax ; rbx = original LSTAR value mov rax, rdx ; rax = temp LSTAR value shr rdx, 32 ;

As we can see the temporary LSTAR value written is the address at RDI+0x87A . Knowing a little about the patchguard callback we know that the RDI register holds a temporary addresses of the current “patchguard context”. Using this knowledge, we can easily determine where the context+0x87A is written to in the patchguard initialization routine:

mov byte ptr [r14+87Ah], 0C3h ; store RET instruction