- Unter Windows können als Laufwerksbuchstaben auch Symbole oder Nicht-ASCII-Zeichen außerhalb von A–Z verwendet werden
- Intern wird ein Win32-Pfad (
C:\foo) als NT-Namespace-Pfad (\??\C:\foo) verarbeitet
- Diese Struktur wird vom Object Manager verwaltet; ein Laufwerksbuchstabe wie
C: existiert als einfacher symbolischer Link.
- Mit dem Befehl
subst können nichtstandardmäßige Laufwerksbuchstaben wie +: oder €: erzeugt werden, aber Explorer oder PowerShell erkennen sie nicht.
- Dieses Verhalten liefert einen wichtigen Hinweis für das Verständnis der internen Struktur der Windows-Pfadverarbeitung und des Kodierungsverfahrens (WTF-16 usw.).
Interne Struktur von Laufwerksbuchstaben
- Ein normaler Windows-Pfad (
C:\foo) ist ein Win32-Namespace-Pfad und wird bei API-Aufrufen in einen NT-Namespace-Pfad konvertiert
- Beispiel: Bei einem Aufruf von
CreateFileW("C:\foo") erfolgt intern die Umwandlung zu NtCreateFile("\??\C:\foo")
\?? ist ein virtueller Ordner des Object Managers, der \GLOBAL?? und den benutzerspezifischen DosDevices-Ordner kombiniert- Das Objekt
C: existiert als symbolischer Link in \GLOBAL?? und verweist auf den tatsächlichen Gerätepfad \Device\HarddiskVolume4
- Daher wird
C: nicht als reserviertes Sonderzeichen, sondern als normaler Name eines symbolischen Links behandelt
Definition von Laufwerksbuchstaben
- Ein Laufwerksbuchstabe ist ein Ergebnis des Umwandlungsprozesses, durch den ein Win32-Pfad in einen NT-Pfad übersetzt wird
- Die Konvertierungsfunktion
RtlDosPathNameToNtPathName_U wandelt C:\foo in \??\C:\foo um
- Dieselbe Funktion behandelt auch nichtstandardmäßige Zeichen wie
+: gleich, daher funktioniert +:\ wenn das Objekt +: existiert
- Das durch
subst +: C:\foo erzeugte +:-Objekt wird im benutzerspezifischen DosDevices-Ordner gespeichert
Verhalten nichtstandardmäßiger Laufwerksbuchstaben
- Explorer.exe durchsucht nur den Bereich A–Z, daher wird das
+:-Laufwerk nicht angezeigt
- Auch PowerShell erkennt keine Nicht-ASCII-Laufwerke und gibt einen Fehler aus
- In cmd.exe funktionieren jedoch Laufwerke wie
+: oder €: normal
Nicht-ASCII- und Unicode-Laufwerksbuchstaben
- Mit
subst €: C:\foo lässt sich ein Euro-Symbol (€)-Laufwerk erzeugen
- Die Erkennung erfolgt case-insensitiv (
Λ: und λ: werden gleich behandelt)
- Laufwerksbuchstaben sind auf eine einzelne WTF-16-Codeeinheit (<= U+FFFF) beschränkt
- Bei Zeichen wie
𤭢: (über U+FFFF hinaus) gibt subst einen Fehler aus
- Ein direkter Aufruf von
MountPointManager kann zwar erstellt werden, doch die Win32-Pfadumwandlung schlägt fehl, sodass kein Zugriff möglich ist
- Das zeigt, dass Windows UTF-16-Surrogate-Paare nicht vollständig unterstützt
Pfadprüfung und Kodierungsprobleme
- Die Implementierung der Pfadverarbeitung kann je nach Sprache von
RtlDosPathNameToNtPathName_U abweichen
- Rust erkennt nur
A-Z als absoluten Pfad (C:\ ist true, +:\ ist false)
- Abhängig vom Kodierungsschema (WTF-8 vs. WTF-16) können
path[0], path[1] usw. an unterschiedlichen Stellen liegen, sodass das Ergebnis der Erkennung absoluter Pfade variieren kann
- Die Zig-Standardbibliothek wurde so implementiert, dass sie den Bereich bis
<= U+FFFF berücksichtigt
Bug bei der Nicht-ASCII-Verarbeitung von SetVolumeMountPointW
- Der Aufruf
SetVolumeMountPointW("€:\", volume) ist erfolgreich, der tatsächlich erzeugte Link erscheint jedoch als ¬:
- Das scheint auf einen Effekt zurückzuführen zu sein, bei dem
0x20AC (€) auf 0xAC gekürzt gespeichert wird
- Ein Beispiel für die Grenze der API bei der Verarbeitung nicht-ASCII-Laufwerksbuchstaben
Fazit
- Windows begrenzt intern nicht die Laufwerksbuchstaben auf A–Z
- Die Beschränkungen entstehen aus Implementierungsunterschieden in höheren Schichten wie Explorer, PowerShell und ähnlichen Tools
- Wer die Umwandlung zwischen Win32- und NT-Namespace, die Kodierungsverarbeitung und das Verhalten des Object Managers versteht, kann die inneren Mechanismen des Windows-Dateisystems besser nachvollziehen
1 Kommentare
Hacker-News-Kommentar
NT-Pfade sind die Art und Weise, wie der Object Manager Ressourcen referenziert
Zum Beispiel ist
HKEY_LOCAL_MACHINEein Alias für\\Registry\\MachineNT ähnelt Unix insofern, als es einen globalen VFS-Namensraum verwendet
Pfade, die mit einem Laufwerksbuchstaben beginnen, sind „DOSPath“ zur DOS-Kompatibilität, und einige Subsysteme verwenden sie auch im Kernel-Modus weiterhin
In PowerShell werden verschiedene Ressourcen als „Laufwerke“ bereitgestellt, und neben Standardlaufwerken wie
hklm:\kann man auch benutzerdefinierte Laufwerke anlegenZugehörige Doku: Beispiel zur Verwaltung von PowerShell Drives
Unter Linux/Bash kann man Zertifikate nicht über Dateipfade ansprechen, unter PowerShell/Windows dagegen schon
Empfohlen wird, das PowerShell-Modul NtObjectManager zu installieren und mit
ls NtObject:\darin zu stöbernModul-Link
Connect-PnPOnline-Doku
/usr/share/ca-certificatesoder/etc/ssl/certsauf Zertifikate als Dateien zugreifenEs ist nur nicht so integriert wie die Windows Registry
Er funktioniert auch unter Windows
Beispiel für den ReactOS NT Object Browser
Unter
/etc/ca-certificates/extracted/cadirkann man die PEM-Dateien direkt sehenWindows kann auch ohne Laufwerksbuchstaben auf Partitionen zugreifen
Wie unter Linux können sie unter einem Verzeichnis eingehängt werden; in PowerShell lässt sich das mit
Add-PartitionAccessPatheinrichtenDie Einstellung bleibt auch nach einem Neustart erhalten
Der Installer lehnt die SD-Karte ab, aber mit einem NTFS-Mountpoint kann man ihn austricksen
Manche Installer geraten allerdings durcheinander, wenn sie den freien Speicherplatz des übergeordneten Datenträgers prüfen
Für permanente Mounts sind symbolische Links nützlicher
Man kann VM-Datenträger mit unterschiedlichen Performance-Richtlinien unter einem einzigen Pfad zusammenführen
Beim Anlegen einer Partition kann man in der GUI statt „Laufwerksbuchstaben zuweisen“ auch „In folgendem leeren NTFS-Ordner bereitstellen“ wählen
Laufwerksbuchstaben wie „€:\“ sind ein verfluchtes, aber cooles Beispiel
Der NT-Kernel ist viel flexibler, als das, was dem Benutzer gezeigt wird
Darunter verbirgt sich eine komplexe Struktur auf Basis von GUID-Zuordnungen
Wenn man zum Beispiel eine Verknüpfung mit dem Namen
{GUID}anlegt, landet man teils bei versteckten FunktionenGerade diese Struktur macht Windows auch zu einem Tummelplatz für Malware
Der Datei-Explorer erkennt keine Laufwerksbuchstaben außerhalb von A bis Z
Deshalb bleibt der Traum, alle Laufwerksbuchstaben durch Emoji zu ersetzen, unerfüllbar
Sinnvoller wäre es aber, das Laufwerkssymbol über
autorun.infauf ein Emoji zu setzen; auch im Label lassen sich Emoji verwendenZu Win9x-Zeiten konnte man mit dem Trick
ALT + 255Ordner erzeugen, auf die der Explorer nicht zugreifen konnteIn der Xbox-360-Entwicklungsumgebung waren Laufwerksbuchstaben Zeichenketten
Zum Beispiel:
Game:\foo,Hdd0:\fooDer Xenia-Emulator behandelt das als virtuelles Dateisystem auf Basis symbolischer Links
Xenia-Codebeispiel
Unter Linux gibt es mit Abstract Domain Sockets ein ähnliches Konzept
Das sind Unix-Domain-Sockets, deren erstes Zeichen NUL (
\0) ist und die Berechtigungsbeschränkungen umgehen könnenIch nutze sie auf Gameservern, um die Ressourcen einzelner Spieler zu trennen und trotzdem die Kommunikation aufrechtzuerhalten
/proc/net/unixkann man solche Sockets ebenfalls findenSo etwas klingt nach einer Umgebung, die sich gut für Malware eignet
Mit versteckten Mounts oder seltsamen Laufwerksnamen ließe sich das System wohl ziemlich durcheinanderbringen
Wenn man viele Disk-Images mounten muss, werden Laufwerksbuchstaben schnell extrem unübersichtlich
Wer zum Beispiel 36 DVD-ISOs einhängt, erlebt die Hölle der Kommandozeilen-Quoting-Regeln
In altem DOS (vermutlich Version 3.3) kam nach Z als Laufwerksbuchstabe AA
Das habe ich damals überprüft, indem ich mehrere kleine RAM-Drives angelegt habe