Windows Debugging 204

Isletim sisteminin islevsel olarak temel yönetim ihtiyaçlari vardir. Isletim sisteminin modülleri dâhil olmak üzere, yazimlarin ve sürücülerin ne zaman ve nasil baslatilacaklari ve bunlar ile ilgili bilgilerin nasil tutulacaklari konulari seffaf bir sistemde uyarlaniyor olmali. Burada farkli özellikleri sorgulama imkânlari olmali. Aralarindaki iliskiler net olmali. Hangi bilgilerin geçici, sadece açik olan sistemin RAM in de tutulmasi gerektigi ve hangi bilgilerin geçici tutulmasi gerektigi net olmali. Ve elbette çok önemli olmak üzere bütün bu uyarlamalar Windows un güvenlik yapisi ile çalisiyor olmali.

Buradaki en temel yapi Registry dir. Burada sistemin ve kullanicilarin bilgileri tutulur. Registry de tutulan bilglere boot asamasindan itibaren ihtiyaç duyariz. Örnegin HKLM\SYSTEM\CurrentControlSet\services de sürücülerin toplamini görebiliriz ve ‘Start’ degerine göre hangi asamada yüklenmesi gerektigini de görebiliriz. Kullanici bazinda ayarlar tutabiliriz. Örnegin bir Windows Phone sahibiyseniz, bilgisayariniza Zune yazilimini kurmussunuzdur. Zune mesela HKCU\Software\Microsoft\Zune\Groveler altinda bilgisayarinizda hangi klasörleri eslestirmek istediginizi veya telefonuz deki resimleri bilgisayarda hangi klasöre eslestirmek istediginize dair bilgileri tutar. Aslinda akliniza gelebilecek hemen hemen her sey için Registry kullanilabilir. Ama bu Registry tam olarak ne?

Registry, disk de tutulan hive adi verilmis dosyalarin ve fiziki bellek de sistem çalisirken geçici kopyasi tutulan bilgilerin olusturdugu bütündür. Örnegin HKLM in ‘System’ hive ini C:\Windows\System32\config altinda bulabilirsiniz. Veya kendi kullaniciniz ile ilgili bilgileri, profil bilgilerinizi n tutuldugu hive i ntuser.dat olarak C:\Users\kullaniciadiniz altinda görebilirsiniz. Bu HKU\KullaniciadinizinSIDi olarak Registrye yüklenir.

Ayrica registry editörü açtiginizda yüklenmemis bölümler vardir, örnegin HKEY_Performance_Data. Bu mesela performance counterlari için kullanilir ve buraya sadece KerneldekiRgQueryValueEx fonksiyonunu kullanarak erisebiliriz.
HKLM\Hardware hive ina da volatile deriz. Bunun nedeni bunun hive in olmamasi ve boot dan sonra olusturulup sadece fiziki bellek de tutulmasidir.

Bir de sembolik linklerimiz vardir. Yani bir de Hive Key olarak sembolik linkler vardir. Mesela HKEY_CURRENT_CONFIG ile HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Hardware Profiles\Current aynidir. Bunun nedeni link olmasi. Yani HKEY_CURRENT_CONFIG ile sadece C:\Windows\System32\config\System dosyasinin belli bir bölümüne erismis oluruz.
Bunun karma durumu da vardir. Örnegin HKEY_CLASSES_ROOT. Burasi HKEY_LOCAL_MACHINE\SOFTWARE\Classes ile HKU\KullaniciadinizinSIDi_Classes in merge edilmis bakisidir.Yani bütün Classlari bir yerde görürüz.

O zaman açik kalan soru hive in tam olarak ne olmasi. Hive dosyasinin kendisini 4KB lik bloklara bölürüz. Ilk blok base blok umuzdur ve burada en temel bilgileri tutariz. Hive büyüdügünde 4KB lik blok boyutunda dosyasi büyür. Bloklarin içerisinde veriyi asil tutan Cell yapisi vardir. Ilk Cell in basi veri türünü ve uzunlugunu tanimlar. Cell in kalani veya takip eden Cell ler asil veriyi tutar. Bu mesela REG_DWORD veya bir Key adi olabilir. Simdi bu blok un sonuna dogru geldiysek ve kullanmamiz gereken Cell er bir sonraki blok a kayacaklarsa, bin olarak adlandirilmis yapi devreye girer. Farkli bilgileri tutabilmek için farkli Cell yapilari vardir. Bin yapisinin kullanilmasinin bir nedeni de verimliktir. Mantiksal bin ler ile ilerlemek daha yüksek bir abstraksiyondur ve örnegin iliskin bellek hareketlerini yönetmeyi kolaylastirir. Hive in yapisini biraz disk yapisi gibi düsünebilirsiniz. Bloklar diskdeki sektörler, bin ler klasörler ve cell ler dosyalar olabilir.

