Hello Alex,

Secure Boot should stop malware from loading early in the boot process, before Windows is in complete control of the system. When thinking about how the malware is establishing itself in your system, knowing that it is unlikely to be an early load infection should be helpful.

Here is an update on what I have been working on (perhaps of interest to vivs_lunchtime).

Searching the dump file from within a debugger session of the crash dump is very slow (at least with the commands that I know - in particular the debugger "s" command). What I tried instead was just mapping the dump file as a stream of bytes and searching that (a search of the entire file takes about 5 seconds).

This is a search for the CR0 manipulation code (it is found in 6 different locations), with my annotation in bold of the physical address:

0:000> s 7FFF0000 L? 0n1884972538 41 0f 20 c4 49 8b c4 48 0f ba f0 10 0f 22 c0

00000000`81178c82 41 0f 20 c4 49 8b c4 48-0f ba f0 10 0f 22 c0 8b A. .I..H.....".. 2bddc82

00000000`817aa904 41 0f 20 c4 49 8b c4 48-0f ba f0 10 0f 22 c0 41 A. .I..H.....".A 320f904

00000000`817af39f 41 0f 20 c4 49 8b c4 48-0f ba f0 10 0f 22 c0 44 A. .I..H.....".D 321439f

00000000`82c1b10d 41 0f 20 c4 49 8b c4 48-0f ba f0 10 0f 22 c0 8b A. .I..H.....".. 4de910d

00000000`ec099d90 41 0f 20 c4 49 8b c4 48-0f ba f0 10 0f 22 c0 44 A. .I..H.....".D 839a3cd90

00000000`ec09d2f5 41 0f 20 c4 49 8b c4 48-0f ba f0 10 0f 22 c0 41 A. .I..H.....".A 839A402f5

One can verify the data at the physical address matches with the !db command:

6: kd> !db 2bddc82 l 10

2bddc82 41 0f 20 c4 49 8b c4 48-0f ba f0 10 0f 22 c0 8b A. .I..H....."..

To get a virtual address, I use a combination of the !pfn and !pte commands:

6: kd> !pfn 2bdd

unable to get nt!PspSessionIdBitmap

PFN 00002BDD at address FFFF840000083970 

flink       00000000  blink / share count 00000001  pteaddress **FFFF997C0033AEE8** 

reference count 0001    used entry count  0000      Cached    color 0   Priority 0 

restore pte 00000080  containing page 004A0B  Active 

6: kd> !pte FFFF997C0033AEE8

                                       VA **fffff800675dd000** 

PXE at FFFF994CA6532F80 PPE at FFFF994CA65F0008 PDE at FFFF994CBE0019D0 PTE at FFFF997C0033AEE8

contains 000000000490A063 contains 0000000004A0B063 contains 0A00000002A001A1 contains 0000000000000000

pfn 490a ---DA--KWEV pfn 4a0b ---DA--KWEV pfn 2a00 -GL-A--KREV LARGE PAGE pfn 2bdd

6: kd> db fffff800675dd000+c82 l 10

fffff800`675ddc82 41 0f 20 c4 49 8b c4 48-0f ba f0 10 0f 22 c0 8b A. .I..H....."..

In the six found instances of the CR0 code sequence, where the first 0x10 bytes are shown, one can see that the last byte differs.

410f20c4 mov r12,cr0

498bc4 mov rax,r12

480fbaf010 btr rax,10h

0f22c0 mov cr0,rax

8b83a00a0000 mov eax,dword ptr [rbx+0AA0h]

These show examples of register renaming:

0:000> u 81178c82+f l 1

00000000`81178c91 8b83a00a0000 mov eax,dword ptr [rbx+0AA0h]

0:000> u 817aa904+f l 1

00000000`817aa913 418b81a00a0000 mov eax,dword ptr [r9+0AA0h]

0:000> u 817af39f+f l 1

00000000`817af3ae 448b8fa00a0000 mov r9d,dword ptr [rdi+0AA0h]

0:000> u 82c1b10d+f l 1

00000000`82c1b11c 8b87a00a0000 mov eax,dword ptr [rdi+0AA0h]

0:000> u ec099d90+f l 1

00000000`ec099d9f 448b8fa00a0000 mov r9d,dword ptr [rdi+0AA0h]

0:000> u ec09d2f5+f l 1

00000000`ec09d304 418b81a00a0000 mov eax,dword ptr [r9+0AA0h]

Gary

The first 3 of those code addresses are in the NT kernel:

For analysis of this file, run !analyze -v

6: kd> u fffff800675dd000+c82 l 4

nt!KiSwInterruptDispatch+0xb42:

fffff800`675ddc82 410f20c4 mov r12,cr0

fffff800`675ddc86 498bc4 mov rax,r12

fffff800`675ddc89 480fbaf010 btr rax,10h

fffff800`675ddc8e 0f22c0 mov cr0,rax

6: kd> u fffff80067c0f000+904 l 4

nt!FsRtlMdlReadCompleteDevEx+0x138f4:

fffff800`67c0f904 410f20c4 mov r12,cr0

fffff800`67c0f908 498bc4 mov rax,r12

fffff800`67c0f90b 480fbaf010 btr rax,10h

fffff800`67c0f910 0f22c0 mov cr0,rax

6: kd> u fffff80067c14000+39f l 4

nt!$$b8+0xfd3:

fffff800`67c1439f 410f20c4 mov r12,cr0

fffff800`67c143a3 498bc4 mov rax,r12

fffff800`67c143a6 480fbaf010 btr rax,10h

