Aperçu

EfiGuard est un bootkit UEFI x64 portable qui patche le gestionnaire de démarrage Windows, le chargeur de démarrage et le noyau au moment du démarrage afin de désactiver PatchGuard et Driver Signature Enforcement (DSE).

Si vous cherchez simplement à essayer EfiGuard, passez à Usage.

Fonctionnalités

• Prend actuellement en charge toutes les versions compatibles EFI de Windows x64 jamais publiées, de Vista SP1 à Windows 11.

• Facile à utiliser : peut être démarré depuis une clé USB ou la partition EFI Windows via un chargeur qui trouve et démarre automatiquement Windows. Le pilote peut également être chargé et configuré manuellement à l'aide du shell UEFI ou du chargeur.

• Utilise largement la bibliothèque de désassembleur Zydis pour un décodage rapide des instructions à l'exécution, afin de prendre en charge une analyse plus robuste que ce qui est possible avec la correspondance de signatures, qui nécessite souvent des modifications avec les nouvelles mises à jour du système d'exploitation.

• Fonctionne passivement : le pilote ne charge ni ne démarre le gestionnaire de démarrage Windows. Il agit plutôt sur un chargement de bootmgfw.efi par le gestionnaire de démarrage du firmware via le menu de sélection de démarrage ou une application EFI telle que le chargeur. Si un système d'exploitation non Windows est démarré, le pilote se déchargera automatiquement.

• Prend en charge le patching en quatre étapes lorsque bootmgfw.efi démarre bootmgr.efi plutôt que winload.efi. C'est le cas lorsqu'un fichier WIM est chargé pour démarrer WinPE, le programme d'installation de Windows ou le mode de récupération de Windows.

• Récupération élégante : en cas d'échec du patch, le pilote affichera des informations d'erreur et demandera de continuer le démarrage ou de redémarrer en appuyant sur ESC. Cela est vrai même jusqu'à la dernière étape de patching du noyau, car la dernière étape de patching a lieu avant l'appel de ExitBootServices. De nombreux bootkits UEFI Windows hookent OslArchTransferToKernel qui, bien que facile à trouver par correspondance de motifs, est une fonction qui s'exécute en mode protégé après ExitBootServices. Cela signifie qu'aucun service de démarrage n'est disponible pour informer l'utilisateur que quelque chose s'est mal passé.

  Échec de patch simulé avec informations d'erreur

• Débogable : peut afficher des messages vers un débogueur de noyau et vers l'écran (bien que mis en mémoire tampon) pendant l'étape de patching du noyau, et vers un port série ou sans mémoire tampon vers l'écran pendant les étapes de patching du gestionnaire de démarrage et du chargeur de démarrage. Si le pilote est compilé avec des informations de débogage PDB, il est possible de charger les symboles de débogage à tout moment après l'initialisation de HAL en spécifiant la base virtuelle du pilote DXE et en le débogant comme vous le feriez avec un pilote NT classique.

• Contournements de DSE : disponibles soit sous la forme d'une désactivation DSE simple de style UPGDSED au moment du démarrage, soit sous la forme d'un hook sur le service d'exécution EFI SetVariable(). Ce dernier sert de backdoor arbitraire de lecture/écriture en mode noyau qui peut être appelé depuis Windows à l'aide de NtSetSystemEnvironmentValueEx et permet de définir g_CiEnabled/g_CiOptions à la valeur souhaitée. Une petite application de style DSEFix nommée EfiDSEFix.exe est fournie pour le faire. Il est également possible de laisser DSE activé et de désactiver uniquement PatchGuard. Le chargeur utilisera la méthode de hook SetVariable par défaut, car certains programmes anti-triche et antivirus ne comprennent pas la différence entre les triches ou les logiciels malveillants et les pilotes auto-signés en général et ciblent le correctif UPGDSED.

• Prend en charge les noyaux et chargeurs de démarrage modifiés sur disque en patchant ImgpValidateImageHash à chaque étape ainsi que ImgpFilterValidationFailure, ce qui peut silencieusement signaler certaines classes de violations à un TPM ou au fichier journal SI.