Bellek verimligi ile beraber elbette disk erisimi de önemli. Her hive erisimini bir disk erisimine çevirmemek için, configuration manager, cache manager üzerinden 256 yi geçmemek sartiyla hive larin 16KB lik view larini ihtiyaca göre fiziki bellege mapler. 256 dolunca yeni view yükleyebilmek için, en az kullanilan view u unload ederiz. Bunu limitlemek zorundayiz, çünkü bu view lar paged pool belleginden kullanirlar.

Fizki diskde ki kopya ve bellek deki kopya arasindaki eslesmeyi ve ani sistemin kapanmasi gibi bir durumdan olusabilecek veri kirligini önleyebilmek için hive dosyalarin ayni isimli log dosyalari olur.
Sorunlu senaryolardan kendisini System last known good denen yapi ile de kurtarabilir. Örnegin bir sürücü yüklenir ve sunucu artik boot etmez. Last known good dan ama boot edebilirsiniz. Sürücü de artik en azindan registry açisindan kurulu degildir. Bunun arka planda dönen yapisi HKLM\SYSTEM\CurrentControlSet in korunmasidir. Servisler de bunun altindadir ve sürücüler de buradadir. CurrentControlSet in üsütnde örnegin CurrentControlSet001 ve CurrentControlSet002 diye iki key daha görebilirsiniz. Bunlarin ne oldugunu buradan görebiliriz: HKLM\SYSTEM\Select. Hangisinin su an kullanildigini ve hangisinin henüz degisiklikleri almamis oldugunu ve last known good olarak tutuldugunu görebilirsiniz. Boot edemezseniz CurrentControlSet in last known good versiyonundan boot edebiliriz. Eger current den boot edersek, yani örnegin sürücüyü yükledikten sonra bunun ile ilgili bilgileri tutan tree den, basarili boot etmis oluruz ve asil o zaman sürücü ile ilgili degisiklikler last known good kopyasina islenir. Yani boot dan sonra yapilmis degisikleri last known good tree sine yansitmayiz. Burada dokunmadigimiz bir CurrentControlSet durur. Rebootdan sonra bootun basarili oldugu kanatina varinca, bir önceki bootdan sonra yapilmis degisiklikleri last known good tree sine isleriz. Bu karari da service control manager bir kullanici login olduktan sonra verir. Yani sisteme login oldugunuzda bir önceki last known good u kaybederiz.

Registry islemlerini takip etmenin en kolay yolu process monitör toolu dur. Burada bütün registry islemlerini loglayabiliriz.

Ikinci en temel ve yaygin bilinen yapi Windows Servisleridir. Mantikken bu unixdeki daemonlar ile ayni seydir. Kisaca sisteme bir kullanici login olmadan bir. exe yi belli bir güvenlik çerçevesinde çalistirmak isteriz. Servislerden service control manager sorumludur (scm.exe). Bu servisler de HKLM\SYSTEM\CurrentControlSet\services altinda toplanir. Burada bütün sürücüleri ve servisleri bulabiliriz. Yüklenip yüklenmedigi, ondan önce neyin yüklenmesi gerektigi, ne zaman yüklenmesi gerektigi gibi bilgiler tutulur. Bir özel servis service host içinde çalisan servislerdir. Yani birkaç servisi bir servis altinda toplayabiliriz, bunu svchost olarak biliriz. ‘tasklist /svc’ ile bu processleri listeleyebiliriz. Ayrica Process explorer da svchost processlerin üstünden geçince, içerigi Mouse tool tip olarak görüntülenir. Ortak servis ortak yönetim ve ortak process demektir. Bu avantajlidir ama örnegin yüksek kaynak kullanimlarinda böyle bir servisin içinde nelerin çalistigini ilk kontrol etmek gerekir. Servislerin diger temel sorusu da izolasyondur. Yani bir servis bir kullanici accountun güvenlik konteksti altinda çalistigi için hep servisin arkasinda çalisan .exe ye fazla hak verme tehlikesi olabilir.

Yönetim mekanizmalarin önemli noktalarina ayrica Windows Management Instrumentation (WMI) ve Windows Diagnostic Infrastructure (WDI) dahildir. Bunlar kaynak olarak gösterilen kitapta kisa özetlenmislerdir. Okunmanizi öneririm. Windows un yönetim mekanizmalari hakkinda daha detayli bilgiyi Windows Internals 5th ed. Chapter 4 ‘Management Mechanisms’ altinda bulabilirsiniz:
https://technet.microsoft.com/en-us/sysinternals/bb963901
Bu blogun amaci kitabi okurken size destek olabilmesi. Her bölümün en önemli noktalarini vurgulamasi ve anlasilmasi gereken konseptleri aktarabilmesi. Maksat, kitabin sonuna kadar dogru odagi tutabilmenize yardimci olabilmesi. En nihayetinde ama Kitabi okumazsaniz derin bilgi edinemezsiniz. Ama sadece blogu okumanin da elbette bir sakincasi yok.

Basar Güner