error 0xC000000D on ver 1.3 - Githubissues

Mattiwatti / EfiGuard

Disable PatchGuard and Driver Signature Enforcement at boot time

GNU General Public License v3.0

1.69k stars 326 forks source link

error 0xC000000D on ver 1.3 #97

Closed Tomatcree01 closed 11 months ago

Tomatcree01 commented 11 months ago

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

Screenshot 2023-07-16 045159

Mattiwatti commented 11 months ago

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 commented 11 months ago

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 commented 11 months ago

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 commented 11 months ago

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 commented 11 months ago

Tomatcree01 commented 11 months ago

Mattiwatti commented 11 months ago

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 commented 11 months ago

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

Mattiwatti commented 11 months ago

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.