Solved New revocations for CVE-2023-24932 (Black Lotus) not working correctly?

Following the instructions from this site: KB5025885: How to manage the Windows Boot Manager revocations for Secure Boot changes associated with CVE-2023-24932 - Microsoft Support

Ever since the July 11 KB5028185 update, the method of patching against Black Lotus was made a bit easier.
The first step to take is to update your Windows installers orcourse.

Then open an administrative command prompt, paste the following: "reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot /v AvailableUpdates /t REG_DWORD /d 0x30 /f"

Reboot

Wait 5 minutes

Reboot again.

To verify that the revocations have been applied successfully, 2 new Event ID's should appear in Event Viewer.
ID 1035 to verify that Dbx have been updated successfully, and also Event ID 276 to verify that the boot manager loads the SKUSIPolicy.p7b successfully.

However, I have tested this on several new unpatched machines. All with the latest updates, both Win 11 Home and Pro (all 2H22) and there is no 276 Event ID after the revocations are completed.

I do see the 1035 Event, but no 276 Event.

Could somebody else verify this?

Anybody with an unpatched system that wanna try this themselves and share their results?

In the original MS document the revocation consisted of two actions - 1) copying a .p7b file from the local file system to the EFI partition and 2) changing the registry entry. The current version of the document omits item 1 and refers only to item 2. Actually it mentions the p7b file but the instructions are no longer there. The July update did not copy it either - I've just checked.
So maybe the reason you are not getting the 276 message is because the new p7b file really isn't there - unless you already copied it before.

This is what the original article contained:
mountvol q: /S
xcopy %systemroot%\System32\SecureBootUpdates\SKUSiPolicy.p7b q:\EFI\Microsoft\Boot
mountvol q: /D

xrms3 said:

In the original MS document the revocation consisted of two actions - 1) copying a .p7b file from the local file system to the EFI partition and 2) changing the registry entry. The current version of the document omits item 1 and refers only to item 2. Actually it mentions the p7b file but the instructions are no longer there. The July update did not copy it either - I've just checked.
So maybe the reason you are not getting the 276 message is because the new p7b file really isn't there - unless you already copied it before.

This is what the original article contained:
mountvol q: /S
xcopy %systemroot%\System32\SecureBootUpdates\SKUSiPolicy.p7b q:\EFI\Microsoft\Boot
mountvol q: /D

Click to expand...

Yes, it's now only 1 line of code after the July 11 2023 update. (reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot /v AvailableUpdates /t REG_DWORD /d 0x30 /f)

On a fresh install, after applying the latest update and rebooting. Issuing the following command: "dir q:\EFI\Microsoft\Boot" reveals that SKUSiPolicy.p7b is actually located under the EFI\Microsoft\Boot folder. It just does not seem like SKUSIPolicy.p7b loads successfully.

I also have another machine with the first revocations active but I still don't see the 276 Event ID on that machine.


Have you tried it yourself? Do you get Event ID 276 on your machine?

No, I haven't tried it.

I did notice, though, that following the July update, little fingers have been busy in the C:\$Winreagent directory. It now contains a copy of my current winre.wim plus what appears to be an updated version - update.wim. This may have been a test to confirm that applying the July update works ok and that the size of the end product would fit the current partition.

Sorry can't help further with Event 276. I think this is all still a work-in-progress as far as MS is concerned and it will all be sorted eventually.

xrms3 said:

No, I haven't tried it.

I did notice, though, that following the July update, little fingers have been busy in the C:\$Winreagent directory. It now contains a copy of my current winre.wim plus what appears to be an updated version - update.wim. This may have been a test to confirm that applying the July update works ok and that the size of the end product would fit the current partition.

Sorry can't help further with Event 276. I think this is all still a work-in-progress as far as MS is concerned and it will all be sorted eventually.

Click to expand...

I see.
Well, if you want to patch your system it's only 1 line of code and 2 reboots to apply it. If you get around to try it, please share your results regarding the Event ID's.

It's probably still a work in progress. The Feedback Hub is pretty much useless and Microsoft support does not know. After being in contact with them regarding this issue I simply got the answer to use the Feedback Hub, and maybe, most likely not, the engineers at Microsoft might take a look at this and actually test this for themselves. (And hopefully, update their own instructions about how to verify that the patch was successful).

I feel like it's up to the community to actually test these things.

I found it!

I was looking at the wrong place. I had to go to Kernel-Boot / Operational, and there is it. Event ID 276.
It also says so clearly in the guide. I just assumed that these Event ID's would be shown under System (Since Event ID 1035 is there, and other Kernel-Boot Event ID's show up in the same place).

I have to apologize to Microsoft and can only blame myself.

I do wish that Microsoft support would have shown me this though, and not tell me to look for it under system.

Do the systems to which you have applied the revocations still allow you to boot pre-May devices like USB sticks, CDs etc successfully?

(Sorry - I see our posts went out simultaneously. Glad everything is resolved.)

xrms3 said:

Do the systems to which you have applied the revocations still allow you to boot pre-May devices like USB sticks, CDs etc successfully?

(Sorry - I see our posts went out simultaneously. Glad everything is resolved.)

Click to expand...

They do not boot older media devices and everything seems to be working as expected.