Les lettres de lecteur Windows ne sont pas limitées à A-Z

 (ryanliptak.com)
2 points par GN⁺ 2025-12-01 | 1 commentaires | Partager sur WhatsApp
  • Sous Windows, il est possible d’utiliser comme lettre de lecteur des symboles ou des caractères non-ASCII en dehors de A-Z
  • En interne, le chemin Win32 (C:\\foo) est traité comme un chemin de l’espace de noms NT (\\??\\C\\foo)
  • Cette structure est gérée par l’Object Manager, et une lettre de lecteur comme C: existe comme un simple objet de lien symbolique
  • Grâce à la commande subst, il est possible de créer des lettres de lecteur non standard comme +: ou €:, mais Explorer ou PowerShell ne les reconnaissent pas
  • Ce comportement constitue un indice important pour comprendre la structure interne de la gestion des chemins Windows et le mode d’encodage (WTF-16, etc.)

Structure interne des lettres de lecteur

  • Le chemin Win32 courant (C:\\foo) est un chemin de l’espace de noms Win32, et il est converti en chemin de l’espace de noms NT lors d’un appel d’API
    • Exemple : CreateFileW("C:\\foo") est converti en interne vers NtCreateFile("\\\\??\\\\C:\\foo")
  • \\?? est un dossier virtuel de l’Object Manager, une combinaison de \\GLOBAL?? et du dossier DosDevices propre à chaque utilisateur
  • L’objet C: existe comme lien symbolique dans \\GLOBAL??, et pointe vers le chemin de périphérique réel \\Device\\HarddiskVolume4
  • Donc, C: n’est pas un caractère réservé spécial, mais traité comme un nom de lien symbolique ordinaire

Définition des lettres de lecteur

  • Une lettre de lecteur est un sous-produit du processus qui transforme un chemin Win32 en chemin NT
    • La fonction de conversion RtlDosPathNameToNtPathName_U convertit C:\\foo en \\??\\C:\\foo
  • Cette fonction gère aussi de la même manière des caractères non standard comme +:, donc si l’objet +: existe, le chemin +:\\ fonctionne correctement
  • L’objet +: créé via subst +: C:\\foo est stocké dans le dossier DosDevices propre à l’utilisateur

Comportement des lettres de lecteur non standard

  • Explorer.exe n’explore que la plage A-Z, donc le lecteur +: ne s’affiche pas
  • PowerShell ne reconnaît pas non plus les lecteurs non ASCII et renvoie une erreur
  • cmd.exe, en revanche, gère correctement les lecteurs comme +: ou €:

Lettres de lecteur non ASCII et Unicode

  • Il est possible de créer un lecteur (€, le symbole euro) avec la commande subst €: C:\\foo
    • Cela fonctionne sans distinction de casse (Λ: et λ: sont reconnus de la même manière)
  • La lettre de lecteur est limitée à une unité de code WTF-16 unique (≤ U+FFFF)
    • Les caractères au-delà de U+FFFF, comme 𤭢:, provoquent une erreur dans subst
    • Il est possible de créer via un appel direct à MountPointManager, mais la conversion du chemin Win32 échoue et l’accès est impossible
  • Cela montre que Windows ne prend pas entièrement en charge les paires de substitution UTF-16

Détermination du chemin et problème d’encodage

  • L’implémentation de la gestion des chemins selon le langage peut différer de RtlDosPathNameToNtPathName_U
    • Exemple : Rust reconnaît comme chemins absolus uniquement A-Z (C:\\ vaut true, +:\\ vaut false)
  • Selon l’encodage (WTF-8 vs WTF-16), les indices path[0], path[1], etc. peuvent différer, ce qui peut changer le résultat de la détection d’un chemin absolu
  • La bibliothèque standard de Zig implémente la reconnaissance jusqu’à la plage <= U+FFFF pour prendre en compte cette différence

Bug de traitement non-ASCII de SetVolumeMountPointW

  • L’appel SetVolumeMountPointW("€:\\", volume) réussit, mais le lien réellement créé apparaît comme ¬:
  • Cela est probablement dû au fait que 0x20AC (€) est stocké en étant tronqué à 0xAC
  • Un cas qui montre la limite de l’API à traiter correctement les lettres de lecteur non ASCII

Conclusion

  • Windows ne limite pas en interne les lettres de lecteur à A-Z
  • Les limites viennent des différences d’implémentation d’outils de niveau supérieur comme Explorer ou PowerShell
  • Comprendre la structure de conversion entre Win32 et l’espace de noms NT, le traitement de l’encodage et le comportement de l’Object Manager permet de mieux comprendre le mécanisme interne du système de fichiers Windows

À lire aussi

