rss logo

BitLocker et auto-déverrouillage : cas réel de récupération

Illustration Windows BitLocker avec un disque dur, un cadenas et une clé

Dans les versions récentes de Windows, Microsoft peut activer automatiquement BitLocker ou le chiffrement de l’appareil sur les systèmes compatibles. D’un point de vue sécurité, cela peut avoir du sens : si un ordinateur portable est volé, ou si quelqu’un retire le disque et le connecte à un autre ordinateur, les données doivent rester illisibles sans la clé de récupération appropriée.

Cependant, ce comportement par défaut peut aussi prêter à confusion. Dans certains cas, le disque apparaît comme chiffré et ne peut pas être monté directement depuis un LiveCD Linux, mais l’environnement Windows d’origine peut encore être capable de le déverrouiller automatiquement grâce à la chaîne de confiance matérielle locale. Cela peut donner aux utilisateurs un faux sentiment de sécurité, tout en rendant la récupération plus difficile lorsqu’ils ne comprennent pas comment la protection est réellement configurée.

Le chiffrement automatique peut également créer un problème sérieux pour les utilisateurs classiques. Dans beaucoup de cas, ils ne savent pas clairement que leur disque est chiffré, où se trouve la clé de récupération, ni ce qui se passera s’ils perdent l’accès à leur compte Windows.

C’est exactement ce qui est arrivé avec l’ordinateur d’un ami. La machine était légitime, les données appartenaient bien à son propriétaire, mais le mot de passe Windows avait été perdu et il ne pouvait pas récupérer ses données depuis un LiveCD Linux.

Dans cet article, je vais partager mon retour d’expérience sur cette situation et expliquer comment l’accès peut parfois être récupéré dans un scénario spécifique d’auto-déverrouillage BitLocker, sans couvrir les cas où BitLocker a été activé manuellement et correctement protégé par l’utilisateur.

🚨 Avertissement : cet article ne couvre pas les situations où BitLocker a été activé manuellement et entièrement configuré par l’utilisateur, par exemple avec une clé de récupération connue, TPM + PIN, ou d’autres méthodes de protection renforcées. Il traite uniquement d’un scénario spécifique de chiffrement automatique de l’appareil / auto-déverrouillage, dans lequel l’utilisateur n’a pas activé BitLocker en connaissance de cause.

💡 Note : au départ, j’avais envisagé d’utiliser les recherches récentes autour du contournement YellowKey de BitLocker, mais je n’ai pas réussi à le faire fonctionner dans ce cas. La méthode de récupération décrite dans cet article ne repose donc pas sur YellowKey.

Écran de connexion Windows 11 affichant un compte utilisateur local demandant un mot de passe
L’utilisateur est bloqué sur l’écran de connexion Windows car le mot de passe n’est plus disponible.

BitLocker ou non ?

Comme expliqué précédemment, l’objectif initial était simplement de récupérer l’accès à l’ordinateur et aux fichiers de l’utilisateur. Au départ, j’ai envisagé d’utiliser la méthode classique de réinitialisation du mot de passe via utilman.exe depuis l’environnement de récupération Windows. Cependant, j’ai rapidement compris que ce ne serait pas aussi simple lorsque j’ai vérifié l’organisation du disque depuis un LiveCD Linux.

  • J’ai d’abord listé les partitions du disque avec fdisk :
root@livecd:~# fdisk -l
Disk /dev/sda: 60 GiB, 64424509440 bytes, 125829120 sectors
Disk model: Samsung SSD 610xs
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 5A2C0C90-61D9-1BBV-96C1-7ED8C4EI8BA5

Device         Start        End    Sectors   Size Type
/dev/sda1       2048     411647     409600   200M EFI System
/dev/sda2     411648     444415      32768    16M Microsoft reserved
/dev/sda3     444416  124205055  123760640    59G Microsoft basic data
/dev/sda4  124205056  125825023    1619968   791M Windows recovery environment
  • Ensuite, j’ai essayé de monter la partition principale de Windows :
root@livecd:~# mount /dev/sda3 /mnt/
mount: /mnt: unknown filesystem type 'BitLocker'.
       dmesg(1) may have more information after failed mount system call.

À ce stade, la situation devenait claire — même si la partition, elle, ne l’était pas ! 🫢🤭 La partition système Windows était protégée par BitLocker. Cela signifiait qu’une simple réinitialisation hors ligne du mot de passe ne suffirait pas, et que je ne pouvais pas accéder directement aux données de l’utilisateur, car le système de fichiers lui-même était chiffré.

Cependant, comme nous allons le voir ensuite, cela ne signifie pas toujours que les données sont définitivement inaccessibles. Dans ce scénario spécifique d’auto-déverrouillage, l’environnement de récupération Windows d’origine peut encore fournir un moyen de récupérer l’accès au système.

Démarrer en mode de récupération

Pour récupérer l’accès dans ce cas précis, nous devons d’abord démarrer dans l’environnement de récupération Windows. Cela peut être fait directement depuis l’écran de connexion en maintenant la touche ⇧ Shift enfoncée tout en sélectionnant Redémarrer.

  • Maintenez la touche ⇧ Shift enfoncée et sélectionnez Redémarrer :
Écran de connexion Windows 11 montrant l’option Shift Redémarrer pour démarrer en mode de récupération
Maintenir ⇧ Shift enfoncé en sélectionnant Redémarrer permet d’ouvrir l’environnement de récupération Windows.
  • Depuis l’environnement de récupération, le volume système est lisible depuis l’Invite de commandes. Cela confirme que, même si BitLocker est présent, le système de fichiers est automatiquement déverrouillé dans ce contexte de démarrage spécifique. À partir de là, des opérations locales de récupération deviennent possibles, comme travailler avec Utilman.exe :
Environnement de récupération Windows affichant l’Invite de commandes et un volume système Windows lisible
L’environnement de récupération Windows peut accéder au volume système lorsque BitLocker est automatiquement déverrouillé.

Ce cas montre que BitLocker peut être présent et empêcher l’accès direct depuis un LiveCD Linux, tout en étant automatiquement déverrouillé depuis l’environnement de récupération Windows d’origine.