• Permet à Secure Boot de fonctionner avec Windows 7 (ce n'est pas une blague !). Windows 7 lui-même ignore Secure Boot car il ne le prend pas en charge, ni (officiellement) même le démarrage sans CSM. Ceci est utile pour les personnes qui souhaitent utiliser Windows 7 sur un appareil verrouillé qui nécessite WHQL Secure Boot. Entrée du wiki sur la façon de faire fonctionner cela ici.

  WinObjEx64 sur Windows 7 avec Secure Boot activé

Problèmes et limitations

• EfiGuard ne peut pas désactiver l'Intégrité du Code renforcée par l'Hyperviseur (HVCI ou HyperGuard) car HVCI s'exécute à un niveau de privilège supérieur. EfiGuard peut coexister avec HVCI et même désactiver avec succès PatchGuard dans le noyau normal, mais cela n'est pas utile en pratique car HVCI attrapera ce que PatchGuard faisait auparavant. Les deux types de contournement de DSE sont rendus inutiles par HVCI : le patch au démarrage n'a aucun effet car le noyau délègue au noyau sécurisé les vérifications d'intégrité, et le hook SetVariable provoquera un bugcheck SECURE_KERNEL_ERROR s'il est utilisé pour écrire dans g_CiOptions.
• Les noyaux vérifiés ne sont pas pris en charge en raison des différences dans le code d'initialisation de PatchGuard et DSE causées par les optimisations désactivées et les assertions ajoutées, ainsi que des modifications supplémentaires de PatchGuard dans les noyaux vérifiés. Cela ne devrait pas poser de problème car les noyaux vérifiés ne sont généralement pas utiles sans un débogueur de noyau attaché, ce qui désactive PatchGuard.

Utilisation

Il existe deux façons d'utiliser EfiGuard : démarrer l'application de chargeur, qui chargera le pilote et démarrera Windows pour vous, ou installer le pilote comme entrée de pilote UEFI afin qu'il soit chargé automatiquement par le firmware.

L'installation du pilote peut être préférable dans certaines configurations avancées, comme le multi-démarrage, mais le chargeur est le plus facile à utiliser et devrait bien fonctionner dans toutes les configurations. Voir le tableau ci-dessous pour les différences les plus importantes entre les deux méthodes. En cas de doute, choisissez l'application de chargeur.

Comparaison entre le chargeur et l'entrée de pilote UEFI

Démarrer le chargeur

1. Téléchargez EfiGuard et renommez EFI/Boot/Loader.efi en bootx64.efi.
2. Placez les fichiers sur un disque de démarrage tel qu'une clé USB formatée en FAT32 (pour les machines physiques) ou un disque ISO/virtuel (pour les machines virtuelles). En supposant le lecteur X:, les chemins pour les deux fichiers devraient maintenant être X:/EFI/Boot/{bootx64|EfiGuardDxe}.efi
3. Démarrez la machine à partir du disque utilisé à l'étape 2. La plupart des firmwares fournissent un menu de démarrage pour cela via F8/F10/F11/F12. Sinon, vous devrez configurer le BIOS pour démarrer à partir du nouveau disque.
4. Windows devrait maintenant démarrer et vous devriez voir des messages EfiGuard pendant le démarrage.
5. Si vous avez démarré avec le hook SetVariable (par défaut), exécutez EfiDSEFix.exe -d à partir d'une invite de commandes Administrateur après le démarrage pour désactiver DSE, ou exécutez EfiDSEFix.exe pour voir la liste complète des options.

Notez que vous n'avez pas besoin d'utiliser un disque séparé pour le chargeur. Si vous préférez, vous pouvez installer EfiGuard sur l'ESP sur lequel Windows est déjà installé. Cependant, cela est un peu plus compliqué car vous devrez ajouter une entrée de démarrage UEFI pour le chargeur.

Pour ce faire, montez l'ESP à X: en utilisant mountvol X: /S et suivez les étapes ci-dessus, mais ne renommez pas le chargeur et copiez simplement les deux fichiers dans X:/EFI/Boot. Ensuite, vous devrez ajouter manuellement une entrée de démarrage UEFI depuis le shell UEFI en utilisant bcfg boot addp 0 Loader.efi "EfiGuard", ou alternativement en utilisant efibootmgr (Linux), EasyUEFI (Windows), ou similaire.

Installer le pilote

1. Montez l'ESP à X: en utilisant mountvol X: /S.
2. Copiez EfiGuardDxe.efi vers X:/EFI/Boot/EfiGuardDxe.efi.
3. Démarrez dans le shell UEFI et ajoutez une entrée de pilote UEFI : bcfg driver add 0 EfiGuardDxe.efi "EfiGuardDxe".
4. Windows devrait maintenant démarrer et vous devriez voir des messages EfiGuard pendant le démarrage.
5. Si vous avez démarré avec le hook SetVariable (par défaut), exécutez EfiDSEFix.exe -d à partir d'une invite de commandes Administrateur après le démarrage pour désactiver DSE, ou exécutez EfiDSEFix.exe pour voir la liste complète des options.

Note : selon votre firmware, vous devrez peut-être utiliser "addp" à l'étape 3 au lieu de "add". VirtualBox est connu pour nécessiter cela, et certains firmwares de carte mère aussi probablement.

Note : certains firmwares très anciens ou non conformes peuvent ne pas du tout prendre en charge cette méthode d'installation. Sur ces systèmes, vous n'aurez d'autre choix que d'utiliser le chargeur.

Compilation

Compilation de EfiGuardDxe et du chargeur

EfiGuard nécessite EDK2 pour être compilé. Si vous n'avez pas EDK2 installé, suivez d'abord les étapes dans Getting Started with EDK2 car le système de compilation EDK2 est assez complexe à mettre en place. Cette section suppose que vous avez un répertoire workspace vers lequel pointe votre variable d'environnement WORKSPACE, avec une copie de EDK2 extraite dans workspace/edk2. Les compilateurs pris en charge sont MSVC, Clang, GCC et ICC.

1. Clonez le dépôt EfiGuard dans workspace/edk2/EfiGuardPkg.
2. Ouvrez une invite ou un shell qui configure les variables d'environnement pour EDK2.
3. Exécutez build -a X64 -t VS2019 -p EfiGuardPkg/EfiGuardPkg.dsc -b RELEASE, en remplaçant VS2019 par votre chaîne d'outils.

Cela produira EfiGuardDxe.efi et Loader.efi dans workspace/Build/EfiGuard/RELEASE_VS2019/X64.

Compilation de EfiDSEFix

EfiDSEFix nécessite Visual Studio pour être compilé.

1. Ouvrez EfiGuard.sln et compilez la solution.

Le binaire de sortie EfiDSEFix.exe se trouvera dans Application/EfiDSEFix/bin.

La solution Visual Studio inclut également des projets pour EfiGuardDxe.efi et Loader.efi qui peuvent être utilisés avec VisualUefi, mais ces projets ne sont pas compilés par défaut car ils ne peuvent pas être liés sans code supplémentaire, et le résultat de la compilation sera inférieur (plus gros) que ce que produit EDK2. Loader.efi ne pourra pas du tout être lié en raison de l'absence de UefiBootManagerLib dans VisualUefi. Ces fichiers de projet sont donc destinés uniquement à aider au développement et les fichiers EFI doivent toujours être compilés avec EDK2. Pour configurer VisualUefi à cette fin, clonez le dépôt dans workspace/VisualUefi et ouvrez EfiGuard.sln.

Architecture

Bien qu'EfiGuard soit un bootkit UEFI, il n'a pas commencé comme tel. EfiGuard était à l'origine un patcher sur disque fonctionnant sur NT (similaire à UPGDSED), destiné à tester la viabilité d'une approche basée sur un désassembleur, par opposition à l'utilisation de symboles PDB et de signatures spécifiques à une version. PatchNtoskrnl.c ressemble encore beaucoup à cette conception originale. Ce n'est qu'après que cette approche se soit avérée réussie, sans qu'aucune modification du code ne soit nécessaire pendant plus d'un an de mises à jour Windows, que l'UEFI est entré en jeu comme un moyen d'améliorer encore les capacités et la facilité d'utilisation.

Certains des avantages offerts par une approche de bootkit incluent :

• Aucune modification sur disque des noyaux ou des chargeurs de démarrage nécessaire.
• Pas besoin de modifier le magasin de configuration de démarrage à l'aide de bcdedit.
• Pas besoin de patcher ImgpValidateImageHash (bien que cela soit toujours fait optionnellement).
• Ironiquement, l'utilisation d'un bootkit permet d'activer Secure Boot, à condition de posséder la clé de plateforme et de pouvoir ajouter votre certificat personnel au magasin db.

La première incarnation d'EfiGuard en tant que bootkit était une tentative de faire fonctionner le UEFI-Bootkit de dude719 avec les versions récentes de Windows 10, car il était devenu obsolète et ne fonctionnait plus sur les dernières versions (comme UPGDSED, souvent causé par des analyses de motifs sensibles à la version). Bien que j'aie finalement réussi à le faire fonctionner, je n'étais pas satisfait du résultat principalement à cause du choix de hooker OslArchTransferToKernel, qui, comme noté plus haut, s'exécute en mode protégé et après l'appel de ExitBootServices. En dehors de cela, je n'étais pas satisfait de ne pouvoir patcher que certaines versions de Windows 10 ; je voulais que le bootkit fonctionne sur toutes les versions compatibles EFI de Windows x64 jamais publiées. Pour cette raison, j'ai réécrit le bootkit à partir de zéro avec les objectifs suivants :

• Fournir des informations de patch à chaque étape du démarrage, y compris le patch du noyau lui-même.
• Prendre en charge toutes les versions de Windows compatibles EFI (au moment de la rédaction).
• Permettre l'instanciation paresseuse du bootkit et optionnellement une backdoor du noyau, réalisée par des hooks de la table système EFI.

Un aperçu général du flux de démarrage final d'EfiGuard est montré dans le diagramme ci-dessus. Pour les hooks et patches spécifiques à chaque composant, voir EfiGuardDxe/PatchXxx.c dans les fichiers sources. Pour l'initialisation/déchargement du pilote et les hooks des services de démarrage et d'exécution EFI, voir EfiGuardDxe.c.

Crédits

• UPGDSED par hfiref0x et Fyyre
• Zydis par zyantific
• Articles Uninformed sur PatchGuard v1, v2 et v3 par Skywing
• UEFI-Bootkit par dude719
• ReactOS

Licence

EfiGuard est sous licence GPLv3. Les fichiers du sous-module EfiGuardDxe/Zydis sont sous licence MIT.