1 commentaires

 
GN⁺ 2025-12-01
Commentaire Hacker News

  • Les chemins NT sont la manière dont Object Manager référence les ressources
    Par exemple, HKEY_LOCAL_MACHINE est un alias de \Registry\Machine
    NT est similaire à Unix en ce qu’il utilise un espace de noms VFS global
    Les chemins commençant par une lettre de lecteur sont des « DOSPath » pour la compatibilité DOS, et certains sous-systèmes les utilisent encore, y compris en mode noyau
    Dans PowerShell, diverses ressources sont exposées comme des « lecteurs », et au-delà des lecteurs par défaut comme hklm:\, on peut aussi créer des lecteurs personnalisés
    Documentation associée : exemple de gestion des lecteurs PowerShell
    Sous Linux/Bash, on ne peut pas accéder aux certificats via un chemin de fichier, mais c’est possible avec PowerShell/Windows
    Je recommande d’installer le module PowerShell NtObjectManager et d’explorer avec ls NtObject:\
    Lien du module

    • Il est étonnant qu’après 30 ans, Windows soit encore attaché à une structure de répertoires des années 80. Alors qu’il n’y a même plus de lecteurs de disquettes
    • Avec le fournisseur PSDrive de PnP PowerShell, on peut aussi parcourir SharePoint Online comme un lecteur
      Documentation Connect-PnPOnline
    • Sous Linux aussi, on peut accéder aux certificats comme à des fichiers via /usr/share/ca-certificates ou /etc/ssl/certs
      C’est simplement moins intégré que le Windows Registry
    • ReactOS possède un navigateur d’objets NT qui permet d’explorer toute la hiérarchie du Registry en GUI
      Il fonctionne aussi sous Windows
      Exemple du navigateur NT Object de ReactOS
    • Sous Linux également, les certificats sont accessibles simplement sous forme de fichiers
      On peut voir directement les fichiers PEM sous /etc/ca-certificates/extracted/cadir

  • Windows peut aussi accéder aux partitions sans lettre de lecteur
    Comme sous Linux, on peut les monter sous un répertoire, et le configurer avec la commande PowerShell Add-PartitionAccessPath
    Cela persiste après redémarrage

    • J’ai déjà utilisé cette fonction pour détourner un chemin d’installation de jeu vers une carte SD
      L’installateur refuse la carte SD, mais on peut le tromper avec un point de montage NTFS
      En revanche, certains installateurs vérifient l’espace libre du disque parent et s’y perdent
      Pour les montages permanents, les liens symboliques sont plus pratiques
    • Même sans PowerShell, on peut le configurer dans l’outil de gestion des disques via le menu « modifier la lettre de lecteur et les chemins d’accès »
    • Les points de montage NTFS sont utiles pour contourner des logiciels qui ne permettent pas de personnaliser les chemins
      On peut regrouper sous un même chemin des disques de VM avec des politiques de performance différentes
    • En revanche, cela ne fonctionne qu’entre volumes NTFS. exFAT et ReFS ne sont pas pris en charge
      Lors de la création d’une partition dans l’interface GUI, on peut choisir « monter dans le chemin » au lieu de « attribuer une lettre de lecteur »
    • Certains programmes, comme Steam, peuvent refuser l’installation en vérifiant l’espace libre du disque parent

  • Une lettre de lecteur comme €:\ est un exemple maudit mais génial
    Le noyau NT est bien plus flexible que ce qui est exposé à l’utilisateur

    • La plupart des gens ne connaissent que la coquille DOS de Windows NT
      À l’intérieur se cache une structure complexe fondée sur des mappages GUID
      Par exemple, créer un raccourci nommé {GUID} peut pointer vers une fonctionnalité cachée
      C’est aussi ce genre de structure qui fait de Windows un terrain fertile pour les malwares
    • Selon la page de codes, il peut même être impossible d’accéder à ce type de lettre de lecteur
    • Pour être vraiment flexible, il faudrait pouvoir utiliser des emoji comme lettres de lecteur

  • L’Explorateur de fichiers ne reconnaît pas les lettres de lecteur autres que A à Z
    Donc le rêve de remplacer toutes les lettres de lecteur par des emoji est impossible

    • La plupart des emoji ne sont pas représentés par une seule unité de code UTF-16, ce qui limite la chose
    • Certains emoji de smiley sont possibles selon la page de codes
      Cela dit, mieux vaut remplacer l’icône du lecteur par un emoji via autorun.inf, et on peut aussi mettre des emoji dans le libellé
    • On peut utiliser des emoji dans le nom de l’ordinateur

  • À l’époque de Win9x, l’astuce ALT + 255 permettait de créer des dossiers inaccessibles depuis l’Explorateur

    • Je m’en servais pour cacher Duke Nukem sur les ordinateurs du dortoir
    • Jusqu’à récemment, on pouvait encore bloquer l’accès à des clés du Registry de la même façon
    • Aujourd’hui c’est encore pire. Exemple de faille de sécurité Windows 10/11

  • Dans l’environnement de développement Xbox 360, les lettres de lecteur étaient des chaînes de caractères
    Ex. : Game:\foo, Hdd0:\foo

    • Oui, cela a vraiment existé
      L’émulateur Xenia le gère avec un système de fichiers virtuel basé sur des liens symboliques
      Exemple de code Xenia

  • Sous Linux, il existe un concept similaire avec les Abstract Domain Socket
    Ce sont des sockets de domaine Unix dont le premier caractère est NUL(\0), ce qui permet de contourner les restrictions de permissions
    Je les utilise sur un serveur de jeu pour isoler les ressources de chaque joueur tout en maintenant la communication

    • On peut aussi retrouver ces sockets dans /proc/net/unix

  • Ce genre de fonctionnalité semble offrir un excellent terrain pour créer des malwares
    Avec des montages cachés ou des noms de lecteurs étranges, on pourrait perturber le système

    • Mais en pratique, les chemins NT doivent être mappés vers un volume réel, donc il est difficile de les cacher complètement
    • Attendez de découvrir les Alternate Data Streams
    • Il faut des privilèges administrateur pour manipuler les lecteurs

  • Lorsqu’il faut monter plusieurs images disque, les lettres de lecteur deviennent vite très confuses
    Par exemple, monter 36 ISO de DVD fait vite tomber dans un enfer de guillemets en ligne de commande

  • Sur les anciens DOS, probablement la version 3.3, la lettre qui suivait Z était AA
    Je l’avais vérifié en créant plusieurs petits RAM drives

    • Il me semble aussi que Netware permettait un mappage de lecteurs au-delà de Z