fffff800`67c143ab 0f22c0 mov cr0,rax

I downloaded the kernel image from the Microsoft symbol server and the code is present there too. This code could be part of the Microsoft PatchGuard implementation. Microsoft intentionally obfuscate PatchGuard to make it more difficult (time consuming) to reverse engineer and evade...

I am currently balancing two possibilities:

1. Malware has copied and reused part of PatchGuard. [my gut feeling is currently 60 % chance]
2. There is not a malware problem - just a "normal" bug. [my gut feeling is currently 40 % chance]

Gary

@Gary: Thanks für the update. I start feeling the same. After your last update, I start to get the eerie feeling it might be an amok-running instance of patchguard killing people's PCs on AMD platform with Win10 systems, but there are also contra arguments.

I summarize the known facts below.

Loading the shellcode: I don't know. Having rifled through the stack, I found vague indications that it might have been though MmAllocateIndependentPages. But I would need to verify that this API creates linear PA space.

Loading, in general: nothing.

It appears to have no driver image. That sucks. Usermode information is not really available in the dump. I went through the driver list of both affected persons, comparing both, and though there are plenty of suspect third party drivers, there was no apparent overlap. Currently there is no indication that anyone of the drivers in the module list is the originator.

I don't think there will be a solution soon. Except if Microsoft sees this thread and finds out that it's an amok-running patchguard. Then we could get a "cure" perhaps as soon as Jan/Feb. :-D

But there is other news. This specific BSOD and the cr0 sequence shellcode has been a real epidemy lately, but only for AMD and Win10 users (could it be the motherboards software after all?).

All of these people suffer from the same:

• 22. June 2024, Last updated November 13, 2024 https://answers.microsoft.com/en-us/windows/forum/all/bsod-kmode-exception-not-handled/74749c53-923f-4acf-ac5a-834ee27b5e89
• 25. February 2024, Last updated November 12, 2024 https://answers.microsoft.com/en-us/windows/forum/all/criticalstructurecorruption-on-new-win10-desktop/29d46e64-33d8-4d12-a5a2-61ab231ac2a7
• 5. April 2024, Last updated November 12, 2024 https://answers.microsoft.com/en-us/windows/forum/all/bsod-on-new-pc/5240dda4-16b5-4fbf-be78-7a5fe8f8dbf8
• 9 November 2024, Last updated November 16, 2024 https://answers.microsoft.com/en-us/windows/forum/all/windows-crashes-randomly-due-to-ntkrnlmpexe/a25c76cb-c355-4ee6-aed1-e08b4c62403c
• 29. October 2024, Last updated November 6 2024 https://answers.microsoft.com/en-us/windows/forum/all/windows-10-machine-keeps-bsod-kmode-exception-not/1659899f-977d-4dca-9d48-124e6cc483ec
• 14. December 2024 https://answers.microsoft.com/en-us/windows/forum/all/system-crashes-and-bsods/f96789bc-1b91-4579-bdc1-381613f56376

The list goes on indefinitely... Many of these people have been stuck for months with the BSODs.

Only Win10 & AMD platforms are affected... (it seems?)

The cr0 Write Protection trick in the rwx shellcode is documented at various places, anticheat forum for instance. It is also denoted there for its unsafety and deprecation because attempting to write to CR0 may cause a BSOD. Essentially the BSOD those people are suffering.

Summary of solid facts:

• It uses nonpaged rwx shellcode with polymorphic ring0 code.
• The shellcode attempts to modify CR0 and remove Write Protection and that kills a lot of people's PCs. (Would Patchguard ever try to remove the Write Protectio bit in CR0?)
• The shellcode is using a linear PA space. It could not have been allocated by ExAllocateXXX.
• The use of KM RWX kernel memory (and shellcode) is on Microsoft most hated list.
• It affects only AMD platform users with Win10. (Actually, this point is not fully proven.)
• In Alex case, in two minidumps write protection was removed and the read-only code of an ndis routine was provably overwritten in the middle, detected by patchguard which alerted and shut down the OS with a CRITICAL CORRUPTION alert and pointing to the afflicted ndis routine. (The new bytes cut plain through the middle of an x64 instruction, probably not intentional. It must have been a heuristical approach that missed its true target, but here we are at speculations again which I was trying to avoid).

Most likely origins:

• Advanced rootkit, coming in from motherboard software or misusing it as entry point (rw primitive etc).
• Motherboard software
• Amok-running Patchguard

WARNING: I am going to have long christmas holidays, we have to find a *temporary* solution for all these people ASAP.

I'm going to lead all these people here and tell them to use Core Isolation as temporary solution.

With many people turning on the Core Isolation, we get another clue through them reporting back if it works.

Except for the patchguard-theory, the BSODs are guaranteed to stop. In other words, if the BSODs don't vanish it leaves patchguard pretty much as the only possible origin.

Hello vivs_lunchtime,

It has been great collaborating with you so far - I don't often encounter people in the web to whom I can express my technical thoughts without providing a lengthy explanatory text.

I think that the useful information for Alex and others is that we have moved from an opinion of "very probably malware" to "possibly malware". The steps that Alex has taken (enabling Secure Boot, Core Isolation, Windows reinstall) is probably enough to tackle the possibility of malware - more time consuming resetting and reinstallation is probably not warranted.

I am retired and enjoy this type of problem as a hobby, so I will continue searching for an explanation but progress (if any) will probably only come slowly...

Gary