What is causing my computer to BSOD at random times?

Hello Alex,

Can you make copies of these drivers available so that we can search them for CR manipulation instructions?

\Windows\system32\AMDRyzenMasterDriver.sys

\Windows\System32\drivers\acpipagr.sys

\Windows\System32\drivers\amdkmpfd.sys

\Windows\System32\drivers\amdpsp.sys

\Windows\System32\drivers\amdxe.sys

\Windows\system32\DRIVERS\farflt.sys

\Windows\System32\drivers\gpuenergydrv.sys

\Windows\System32\drivers\IntelTA.sys

\Windows\system32\drivers\mbae64.sys

\Windows\system32\DRIVERS\mbam.sys

\Windows\System32\Drivers\MbamChameleon.sys

\Windows\System32\Drivers\mbamswissarmy.sys

\Windows\system32\DRIVERS\mwac.sys

\Windows\system32\drivers\RTKVHD64.sys

\Windows\System32\Drivers\SignalRgbDriver.sys

\Windows\system32\drivers\SleepStudyHelper.sys

\Windows\System32\DriverStore\FileRepository\amd3dvcache.inf_amd64_558311a8a60226a4\amd3dvcache.sys

\Windows\System32\DriverStore\FileRepository\amdfendr.inf_amd64_05bfde18331c4d58\amdfendr.sys

\Windows\System32\DriverStore\FileRepository\amdfendr.inf_amd64_05bfde18331c4d58\amdfendrmgr.sys

\Windows\System32\DriverStore\FileRepository\amdsafd.inf_amd64_d4de13a10f2586d0\amdsafd.sys

\Windows\System32\DriverStore\FileRepository\atihdwt6.inf_amd64_4ad1437aef138551\AtihdWT6.sys

\Windows\System32\DriverStore\FileRepository\basicdisplay.inf_amd64_19e58b6267591a82\BasicDisplay.sys

\Windows\System32\DriverStore\FileRepository\basicrender.inf_amd64_d3f5994a67770b50\BasicRender.sys

\Windows\System32\DriverStore\FileRepository\compositebus.inf_amd64_7500cffa210c6946\CompositeBus.sys

\Windows\System32\DriverStore\FileRepository\gameflt.inf_amd64_25b1fe3637126834\gameflt.sys

\Windows\System32\DriverStore\FileRepository\swenum.inf_amd64_16a14542b63c02af\swenum.sys

\Windows\System32\DriverStore\FileRepository\u0410212.inf_amd64_daae2c8b5eb35aaa\B409877\amdkmdag.sys

\Windows\System32\DriverStore\FileRepository\uefi.inf_amd64_c1628ffa62c8e54c\UEFI.sys

\Windows\System32\DriverStore\FileRepository\umbus.inf_amd64_b78a9c5b6fd62c27\umbus.sys

\Windows\System32\DriverStore\FileRepository\xvdd.inf_amd64_a651bff0be9a1044\xvdd.sys

Gary

Batch-find Cr0.WP manipulating byte sequences using ropper

// Can likewise be used to find CR4-manipulating sequences... but you have to find the Cr0 sequences first. Cr4.cet check needs to be coupled to the Cr0.WP manipulation.

Given (from memory.dmp in KD):

ffffd28a`a9e182f5 410f20c4        mov     r12,cr0 ; => mov reg, cr0. Exists with 41 prefix and without.

ffffd28a`a9e182f9 498bc4          mov     rax,r12 ; => 3 bytes for a "mov reg,reg" intermezzo to save original CR0 bitmask on other reg.
ffffd28a`a9e182fc 480fbaf010      btr     rax,10h ; => Compiler optimization. Might be used or not. 
ffffd28a`a9e18301 0f22c0          mov     cr0,rax ; => mov cr0, reg. Exists with 41 prefix and without. 

