Windows sürücü harfleri A-Z ile sınırlı değildir

 (ryanliptak.com)
2 puan yazan GN⁺ 2025-12-01 | 1 yorum | WhatsApp'ta paylaş
  • Windows'ta A~Z dışındaki simgeler veya ASCII olmayan karakterler de sürücü harfi olarak kullanılabilir
  • Dahili olarak Win32 yolu (C:\\foo), NT ad alanı yolu (\\??\\C\\foo) olarak dönüştürülüp işlenir
  • Bu yapı Object Manager tarafından yönetilir ve C: gibi bir sürücü harfi, basit bir sembolik bağlantı nesnesi olarak var olur
  • subst komutuyla +: veya €: gibi standart dışı sürücü harfleri oluşturulabilir ancak Explorer veya PowerShell bunları tanımaz
  • Bu davranışlar, Windows'un yol işleme iç yapısını ve kodlama yöntemini (WTF-16 vb.) anlamak için önemli birer ipucudur

Sürücü Harflerinin İç Yapısı

  • Windows'taki normal yol (C:\\foo), bir Win32 ad alanı yoludur ve API çağrısında bir NT ad alanı yoluna dönüştürülür
    • Örn: CreateFileW("C:\\foo") çağrısı içerde NtCreateFile("\\??\\C\\foo") olarak dönüştürülür
  • \\?? Object Manager'ın sanal klasörüdür ve \\GLOBAL?? ile kullanıcı bazlı DosDevices klasörlerini birleştirir
  • C: nesnesi \\GLOBAL?? içinde bir sembolik bağlantı olarak bulunur ve gerçek aygıt yolu \\Device\\HarddiskVolume4 ile ilişkilidir
  • Bu nedenle C: özel bir ayrılmış karakter değil, genel bir sembolik bağlantı adı olarak ele alınır

Sürücü Harfinin Tanımı

  • Sürücü harfi, Win32 yolunu NT yoluna dönüştürme sürecinin bir ürünüdür
    • Dönüştürme işlevi RtlDosPathNameToNtPathName_U, C:\\foo değerini \\??\\C\\foo olarak dönüştürür
  • Bu işlev +: gibi standart dışı bir karakteri de aynı şekilde işler; böylece +: nesnesi varsa +:\\ yolu da düzgün çalışır
  • subst +: C:\\foo komutuyla oluşturulan +: nesnesi, kullanıcıya özel DosDevices klasöründe saklanır

Standart Dışı Sürücü Harflerinin Davranışı

  • Explorer.exe yalnızca A~Z aralığını taradığından +: sürücüsü görünmez
  • PowerShell de ASCII dışı sürücüleri tanımaz ve hata döndürür
  • Ancak cmd.exe içinde +: veya €: gibi sürücüler normal çalışır

ASCII Dışı ve Unicode Sürücü Harfleri

  • subst €: C:\\foo komutuyla euro işareti(€) sürücüsü oluşturulabilir
    • Büyük/küçük harf farkı olmadan çalışır (Λ: ve λ: aynı şekilde algılanır)
  • Sürücü harfi, tekil bir WTF-16 kod ünitesi (U+FFFF ve altı) ile sınırlıdır
    • 𤭢: gibi U+FFFF'i aşan karakterlerde subst hata verir
    • MountPointManager doğrudan çağrılırsa oluşturma mümkün olsa da, Win32 yol dönüştürme başarısız olduğundan erişilemez
  • Bu durum Windows'un UTF-16 surrogate çiftlerini tam desteklemediğini gösterir

Yol Tanımlama ve Kodlama Sorunları

  • Dillerdeki yol işleme implementasyonları RtlDosPathNameToNtPathName_U ile farklılık gösterebilir
    • Örnek: Rust yalnızca A-Z aralığını mutlak yol olarak kabul eder (C:\\ true, +:\\ false)
  • Kodlama biçimine (WTF-8 ve WTF-16) göre path[0], path[1] dizinleri değişebilir, bu da mutlak yol tespiti sonucunu farklılaştırır
  • Zig standart kütüphanesi bu farkı <= U+FFFF aralığını tanıyacak şekilde ele alır

