EFI bootkit bypassing DSE
These more or less mandatory additional features that has recently started popping up for an OV or EV code signing certificates. The prices have clearly risen and the author personal opinion is that it's a quick money grabbing. https://www.ssl.com/certificates/ev-code-signing/
And the process of getting one is far from user-friendly: https://www.unknowncheats.me/forum/anti-cheat-bypass/588600-process-legally-obtaining-ev-certificate-getting-accepted-mpp.html
This is a big setback for individual software developers who cannot for reason or another run a business. And it seems that your non malicious software is immediately deemed as a "malware" or "unwanted" if the software is not signed because the software originates from an unknown author. The problem is that one problem feeds another problem.
As of 08/2023, a DigiCert certificate for one year costs $845 USD. The good thing about a legitimate certificate is that the code cannot be modified afterwards once it has been signed and your software or kernel driver gets more "trust" because the origin is "known".
In addition to everything, a large number of new EDR providers have entered the market that do not cooperate (e.g share a list of vulnerable drivers that professional malware analyst's have verified) when they should. These "new" solutions are not as well tested as decades-old antivirus software's such as F-Secure SAFE. The end result is that there are too many false positives.
USB:
You need to download https://github.com/pbatard/UEFI Shell/releases/download/23H1/UEFI-Shell-2.2-23H1-RELEASE.iso and extract bootx64.efi from the ISO and copy it as shown below. You can scroll through the list with the Page Up/Down key.
1600:1200
"memory.efi" is the bootkit that allows you to load the manually mapped driver that bypasses DSE at runtime and flips the byte back to the original value. Bypassing DSE is subject to a 0x109_20_CI!g_CiOptions PatchGuard bug check. Therefore the bootkit will not disable DSE at boot time.
The advantage of using an EFI bootkit is that it allows you to load a manually mapped driver that bypasses DSE checks because the driver entry point gets called directly without the need to use the Nt"Zw"LoadDriver function. The trick is to bypass the DSE at runtime in a manually mapped driver that bypasses driver signature enforcement. Once the DSE has been bypassed using a bootkit and an unsigned driver has been loaded. There are various advantages of using a driver with nt!_DRIVER_OBJECT.
For example a manually mapped driver cannot have any callbacks that can be used for malware detection. If you create a system thread (PsCreateSystemThread) in the mapped driver. Your "driverless" driver will run a non backed code (that is a thread executing code outside of valid modules memory ranges). An anti-cheat is able to detect that by stackwalking that thread, which will likely result in a ban unless the thread is hidden in DKOM.
And the process of getting one is far from user-friendly: https://www.unknowncheats.me/forum/anti-cheat-bypass/588600-process-legally-obtaining-ev-certificate-getting-accepted-mpp.html
This is a big setback for individual software developers who cannot for reason or another run a business. And it seems that your non malicious software is immediately deemed as a "malware" or "unwanted" if the software is not signed because the software originates from an unknown author. The problem is that one problem feeds another problem.
As of 08/2023, a DigiCert certificate for one year costs $845 USD. The good thing about a legitimate certificate is that the code cannot be modified afterwards once it has been signed and your software or kernel driver gets more "trust" because the origin is "known".
In addition to everything, a large number of new EDR providers have entered the market that do not cooperate (e.g share a list of vulnerable drivers that professional malware analyst's have verified) when they should. These "new" solutions are not as well tested as decades-old antivirus software's such as F-Secure SAFE. The end result is that there are too many false positives.
EFI bootkit howto
Create the following folder structure on the FAT32 formattedUSB:
\memory.efi
\Boot\EFI\bootx64.efi
\Boot\EFI\bootx64.efi
You need to download https://github.com/pbatard/UEFI Shell/releases/download/23H1/UEFI-Shell-2.2-23H1-RELEASE.iso and extract bootx64.efi from the ISO and copy it as shown below. You can scroll through the list with the Page Up/Down key.
1600:1200
"memory.efi" is the bootkit that allows you to load the manually mapped driver that bypasses DSE at runtime and flips the byte back to the original value. Bypassing DSE is subject to a 0x109_20_CI!g_CiOptions PatchGuard bug check. Therefore the bootkit will not disable DSE at boot time.
EFI bootkit DSE bypass
If you try to load an unsigned driver with DRIVER_OBJECT when DSE is enabled. You will get a STATUS_INVALID_IMAGE_HASH (0xC0000428) error or if you have a signed driver with a valid EV certificate, whose certificate has been revoked by MS. The following error will appear: STATUS_IMAGE_CERT_REVOKED (0xC0000603).The advantage of using an EFI bootkit is that it allows you to load a manually mapped driver that bypasses DSE checks because the driver entry point gets called directly without the need to use the Nt"Zw"LoadDriver function. The trick is to bypass the DSE at runtime in a manually mapped driver that bypasses driver signature enforcement. Once the DSE has been bypassed using a bootkit and an unsigned driver has been loaded. There are various advantages of using a driver with nt!_DRIVER_OBJECT.
For example a manually mapped driver cannot have any callbacks that can be used for malware detection. If you create a system thread (PsCreateSystemThread) in the mapped driver. Your "driverless" driver will run a non backed code (that is a thread executing code outside of valid modules memory ranges). An anti-cheat is able to detect that by stackwalking that thread, which will likely result in a ban unless the thread is hidden in DKOM.