Using ropper, after trying a bit and some tweaking: ?? + 0f20c? + ??????????????10 + 0f22c? . (There is still optimization potential in here.)

The first "??" is for getting optical output enhancement, for the possible 41.

> opcode ??0f20c???????????????100f22c? 

0x00000001403e0c81: 410f20c4498bc4480fbaf0100f22c0; 

0x00000001403ece4a: 410f20c7498bc7480fbaf0100f22c0; 

0x0000000140b0af5d: 410f20c7498bc7480fbaf0100f22c0; 

0x0000000140b1081d: 410f20c4498bc4480fbaf0100f22c0; 

0x0000000140b313ab: 410f20c7498bc7480fbaf0100f22c0; 

Looks good. By the way, that's for my Win11 VM (23H2). No Win 10 involved.

> disasm 410f20c4498bc4480fbaf0100f22c0 

mov r12, cr0 

mov rax, r12 

btr rax, 0x10 

mov cr0, rax 

>  disasm 410f20c7498bc7480fbaf0100f22c0 

mov r15, cr0 

mov rax, r15 

btr rax, 0x10 

mov cr0, rax 

The sequence with "remove Write Protection bit from CR0" exists in two variants with r15 (3x) and r12 (2x) register use. If these five sequences do not also check CR4.CET before removing CR0.WP, they will kill all PCs with Intel CET enabled on their execution.

So, for loading all third party driver images at once in ropper and make ropper search on all:

"ropper.exe --console --all -f C:\thirdpartydrivers\driver1.sys C:\thirdpartydrivers\driver2.sys C:\thirdpartydrivers\driver3.sys"

Put as many third party driver files as you want to the invocation line. Everything you do will be done on all of them.

The opcode search is not only blazing fast (returns almost instantly), it also has wildcard/regex support and searches only on code sections, not in data sections. On ALL code sections of ALL loaded driver images. Also helpful are the support commands like asm and disasm.

Don't use the search command, a shame that it tries to find rets (why would anyone want to do that? :-DD), with no option to turn this off(?).

For people without complete x64 menomic reference in their head, the asm and disasm command could be helpful:

> asm mov rax, cr0 

0f20c0 

> disasm 410f20c1 

mov r9, cr0 

I would bet a chocolate that all 5 sequences above (on my Win11) don't check the needed CR4.CET bit when they trying to remove Write Protection globally. But I won't suffer a BSOD any time soon -- no Intel CET.

I don't think it's comes from any third party driver images, there are already multiple occurances of the definitely faulty code in ntoskrnl (all ntoskrnls, even on Win11). But, the possibility cannot be excluded. I will be in holidays tomorrow and seriously offline. I think it's patchguard and only patchguard.

The most practical way to go hunting for the sequence in my opionion is to use ropper against all the third party driver files to find CR4-using instructions. You can then go wildcard-searching for x64 assembly instruction with any CR4 reg usage. And you can load all the third party drivers at once in ropper, and then have one big search.

Have nice christmas, and I hope one of my former solutions work.

For anyone with the BSODs and the shellcode, please be sure to report success if either Core Isolation or Win11 24H2 works, for all the other people still suffering BSODs!

Hello vivs_lunchtime

I think that there is a very good chance that you have found the explanation,

I will put together a list of third party drivers on Alex's system, which he could possibly zip up and make available, so that we can search the code for "mov, cr4,r?" instructions ((part of) the code of many drivers is "paged out" and not available in the kernel dump).

If we find a suitable code sequence in a third party driver, then that would be pretty strong evidence for the cause of the problem.

Gary

Updated potential solutions:

• Win 10 with Core Isolation, might change patchguard behavior. It won't be able to use the rwx shellcode with the bad sequence. (originator can't be proven but it's patchguards code.)
• Win 11 24H2, because the OS developers must have been more aware of the new technology at this point, potentially including newer patchguard code (although one bad sequence is in nt!KiSwInterruptDispatch, as of 23H2).