SetVolumeMountPointW'deki ASCII Dışı İşleme Hatası

  • SetVolumeMountPointW("€:\\", volume) çağrısı başarılı olur, ancak üretilen gerçek bağlantı ¬: olarak görünür
  • Bu, 0x20AC (€) karakterinin 0xAC olarak kesilerek kaydedildiği bir olguya işaret ediyor
  • ASCII dışı sürücü harflerini işleyemeyen API sınırlılığını gösteren bir örnek

Sonuç

  • Windows, içsel olarak sürücü harflerini A~Z ile sınırlandırmaz
  • Kısıtlama, Explorer, PowerShell gibi üst seviye araçlardaki uygulama farklarından ortaya çıkar
  • Win32 ve NT ad alanı dönüştürme yapısı, kodlama işleme ve Object Manager davranışını anladığınızda, Windows dosya sistemi iç mekanizmasını çok daha derinden kavrayabilirsiniz

İlgili okumalar

1 yorum

 
GN⁺ 2025-12-01
Hacker News görüşü

  • NT yolları, Object Manager'ın kaynaklara başvurma biçimidir
    Örneğin HKEY_LOCAL_MACHINE, \Registry\Machine için bir takma addır
    NT, küresel bir VFS ad alanı kullanması bakımından Unix'e benzer
    Sürücü harfiyle başlayan yollar, DOS uyumluluğu için kullanılan “DOSPath” biçimidir; çekirdek modunda bile bazı alt sistemler bunu hâlâ kullanır
    PowerShell, çeşitli kaynakları “sürücü” olarak gösterir; hklm:\ gibi varsayılan sürücülerin yanı sıra özel sürücüler de oluşturabilirsiniz
    İlgili belge: PowerShell Drive yönetimi örneği
    Linux/Bash'te sertifikalara dosya yolu olarak erişemezsiniz, ancak PowerShell/Windows'ta bu mümkündür
    ls NtObject:\ ile gezmek için NtObjectManager PowerShell modülünü kurmanız tavsiye edilir
    Modül bağlantısı

    • 30 yıl geçmesine rağmen Windows'un hâlâ 80'ler tarzı dizin yapısına bağlı olması şaşırtıcı. Üstelik artık disket sürücüler de yok
    • PnP PowerShell'in PSDrive sağlayıcısını kullanırsanız SharePoint Online içinde de bir sürücüymüş gibi gezebilirsiniz
      Connect-PnPOnline belgesi
    • Linux'ta da /usr/share/ca-certificates veya /etc/ssl/certs üzerinden sertifikalara dosya olarak erişilebilir
      Ancak bu yapı Windows Registry kadar bütünleşik değildir
    • ReactOS içinde, tüm Registry hiyerarşisini GUI üzerinden gezebileceğiniz bir NT Object tarayıcısı vardır
      Windows'ta da çalışır
      ReactOS NT Object Browser örneği
    • Linux'ta sertifikalara sadece dosya olarak erişmek de mümkündür
      /etc/ca-certificates/extracted/cadir altında PEM dosyalarını doğrudan görebilirsiniz

  • Windows'ta bölümlere sürücü harfi olmadan da erişilebilir
    Linux'taki gibi bir dizin altına bağlanabilir ve bu PowerShell'deki Add-PartitionAccessPath komutuyla ayarlanabilir
    Yeniden başlatmadan sonra da kalıcı olur

    • Bu özelliği kullanarak oyun kurulum yolunu SD karta yönlendirmiştim
      Kurulum programı SD kartı reddediyor, ama NTFS mount point kullanınca kandırılabiliyor
      Yalnız bazı kurulum programları üst diskin boş alanını kontrol ettiği için kafası karışabiliyor
      Kalıcı bağlama için sembolik bağlantılar daha kullanışlıdır
    • PowerShell olmadan da Disk Yönetimi aracındaki “sürücü harfi ve yolu değiştir” menüsünden ayarlanabilir
    • NTFS mount point'ler, yolu özelleştirilemeyen yazılımları aşmak için kullanışlıdır
      Farklı performans ilkelerine sahip VM disklerini tek bir yol altında birleştirebilirsiniz
    • Ancak bu yalnızca NTFS'ten NTFS'e mümkündür. exFAT veya ReFS desteklenmez
      GUI'de bölüm oluştururken “sürücü harfi ata” yerine “yola bağla” seçeneğini seçebilirsiniz
    • Bazı programlar (ör. Steam) üst diskin boş alanını kontrol edip kurulumu reddedebilir

  • “€:\” gibi sürücü harfleri lanetli ama havalı bir örnektir
    NT çekirdeği, kullanıcıya görünenin çok ötesinde esnektir

    • Çoğu kişi Windows NT'nin yalnızca DOS kabuğunu bilir
      İçeride GUID eşlemelerine dayanan karmaşık bir yapı gizlidir
      Örneğin {GUID} adlı bir kısayol oluşturursanız, gizli bir işleve bağlanabilir
      Bu yapı yüzünden Windows, bir bakıma zararlı yazılımlar için verimli bir alan hâline de gelir
    • Kod sayfasına bağlı olarak bu tür sürücü harflerine erişmek bile imkânsız olabilir
    • Gerçekten esnek olacaksa, sürücü harfleri için emoji kullanılabilmeli

  • File Explorer, A~Z dışındaki sürücü harflerini tanımaz
    Bu yüzden tüm sürücü harflerini emojiye çevirme hayali mümkün değildir

    • Çoğu emoji tek bir UTF-16 kod birimi olarak temsil edilmediği için sınırlayıcıdır
    • Bazı gülen yüz emojileri kod sayfasına bağlı olarak mümkün olabilir
      Yine de autorun.inf ile sürücü simgesini emoji yapmak daha iyidir; etikete de emoji eklenebilir
    • Bilgisayar adında emoji kullanılabilir

  • Win9x döneminde ALT + 255 hilesiyle Explorer'dan erişilemeyen klasörler oluşturulabiliyordu

    • Bu yöntemle yurttaki bilgisayarda Duke Nukem'i saklardım
    • Yakın zamana kadar Registry anahtarlarında da aynı yöntemle erişim engellenebiliyordu
    • Şimdi durum daha da ciddi. Windows 10/11 güvenlik açığı örneği

  • Xbox 360 geliştirme ortamında sürücü harfleri dize biçimindeydi
    Örn: Game:\foo, Hdd0:\foo

    • Evet, gerçekten vardı
      Xenia emülatörü bunu sembolik bağlantı tabanlı sanal dosya sistemi olarak ele alıyor
      Xenia kod örneği

  • Linux'ta benzer bir kavram olarak Abstract Domain Socket bulunur
    İlk karakteri NUL(\0) olan bir Unix domain socket'tir ve izin kısıtlarını aşmak için kullanılabilir
    Oyun sunucularında, her oyuncunun kaynaklarını ayırırken iletişimi korumak için kullanılıyor

    • Bu soketleri /proc/net/unix içinde de bulabilirsiniz

  • Bu tür özellikler, zararlı yazılım geliştirmek için elverişli bir ortam gibi geliyor
    Gizli mount point'ler veya tuhaf sürücü adlarıyla sistemi karıştırmak mümkünmüş gibi duruyor

    • Ama pratikte NT yollarının gerçek bir volume'e eşlenmesi gerektiğinden, tamamen gizlemek zordur
    • Alternate Data Streams'i öğrenince daha da şaşıracaksınız
    • Sürücüleri değiştirmek için yönetici yetkisi gerekir

  • Birden fazla disk imajı bağlamanız gerektiğinde, sürücü harfleri ciddi biçimde kafa karıştırıcı olur
    Örneğin 36 DVD ISO'su bağlarsanız komut satırı tırnak cehennemi yaşayabilirsiniz

  • Eski DOS'ta (muhtemelen 3.3 sürümünde) Z'den sonraki sürücü harfi AA idi
    Bunu doğrulamak için birkaç küçük RAM diski oluşturmuştum

    • Netware'de de Z'nin ötesine geçen sürücü eşlemeleri yapılabildiğini hatırlıyorum