error 0xC000000D on ver 1.3

[Tomatcree01]

I saw some other people had this issue but on earlier versions. I was able to get this on 1.3 and windows11.

[Mattiwatti]

The v1.3 release didn't fix anything about this error - the only change relating to this was the added explanation provided with the specific error code you're seeing. Why is it not fixed? Because this is (almost certainly) not a problem in EfiGuard but with the way you're using it. Which is what the error message is also trying to say.

If EfiGuard's DXE driver wasn't loaded during boot as instructed in the README, you can't expect EfiDSEFix.exe to do anything. See also my comment in #96.

[Mattiwatti]

Unrelated to above: I would like to know what version of Windows you're using in the screenshot, because you are seeing a clearly invalid address for g_CiOptions being returned, which would in fact be a bug. By "version" here I mean the full kernel version number, found in file properties of ntoskrnl.exe.

[Tomatcree01]

Im trying to find what is different (Im using Windows 11 Pro Insider Preview) I would expect adresses to be different. When patching after bios boots, it succesfully finds all adresses and 'succesfully disables DSE'...

[Mattiwatti]

Different from what? If you have two Windows installations, and EfiGuard only works on one of these (I'm assuming here that you're using EfiGuard correctly on the other system), then I want to know the version numbers for both. Or at the very least, the version of Windows on which EfiGuard isn't working.

Again note that I need the kernel version number. Things like "11 Pro Insider Preview" don't help me much, given that there have been a great number of Windows 11 "insider previews" released, some of these with a kernel build number that is lower than the current Windows 11 "release" kernel version.

[Tomatcree01]

[Tomatcree01]

[Mattiwatti]

Thanks, this helps. I was able to reproduce the issue on build 25915. This was caused by a change in the kernel that makes it so that kernel addresses are no longer exposed to user mode unless the requesting process has SE_DEBUG_PRIVILEGE. (I actually knew this was going to be changed, except then I forgot about it again before ever fixing it...)

Please confirm this EXE fixes the issue: EfiDSEFix-41b1731.zip

[Tomatcree01]

Interesting, can you explain a little more into how you managed to bypass this security?

[Mattiwatti]

Thanks. I've pushed the fix for this just now so if you want you can see the change I made in 41b1731.

All the change really does is acquire the newly required SE_DEBUG_PRIVILEGE before attempting to find any kernel address. So it's not really accurate to call it a 'bypass', rather it's simply a fix to make sure all required privileges are enabled before proceeding.