Kernel Turk

APT vs ATD - Bypass ve Ürün İnceleme

noreply@blogger.com (kernelturk) — Thu, 16 Apr 2015 14:24:00 +0300

Uzun bir aradan sonra yeniden merhabalar. Bir yıldır bir şeyler yazıp karalamıyorum . [Buraya bahaneler sıralanacak] :))

Giriş

Malumunuz değerli verilerimizin başı bir türlü bitten kurtulmuyor. Virüs,worm, trojan, sniffer, logger, hooker filan derken bir de gelişmiş akıllı hedef güdümlü APT zararlıları icat oldu. İyiden iyiye bir zenginlik aracı olmaya başlayan zararlı yazılım alanı zevk, hırs ve ego için zararlı geliştirmenin ötesinde bol kazançlı bir iş alanı haline geldi. Geçmişte sadece boy göstermek için yazılan bu kodlar günümüzde ulus devletlerin veya kurumsal ölçekli şirketlerin emellerine yataklık edecek şekilde geliştiriliyor. Bugünlerde artık tek kişilik çaba ve emeklerin eseri zararlılardan öte, dev geliştirici kadrosu olan ciddi ve planlı ekiplerin elinde çıkmış ve gerçekten kötü niyetli ürünler ile muhatap olmaya başladık. Bu tehditler artık geleneksel güvenlik çözümlerini bir çırpıda aşabiliyor ve sistemlerimizde amaçladıkları aksiyonları zorlanmadan gerçekleştirebiliyorlar. Zararlıların bazıları hedeflerini gerçekleştirdikten sonra, bazıları ise güzel güzel çalışırken yıllar sonra kafasına taş düşen bir güvenlik uzmanın merakı neticesinde tesadüf eseri tespit edilebilir hale gelmiş durumdalar.

Gelişme

IPS, Next-Gen Firewall, DLP, Web Proxy, Anti Virüs, Hips, katı güvenlik politikaları ve son açıklara karşı güncellediğimiz işletim sistemleri... Nasıl ama? Uçtan uca güzel bir güvenlik mimarisi gibi görünüyor değil mi? Bilinen bir tehdidin bu zincire takılmadan hedefine ulaşması pek olası görünmüyor. Açıkçası bilinen tehditlere karşı geleneksel imza tabanlı koruma sistemlerinin biraz daha evrilmiş hallerinden oluşan bu ürünler, bilinmeyen tehditlere karşı sezgisel olarak hiçbir zaman vaat edileni sunamadılar. Bu nedenledir ki artık bizler günümüzün gelişmiş ve akıllı zararlılarına karşı en az onlar kadar hızlı tepki verebilen, karşılaştığı riski uç noktada hareket ediyormuşcasına yorumlayıp doğru analiz sonuçlarını üretebilen sistemlerle çalışmak istiyoruz. Konuyu güncel bir örnekle açıklamamız gerekirse; popüler ebanking virüsleri ve fatura virüsünün onlarca varyantı ve sürekli güncellenen sample’ları yukarıda sayılan hiçbir sistem tarafından tanınamıyorken ATD sistemlerinin Payload Analysis fazında başarılı bir şekilde tespit edilebiliyorlar!!! Peki ya çözüm?

Bu sorunun cevabı da en az sorunun kendisi kadar bol çeşitli ve karmaşık. Verilen cevaplar ve sunulan çözümler ya yetersiz kalıyor ya da uygulanmak istenildiğinde farklı süreçleri etkilediğinden ölü doğuyor.

Çözüm ATD, mi?;

Advance Thread Defense (ATD). En az Advance Persistent Thread kadar havalı bir isim değil mi? Çözüm sağlayıcılar APT tehditlerine karşı katmanlı bir yaklaşım senaryosu sunmaktalar. Tehditlerin, ağ katmanında gösterdiği trafik hareketlerinden veya yine ağ katmanında yakalanan tehlike arz edebilecek dosyanın sandbox analiz sonuçlarına yada doğrudan endpoint üzerinde ki katılaştırma ve beyaz liste yolu ile engelleme yoluna gidilmekte. Bu yazımda sizlere, bu çözümlerden Payload analiz tekniklerini kullanan Sandbox çözümleri üzerinde edindiğim tecrübelerden bahsedeceğim.

Challange!

APT tehditlerinin popülaritesi hız kesmeden devam ediyor. Pazardaki bu açığı gören zeki girişimciler de aslında hep var olan davranışsal analiz ve sanallaştırma teknolojisinin güçlerini bir ürün haline getirerek bizlere sunmakta gecikmedi. Pazarlama aşamasında oldukça cüretkar vaatler sunan ürünlerin iş PoC’ler’e gelince topu taca atma girişimlerinin yorumlanması ise bu yazının bir başka konusu. Şu bir gerçek ki gelişmiş hedef odaklı zararlılara karşı koruma vaat eden ürünlerin kesinlikle olgunlaşması gerekiyor ve bir başka gerçekte şu ki bu ürünlere ait mekanizmaların bir şekilde etkisiz hale getirilebiliyor olması onları asla gereksiz kılmıyor. Tam aksine sundukları yetenekleri ile farkındalık seviyesinin artmasına ve mevcut güvenlik ürünleri ile tespit edilmesi mümkün olmayan potansiyel veya bilinen tehditlerin tespitine yardımcı oldukları kabul edilmesi gereken bir gerçek.

2014 yılı içerisinde birkaç Payload Analizi yapan ATD ürünü ile test yapabilme fırsatım oldu. Çalıştığım kuruma ait güvenlik alt yapısının iyileştirilmesi kapsamında çözüm sağlayıcılar ile yapılan görüşmeler neticesinde ülkemizde bu alanda faaliyet gösteren üç üretici ile çalıştık. Bunlar; FireEye, Trend Micro ve McAfee oldu. PaloAlto ve SourceFire ise PoC takviminin darlığı sebebi ile testlere yetişemedi. Fidelis ve Damballa ise test etmek istediğim ancak ülkemiz pazarında muhatap bulamadığım için testini gerçekleştiremediğim Breach Detection ürünleri arasında yer aldı.

Hazırlık

Testler iki aşamadan oluşuyor;

İlk olarak ATD sisteminin vaat ettiği yeteneklerinin gerçek ortamda ne kadar etkin çalıştığının testlerini gerçekleştirdim. Bu testlerde;

Yüksek traffic througput’larında ürün tarafından analiz edilmesi beklenen sample’ların yakalanma oranı,
Sample analizlerinin süresi,
Waiting Queue’ların uzunluğu,
False-Positive oranı,
Bilinen bir zararlının farklı formlarda tanınması(Bulk Zip, Encapsulate Binary vb..)
Diğer güvenlik çözümleri ile entegrasyon,
Raporların açıklayıcı ve detaylı olması

gibi kriterler ürün seçimi aşamasında ki ana noktaları oluşturuyordu.

2. İkinci aşama tamamı ile benim eğlence dünyama hitap ettiğinden, dileyen okuyucular bu kısmı atlayabilir;

El Yapımı APT

Geçmişten gelen low-level merakı ve kendi zararlılarımı yazabilmenin verdiği öz güven ile birlikte bende APT tehditleri konusunda iddialı olan bu ürünler üzerinde hazır fırsatını bulmuşken biraz oynamak istedim. Amacım gelişmiş zararlılar karşısında iddialı bir güvenlik çözümü olma vaadinde bulunan bu ürünlerin kendi güvenliklerinin durumunu test etmek ve sundukları Sandbox analiz yeteneklerinin etkisiz hale getirilip getirilemeyeceğini görmekti. Hali hazırda sahada keşfedilmiş bir çok sandbox bypass tekniği mevcut ancak üreticilerin de bunlardan haberdar olduğu denediğim her bilinen bypass yönteminin sandbox analiz raporunda gözüme sokulması ile kendini belli ediyordu. Lafı uzatmadan doğrudan sonuca gelecek olursam. Tüm ürünleri sample malware’im ile bypass edebildim. Hatta her hangi bilinen bir zararlıyı da dilenirse bu sample ile merge edip hedefe sorunsuzca ulaştırmak mümkün. Ben testlerimde kolay erişilebilirlik ve hız açısından EICAR ve Fatura sample’larını tercih ettim.

Testler esnasında bir ürünün üzerinde ki tespit ettiğim web tabanlı açıkları yenilir yutulur cinsten değildi. Gerek bypass yöntemlerini gerekse de ürünlere ait kritik zafiyetleri ilgili firmalar ile paylaştım. Şu aşamada iki firma ile etik çerçevede yeni sürüm çıkana dek bu zafiyetleri public etmeme konusunda anlaştık.

Yazdığım test zararlısını aslında bloğumu takip edenler hatırlayacaktır. “Malware Analizlerinde Anti-Analysis ve Anti-Debugging Teknikleri” adlı yazımda Malware analizine meraklı arkadaşlar için tüm detaylı açıklamaları da içinde yer alan kaynak kodu ile birlikte bir sample paylaşmıştım. İşte bu testler için de bu çalışmamı biraz daha geliştirip aşağıda ki özelliklere sahip bir test zararlısına dönüştürdüm.

Not: İlgili linkte yer alan streamer.exe sample'i bu yazıda incelenen ürünlere ait evasion tekniklerini ve diğer zararlı özelliklerini içermemektedir.

Test zararlısının kullandığı bazı bilinen tekniklerin içeriği aşağıda ki gibi:

Anti-Debugging
Anti-Disassembly
Anti-Analysis
Anti-Emulation
Anti-VM
C&C Communication
Shell Code Injection
Web ve Local Malware Drop
x86 Asm tricks
ve daha bir çok irili ufaklı zararlı yapıları..

Test zararlısını kodlarken en eğlendiğim kısım APT analiz süreçlerini atlatmaya çalıştığım kısımlardı. Bir çok bypass denememi başarı ile tespit edip, bu girişimleri Evasion Techniques veya Suspicious Activities olarak kategorilendiren ürünler, hiç ummadığım yerlerden gol yediklerinde beni oldukça şaşırttılar.

Bu özelliklerin kurban sistem üzerinde ki aktivitesini gösteren ekran alıntılarını da aşağıda yer alıyor:

Zararlımız çalışmadan önce...

Çalıştırıldıktan sonra.

Yukarıda ki resimlerden de anlaşılacağı üzere zararlımız herhangi bir sandbox veya analiz ortamında çalışmadığına emin olduğunda aşağıdaki görevlerini gerçekleştiriyor;

Başka bir zararlıyı (eicar veya ptt.exe) HTTPS kanalı ile download edip çalıştığı dizine yazma,
Zararlının kendi code bloğunda encrypt durumda olan EICAR test dosyasını doğrudan diske yazma,
Şayet ortamda PuTTY çalışıyorsa, ona shellcodunu inject ederek sistemde yönetici haklarına sahip kullanıcı oluşturma,

işlemlerini gerçekleştiriyor. Bu basit aktiviteleri streamer.exe'nin ilave kod yapısı gereği de tam olarak bir zararlı görünümüne sahip olması için yaptım. Download yöntemi olarak https kanalı kullanmamanın nedeni de ortamda ki IPS,Firewall ve Proxy Gateway'lerin görevlerini yapıp yapmadığını test etmek içindi. Testler sonucunda da anlaşıldı ki doğru ve etkili müdahaleler için SSL Inspection cihazları ile sadece Algılama ve Engelleme yapan cihazların bulunacağı bir Decrypt Zone oluşturmak mantıklı bir seçenek olarak karşımıza çıkıyor. Local bir admin accountu eklemek için ise zararlımızın hali ile SeDebugPrivilege tokeni ile çalışıyor olması gerektiğinden ya ilk açılışta UAC'den icazet almamız ya da onu bypass etmemiz gerekiyor. Bu arada belirtmeliyim ki tüm testlerimi son güncellemeleri yapılmış Windows 8.1 ve Windows 7 işletim sistemleri üzerinde yaptım. Ben test ortamımda Avecto Privilege Guard uygulamasının yeni keşfettiğim bir açığından yararlanarak local admin hesabını ekleyebildim. Normal şartlarda Avecto size tüm admin haklarını verse dahi Administrators grubuna ekleme/çıkarma yapmanıza izin vermiyor! Avecto olmayan bir ortamda ise tüm özellikleri ile test etmek istediğimizde Yönetici olarak çalıştır seçeneğini seçmemiz gerekiyor.

Aşağıda test edilen her ürün için streamer.exe zararlısına ait analiz sonuçlarını görebilirsiniz:

FireEye analizi esnasında, streamer.exe bilinen bir detection yöntemi ile analiz edildiğini algılıyor ve zararlı aktivitelerini gerçekleştirmeden kendini sonlandırıyor. Bilinmeyen diğer bypass yöntemlerini firma ile etik bir çerçevede paylaştığımdan burada yer veremiyorum.

McAfee ATD ürünü streamer.exe analiz sonucu için bir skorlama dahi yapma gereği duymuyor.

Trend Micro Deep Discovery Analyzer'in streamer.exe analizine ait bir ekran görüntüsü. Test sample'imiz kendisinin analiz edildiğini anlıyor ve sürecini sonlandırıp analiz aşamasını bypass ediyor.

Ürün Testleri

Testlere geçmeden önce konu hakkında ki bazı hayati bilgileri aktarmam gerektiğini düşünüyorum. Mevcut durumda APT tehditlerine karşı oluşturulmuş genel bir konsept bulunmuyor. Breach Detection, Advanced Thread Detection/Protection, ZeroDay Protection vs.. vs.. ATD ürünlerinden en büyük beklentimiz analizleri esnasında zararlı olarak tespit ettiği sample'ları blocklaması. Ancak bunu vaad eden ürünler ne yazık ki Sandbox Analysis aşamasında ilk kez karşılaştığı sample'ı zararlı olarak tespit etse dahi bunu engellemeyi başaramıyor. Bunun hız, kullanıcı isteklerinin bekletilme süreleri gibi bir çok nedeni var. Özetle, bloklama işlemini bu zararlı analiz sonrası tanınır hale geldikten sonra kullanabiliyorsunuz.

FireEye

Ticari Analiz

İlk testini gerçekleştirdiğim ürün FireEye oldu. FireEye, Web ve Email trafiği için iki ayrı kutu sunuyor ve Network Utilization’ınıza göre ölçekleyebildiğiniz geniş bir ürün yelpazesine sahip. Ben testlerimi Web trafiği üzerinde analiz yapan 7400 serisi cihaz ile gerçekleştirdim. Her ne kadar protokol tipine göre ayrı çözümler sunuyor olsa da bu özelliği uçtan uca çözüm isteyen kurumlar için FireEye’ı rakiplerine göre biraz pahalı bir tercih haline getiriyor. Çözümler Inline olarak çalışabildiğinden bilinen zararlıları tespit edildiği anda bloklama imkanınız da bulunuyor.
Ticari boyutunda eleştirebileceğim en olumsuz bulduğum yanı ise manuel analiz yolu ile incelemek istediğiniz sample'lar için yine ayrı bir kutu alma zorunluluğun olması. Diğer incelediğim ürünlerde manuel sample analiz olanağı ücretsiz bir servis olarak sunulmakta.

Teknik Analiz

Bildiğim kadarı ile FireEye kendi patentli sandbox analiz teknolojisini kullanıyor. Satın aldığınız kutu üzerinde ki belirtilen ağ yükleri altında analiz süreleri kimi zaman uzun sürüyor olsa da bu sürenin kabul edilebilir bir aralıkta olduğunu belirtmek isterim. Sandbox analiz sonuçlarını raporlarken, kendi arayüzü üzerinde çok detaylı diyemeyeceğim bir şekilde trace sonucunu paylaşıyor. Zararlının yaptığı ağ trafiği ile alakalı forensic ihtiyacınızı ise export edebildiğiniz pcap dosyası ile sağlayabiliyor. PoC esnasında kurum bünyesinde kullanılan bir activex nesnesine ait ocx’in olması gerektiğinden çok daha über fonksiyonlara sahip olmasından rahatsız olan FireEye’ın bunu raporlaması hoş bir andı. FireEye'ı ayrıca bu yazıyı yazdığım sırada A10 firmasının SSL Inspection çözümü ile birlikte HTTPS trafiği içinde test edebilme fırsatı buldum. FireEye bilinen HTTPS zararlılarını da başarı ile algılayıp bloklayabildi.

McAfee ATD (Advanced Thread Detection)

Ticari Analiz

Öncelikle ATD tek başına çalışan (standalone) bir ürün değil. Vazifesini yapabilmesi için onu besleyecek McAfee etiketli IPS, Web Gateway,Mail Gateway veya McAfee TIE Endpoint ürünlerinden birine sahip olmalısınız. Bu da hali ile ilk satın alma maliyetlerini arttıran bir etken. Tabi bu dezavantajı eğer bu McAfee ürünlerinden en az birini kullanıyorsanız avantaja çevirebilirsiniz. MATD-3000 ve MATD-6000 adlı 2 farklı modele sahip. Bu modeller arasında ki fark eş zamanlı açılabilecek sandbox ve taranabilecek dosya sayısını belirliyor. Testleri gerçekleştirdiğim 6000 serisinde bu sayı 60 Vm Sandbox'tı. Sandbox image'ları için sizin oluşturduğunuz vm image'larına ihtiyaç duyuyor. Bu özelliğin artıları olsa da bazı handikapları olduğu ortada.

Teknik Analiz

McAfee ATD'yi sample'lar ile besleme işlemini McAfee IPS ve Web Gateway ile yaptım. McAfee ATD henüz çok yeni bir ürün. Kağıt üstünde sunduğu özellikleri şayet ileride gerçekleştirilebilirse kendini rakiplerinden sıyırabilen bir ürün olması kuvvetle muhtemel. Ancak PoC’ler esnasında yeni bir çözüm olmasından kaynaklanan bir çok irili ufaklı sorun yüzünden bir türlü istenen verimi alamadım. Analiz sürelerinin uzunluğu, kuyrukta bekleyen sample’ların çok kısa bir süre içinde analiz sürecini imkansız kılacak sayılara ulaşması, False Positive sonuçlar türemesi gibi problemlerle karşılaştım. Analiz aşamasında ki sıkıntılar muhtemelen IPS entegrasyonu ile ilgili bir sıkıntıydı ki aynı sorunları Web Gateway ile kurulan entegrasyonda yaşamadım. PoC sırasında çıkan yeni güncellemeyi de geçtiğimde False Positive sonuç oluşması problemi de ortadan kayboldu. Bunun gibi birçok ürün odaklı sorunu tedarikçi ve üretici firma ile paylaştım. Kendileri ATD’ye oldukça ciddi yatırımlar yaptıklarını, sürekli yaptıkları iyileştirme güncellemeleri ile ispat ediyorlar. Ancak tekrar etmek gerekirse mevcut durumu ile bir APT engelleyici çözüm olarak pazardaki rakiplerinin seviyesine erişmesi için çok daha olgunlaşması gerekliliği satın alma kararlarınızda göz önünde bulundurmanızda fayda var.

TREND MICRO Deep Discovery Inspection & Analyzer

Ticari Analiz

Trend Micro çözümünü 2 ayrı cihaz ile sunuyor. Deep Discovery Inspection (DDI) ve Deep Discovery Analyzer (DDA) olarak isimlendirilen kutular dan Inspection olanı ağ üzerinden kendisine gönderilen trafik içerisinden web protokolü analizleri gerçekleştirirken, Analyzer adlı kutu Inspection’dan kendisine gönderilen executable’ların analizlerini gerçekleştirmekte. Email güvenliği için Trend Micro’da tıpkı FireEye gibi farklı bir kutu sunmakta. Manuel sample analizlerini ise DDA üzerinden gerçekleştirebiliyorsunuz. DDA üzerinde de ki sandbox'lar da sizin oluşturduğunuz Vm Image'lar ile çalışıyor.

Teknik Analiz

TM kutularını 1Gb throughput altında çalışabileceği bir trafik altında test ettim. Yapısı gereği sadece web protokollerine ait tanıdığı extensionlar üzerinde analizler gerçekleştirebilen DDI, ortamdan yakaladığı sample'ları DDA'ya göndererek gayet makul sürelerde analizler gerçekleştirdi. Mirror bir trafikle çalışan DDA, analiz sonucu zararlı olduğunu tespit ettiği sample için blocklama yeteneğinden mahrum. Ancak DDI inline konumlandırıldığı durumlarda bilinen C&C haberleşmelerini RST flag'i ile bloklayabiliyor. TM'nun analiz sonucu raporları ve Dashboard'u oldukça zengin ve doyurucu bir içeriğe sahip.

Sonuç

ATD çözümleri henüz uzun yıllardır pazarda olan seçenekler değil. Olgunlaşmaları ve geliştirmeleri gereken bir çok eksiklerinin olduğu ortada. Analiz ortamlarını ve yeteneklerini iyileştirdikce ve farklı katmanlarda ki Breach Detection sistemleri ile entegre oldukça çok daha iyi çözümler sunan ürünler olmaya devam edeceklerini umuyorum. Özellikle dinamik analizlerde başarılı grafikler çizen ATD teknolojisi bunu ne yazık ki static analizlerine yansıtamıyor görünüyor. Ticari veya serbest geliştirici olarak ATD ürünü geliştirenlere acizane önerim analiz aşamasının ilk fazını static analiz testlerine göre skorlamaları ve ardından dinamik analiz ve davranış analizi sonuçlarına göre ilgili sample için aksiyon almaları yönünde olacaktır. Böyle bir yaklaşımın otonom zararlı analizinin tüm katmanlarını çok daha iyi adresleyebileceğini düşünüyorum.

Özetle günümüz konjektüründe bu ürünlerden beklediğiniz "Maliyet/Güvende Hissetme" dengesi ne yazık ki tatmin edici seviyede değil. Bu nedenle güvenlik yatırımlarınızı, en az bu ürünlere ödediğiniz kadar tecrübeli insan kaynağına da yönlendirmenizi tavsiye ederim.

Not: Şayet Gartner müşterisi iseniz ATD pazarına ait güzel bir yazının linki şöyle: Five Styles of Advanced Threat Defense

Sağlıcakla kalın,

İbrahim AKGÜL - 2015

Malware Analizlerinde Anti-Analysis ve Anti-Debugging Teknikleri

noreply@blogger.com (kernelturk) — Tue, 5 Nov 2013 23:13:00 +0200

Yeniden Merhabalar, Fırsat buldukça bir şeyler karalamaya çalışıyorum. Bu makalede, Malware Analysis ve Reverse Engineering konularında kaynak sıkıntısı çeken ve bu tip işlere meraklı yeni başlayan arkadaşlara Kod Analizleri esnasında karşılaşılan Anti-Debug ve Anti-Analysis yöntemlerini yardımcı bir program eşliğinde sunmaya gayret edeceğim. Programı incelemeye başlamadan önce analiz için VM makinenizi ve Olly, IDA gibi analiz araçlarınızı hazırlamanızı tavsiye ederim.

Analize başlamadan önce;

Kullanacağımız uygulama Masm derleyicisi kullanılarak Assembly dili ile yazılmıştır. Tümü ile detaylı yorum satırları da dahil olmak üzere açık kaynak kodu ile birlikte gelmektedir.
Uygulama 17 faz olup, istediğiniz şekilde ilaveler yapabilirsiniz. Derleme işlemi için www.masm32.com üzerinden ilgili paketi indirmeniz yeterlidir.
Kod içerisinde kullanılan tüm koruma methotdarı temel seviyede olup çözümleri de bir o kadar basittir.
Koruma methodlari sadece öğretici olmak için hazırlandığından atlatılmaları için ZF flag'ini NOT'lamanız yeterli olacaktır. Gerçek senaryolarda bu methodlar çok daha farklı ve obfuscate edilmiş olarak karşınıza çıkar.
Uygulama C dilinde de rahatlıkla yazılabileceği gibi Assembly kullanımında ki amaç analiz yeteneklerinin hızlı gelişimine katkıda bulunmaktır.
Test programı ve bu makale 2 iş günü arasında fırsat bulunarak yazıldığından düzensiz görünmesini normal karşılamanızı rica ediyorum.
Analizler esnasında algılama tekniklerinin işleyişini daha iyi anlayabilmeniz için doğru kod bloklarında olmanız gerekebilir. Bu yüzden analiz süreciniz içerisinde kaynak kod ve debugger pencerenizi eş zamanlı şekilde kullanmanızı öneriyorum.
Masm32 platformuna aşina olmayan arkadaşlar 7 yıl önce yazdığım ve giriş seviyesinde olan http://kernelturk.blogspot.com/2009/10/masm32-ve-win32api-voltran-voltran.html makalesini okuyabilirler.
İlerleyen aşamalarda ucu açık kalan konular hakkında da (ör: polymorphic kod'lar ile packing, permutasyon çeşitleri ile Analizlerden kaçma yolları, kodunuzun bir VM veya Emulator üzerinde çalışıp çalışmadığının anlaşılması gibi) yazmayı planlıyorum. Bu yüzden ben o süreçleri hazırlayana kadar siz bu konuları kavramaya gayret edin lütfen.

Analiz Dosyasına ulaşmak için : İndir

Not: Doğrudan ve hızlı bir şekilde programın analizine başlayabilir veya sizlere fikir vereceğini düşündüğüm kısa bir yazıyı okuyabilirsiniz:

Kolay olan Tespit Etmek mi?

Zararlı Yazılımlar'ın öncelikli hedeflerinden biride tespit edildikleri anda tüm kirli çamaşırlarının bir bir ortaya çıkmasının önüne geçmektir. Zararlı Yazılım Analistleri ele geçirdikleri zararlı örnekleri üzerinde çalışmak için bir çok farklı araçtan yararlanırlar. Ancak analist zararlıyı incelemeden önce tamamı ile yalıtılmış bir ortam hazırlamak zorundadır. Çalışmalar ilk zamanlarda temiz bir işletim sistemi üzerinde tüm gerekli analiz araçları yüklenmiş ve network kablosu çekilmiş fiziksel pc'ler üzerinde yapılıyorken ilerleyen zamanlarda bu iş için uzaktan hata ayıklama (remote debugging) teknikleri yerini almıştı. Ancak yinede fiziksel pc bağımlılığı nedeni ile analiz süreleri zararlıların davranışlarına göre farklılıklar gösterdiğinden çok uzun zaman alıyordu.

İlerleyen zamanlarda Emulatorler ve Virtual Pc'lerin ortaya çıkması ile analiz süreçleri çok daha güvenli ve hızlı olarak yapılabilir hale geldi. Snapshot/Checkpoint teknikleri ile zararlının tüm davranış methodları tekrar ve detaylıca analiz edilebiliyor ve köşeye kıstırıldığı bu alanda eldeki tüm analyze silahları kullanılarak etkisiz kılınıyor ve zararlı tarihin karanlık kodlar çöplüğüne yollanıyordu. Tabi cephenin diğer tarafında bulunan zararlı geliştiricileri bu gelişmelere sessiz kalamazdı! Üstüne üstlük tüm bu savunma mekanizmalarının var oluş nedenleri yine zararlıların ta kendileri iken. Önceden olduğu gibi günümüzde de Zararlılar tespit edilmemenin dışında analiz edilmemek içinde oldukça efor harcıyorlar. Zararlı yazılım geliştiricileri, geliştirdikleri zararlının tespit edilmesi halinde analiz süreçlerini çok daha uzun ve içinden çıkılmaz bir hale getirmek için uğraş içerisindedirler. Aslında burada şunu da belirtmek gerekirse, kodlarının analiz edilmemesini isteyen kesim sadece zararlı geliştiricileri değil! Bir tarafta kötü amaçları için iyilerden kaçmaya çalışanlar olduğu gibi iyi amaçları için kötülerden kaçmaya çalışanlarda var! Ticari yazılım üreticileri programlarının lisans yükümlülükleri altında dağıtılmasını ve bu yol ile kazanç sağlamayı hedeflerler. Ancak bunun önünde Reverse Engineering yetenekleri oldukça gelişmiş Cracker camiasının elemanları bulunmaktadır. Değerli yazılımlarının lisans mekanizmalarının basitçe aşılmasına sessiz kalmak istemeyen yazılım üreticileri bir çok koruyucu tedbirlere yönelmiş ve onlarda yazılımlarını Anti-Analysis teknikleri ile koruma altına alma yoluna başvurmuşlardır. Hatta öyle ki Anti-Debug ve Anti-Analysis tamamen ticari bir kimliğe bürünüp kendine müşteriler bulmaya başladı. Armadillo, AsPack, Themida gibi Reverser'lara karşı koruma vaadeden yazılımların popülerliği hep gündemde yer bulmuştur.

Ne Kadar Bilgi O Kadar Analiz

x86 mimarisi üzerinde çalışan bir yazılım analiz edilmek istenildiğinde hangi dilde yazıldığına bağlı olmaksızın durumuna göre IA32 ve AMD64 komut ailesine ait assembly kodlarına dönüşürler. Analiz süreçlerinde assembly diline aşina olmak elbette önemlidir ancak tek başına yeterli olmayacaktır. Assembly bilginize ilave olarak çalıştığınız işletim sisteminin mimarisi üzerinde derinlemesine bilgi sahibi olmanız, kriptografi bilginiz, sanallaştırma ve emulasyon çözümlerinde ki derin teknik bilginiz analiz süreçlerinin çok daha kısa ve keskin sonuçlar vermesine katkı sağlayacaktır.

Test programımız üzerinde yapacağımız analizlerde de göreceğiz ki Anti-Analysis ve Anti-Debugging tekniklerinin bir çoğu Assembly dilinin getirdiği avantajları değil programın çalıştığı mimarinin yeteneklerini kullanır. Windows ortamında bir process'in ilk ortaya çıkması ile birlikte var olan TIB, PEB gibi yapılar gerek analiz gerekse anti-analiz süreçlerinde anahtar rol oynarlar. Bu ve bunun gibi internal yapıların iyi bir şekilde öğrenilmesi Reverser için analiz sürecini oldukça kısaltacaktır.

Bu test programı ile kazandığınız bilgiler giriş seviyesi olarak sizleri tatmin edecektir. Ancak ilerleyen fazlarda Assembly bilginizi neden ileri derecede geliştirmeniz gerektiğini fark edeceksiniz. Çok iyi bir assembly bilgisi ile ileri seviye koruma methodlarını yazılımlarınıza uygulayabilir veya Malware Analizleri esnasında karşılaştığınız engelleri rahatlıkla egale edebilir duruma gelirsiniz. Nanomites, Magic Opcodes, Stolen Bytes, Code Permutation, Garbage Code ve daha nice insan zekası ile opcode'ların birleşiminden oluşan bu zengin bilgi deryasına ancak iyi bir assembly bilgisi ile aşina olabilirsiniz.

Konu ve gelecek yazılar hakkında görüşlerinizi paylaşabilirsiniz.

Sağlıcakla.

Kasım 2013 - İbrahim Akgül

Uygulama İçi Static Key Zaafiyetlerine Öğretici Bir Yaklaşım

noreply@blogger.com (kernelturk) — Thu, 12 Sep 2013 12:08:00 +0300

Şirketimiz'de staj yapan ve Security'ye ilgi duyan arkadaşlar için 1:1 eğitimlerin dışında örnek olarak hazırladığım bir dokumanı sizlerle de paylaşmak istedim.

Büyük ölçekli şirketlerin kurum içi Instant Message ihtiyaçlarını profesyonel ve free bir şekilde karşılayan Spark uygulamasın da denk geldiğim bir zaafiyet'den bahsedeceğim. Hemde bu vesile ile kriptografi öğrenimi sürecinde eğlenceli bir araç olan Cryptool uygulamasını tanıtmış olurum diye düşündüm.

Spark IM, kullanıcıları authentication işlemleri için Active Directory user hesaplarını kullandığından, sahip olduğu authentication mekanizmasınında bir o kadar güvenilir olması bekleniyor. Spark'ın sunucusu olan Openfire ile iletişimi ssl ile gerçekleşiyor ve Login prompt ekranında sunduğu parola hatırlatma seçeneğinin seçilerek sisteme giriş yapılması halinde girilen parolanın 3DES ile kriptolanarak bir dosyaya yazılması onu bulunduğu açık sistem üzerinde de güvenli kılıyor görünüyor. Ancak Spark açık kaynak kodlu bir ürün olduğundan bu parola bilgisini saklama esnasında kullandığı static key'e kolayca erişebiliyoruz:
http://svn.igniterealtime.org/svn/repos/spark/trunk/src/java/org/jivesoftware/spark/util/Encryptor.java

Aslında Opensource olmasa dahi herhangi bir uygulama encrypt/decrypt işlemleri için kullandığı key'i embed ettiğinde bir kaç Reverse adımı ile de sonuca ulaşabiliyorsunuz.

Statik key'i öğrendikten sonra, encode edilmiş parolanın bulunduğu dizini açıp (Windows 7'de C:\Users\username\AppData\Roaming\Spark\spark.properties) password keyword'ünün hashli içeriğini almamız gerekiyor. Bundan sonraki aşamalar ise süreci eğlenceli kılmamızı sağlayan kriptografik bir kaç dizi işlemi gerçekleştirmemizle devam ediyor.

İlk olarak size tavsiyem , şayet Kriptografi'yi seviyor ve merak ediyor ancak anlamakta güçlük çekiyorsanız mutlaka CrypTools uygulamasını sisteminize kurmalısınız. Cryptools gerçekten çok kullanışlı ve en sıkıcı hale bile gelebilen karmaşık kriptografik işlemleri sizin için eğlenceye dönüştürebilen bir uygulama.

CrypTool 2 karşılama ekranı

Yazının bundan sonraki kısmında Cryptool ile çalışacağız. Uygulamayı açtığımızda karşımıza gelen ekran üzerinden yeni bir boş proje seçerek decode işlemimiz için ilk adımı atıyoruz

Yeni proje açmak için workspace seçeneğini işaretliyoruz

Yeni projemiz için karşımıza gelen görüntü aşağıda ki gibi olacaktır. Ekranın sol kısmında yer alan araç çubuğu üzerinden projemizde kullanacağımız nesnelerinin seçimini yapacak ve sağ menüde bulunan bar ile de nesnelere ait özellikleri değiştirebileceğiz.

Workspace layout

Aşağıda ki resimden de görebileceğiniz gibi 2 adet TextInput, 1 Adet TextOutput ve asıl işlemleri gerçekleştirecek olan DES şifreleme nesnesini workspace'e ekliyoruz. Ardından eklemiş olduğumuz nesnelerin birbirleri ile iletişim kurabilmeleri için doğru renk kombinasyonuna sahip işaretleyiclerini mouse yardımı ile bağlıyoruz. Böylece gireceğmiz key ve encode edilmiş dataları DES cipher'ina gönderebilecek ve sonucu TextOutput penceresinden okuyabileceğiz.

Tasarım aşaması

Projemizin omurgası hazır olduğuna göre artık verileri doğru alanlara girmenin vakti gelmiş demektir. Yazının girişinde de belirttiğim Spark'a ait parola bilgilerinin encode edilmiş olarak durduğu dosya olan spark.properties'i bir editor yardımı ile açıp password keyword'ünün içermiş olduğu 32 karakterlik sabit uzunluğa sahip verimizi alıp bir sonraki adımımız için elde tutuyoruz.

spark.propterties dosyasından parola bilgisinin alınması

Yukarıdaki işlemin aynısını bu sefer secretKey için yine girişte url'ini verdiğim Sparkın kaynak koduna ait ilgili dosyadan temin ediyoruz. Artık elimizde biri kurbanımıza ait şifreli parola diğeri bu parolayı decode edecek keyimiz olmak üzere 2 verimiz var. Bu veriler base64 ile encode olduğundan Cryptools'da ki TextInput alanlarımıza girmeden önce decode etmeliyiz. Bunu net üzerinde online olarak gerçekleştiren bir çok siteden yapabilirsiniz.

http://www.opinionatedgeek.com/DotNet/Tools/Base64Decode/default.aspx

Decode ettiğimiz keyin hexdecimal verisini 2 numaralı TextInput (bknz: alt resim sol alt köşe) nesnemize , parolaya ait olan decode verisinide 1 numaralı TextInput (bknz: alt resim sol üst köşe) yapıştırıyoruz. Bu aşamada text nesnelerinin sağ menü üzerinde bulunan özelliklerini hexdecimal olarak değiştirmeyi ihmal etmeyin.

Artık PlainText parolamıza ulaşmamız için gereken tek şey DES nesnesinin özelliklerini ayarlamak. Ayrıca yazmak gerekirse DES nesnesine girdiğimiz attributes'lar aslında yine girişte linkini verdiğim Spark'ın source code'unda ki ilgili dosyadan elde ettiğim verilere dayanıyor. Özetle parolamız 3DES algoritmasının ECB mode'unu kullanarak şifreleniyor ve son aşamada PKCS7 yöntemi ile de son halini alıyor. Bizde bu veriler ışığında aynı seçenekleri seçip sadece bu defa encrypt yerine decrypt işlemi yapacağımızı belirtiyoruz. Bu işlem için DES nesnemizi seçtiğimizde sağ menüde görülecek olan özelliklerinden Actions alanını Decrypt, Chaining Mode'unu ECB, Padding Mode'u PKCS7 ve son olarak 3DES checkbox'ını işaretlememiz yeterli olacaktır. Tüm bu süreç sonunda Menü çubuğunda yer alan Play simgesine basarak decode edilmiş parolayı görebiliyor olacağız.

Sonuç

Ben programcıyım eğlenmek'te istemiyorum, bana decrypt edecek kodlar lazım diyenler için:

private const string STATIC_KEY = "ugfpV1dMC5jyJtqwVAfTpHkxqJ0+E0ae";

public static string Decrypt(string data)

{

var 3des = new TripleDESCryptoServiceProvider();

3des.Mode = CipherMode.ECB;

3des.Padding = PaddingMode.PKCS7;

3des.Key = Convert.FromBase64String(STATIC_KEY);

var decrypt = 3des.CreateDecryptor();

var b64 = Convert.FromBase64String(data);

var result = decrypt.TransformFinalBlock(b64, 0, b64.Length);

return Encoding.UTF8.GetString(result);

}

Teşekkürler

Sahipsiz Blog

noreply@blogger.com (kernelturk) — Sun, 8 Sep 2013 19:55:00 +0300

İş hayatı böyle gaddar işte! Verdiklerinden çok götürdükleri oluyor. Son girdimi 2 sene önce yazmışım. Demek ki blog yazarlığı bana göre değilmiş :( Hala varsa takipçilerden özür diliyorum. Aslında Google Analytics doğru söylüyorsa :p günlük 60'ın üzerine düşmemiş ve search edilen keyword'lere göre baya lowlevel meraklısı varmış. Eğer başarabilirsem bu aralar bir şeyler karalamak istiyorum çünkü baya bi bilgi yüklü katır formundayım ve birileri ile paylaşmazsam bu bilgilerin değersizleştiğini düşünüyor insan. Mesala 6 ay önce Hyper-V 3.0'da keşfettiğim ve mission critical derecede değerlendirilip patch'i yayınlanan zevkli bir debugging serüvenini karalamaya başlıyorum. Hazır izindeyim bari bu sözümü tutayım. Daha böyle çok serüven var, umarım hepsini yazmayı başarırım ve birlikte eğleniriz.

Kernel Mode Driver Nedir? Nasıl Yazılır?

noreply@blogger.com (kernelturk) — Thu, 21 Jul 2011 13:57:00 +0300

Tekrar merhabalar, seneler önce merakla Windows Nt tabanlı sistemler üzerinde Kernel Mode Driver yazımı için kaynak aradığım zamanlardan rastladığım ve beğenerek takip ettiğim F-Four serisinden öğrenmiş olduğum bilgilerin ilk bölümünü arşivlerimden sizlerin huzuruna sunuyorum:

Bu makale de güncel olarak kullanılan Microsoft Windows 2003, XP, 2000, NT4.0 gibi Windows NT tabanlı işletim sistemleri üzerinde 32-Bit Assembly dili kullanılarak Kernel-Mode Aygıt sürücülerinin (device drivers) nasıl yazılacağı anlatılacaktır. Windows 95/98/ME versiyonları için VxD sürücüleri geliştirmek ise bu makalenin alanı dışındadır. Muhtemelen size aktardığım bilgilerde bazı konsept farklılıkları ve kişisel hatalar yapabilirim.

· Mimariyi Tanıyalım

Ana Sistem Bileşenleri

Windows NT'nin mimarisi dahili olarak code denetimi (code permissions) ve adres boşluğu (address space) olarak iki kısma ayrılmıştır. Bu ayırım işlemi ile daha güvenli ve daha esnek bir işletim sistemi oluşturulması amaçlanmıştır. Ayrıca programcılar içinde yeni nesil işlemcilerin tüm yeteneklerinin kullanılması amaçlanmıştır. İşletim sistemi üzerinde çalışacak her programın çalışması için bir hafıza alanına ihtiyacı vardır. Bu alanlar işletim sistemi tarafından adres boşluklarının organize bir şekilde yönetilmesi ile uygulamalara paylaştırılır. Adres boşluğunun paylaşımı ise sanıldığının aksine basit bir mantığa dayanmaktadır. 32-Bit işlemci mimarisinde Adreslenebilir 4GB hafıza iki eşit parçaya ayrılır (tabi burada Fiziksel Adres açılımı olan PAE desteğini yok sayıyoruz) ve bu iki parçadan kullanıcı modun'da (user-mode) olana bu boşluğun en düşük alanı olan 00000000 - 7FFFFFFFh adresleri arasındaki 2GB'lık alan verilir. Yani User-Mode dediğimiz user process'leri bu hafıza alanında çalışır ve bu onlar için bir sınır değerdir. Diğer kalan üst limit 80000000 - 0FFFFFFFFh 'lik doğrusal hafıza alan adresi oranı ise aygıt sürücüleri (device drivers) , sistem hafıza havuzu (system memory pools) ve sistem data yapıları (system data structures) gibi sistem bileşenlerine verilir. Bu adres oranlarına adreslenebilir hafıza alanları diyoruz. Bu hafıza alanları arasındaki ayrım ve yönetim işlemlerini ise hangi bileşenlerin kontrol ettiğini makalenin ilerleyen kısımlarında ayrıntılı bir şekilde işleyeceğiz.

User-mode'da çalışan temel işlemleri aşağıdaki şekilde tanımlayabiliriz:

Sistem Destek İşlemleri (System Support Processes) - örneğin, Logon process'i (\%SystemRoot%\System32\Winlogon.exe dizininde yer alır);
Hizmet İşlemleri (Service Processes) - örneğin, Yazıcılar için Spooler servisi (\%SystemRoot%\System32\spoolsv.exe'da yer alır);
Kullanıcı uygulamaları (User Applications) - beş çeşittir: Win32, Windows 3.1, MS-DOS, POSIX ve OS/2;
Ortam AltSistemleri (Environment Subsystems) - Windowsta üç çeşit ortama ait processleri çalıştırabilirsiniz: Win32 (\%SystemRoot%\System32\Csrss.exe yer alır); POSIX (\%SystemRoot%\System32\Psxss.exe'yer alır); OS/2 (\%SystemRoot%\System32\Os2ss.exe yer alır).

Windows XP ile birlikte artık OS/2 alt sistemi kaldırılmıştır.

Kernel-Mode bileşenleri ise aşağıdaki gibi tanımlanabilir:

Yönetim (Executive) - hafıza yönetimi, process ve thread yönetimi, security, etc.;
Kernel - thread'ların planlanması, kesme isteği(interrupt) ve istisna işleme (exception dispatching), etc. (Executive ve Kernel \%SystemRoot%\System32\Ntoskrnl.exe tarafından icra edilir);
Aygıt Sürücler (Device Drivers) - Donanım aygıt sürücüleri (hardware device drivers), dosya sistemi sürücüleri (file system) ve ağ sürücüleri ( network drivers);
Donanımdan soyutlandırma katmanı (Hardware Abstraction Layer), HAL - Kernel'den aygıt sürücülerden yönetim biriminden ve platforma özel donanım farklılıklarından yalıtılmış bir birimdir. ( \%SystemRoot%\System32\Hal.dll'de yer alır);
Pencere ve Grafik sistemi (Windowing And Graphics System) - Pencerelerle çalışmak, kullanıcı arayüz kontrolleri ve çizim (drawing) işlemleri ile uğraşmak için grafiksel kullanıcı arayüzü (Graphical user interface [GUI]) fonksiyonları sağlar. ( \%SystemRoot%\System32\Win32k.sys'de yer alır).

1.1.2 Kernel Mode vs. User Mode

Aslında Intel x86 işlemcileri 4 adet imtiyaz seviyesi (privilege levels) sağlar (ring olarakta anılırlar) , ancak Windows bunlardan sadece 2 sini kullanır. Bunlar Kernel-Mode için privilege levels 0 (veya ring0) , user-mode için ise privilege levels 3 (veya ring3) seviyesidir.

Her user-mode processi kendine ait özel bir hafıza boşluğuna sahiptir. Processler en düşük imtiyaz seviyesinde (user-mode veya ring 3 diyebilirsiniz) çalıştıklarından, özel cpu komutlarını icra edemez, sistem data'ları ve sistem adres boşluğuna erişim sağlayamaz ve donanıma doğrudan erişim yapamazlar. Örneğin user-mode'da çalışan bir process adres boşluğunun kernel-mode tarafına ait bir orandaki hafıza adresine (8000000-0FFFFFFFFh) ulaşmaya çalışırsa, sistem o işlemi hemen sonlandıracaktır. User-Mode processleri sistem servislerini çağırarak kernel-mode'a geçiş yapabilirler ancak bu durum o hizmete yaptırılan işlemlerle sınırlıdır ve process user-mode'a döner dönmez tüm kontrolü tekrar kaybedecektir.

User-Mode processleri sistem stabilizesini bozabileceklerinden potansiyel tehlike olarak görünürler. Bu yüzden sahip olduğu imtiyazlar sert çizgilerle belirlenmiştir ve yetkisizce yapmaya çalıştığı her işlem anında sonlandırılır.

Kernel-Mode bileşenleri ise kernel-mode hafıza alanını ortak bir şekilde paylaşırlar, en üst imtiyazlarla (ring0) çalışabilir ve istedikleri CPU komutunu çalıştırabilirler. Kısacası erişimleri sınırsızdır.

Sistemin adres boşluğunda çalışan kodlar tümüyle güvenilir olarak düşünülür. Bir sürücünün yüklenmesi esnasında sistem o sürücü kodlarını kendi bölümüymüş gibi varsayar. Driver'lar kernel'in kendi güvenilir bileşenleri listesinde yer aldığından istediği her erişimi sınırsızca yapabilir.

Tam olarak ifade edersek user-mode uygulamaları işletim sistemi tarafından bütünüyle soyutlanmıştır. Aslında bu işletim sisteminin bütünlüğü açısından iyidir, fakat , debugging araçları gibi bazı yardımcı araçların için tam bir baş ağrısıdır. User-Mode uygulamaları ile sistemle bütünleşik bir yazılım gerçekleştirmek çoğu zaman imkansızdır. İşletim sisteminin dahili fonksiyonları ve data yapıları'na user-mode'dan asla ulaşamazsınız bunun için yapmanız gereken sistem adres boşluğunun içerisine girmektir buda kernel-mode düşerek olur.

Windows NT Device Drivers

1.2.1 Aygıt Sürücülerinin Tipleri

Windows NT geniş bir yelpazede aygıt sürücü tiplerini destekler, bunları aşağıdaki gibi listeleyebiliriz:

User-Mode Drivers:

Virtual Device Drivers (VDD) - 16-bit MS-DOS uygulamalarını emule edebilmek için kullanılan bir user-mode bileşenidir. Karıştırmayasınız diye yazıyorum Win 9x zamanı VxD'lerle benzer bir yanları yoktur.
Printer Drivers - Aygıttan bağımsız baskı isteklerini yazıcıya özel komutlara çevirirler.

Kernel-Mode Drivers:

File System Drivers - Standart dosya sistem işlemlerini yerine getirirler.
Legacy Drivers - Windows 2000/XP/2003 üzerinde değişmemiş ama önceki Windows NT versiyonları için yazılmış farklı sürücülerden yardım almaksızın bir donanım aygıtını kontrol etmeye yarayan sürücü çeşididir.
Video Drivers - görsel data işleme;
Streaming Drivers - ses ve tv kartı gibi multimedia aygıtları içindirler;
WDM-Drivers - Windows Driver Model konseptine bağlıdırlar. WDM; Windows NT'nin güç yönetim desteğini ve tak çalıştır desteğini destekler. WDM'ler işletim sistemleri arasında binary uyumlulukları sayesinde kaynak-uyumu sağlarlar. Örneğin Windows 2000 için yazılmış bir WDM driver Windows Me ve 98 üzerinde çalışabilir.

Bunlardan farklı modellerde vardır ancak şimdilik bu konsepti tanımanız açısından yeterlidir.

Adlarında da gayet net anlaşılacağı gibi aygıt sürücüler bir aygıtı kontrol etmek için kullanılırlar. Ancak iyi bir tarafları vardır ki bu aygıt illa ki fiziksel bir aygıt olmak zorunda değildir. Dilerseniz sanal bir aygıt oluşturup onu programlayabilirsiniz.

Yapısal olarak aslında aygıt sürücüleri bir PE-format (Exe) dosyasından başka bir şey değildir. Aygıt sürücüler (Device Drivers) yüklenebilir kernel-mode modülleridirler. Genel olarak .sys uzantılarına sahiptirler. Aygıt sürücüler yükleme ve yönetim açısından bütünüyle farklı yollara sahiptirler. Gerçekte kernel-mode dll'leri user-mode tarafında çözülemeyecek görevleri yerine getirilmesi için tasarlanırlar. Bir de şu var ki biz user-mode processlerimiz ile aygıt sürücülerimizin ne kod ne de data alanlarına ulaşamayız. Bizim sürücülerimizle irtibat kuracağımız tek yol I/O Yöneticisi (I/O Manager)'dir.

Kernel-mode aygıt sürücüsü geliştirme aşamasında kendinizi bütünüyle çaylak hissedecek ve aslında önceden öğrendiğiniz onca programlama ve Win32API bilgisinin şimdi nasıl olup ta size yardımcı olamadığına şahit olacaksınız. Belki bundan önce hatırı sayılır user-mode uygulamaya imza atmış olabilirsiniz ancak kernel-mode mimarisinin komutları ve yapıları bütünüyle farklıdır.

· Katmanlı ve Monolithic (Tek-Katmanlı) Aygıt Sürücüleri

Katmanlı sürücülerin çoğu fiziksel aygıtları kontrol etmek için yazılırlar. Adlarından gayet net anlaşıldığı gibi katmanlı sürücüler drivers stack olarak ta anılan bir konseptle en alt katmandaki sürücülere en üst katmandan aldıkları istekleri işleyerek veya bunun tam tersini yaparak çalışırlar. Bu mimaride I/O isteklerinin işlenmesi (handling request) görevi farklı sürücüler arasında dağıtılmıştır. Örneğin sabit disk üzerindeki bir dosyayı okumak isteyen uygulama’nın i/o istekleri önce dosya sistem sürücüsüne geçirilecek, oradan da disk sürücüsüne yönlenecek ve disk üzerinde veriyi okuyacaktır. Driver geldiği katmansal yolun tam tersini işleyerek veriyi uygulamaya ulaştıracaktır. Dilerseniz sizde bu katmansal mimarinin herhangi bir yerinde araya girerek filter-driver yazabilir , gelen ve giden veriyi encrypt/decrypt gibi şifreleme işlemlerine tabi tutabilirsiniz.

Monolithic driver ‘lar ise aygıt sürücülerin en basit tipleridirler. Yine adlarından anlaşılacağı gibi katmansız bir mimarileri vardır ve layered modeldeki gibi diğer driver’lar ile i/o işleme konusunda herhangi bir paylaşım yapmazlar. Sık olarak doğrudan user-mode uygulamalarına tek başlarına arayüz olarak destek vermeleri gerektiklerinde yazılırlar. Geliştirme ve debugging hizmetleri ise tanımlanabilir en basit görevleridir. Zaten makalenin ilerleyen kısımlarında böyle bir driver yazacağız ve ne anlatmak istediğimi daha iyi anlayacaksınız. Diğer aygıt sürücüsü kategorileri ise şimdilik yazımızın kapsamı dışındadır.

· Thread context

Çoğu durumda yalnızca tek bir işlemciye sahip olduğumuz için, sistemin uygulamaları icra ediş şekli bizi hep bu işlemlerin aynı anda oluyormuşcasına izlenimine sokar. Çalışan tüm uygulamalar için işletim sistemi cpu zamanını herbir processin thread’ları için ayrı ayrı dilimlere ayırır. Cpu tek bir kaynaktır ve bu kaynağı işlemlerin sırası ile kullanabilmesi için Round-Robin denen algoritma kullanılır. Bu teknik sayesinde cpu ile olan işi kendine verilen quantum sürelik zamanı aşmasına rağmen bitmeyen bir thread’ın o anki tüm çalışma bilgileri bir yapıya geçirilip (CONTEXT) makine durum registerleri (msr)’lere saklanır ve sonraki thread’a geçilir. Tabi bu teknik aslında çok daha kompleks işlerde yapar ama şimdilik bunlar bizim için yeterlidir. Birde fiziksel olarak işlemcilerin 1’den fazla olduğu durumlar vardır ki o zaman thread scheduling işlemi daha da karmaşık bir hal alır. Böyle bir yapıda thread’lar çekirdekler arası yük paylaşımına sokulur ve işletim sistemi çok daha gelişmiş kompleks algoritmalar kullanarak yönetim yapar. Thread’lar arası geçişte eğer bir sonraki çalışma sırası gelen thread aynı uygulamaya ait bir thread ise , işlemci tarafında sadece yukarıda tanımlamasını yaptığım basit bir thread context gerçekleşir. Lakin geçiş yapılan thread farklı bir process’e ait bir thread ise , işte o zaman hem bir “thread context switch” hemde işlemcinin CR3 register’inin içerisine o processe ait page table yüklenir.

Her kullanıcı işlemi (user process) kendine ait özel bir adres alanına sahiptir. Bu da şu demektir ki : her user process’i sayfa tablolarını (page tables) farklı sayfa dizinlerinde (page directory) tutar. Sayfa tabloları (page tables) sanal (virtual) adresleri fiziksel adreslere çevirmek için işlemcinin kullandığı tablolardır. Bu tabloları hazırlamak işlemcinin sorumluluğundadır ve her process’te mutlaka olmalıdır. İşlemci context’ine girdiği thread’in cr3 register’inada bakarak kullanacağı hafıza alanını tespit eder ve hafıza alanından faydalanmasını sağlar. Aslında kernel-mode’da driver yazarken bu işlemlerle bizim doğrudan bir etkileşimimiz yoktur. Fakat her context switch cpu israfına neden olduğundan driverlar genellikle kendileri thread olusturmazlar . Bu yüzden context switch’ler esnasında CPU zamanından tasarruf edebilmek için kernel-mode’da çalışan driver’lar üç çeşit context’ten birini kullanır:

· Kullanıcı thread’inin context’in de bir I/O işlemi ile birlikte ;

· Kernel-mode sistemi bağlamındaki threadlar olarak;

Veya bir interrupt vasıtası ile .

· Kesme isteği seviyeleri

Kesmeler (interrupts) her işletim sisteminin de bulunan en önemli kısımlardandır. Her kesme oluştuğunda işlenmesi gerekir ve bu yüzden işlemci bir kesme oluştuğunda o anki normal akışını durdurur ve kesme'yi ilgilendiren koda dallanır. Yazılımsal ve Donanımsal olarak iki tip kesme vardır. Kesme'lere önceliklerine göre hizmet edilir. Düşük önceliğe sahip bir kesme akışına devam ederken, sonradan gelen yüksek öncelikli bir kesme bu akışı durdurup akışı ele geçirebilir.

Windows kesmelerin öncelik şemasını kesme isteği seviyeleri (interrupt request levels[IRQL]) olarak bilinen bir sistemle yönetir. Kernel IRQL'leri 0 dan 31'e kadar olan bir öncelik sırasına göre sıralar. Bu seviyelerden en yüksek duruma sahip olan en imtiyazlı interrupt olarak bilinir. Unutmadan belirtmeliyim ki IRQL imtiyaz seviyeleri ile işleç-programlama (thread-scheduling) arasında farklılıklar vardır. Bu yüzden birbirleri ile karıştırmayın.

Yukarıda ki tanımlamalarımıza göre IRQL=0 'a sahip bir kesme aslında bir kesme olayı başlatıp bir kodun akışını kesmez. Yani açıkçası aslında zaten o bir kesme değildir. User-Mode'da çalışan her thread passive level'de yürütülür. Bizim yazacağımız kodlarda bu IRQL seviyesinde olacaklardır. Böylelikle yazdığımız kodlar, başka akışların yarıda kesilmesine sebebiyet doğurmayacak. Tabi bu demek değildir ki her driver passive level de çalışacak. Bu sadece bizim örneklerimiz için geçerlidir.

Son olarak şunları belirtmekte fayda var:

Birincisi: Sürücü kodlarını icra ederken daha yüksek IRQL'le sahip bir işlem tarafından her zaman için akışı kesilebilir. Sürücü içersinde kod işleme aşamasında güncel IRQL seviyenizi öğrenebilir ve işleminizin yarıda kesilmemesi gereken kod bloklarında IRQL seviyenizi arttırabilir ve azaltabilirsiniz.

İkinci olarak: Passive IRQL seviyesindeyken bile her kernel fonksiyonunu çağırabilirsiniz. (Ayrıca DDK her fonksiyon için istenen IRQL seviyesini belirtmiştir). Ayrıca sayfalı(paged) ve sayfasız(nonpaged) adresleme yapabilirsiniz. Hafıza Yöneticisi sayfa hatası (page fault) hizmetleri açısından yetersiz kaldığından yüksek bir IRQL'de (DISPATCH_LEVEL veya daha yüksek (15-31 arası mesala)) paged bir hafıza alanına erişmeyi denerseniz sistemin çökmesine sebep olursunuz.

· Sistem Çökmeleri

Daha önce hiç rastlamadım demeniz mümkün değil! Neden mi bahsediyorum? Tabi ki Meşhur Mavi Ekrandan (BSOD[Blue Screen of Death]). Muhtemelen hepte hiç beklemediğimiz bir anda ansızın karşımıza çıkmıştır. Ama onu uzun süredir göremiyorsanız üzülmeyin, çünkü kernel-mode'da driver yazarken kendisi ile bol bol haşır neşir olucaz :)

Windows kermel-mode 'da çalışan sürücüler tarafından kullanılan özel sistem hafızasını korumak için herhangi bir koruma işlemi yapmaz. Driver kernel-mode'a bir kere kancayı attımı artık tüm işletim sistemi dataları ve sistem hafıza alanı onun için serbest bölgedir. Bu yüzden driver'imizi kodlarken önceden planlı bir yapılanma izleyip sistem stabilitesini tehlikeye atmamamız şart.

Artık yukarıda anlatılanları iyice kavramanız şart. Şayet sizde kernel-mode'da bir driver'da benim olsun diyenlerdenseniz thread context, interrupt request levels, kernel-mode ve user-mode etc... gibi kavramlara mutlaka aşina olmak zorundasınız.

· Driver Development Kit

Windows DDK ile aygıt sürücü geliştirme aşamasında ihtiyacımız olan tüm dahili sistem rutinleri ve data yapılarına erişebiliriz. Windows DDK, MSDN Profesyonel üyeliliğinin bir parçasıdır. Dilerseniz http://msdn.microsoft.com 'dan online olarak dokümantasyonlara erişebilir ve eğer Türkiye'de iseniz sembolik ( kızmayın :p ) bir ücret ödeyerek kargo ile microsoftun size gerekli kütüphane ve örneklerle komple kiti göndermesini sağlayabilirsiniz.

· MASM programcıları için Kernel-Mode Driver Kit

KmdKit sizin assembly dilinin gücünü ve Masm32 compiler'inin yeteneklerini birleştirerek aygıt sürücüleri yazabilmenizi sağlayacak alt yapıyı oluşturur. İndirmek için lütfen tıklayın :

http://www.freewebs.com/four-f/KmdKit/KmdKit.zip

· Driver Debugging

Yazdığımız kernel-mode sürücülerini yine kernel-mode'da çalışacak debugger'lar vasıtası ile analiz edebiliriz. Bunun için en ideal araç ve tercihim Compuware firmasının Driver Studio ürünüdür. İçerisinde barındırdığı güçlü debugging yetenekleri ve sembol dosyası desteği ile daha boot aşamasından itibaren kernel'i ve yükleme aşamasından itibarende driver'larımı ayrıntılı olarak debug etme fırsatımız oluyor. Ayrıca birde microsoftun ücretsiz WinDbg ürünü var. Şayet iki pc'niz var ise diğer pc'nin kernelini adım adım yükleyebilir ve tüm sistemi tam anlamı ile kontrol edebilirsiniz. Birde ünlü SysInternals ekibinden Mark Russionovich'in yazdığı tool'u kullanarak windbg ile ikinci bir pc'ye ihtiyaç duymadan live debuging yapabilirsiniz.

Faydalı kaynaklar

David Solomon, Mark Russinovich, "Inside Microsoft Windows 2000. Third Edition", Microsoft Press, 2000

Aygıt sürücü yazarları ve adayları için bir numaralı kaynak. Bu kitabı okuyarak benim iğrenc makalemi okumak zorunda kalmayabilirsiniz :}

Sven B. Schreiber, "Undocumented Windows 2000 Secrets. A Programming Cookbook", Addison-Wesley

Bu da baş ucu eseri olma niteliğinde Win2000 neredeyse tüm gizliliklerini ifşa etmiş bir eser.

Walter Oney, "Programming the Microsoft Driver Model", Microsoft Press, 1999

Walter'in anlatımı çok ağır ve zaten karmaşık olan bir konuyu iyice zorlaştırmış ama yinede okunması gerekir

Walter Oney, "Programming the Microsoft Windows Driver Model. 2nd edition", Microsoft Press, 2003

İşte bu diğerine 5 basar. hem anlatım sadeleşmiş hemde plug-in-play hiç bu kadar kolay anlatılmamıştı..

Art Baker č Jerry Lozano, "The Windows 2000 Device Driver Book, A Guide for Programmers, Second Edition", Prentice Hall, 2000

Bunu okumadım ama referansı iyiye benziyor ve konumuzla tamamen alakalı olduğundan buraya yazdım

Rajeev Nagar, "Windows NT File System Internals. A Developer's Guide", O'Reilly

Bu kitap varken bu makaleyi yazmamalıydım :)

Prasad Dabak, Sandeep Phadke, and Milind Borate, "Undocumented Windows NT", M&T Books, 1999

Gary Nebbett, " Windows NT-2000 Native API Reference", MacMillan Technical Publishing, 2000
Jeffrey Richter, "Programming Applications for Microsoft Windows. Fourth Edition", Microsoft Press, 1999

Serinin ikincisinde görüşmek üzere...

Stuxnet hakkında herşey

noreply@blogger.com (kernelturk) — Mon, 20 Jun 2011 11:47:00 +0300

Blogu bu aralar ziyaret edenlerin çoğu stuxnet cümlesini kullanmışlar. Bende ziyaretçilerin elini boş göndermemek için bir derleme yaptım. Aşağıda ki doküman ve videolar bu konudaki tüm soru işaretlerini silecektir diye umuyorum.

Analyzing a Stuxnet Infection with the Sysinternals Tools, Part 1

Analyzing a Stuxnet Infection with the Sysinternals Tools, Part 2

Stuxnet is embarrassing, not amazing

Stuxnet hakkında yapılmış belgesel tadında bir video:

Stuxnet: Anatomy of a Computer Virus from Patrick Clair on Vimeo.

Stuxnet, kısacası; ileri reverse engineering ve çalıştığı mimariye ait derinlemesine assembly bilgisi olanlar için yapılabilirilitesi gayet mümkün olan bir iş.

Windows'un Evrimi (Video)

noreply@blogger.com (kernelturk) — Mon, 7 Mar 2011 21:00:00 +0200

Windows işletim sisteminin Dos 5.0'dan Windows 7'ye kadar çıkmış tüm sürümlerinin hızlıca ve sade bir dille anlatıldığı çok hoş bir çalışmayı paylaşmak istedim.

Microsoft: Command Prompt vulnerabilty

noreply@blogger.com (kernelturk) — Tue, 11 Jan 2011 22:36:00 +0200

2006 yılında Windows 2003 Server ve Windows Xp client'larında keşfettiğim ve ne yazık ki Windows 2008 R2 Server ve Windows 7 x64 sistemlerde aynen devam eden Command Prompt(Cmd.exe) zayıflığı halen varlığını sürdürmekte. Bir hexeditor veya Excel makro çalıştırma hakkınız var ise Cmd.exe'yi yazma yetkiniz olan bir alana kopyalayıp içerisindeki DisableCMD satırından sadece tek bir karakteri değiştirmeniz command prompt kısıtlaması policy'sini etkisiz hale getirmenize yetecektir.

Bu açıklığı PoC ile gösteren bir macroyu da o seneler ilk acemi deneyimim olan camtasia screen record ile zabıt altına almıştım . İzleyip gülmeyelim lütfen :

Yeni eğlencemiz: Binary Planting

noreply@blogger.com (kernelturk) — Sat, 11 Sep 2010 20:20:00 +0300

Bu aralar vulnerability keşiflerinde gözle görülür bir artış var ve sebebi menba-ı da yine malum windows mimarisi. Mailime her gün dll injection vuln reportları geliyor ve tümünün origin'i de Binary Planting. Win32 Sistem programcılığı yapmış olanlar iyi bilirler ki uygulamanızda export edip nimetlerinden faydalandığımız bir dll'i (ör: dwmapi.dll, secacc.dll ...) LoadLibrary api si ile kullanmak istediğimizde işletim sistemiz bu kullanılmak istenen dll dosyasını safe search list algoritmasına göre şu şekilde arar:

LoadLibrary library arama öncelikleri :

1 - Uygulamanın çalıştırıldığı dizin
2 - 32-bit Sistem dizini (Windows\System32)
3 - 16-bit Sistem dizini (Windows\System)
4 - Windowsun kurulu olduğu dizin (Windows)
5 - Çalışma dizini
6 - Ortam değişkenlerinde PATH ile belirtilmiş olan dizinler

Sanırım her şey gayet net ve açık. Eğer bir uygulamanın bu şekilde zaafiyetini kullanmak istiyorsanız rolünü almak istediğiniz dll dosyasının fonksiyonlarını memory inject etmek yerine o dll'in manipüle ettiğiniz halini zehirlemek istediğiniz uygulamanın kurulu olduğu dizine kopyalamanız kafi gelicektir. Kısacası yine bir microsoft mimarisi hatası. Ki olay sadece LoadLibrary ile bitmiyor ve ne yazık ki CreateProcess, LoadModule, WinExec, ShellExecute gibi api'ler için aynı senaryo geçerli.

Zaafiyetin tüm güncellemeleri almış bir sistemde nasıl işlediği ile alakalı bir görseli aşağıdaki linkten izleyebilirsiniz:

http://core.yehg.net/lab/pr0js/advisories/dll_hijacking/flash_player/poc/movie/flash_player_ie_10.x_dll_hijacking_vuln.mp4

Daha ayrıntılı zaafiyet açıklaması ve microsoftun çabaları için aşağıda ki linkleri ziyaret edebilirsiniz:

http://blog.acrossecurity.com/2010/09/binary-planting-goes-exe.html

http://support.microsoft.com/kb/2264107

Biraz nostalji: Masm32 ile ilk çırpınışlar

noreply@blogger.com (kernelturk) — Wed, 8 Sep 2010 23:03:00 +0300

Sene 2002, çalıştığım şirkette gece vardiyalarında bol boş vakit den kaynaklanan zaman aralıklarını faydalı bir şeylerle değerlendireyim derken tanıştım masm32 ile. Icezelion'un müthiş win32 serisini bir çırpıda okuyup yaklaşık 24 step'lik tuts larınıda example'ları ile yuttuktan sonra ilk denememi yapayım demiş ve aşağıdaki acaip şey ortaya çıkmıştı :) Arşivimden bir mp3 cutter ararken rast geldim ve paylaşayım istedim:

;Writed by StreAmeR 10.10.2002 bilgislem@hotmail.com
.386
.model flat,stdcall
option casemap:none

WinMain proto :DWORD,:DWORD,:DWORD,:DWORD

include \masm32\include\windows.inc
include \masm32\include\kernel32.inc
include \masm32\include\user32.inc
includelib \masm32\lib\kernel32.lib
includelib \masm32\lib\user32.lib

@UzunlukAl MACRO
push edi
mov edi,esi
xor al,al
xor ecx,ecx
scasb
pushf
inc ecx
popf
jnz $-6
mov konum,edi
pop edi
ENDM

@SatirAtla MACRO
dec edi
mov al,0ah
stosb
mov al,0dh
stosb
ENDM

asd proto :DWORD

.data
baslik db "GetEnvironmentStrings&Assembly Example",0
hata db "Hata",0
konum dd 0

.data?
hHandle HWND ?
buf db 512 dup(?)

.code
start:
invoke GetEnvironmentStrings ; Programın işletim sistemi tarafından otomatik olarak tanımlanan ortam değişken tablosuna pointer al

mov hHandle,eax ; Pointer'i sakla
mov edi,hHandle ; Pointer üzerinde işlem yapabilmeniz için bir kopyasını edi'ye çekiyoruz

; Ortam bilgisinin hafızada yer alan bilgisinin tümünü tarayıp bitis noktasini aliyoruz

; ------------ Pointerin sonu Bir sonlandırıcı 00 ve iki bitiş 00 00 ile bitiyor. Biz bu değişken tablosunun sonunu bulmalıyız
push edi ; Pointer'in base adresini stacke atıyoruz
xor ax,ax ;
scasw
jnz $-2
dec edi
mov edx,edi ;Yapının son adresini edx'e alıyoruz

;İlk bilgi yapısını alıyor ve geçersiz olduğundan dolayı tamponumuza almıyıp bize gecerli olan adresi isaretlemesini sağlıyoruz
pop edi
xor al,al
xor ecx,ecx
scasb
pushf
inc ecx
popf
jnz $-6

lea edi,buf
push edi
mov esi,hHandle
xor al,al
rep movsb
pop edi
push edi
mov ecx,20
xor al,al
rep stosb

@UzunlukAl

lea edi,buf ;tampon
rep movsb
@SatirAtla

@UzunlukAl
rep movsb
@SatirAtla

mov konum,edi
.while konum!=edx
@UzunlukAl
rep movsb
@SatirAtla
.endw

invoke MessageBox,NULL,ADDR buf,addr baslik,MB_OK

invoke FreeEnvironmentStrings,hHandle
invoke ExitProcess,NULL
ret

end start

Sadece 1K ile neler yapılabilir

noreply@blogger.com (kernelturk) — Tue, 7 Sep 2010 16:06:00 +0300

Çoğunuz duymuşsunuzdur JS1K.com adlı site geliştiricilerden 1K sınırını aşmaksızın javascript ile etkileşimli projeler geliştirmesi için bir yarışma başlattı. Bir şeyler karalayıp gönderdim ama oradaki diğer parlak fikirleri görünce geri çekilesim geldi :) Örnek: pleaseDontHotlinkMe

Windows 7 x64 için Rootkitler MBR ile geri mi dönüyor?

noreply@blogger.com (kernelturk) — Wed, 1 Sep 2010 14:34:00 +0300

Windows'un ne yapsa bir türlü kurtulamadığı Kernel taraflı açıklarına karşı geliştirdiği yeni nesil koruma sistemlerine uzun zamandır pratik bir çözüm bulunamamıştı! Ramazan ayının da verdiği rehavet ile internet'te boş boş dolaşırken http://www.prevx.com/blog.asp adlı bloga rastladım. Arkadaşlar gayet akılcı ve ince bir yol ile Windows 7 x64 sistemleri üzerinde KMCS(Code Singing) ve KPP (patch protection) korumalarını atlatmayı başarmışlar. Mantık kısaca MBR üzerinden windows'un başlangıç parametrelerini manipüle ederek bu korumaları devre dışı bırakmaktan geçiyor. Seneler önce sistemde kalıcı olarak bulunabilmek/zarar verebilmek için virüsler tarafından kullanılan mbr alanı x64 mimarisi ile yeniden gündemde. Umarım ortalığın hareketlenmesine biraz olsun yardımcı olur.

Sağlıcakla.

McAfee VirusScan Enterprise 8.7.0i sonlandırma açığı

noreply@blogger.com (kernelturk) — Wed, 1 Sep 2010 10:03:00 +0300

Her ne kadar Windows taraflı güvenlik yazılımları sektörüne zorunlu bir Unix-Linux macerası yaşıyor olmam sebebi ile ara vermiş olsam da, kötü güvenlik politikaları coder'i deneyim sahibi yapar sözüne istinaden yine bir açıkla karşınızdayım.

Şirketimiz için bir Network Analyze uygulaması yazmış ve deploy edilmesi için Visual Studio'nun publisher'ini kullanmıştım ancak her kurulum denememde inatla herhangi bir uygulamaya özel hata almadan sadece autorun.inf dosyasının execute olmasını engelleyen bir windows hatası ile karşılaşıyordum ve kısa bir bakıştan sonra buna neden olanın yeni satın almış olduğumuz McAfee VirusScan Enterprise olduğunu öğrendim. Hemen ilk aklıma geleni yani uygulamayı disable etmeyi denedim ancak şifre soran bir ekran ile karşı karşıya kalmıştım. Antivirüsün deployunu başka bir arkadaşım yaptığından parolayı da bilen oydu ve ne yazık ki o sırada ona ulaşmıyordum. Sırası ile service'i stop etmeyi ve terminate attack'larla sonlandırmayı denedim ama mcafee bunlara hali ile önlem almıştı. İşin benim için eğlendirici tarafı da o sırada başlamıştı.

Her nasıl olduysa genelde en son denediğim şeylerden birini, heap memory'ye müdahale etmeyi hemen denedim ve kernel taraflı ana processin kullandığı kendine ait en yüksek boyuta ait private alana ntdll.dll dosyasından export edilen virtualmemory fonskiyonları ile müdahele ettim ve sonuç mcafee ye ait ana sistem koruma bileşeni sonlanarak host sistemi savunmasız hale getirdi. Böylece bende uygulamamı rahatlıkla kurabildim :)

Açığı geçtiğimiz hafta McAfee yetkililerine bir PoC ile bildirdim. Halen bir feedback alamadığımı da ayrıca belirtmek isterim. İlgisizliklerine göre bir zaman aralığında kodu sizlerle paylaşmayı düşünüyor iyi günler diliyorum.

Kendime Not: Outlook 2010 crash problemi

noreply@blogger.com (kernelturk) — Tue, 17 Aug 2010 16:29:00 +0300

Outlook 2010 kullanan ve kişisel klasörünü(personel folder yada pst) varsayılan teslim kutusu olarak seçen kullanıcılarda Outlook'u her açış denemesinde uygulama dump olup sonlanıyor. Microsoft halen açılan caselere çözüm arıyo dursun ben bulduğum çareyi sizlerle paylaşayım:

Sorun kişisel klasör dosyasınızda bulunan junk mail klasörüne güvenli gönderici listesi(safe sender list) kullanıldığı durumlarda vuku buluyor. Ida ile baktığımda
her defasında bu fonksiyonda hata veriyordu. Kullandığı registry yolu ise şöyle:

HKCU\Software\Policies\Microsoft\Office\14.0\outlook\options\mail

Bu yoldaki "JunkMailImportLists" anahtarının değerini "0" yaparak outlook'u problemsiz bir şekilde çalıştırabiliyoruz.

Kendime Not: Ntlmv2 ile mount işlemi

noreply@blogger.com (kernelturk) — Tue, 29 Jun 2010 12:05:00 +0300

Kısa bir zaman önce ldap güvenliğinde ntlmv2 şifreleme yöntemine geçtik ve bu yüzden eski basit mount işlemlerimiz işlev görmez hale geldi. Aşağıdaki komut ile başarı ile paylaşımlarınıza bağlanabilirsiniz:

[root@localhost /]# mount -t cifs //serveradi/paylasimadi /mnt/dizinadi --verbose -o sec=ntlmv2,user=domainuseradi,pass=parolasi,domain=DOMAINADI

Kendime Not:Esx Server Root parolasını Resetleme

noreply@blogger.com (kernelturk) — Mon, 28 Jun 2010 12:16:00 +0300

Grub ekranındayken editing moda geçiyor ve son satırı single olarak değiştirip multimode'un dışında çalışacağımızı belirtiyoruz ardından düştüğümüz cli'dan passwd ile parolamızı değiştiriyor ve projemize kaldığımız yerden devam ediyoruz. Aşağıda bu adımların görsel temsilleri yer almaktadır.

Bu aşamada önünüze gelen 4 adet seçenekten "kernel /vmlinuz...." ile baslayan satırı bulup "e" tuşuna basarak komutu özelleştirme işlemine geçiyoruz ve çıkan ekranda son satırda yer alan "quiet" kelimesini silip "single" yazıyoruz:

Bu aşamada Esc ile ana menüye dönüp "b" tuşuna basıp sistemi bu parametre ile boot ediyoruz. Ve işlem bitiminde bizden komut bekleyen shell'e passwd komutunu giriyoruz:

Kendime Not: Openfire Ldap Server Singing Problemi

noreply@blogger.com (kernelturk) — Fri, 28 May 2010 14:32:00 +0300

Openfire Server'ini Active Directory Simple LDAP Authentication mekanizması ile problemsiz bir şekilde çalıştıranlar yaptıkları Ldap Server Signing değişikliği ile Spark IM'lerine elvada dediler. Ldap Server Signing özelliğinin zorunlu kıldığı Digest-MD5 authentication mekanizmasını son versiyonunda bile desteklemeyen Jive Software destek forumlarında bu problemle çıkan onlarca soruyuda cevapsız bırakıyor.

Sorunu yine geçmişte uğraştığım Reverse engineering tekniklerine borçlu olarak çözümlemeyi başarabildim ve iğrenç anlatımımla sizlerle paylaşıyorum:

OpenFire ile Windows 2008 Server R2 Ldap Signing Problemi

Problem: Openfire kurulumu LDAP authentication aşamasını geçemiyor, kurulum tamamlanamıyor.

Sebep: Openfire’ın son sürümü dahil (Mayıs 2010 itibari ile 3.6.4) digest-md5 ve auth-int mekanizmalarını desteklenmediğinden Ldap Sign özelliğini kullanan Windows Server ailesi işletim sistemleri ile Ldap authentication başarılı bir şekilde sağlanamıyor.

Çözüm:
1) Openfire’ın kaynak kod dosyaları http://www.igniterealtime.org/downloads/download-landing.jsp?file=openfire/openfire_src_3_6_4.zip adresinden indirelerek uygun bir dizine açılır.

2) Kaynak dosyalarla proje bazlı çalışabilmek ve editing yapabilmek için http://www.eclipse.org/downloads/ adresinden Eclipse IDE’si indirilir

3) src\java\org\jivesoftware\openfire\ldap dizinde yer alan LdapManager.java ve LdapAuthProvider.java Eclipse altında düzenlemek üzere açılır.

4) LdapManager.java dosyası içinde yer alan “env.put(Context.SECURITY_AUTHENTICATION, "simple");” satırları “env.put(Context.SECURITY_AUTHENTICATION, "DIGEST-MD5");” olarak değiştirilir ve hemen alt satırına “env.put("javax.security.sasl.qop", "auth-int")”; eklenir. LdapManager.java altında bu şekilde değiştirilmesi gereken 3 yer vardır.

5) Buraya kadar yapılan aşamalarda Ldap Authentication başarılı bir şekilde sağlanır ancak OpenFire’in kullanıcı denetleme mekanizması halen simple methodu ile distinguished query yaparak çalıştığından bunu iptal etmeliyiz. Bunuda LdapAuthProvider.java dosyasında authenticate() adlı methodun manager.checkAuthentication(string, string) fonksiyonuna geçilen paramtreyi değiştirerek sağlarız.

6) Tüm bu işlemlerden sonra değişiklikleri kaydediyoruz ve derleme adımına geçiyoruz. Derleme yapabilmek için Java Se 1.5 Runtime ve Ant 1.6 veya 1.7 sürümüne ihtiyacımız var.

7) Doğru bir derleme yapabilmek için öncelikle JAVA_HOME ve ANT_HOME değişkenlerini işletim sistemimizin Ortam Değişkenleri (Environment Variables) alanına tanımlamamız lazım.

8) Derleme işlemine başlayabilmek için openfire’ın kaynak kodlarının yer aldığı klasördeki build adlı dizine command prompt penceresi ile geçmemiz gerekiyor:

9) Artık derleme işlemine geçebiliriz. Bunun için build.xml dosyasının bulunduğu dizinde ant komutunu vermemiz yeterlidir. Başarılı bir derleme işleminden sonra almanız gereken sonuç resimdeki gibidir:

10) Derleme işleminden sonra %openfire_src%\work\lib dizini altında oluşan openfire.jar dosyasını authentication sağlayamadığımız orjinal OpenFire kurulum dosyasılarını barındıran dizinedeki openfire.jar ile değiştiriyoruz

Bol dertsiz günler

Bu düzen otururmu?

noreply@blogger.com (kernelturk) — Wed, 12 May 2010 22:55:00 +0300

5 ay'ı aşkın süredir aktif sanal iletişim hayatım sekteye uğramış durumda. En büyük sebebi iş yerimdeki yeni pozisyonum ve getirdiği aşırı iş yükü. Göreve gelmemle birlikte daha ortama alışma ve yapıyı tanıma fırsatım olmadan büyük bir projenin yükü sırtıma bindi. Havacılık sektörü gibi 7/24 hizmet etme mecburiyeti bulunan bir organizasyonun IT yapısını yenilemek ve canlı tutmak gerçekten zor ve yorucu bir iş. Ekip arkadaşlarımla birlikte yeri geldiğinde geceleri yatağımızdan kaldırılarak problem çözmek de artık alışkanlık haline geldi.

Tabi bu kadar iş yükü bir çok yeni ve taze bilgiye de sahip olmama neden oldu. Özellikle en son 7 sene önce kullanıcısı olduğum Linux platformunun şimdilerde Enterprise yönetimi seviyesindeki çözümleri ve problemlerine iyice aşina oldum. Hobi olarak uğraştığım bir çok bilgi koluda (reversing, kernel debugging, code analyzing..) işimin bir parçası ve sorunların çözümlerinde yardımcı araçlar oldu. İnsanın bu kadar bilgiyi boşuna öğrenmemiş olduğu hissi gerçekten hoşuna gidiyor.

Fırsat ve zaman buldukça yaşanan gerçek problemler ve iş geliştirmelerinin süreçleri hakkında canlı senaryolar üzerinden bilgilerimi aktarmaya çalışacağım. Şimdilik sağlıcakla.

Milw0rm artık yok mu?

noreply@blogger.com (kernelturk) — Mon, 14 Dec 2009 14:19:00 +0200

Bugün tekrar aktif hayata dönme çabalarım içerisinde güncel haberleri okuma atraksiyonumu ifa ederken üzücü bir haberle karşılaştım. Str0ke nickli ünlü Milw0rm sitesinin owner'i geçirdiği kalp yetmezliği nedeni ile vefat etmiş. Haberin kaynağı her ne kadar beni pek ikna edememiş olsa da doğruluk payı ihtimalini göz ardı edemiyoruz. Malum milw0rm uzun süredir güncellenmiyordu. Umarım haber hoax çıkar ve Str0ke sevenlerini yalnız bırakmaz.

Haberin kaynağı: Milw0rm is gone

Düzeltme: Evet tahminlerim beni yanıltmadı = Milw0rm is Alive

Sanal alemde ki haberlere hemen zıplamayın'a güzel bir örnek :)

Warning: Your body is infected by A(H1N1) virus

noreply@blogger.com (kernelturk) — Tue, 10 Nov 2009 12:32:00 +0200

Söylenenler sahiden doğruymuş; bu grip denen melet hemde h1n1'li si ilaçlı 7 gün ilaçsız 1 haftada geçiyor. Önceki hafta Cuma günü beni yatağa mıhlayıp bugün itibari ile doğrulmama izin verdiği için saygıdeğer virüsümüze sonsuz şükranlarımı iletiyorum. Doğrusunu söylemek gerekirse diğer grip sendromlarının çok üstünde bir efor harcattı bünyeme. Doktor tarafından verilen ilaçlardan tutunda annemin bitkisel ilaç karışımlarına kadar onlarca şey denemem sadece bol bol uyumama neden oldu ve hala beynimdeki ve ellerimde ki uyuşukluk geçmiş değil bu yüzden imla hataları ve saçmalamalar yüzünden peşinen özür diliyorum :)

Hastalık sürecinde canımı en çok sıkan ama alışkanlıktan olsa gerek pek umursatmayan ülkemiz insanlarının ve onları bu denli bir paranoyaya sokan devlet organları ve medyanın tutumu oldu. 2 gün üst üste , gece yarıları dahil farklı saat dilimlerinde 7 kez 5 farklı hastaneye (2'si devlet 3'ü özel) girme girişimim derbi maç öncesi stat önünden farksız olan kalabalık yüzünden başarısızlıkla sonuçlandı. İnsanlar çıldırmış gibi hastahanelere akın etmişler. Bir kez hapşıran da gelmiş , gözü sulanan da. Benim gibi 41 derece ateşliler ise ya o hengamede beklemeyi tercih edecek ya da evine gidip makus kaderine razı olup yorganı üstüne çekecek.

Soranlar olabilir ! Nereden biliyorsun o virüsü taşıdığını ? diye. Tabi ki bilmiyorum ama karşılaşma fırsatı bulduğum ve 1dk lık bir görüşme şansı yakaladığım acil dokturu ile aramda geçen diyalog:

Dr House - "hımm " dereceye bakıyor "40 derece .... kaç gündür hastasın"
Ben - "bugün 4.gün ve ateşim 38.5 ile 41 arasında"
Dr House - "bulantı, ishal filan oldumu?"
Ben - "evet sanırım 18 kez istiğfra ettim ve karın kaslarım işlemez halde"
Dr House - "delikanlı işte sende kapmışsın domuzun gribini ama neyse varmı evde ilacın?"
Ben - "Evde??? İlaç ???"
DR House - "tmm " bişiler karalıyor "bunları al istrahat et"

Bende bu gribin birilerinin cebini doldurabilmek için türetilmiş bir varyant olduğunu düşünenlerdenim ve onların asla kazanmasını istemem ancak hayatınızdan vereceğiniz bir 5 gününüz yoksa gidip Sam amcanın iğnesini vurulmakta bir şık olarak önünüze çıkıyor.

Hepinize sağlıklı ve mutlu günler.

Günlükten Çıkanlar - 2

noreply@blogger.com (kernelturk) — Tue, 3 Nov 2009 10:33:00 +0200

2005 Yılının ajandasınıda buldum , sadece 8 sayfa not karalamışım ve birbirinden kopuk bilgilerden oluşuyor lakin meraklıları için güzel nimet :

- Device Driver'lar SYSTEM olark anılan özel bir context'te çalışırlar. Bunu taskmanager'da görünen SYSTEM kullanıcısı olarakta görebiliriz.

- Her Aygıt sürücüsü (Device Driver) bir Device Name tag'ı ile tanımlanır. Her sürücü kullanacağı aygıt için bir isim oluşturmalıdır.

- Sürücüler DriverEntry rutininde aygıt için DeviceObject adı verilen aygıtı tanımlayısı sistem taraflı bir nesne ve SymbolicLink adı da verilen ve aygıt adının usermode tarafında da görülebilmesini sağlyan ortak nesne yaratır. Ayrıca bazı driver'a ve aygıta özel başlangıç işlemleride yapar.

- Driver'lar fiziksel bir aygıtı kontrol etmek zorunda değildirler. Bunun yerine sadece sürücü kodu içerisinde verilen görevleride yapabilirler. Ancak unutulmaması gereken en önemli husus bu kodların ring0 denilen en imtiyazlı seviyede çalıştıklarıdır.

- Driver'lara yapılan tüm istekler birer I/O Request Packet (IRP) biçiminde yollanır. Driver, tüm sürücü istekleri için önceden DriverEntry rutininde tanımlanmış olan fonskiyon pointer'larını SYSTEM context'inde bekler.

- Tüm işlemlerin virtual address (sanal adresleri) aynı olabilir ancak fiziksel sayfaları farklı adresleri işaret eder.

- Farklı process'lerin her iki modda aynı hafıza alanını kullanabilmesi için named memory mapped file oluşturması gerekmektedir.

- ObReferenceObjectByHandle komutu belirtilen handle'in istenen erişim izinlerine uygun olup olmadığına bakar. Eğer handle'a istenilen kriterlerde erişim izni verilirse programcıya STATUS__SUCCESS durumu döner.

- 32bit işlemciler bir hafıza adresine erişirken 16bit'lik bir Segment Selector ve 32bit'lik segmentle birlikte kullanılacak offset değeri kullanır.

- Segmentlere erişim ile alakalı gerekli blgiler işlemciye segment table yoluyla aktarılır.Segment Selector, segment table içindeki bir index'tir.

- Herhangi bir anda yalnızca 2 adet segment tablosu aktif olabilir. Bunlar GDT v LDT'dir.

- Segment Selector'de ki bir bit kullanılarak CPU hangi Segment tablosunu kullanacağına karar verir.

- Segment Descriptor'lar, hafızanın bir bölgesini işaret eden bilgiyi ve o bölgeye erişebilmek için gereken erişim haklarına ait bilgiyi tutar. Segment Descriptorlar , Segment Tablosunun içerisinde array şeklinde yer alırlar. Bir Segment Descriptor kısaca bir segmentin başlangıç adresi ile boyutunu tutar ve imtiyaz seviyesini belirten DPL olarakta bilinen 2 bit'i kullanır.

- İşlemci bir segment'e erişim izni vermeden önce DPL ve RPL'i karşılaştırır. RPL selector'de yer alan 2 bitlik bir imtiyaz belirteçidir.

- Address Translation işlemindeki ilk adım, segmetin taban adresi ile offset'in toplanmasıdır. Bu işlemin sonucunda eğer paging mekanizması aktif değil ise doğrudan çıkan sonuç fiziksel adresi gösterir. Paging aktif ise bu adrese logical veya lineer adres adı verilir ve fiziksel adresi bulabilmek için eldeki veri tekrar Paging Address Translation adı verilen bir başka mekanizmaya devr edilir.

- Memory Management şeması Paging olarak anılır. Çünkü Hafıza, Pages olarak bilinen sabit boyutlu birimler halinde tanımlanır. Intel işlemciler üzerinde bir sayfa 4kb olarak varsayılır.

- 32bit Adresleme ile fiziksel hafıza ancak 4GB adreslenebilir. Bunun anlamı 1 milyon sayfayı adresleyebilirsiniz demektir.

- Bir PageDirectoryEntry'si eğer LSB(Least Significant bit) bit'i 1 ise geçerli olarak değerlendirilir.

- WindowsNT her process için ayrı bir PageTable tutar ve bunun sanal adres aralığıda 0xC0000000 dan 0xC03fffff'dir.

- Page Table Directory (1024)1K adet Page Table'in adresini tutar. PDT Lineer adresin son 10bit'inde (22-32 bitleri) yer alır ve bu tabloda ki bir girişe işaret eder.

- Page Table , adresleri PDT'de bulunan ve kendi tablolarında 1024 adet PageTableEntry(PTE) tutan PageTableFrame(PTF)'ye işaret eden tablolardır. Lineer adresin 12 ve 22 bit'leri arasında yer alır.

- Address space olarak bilinen kavram PageDirectory'den başka bişi değildir. Page Directory'nin gösterdiği table'lar üst yarısı bütün process'ler için aynıdır.

- MMCreateProcessAddressSpace fonksiyonu hafızanın 3 aşağıdaki işler için ayırır:
Birinci sayfayı PageDirectory için, ikinci sayfayı HyperSpace Page table girişlerini tutmak için ve 3.Sayfayıda Process ilk defa oluşturulduğunda working set olarak anılan , processin .code , .data , stack gibi nesnelerini tutmaya yarayan hafıza öbeğinin adresini tutar.

- Memory-Mapped, dosyaları, NT section nesneleri ile çalışabilmek için kullanır.

- Bir Process'in çalışma anında fiziksel hafızaya alınamayan kısımları işaretlenir. Process ne zaman hafızada bulunmayan bir datasına ulaşmaya çalışırsa , önceden işaretlenmiş alanlar ikincil depolama aygıtından (senaryomuzda bu hdd'dir) ana hafızaya getirilir.

- Eğer İşletim sistemi fiziksel hafızayı(RAM) tüketirse kendine yer açailmek için bazı dataları atmak durumunda kalır. Ancak bu boşaltım işlemi geri dönüşümsüz bir silinme şeklinde değil swapping yapılarak tekrar hdd'ye atılır ve dilendiği zaman oradan geri alınabilir. Bu dataların atılma işlemine karar verme mekanizması "Replacement Policy" olarak bilinir. Bu mekaizmada WindowsNT FIFO(İlk giren ilk çıkar) yönetimini kullanarak yerine getirir. Bu policy'ye göre bir yer sıkıntısı olduğunda bellekte ki en eski veri atılmış olacaktır.

- Eğer bir Page fiziksel Ram'in üzerinde map edilmemişse WindowsNT bu sayfayı "invalid" olarak işaretler. Bu sayfaya herhangi bir erişim gerçekleşirse bir "page fault" gerçekleşir ve bu hatayı yakalayan "page fault handler" hdd'den ilgili datayı az önce yukarıdaki bahsettiğimiz şekilde getirir.

- Eğer Page bir dll veya executable code içeriyor ise saygfa da o ilgili dll veya exe dosyadan alınır. Şayet sayfa bir data içeriyor ise sayfayı swap dosyasından alacaktır. Yani kod içeren bölgeler datalardan önceliklidir. Eğer sayfa Memory-Mapped paylaşımlı dosya alanından alınacak ise sayfa uygun dosyadan alınır.

- Windows NT fiziksel hafızadaki boş alanı sürekli tahrip eder, böylece bir page fault meydana geldiğinde hdd'den çıkarılacak sayfa için yer ayırabilecektir. Bu takip bilgileri, Page Frame Database (PFD) olarak anılan Kernel data yapısında tutulur.

- PFD hafızadaki sayfaları FIFO tabanlı bir listede tutar ve yer sıkıntısı olduğu durumlarda atılacak sayfaya karar verir. Ancak bir sayfayı atmadan önce WindowsNT bu sayfanın "dirty" kirli olmadığından emin olmalıdır. Dirty biti sayfanın yazılmış olduğunu ve hafızadan atılmak icap eden durumlarda bu sayfanın ilgili swapping işlemine uygun olduğunu gösterir. Ayrıca PFD paylaşılan sayfalar içine bir referans sayacı tutar ve yalnız bu sayaç ilgili sayfa için sıfır olduğunda atılır. Genelde PFD her fiziksel sayfanın durumuna bakar. PFD her fiziksel sayfa için 24byte 'lık bir array'dir. PFD arrayinin boyutu bir kernel değişkeninde depolanan fiziksel sayfanın sayısına eşittir. Bu değeri tutan değişken "MmNumberOfPhysicalPages"'dir. PFD'nin adresini yine bir kernel değişkeni olan MmPfnDatabase tutar. Bir fiziksel sayfa farklı durumlarda olabilir. Örneğin in-use, free ,free ama dirty gibi. PFD girişi bir doubly linkd list'e ve fiziksel sayfanın durumuna bağlıdır. Örneğin boş sayfaları tanımlayacak PFD girişleri free page listesine bağlıdır.

- Virtual Address Descriptor: Windows NT her boş fiziksel sayfanın listesi ile birlikte ayrıca her Process için ayrılmış olan virtual address boşluğunuda izlemeye ihtiyaç duyar. Bir Process ,bir hafıza bloğu ayırmak istediği zaman ki bu işlem örneğin bir dll i hafızaya almakta olabilir bu esnada WindowsNT Virtual Address boşluğundaki boş bloklar için bir kontrol yapar ve ondan sonra gereken yeri ayırır, ve Virtual Address map'i bu doğrultuda günceller ve hali ile bu işlem bilgilerini alabileceği en doğru yer Page Table'dir.

- IO Manager , gerekli şartlar oluşup bir IRP oluşturulduğunda IRP yapısının AssociatedIRP.SystemBuffer alanına usermode'da yer alan buffer'indaki bilgiyi geçer.

Biraz sinerji katalım

noreply@blogger.com (kernelturk) — Mon, 2 Nov 2009 11:58:00 +0200

Takip edenler bilir, yaklaşık bir aydır eski nostaljim olan kernelmode dünyasına geri döndüm. Kendisi ile 2 sene önce hazin bir ayrılık yaşamış ve highlvl yollarını aşındırır olmuştum. Sağolsun Emre Tınaztepe ve Kutalmis dostlarım sayesinde tekrar gerçeten severek uğraştığım işe geri döndüm. Bu sebeple yıllar önce şirketteki a4 ve toner kapasitesinin tükenmesine neden olduğum kernelmode dökümanlarımı tekrar gün yüzüne çıkardım ve hararetle okumaya başladım.

Dökümanları karıştırıken günlük gibi tuttuğum ve iyice sararmaya yüz tutmuş olan not defterime denk geldim. Okudukça iyiki yazmışım bunları dedim ve sizlerle paylaşmak için hemen bloguma giriş yaptım. Umarım sizlerinde işine yarar:

== 2004 ==
- User-Mode kodları Objectlere handle'ları kullanarak erişir ancak Kernel-Mode kodları Object'lere doğrudan erişirken pointer'ları kullanır.

- Object'lerde bulunan ReferenceCount hem user-mode dan handle lar vasıtası ile yapılan erişimlerde hem de kernel-mode'dan yapılan erişimlerde 1 artar.

- Bir process zaten çok küçük zaman aralıklarında çalıştığından (quantum slice) hafıza bölgelerinede bitişik olsalar dahi çok küçük erişim boyutlarında erişir.

- İşletim Sistemi, bir processin sadece o an hafızada çalıştığı kümelerini (bknz:working set) saklamaya ihtiyaç duyar

- Her device controller local bir buffer'a sahiptir. CPU bu local bufferdan, ana hafızaya veya ana hafızdan local buffera data taşır

- I/O: Aygıttın kendi device controllerinde bulunan local buffer'a yapılan işlemdir.
Device controller daha sonra bu i/o işleminin bittiğini Cpu'ya interrupt kullanarak bildirir.

- Trap bir kullanıcı hatası veya başka bir problemden dolayı meydana gelen yazılımsal bir interrupt'tır

- I/O Manager, bir IRP oluşturduğunda _IRP yapısının AssociatedIrp.SystemBuffer buffer alanına kullanıcı taraflı buffer alanındaki bilgiyi geçer.

- IofCompleteRequest çağrısı ile bir irp için gerekli işlemlerin tümünün yapıldığı varsayılır. Bu komut sonrasında I/O Manager driver taraflı buffer alanını user taraflı buffer alanına kopyalar.

- IRQL Notları

1.Bir fonksiyona girdiğinizde mutlaka IRQL'ni kontrol edin
2.Her hangi bir fonksiyonu çağırmadan önce IRQL'ı için DDK'ya göz atın
3.Eğer bir thread en düşük IRQL seviyesinde çalışıyorsa onu daha fazla alt seviyeye indiremezsiniz, ancak yükseltebilirsiniz.
4.DISPATCH_LEVEL da PAGE_FAULT yaşamazsınız
5.Paging I/O APC level'da yapılır
6.Kullanıcı her zaman PASSIVE_LEVEL da çalışır
7.Kernel'de PASSIVE_LEVEL da çalışabilir.
8.PASSIVE_LEVEL da iş yükü dağıtımına izin verilir
9.DPC'ler DISPATCH_LEVEL da çalışırlar ve preempt edilemez(etkisizleştirilemez) (ama interrupt edilebilirler tabiki) ve dispatcher olduklarından DISPATCH_LEVEL'da çalışırlar.
10.IRQL'ları manipüle etmek için KeLowerIrql() ve KeRaiseIrql fonksiyonları kullanılır.

- IRP Notları

1.IRP'ler bir uygulamanın veya driver'in davranışları üzerinden IoManager tarafından üretilirler. IRP'in üst kısmı (header) sabit bilgilerden oluşur, alt kısım ise stack location adı verilen bilgi yığınından oluşur.
2.Uygulama driver'a yalnızca kontrolü IRP'lar vasıtası ile devredebilir, ve bilgiler paylaşılan bir hafıza tarafından değiş tokuş edilir.
3.IoManager driver'lar için bir IRP kuyruğu tutmaz, sadece ne zaman alınacaklarını ve gönderileceklerine bakar. IRP'leri kuyruklamaktan driver kendisi sorumludur.
4.IRP sürücü IoCompleteRequest isteği çağrıldığında işlemini sonlandırır.
5.Irp->IoStatus.Information transfer edilen data boyutunu içerir ve bu bilgi usermode tarafındaki DeviceIOController'in en son paramtresi olan bytesreturned'e aktarilir.
6.IoManager geri donen bilgiyi SystemBuffer'dan OutputBuffer'a kopyalar.
7.IoCompleteRequest fonksiyonu IoManager'a bildirilen en son IRP çağrısıdır ve bu IRP'in artık işinin sona erdiğini bildirir. Bu çağrı bir kez yapıldıktan sonra artık o IRP'e erişilemez.
8. Driver'dan Driver'a IRP'ler vasıtası ile haberleşilebilir. Driver'lar aynı adres boşluğunda çalıştıklarından her biri bir diğeri ile paylaşımlı hafıza alanları sayesinde iletişim kurabilir.
9.IRP, sürücü katmanları arasında dolaşabilir. Bu IRP'in bilgilerine IoGetCurrentIrpStackLocation çağrısı ile ulaşılabilir.

İşe yarar temelinizi oluşturacak şeyler buldukça paylaşmaya devam edeceğim... ,

Şimdilik sağlıcakla.

Programcı Kütüphanesi

noreply@blogger.com (kernelturk) — Wed, 21 Oct 2009 22:17:00 +0300

Buldukça ekliyeceğim bazı eski yazılarım ve sanal ortamlarda yaptigimiz münazarlara ait linkleri sizinle paylaşmak isterim. Şimdilik bunlar çıktı :

Konu:Bir ara gaza gelip komple çevirisini yapmaya niyetlendiğim Win32 Api'nin Windows'lara ait çevirisi.
Link:Win32: Pencereler

Konu:Sene 2003 Masm32 ile yeni tanışmışım bi yandan okuyorum bi yandan kodluyorum. Baktım kavraması zor her satırı ileride anlıyayım diye commentlemişim. Buyrun aynı çileyi çekmeyin:
Link:Masm32 Iskelet

Konu:Masm32 yi çözdük ama bu seferde ddk ya merak saldık ve aynı "anla+kodla ve çevir" sistemini bunada uyguladım. Sağolsun rus dostlardan F-Four sağlam bi makale serisi hazırlamış bizede çevirip derlemesi düştü:
Link:Sistem Programcılığı Serisi

Konu:Win32 Pipe mantığı ve bir örnek
Link:Pipe'ler

Konu:Exe'ler nasıl çalışır . Ben baktım güldüm açın sizde gülün :)
Link:Exe'ler nasıl çalışır

Konu:Kripto ve Sıkıştırma hk. Bi aralar güzel münazaralar oluyordu hey gidi günler...
Link:Sıkıştırma ve Kriptografi

Konu:O zamanlar popüler olan Pe header yapısı hakkında münazara ediyorduk
Link:Import Section olmaksızın executable derleme

Konu:İşe girdim ve ilk defa kısıtlı bir domain kullanıcısı ile tanıştım. Nereye el atsam erişim engellendi hatası. Ben ve Erişim Engellendi hatası aaa hiç olurmu :) Kabul ediyorum acaip amatörce keşifler.
Link:Microsoft ve Group Policy Açıkları
Link:Gpo ile Kısıtlanan Çalıştır (Run) menüsünü geri getirme
Link:

Assembly ve Win32Api Voltran Voltran Voltran

noreply@blogger.com (kernelturk) — Wed, 21 Oct 2009 21:19:00 +0300

Okuyacağınız bu makale 2006 yılında yazılmıştır. Yaptığım uslüp ve makale içindeki komik hata ve eksikler nedeni ile özür dilerim. Okuduğumda bana eski ve yeni durumum hakkında ölçüm yapmamı sağladığından mevcut hataları olduğu gibi bırakmayı tercih ettim.

Masm32 ve Win32'nin Güçlü Birlikteliği

Bu dökümanı ayrıntılı olarak yazmamın en büyük sebebi Türkiye'de ki yanlış anlaşılan ve uygulanan sistem programcılığı müessesini bir nevi olsa da gerçek manasıyla anlaşılabilirliğini sağlamaktır. Dil olarak assembly'i seçmemin manası ise, sistemin işleyişini akıllarda soru işareti bırakmayacak bir şekilde yalın olmasını sağlamaktır. Zaten öncelikle bu dokümanın okuyucuları için assembly temelden inceleyen bir giriş yapılacaktır.

Assembly öğrenmek demek,

· Çalıştığınız mimariyi çok iyi tanımak,
· Hatasız kodlar üretebilmeyi sağlamak,
· Yazılım eksikliklerini keşfedebilmek,
· Hızlı ve eksiksiz programlama süreçleri oluşturabilmek,

gibi yetenekler kazandıracaktır. Assembly de en azından orta seviye bir programcı olabilmek için; hardware yapıları, işlemci mimarisi, hafıza yönetimi, os mimarisi, process davranışları ve eğer ilgileniyorsanız network alt yapısının, katmanlarının ve iletişim mimarisinin nasıl çalıştığı hakkında bilgilere sahip olmak zorundasınızdır. Korktunuz mu! Yapmayın hani sistem uzmanı olmak istiyordunuz?

Ben şöyle düşünüyorum. Sonuç olarak derlenmiş kodlar makine koduna dönüyor ve tüm işleri yapan işlemcimiz de en iyi ondan anlıyor, öyleyse önce onu öğrenmeliyim ki sonra üst katman dilleri geçtiğimde daha hatasız kodlar derleyeyim. Tabi birde karşılaşacağım opcode seviyesi hataların da yorumlayıp hata tespiti yapabileyim. Ayrıca işin birde tilki tarafı var ancak bahsetmeyeyim şimdilik. :)

Dokümana başlamadan önce şunu da belirtmek isterim ki, bu dokümanın hedef kitlesi herhangi bir programlama dilinde en azından orta seviyede bilgili ancak kendini sistem programcılığı konusunda da yetiştirmek isteyen arkadaşlar olacaktır. Dokümanı elimden geldiğince basitleştirip, arada bir iğrenç espirilerimden sıkıştırıp eğlenceli hale getirmeye çalışacağım.

Kısa bir giriş İşlemci

Burada işlemcinin ne olduğunu ve hayat hikayesini anlatacak değilim . Sadece bizi ilgilendiren yerlerini bilmemiz şu anlık yeterli olacaktır.

Nasıl ki diğer programlama dillerinde değişkenler kullanarak bazı değerleri onların içlerinde saklayıp işlemler yapıyorsak assembly içinde işlemcide bulunan registerlar o anlamı ifade eder. Register kavramı eskiden üretici firmalar arasında farklılıklar gösterse de günümüzde bu protokol artık yerleşmiştir.

Registerlar ile değişkenler arasında bir benzetme yapacak olursak.

Delphi için:

var
sayi1,sayi2,sonuc :integer;
begin
sayi1:=10
sayi2:=20
sonuc=sayi1+sayi2

ise

assembly de bu

mov ax,10 ;ax artık 10 sayısını saklıyor
mov bx,20 ;bx artık 20 sayısını saklıyor
add ax,bx ;topladık ve ax artık 30

Bu register'lar dan işlemci de genel amaçlı olanlarından 8 adet bulunur. Bunlar:

EAX,EBX,ECX ve EDX tir. Bunlar 32 bit'lik bilgileri saklarlar ve kendi içlerinde voltran :) oluşturduklarından ayrıca bölünebilirler. Şöyle ki:

*EAX -> AX -> AH,AL
32b 16b 8b, 8b

*E demek Extended demek ilk işlemcilerde bu yoktu ve 16 bittiler registerlar
bu örnek yukarıdaki dörtlü için aynıdır. EBX -> BX -> BH,BL gibi

Şu ana kadar yazdıklarımdan bir şey anlamadıysanız baştan tekrar okuyun veya google da daha basit olan ingilizce dökümanları bulun fakat bu anlatılanlar sizi zaten bildiğiniz şeyleri tekrar okutup sıkıyorsa bir sonraki serileri doğrudan ilerleyen konulardan devam etmeniz daha iyi olacaktır.

Bu yukarıdaki dört register cpu tarafından kunta kinte şeklinde yönetilirler ve her şey için kullanılabilir. Bazı işletim sistemleri bu register'ları kendi isteklerine göre gruplandırmıştır. Örneğin Microsoft kendi API sistemin de işletilen fonksiyon geri dönüşlerini sürekli eax'a gönderir. Birde bunların haricinde EDI ve ESI vardır Intel bunları programcılara bir nevi kıyak olsun programcılar uğraşmasınlar diziler ile, koysunlar kopyalanması istenilen diziyi ESI'ye versinler hedef olarak EDI'yi atsınlar bi dongu komutu hepsi EDI'de Yani bi nevi kopyala yapıştır için iyi bir halta yarar bu iki kardeş register . İlerleyen zamanlarda movs, cmps gibi yardımcı komutlarından çıkması ile işlevsellikleri kanıtlanmıştır index registerlarının.

Unutmadan birde ESP var. Amacı ve işleme mantığı şöyledir Esp'yi bir bidon olarak düşünürsek hatta turşu bidonu olarak düşününki :P olay daha da basitleşsin. Turşu bidonumuza zerzevatı ben şu şekilde yerleştirirsem:

| domates |
| kavun |
| hıyar |
| zerdali |
| floppy :)|
\________/

bunları alırken hangi sırayla alırım . Intel işlemcileri bunu FILO işlemiyle alır yani First In Last Out - Türkçesi: İlk giren Son çıkar dileyen LIFO yani Last In,First Out'da diğebilir aynı şey J. Kısaca bu istiften yada Intel'in deyimi ile stack'ten ilk çıkan domates olur. Onun peşinden kavun ve en son floppy olur. Halbuki domates en son yığına giren nesnemizdi dimi ama? ESP genelde iki asm komutuyla yönetilir bunlar Push ve Pop tur. Örnekten devam edecek olursak Push komutu kovaya(stack) bi yeşillik atar ve kovanın içindekilerin in sayısını ve yerini tutan bir kayıttaki değeri(ESP) küçültür Pop ise tam tersini yapar kovadan en son atılan malzemeyi alır. Intel işlemcilerinde stackten veri alıp veri koyma işlemleri yaparken register değeri ya 4byte(32bit) artar yada 4byte azalır.

örnek
push 20 ; Stacke(kovaya) bi 20'lik attık
push 10 ; Peşinden onunda üstüne bi 10'luk
pop ax ; pop komutunu vererek stackin en üstündeki veriyi ax'e aldık ax=10
pop bx ; bx artık 20
add ax,bx ;ax=30

kolaymış değilmi?

Tabi bu stackten veriyi illaki en üstündeki alacağız diye bir kaide yok, dilersek stackteki en alttaki veriyi bile elde edebiliriz ama bunu yapan kodlar konumunuz hasebiyle şimdilik size uygun değil.

Şimdi sırada EIP registeri var
Bu yazmaç yazdığınız programların kodlarını bir sıraya sokar ve adım adım işler. Basit bir benzetme olması açısından Qbasic'i bilenler varsa hatırlarlar:

1 CLS
2 print "muck muck"
goto 2

deyip her komutu etiketliyorduk ya işte onun daha gelişmişi eip'tir. Bu register'a dışarıdan komutlarla müdahale şansı doğrudan yoktur. Onu derleyici bir kere ayarlar işletim sistemi de işlemciye yollar işlemcide bu sıraya göre teker teker gider. Ollydbg adlı debugger'ı kullanarak EIP yazmacının mantığını anlamanız daha kolay.

Segmentler:
CS: SS: DD: ES: FS: GS

CS DS ve SS : Programınızı yazıp derlediğiniz zaman, programınız sizin onu kodladığınız halinden milyon kez değişik bir halde çalıştırılabilir dosya haline gelir. Yani sizin anladığınız programlama yapısı ile işlemcinin anladığı yapı çok farklıdır. Siz kodunuzun kodlarının nerede,tanımlamaların nerede,sabitlerin nerede olduğunu bilirsiniz. Ama işlemci bunu ancak programınızı derleyen derleyicinin programınızın çalıştırılabilir kod haline getirdiği zaman içerisine eklediği bazı ipuçlarından faydalanarak bulabilir. İşte programınızın kodlarının nerede mahfuz tutulduğunu işaret eden olaya Code Segment(CS), verilerinizi işaret eden bölüme Data Segment(DS), değişkenleriniz,fonksiyon geri dönüşleriniz ve işlemci taraflı kod dallanmaları gibi göstergeyede Stack Segment(SS) denir. İşlemci programınızı çalıştırmak için hazırlık yaparken CS segmentine bakarak kodların yerini DS segmentine bakarak tanımlamaların yerini SS'ye bakar ise Stack'in yerinin bulur.

Peki işlemci kodların yerini buldu diyelim ancak bu kadar kodun içerisinden nereden başlayacağını nasıl bilecek. Yukarıda yazmıştık değil mi? EIP yazmacından. Siz programınızı derlediğinizde programlama dilinize ait compileriniz bu işlemi sizin için ve cpu için yapar. Programlama dili konseptlerin de şu vardır ki her yazılan kod için bir Entry Point vardır. Siz programınızı derler ve çalıştırırsınız ancak compiler önce sizin yazdığınız kodu icra etmek yerine, yazdığınız program için çalışacak ortamı hazırlamak için öncü bazı hazırlıklar yapacaktır. Her program için işletim sistemi o programa ait giriş noktasını gösteren CS:EIP çiftini hazırlar. İşlemci'de o CS:EIP ikilisine ait ,bazı çevrimler yaparak kodu icra etmeye başlar.

Şimdi hızlı bir giriş yaparak assembly programlamaya başlayabiliriz.

www.masm32.com Bu yazdığımız programları işe yarar hale getirmek için gerekli. Çektiğiniz zaman zipi sürücülerinizi kök dizinlerine açın ör: C: D: E: Ğ: :)

OllyDbg Buda derlediğimiz programlarımızı irdeleyebilmemiz için gerekecek.

Evet gerekenler bunlar ve hepsi içerisindeki örneklerden oluşan kabarıklığı saymazsak 1.5 mb kadar alan kaplıyor .

Masm32 Win ortamlarda assembly kodları ile çalışmak için geliştirilmiş bir derleyicidir. Yazdığınız *.asm uzantılı kodlarınızı size *.exe *.dll olarak sunar. Kabul ettiği ve anladığı tek şey assembly komutlarıdır.

Basit bir giriş yaparak aşağıdaki gibi bir örnek verecek olursak:

.386
.model flat, stdcall
option casemap:none
include \masm32\include\windows.inc
include \masm32\include\kernel32.inc
include \masm32\include\user32.inc
includelib \masm32\lib\user32.lib
includelib \masm32\lib\kernel32.lib

.data
Baslik db "Ben bir başlığım",0
Mesaj db "Selamün Aleyküm Dünya!",0

.code
start:
invoke MessageBox, NULL,addr Baslik, addr Mesaj, MB_OK
invoke ExitProcess,NULL

end start

Evet yapısı itibari ile biraz karışık olduğu konusunda haklısınız ancak bu kanınızın ileride değişeceğine eminim. Şimdi yukarıda ki kod örneğimiz üzerinde ayrıntılı bir inceleme yapalım.

.386

Bu komut masm32 derleyecisine(compiler)'e kısaca şöyle der: "Dostum bu programı yazan herifin yazdığı kodlar eski 386 işlemcilerin anladığı opcode'lardan oluşuyor derleme yaparken ona göre yap" der.Ancak bu seçeneği seçerseniz yeni nesil .686 işlemciler için çıkmış son nesil kodlardan yararlanamazsınız. Bu seçeneği isterseniz .686 da yapar yeni nesil komutlarla çalışabilirsiniz. Ayrıca bir diğer önemli hususta adresleme modlarıdır. Yani bu komut eğer .386 altı bir değer ise ör: .286 ve daha aşağısı gibi adresleme modları daha yeni nesil adresleme modlarını örmeğin(80386 Scaled Indexed Addressing Modes) [çok iyi bir indeks bulma yöntemidir zatî alîler-i]desteklemez. O yüzden en iyisi siz .386 ve yukarısını işlemci aileleri ile çalışmayı seçin sonra kafanız ağrımasın.

.model flat,stdcall

Bu komut ise programınızı kodlarken bir hafıza işlemi yaptığınızda ve yahut bir komut çağırdığınızda işe yarar. Şöyle ki: Eğer 32.bit için program yazıyorsanız genelde flat hafıza yöntemi kullanırsınız çünkü flat komutu hafızayı 4GB sanal bellek olarak varsayar.

Ne demek 4Gb sanal bellek kullanmak? Eski işlemcilerle hafıza sadece 640kb olarak adreslenebiliyordu, sonraları bu sınır segmentasyonda yapılan bazı değişikliklerle 1MB sınırına ulaştı. Ancak işlemci teknoloji gelişmiş ve 32'bitlik bir mimari kazanmıştı. Buda artık hafızaya 32 bitlik erişimler yapılabileceği anlamına geliyordu. Kısaca 32Bit erişimlerle 4GB hafıza adreslenebiliyor. (Bunu windowsunuzun hesap makinesinde 32 adet 1'lik biti yan yana getirip daha sonra decimale çevirdiğinizde görebilirsiniz. ) Peki sisteminizde 32 Mb Ram 512mb hdd varken(küçümsemeyin benim hala böyle çalışan bir sistemim var J) nasıl oluyor da her program 4GB hafıza kullanabiliyor. Bu aslında işlemci üreticilerinin geliştirdiği basit ama bir o kadar da harikulade bir numara. Olay şöyle cereyan ediyor. Her program için işletim sisteminiz sadece programınızı ilgilendiren bir tablo tutar. Bu tabloda programınıza ait hafıza adreslerini gösteren adına linear address dediğimiz konumlandırıcılar için fiziksel hafızada nereye denk geldiklerini gösteren girdiler vardır. Daha da basitleştirirsek: olayı 2 sütunlu excel tablosu gibi düşünebiliriz. A sütunu Doğrusal adresleri(linear) b sutunu ise Fiziksel adresleri belirtiyor olsun. Fiziksel adresten kastımız Ram'imizdir. Bu sütunlarda programınıza ait bazı en çok kullanılan doğrusal adreslere denk düşen fiziksel sayfa numaraları bulunur. Tabi o sütunların hepsinde her doğrusal adrese bir fiziksel adres denk geliyor diye bir kaide yok. Dedik ya sadece çok sık kullanılanlar o tabloda yer alıyor. Eğer işlemci programınızdan o tablonun fiziksel sütununda bulunmayan bir doğrusal adresini çağırırsa, işletim sistemi cpu için hdd'ye giderek o programın o doğrusal adresine denk düşen veriyi alır ve o fiziksel sayfa sütununa koyar. İşlemci de "'her şey ne kadar güzel 1.76 gb'da bile verilere erişebiliyorum "' der J. Biraz daha anlatmaya devam edersem Hafıza modelleme konusuna geçiş yapmak zorunda kalacağım en iyisi burada kesmek.

Şimdi stdcall'e geçelim. Bu komut compilere(compiler masm32 de ml.exe'dir) prosedür çağrılarının stack'e hangi sırayla atılacağını ve alınacağını belirtir. Üç çeşitli vardır :

1-C 2-Pascal 3'te - Stdcall

Biz hep StdCall'i kullanırız . Niyemi?
Ne demiştik her programlama dili eninde sonunda kodlarını assembly'de anlaşılacak bir hale getirecektir. Ama bu çevrim işleminde bazı yerler vardır ki o programlama dilini yazan firmanın tercihidir karışamayız. Mesela C çağrım şartı için:

goster(int par1,int par2, int par3) gibi bir prosedür çağrısında işlemci bunu

push [par3]
push [par2]
push [par1]
call goster
add sp,12

şeklinde işleyecektir.

Yukarıdaki kod stacke par3'ten başlayarak değerleri koyar ve goster prosedürünün altındaki komutları icra edip kaldığı yere geri döner ve add sp,12 ise stack'i eski haline geri döndürür. Yani stacki eski haline döndürme işlemi prosedürün işi bittikten sonra yapılır .Ama Pascal çağrım şartında bu tam tersidir. Şöyleki:

topla:= par1+par2+par3 için bu asm'de
push par1
push par2
push par3
call **pla

dır.

Add sp,12'nerde? Tabiiki **pla prosedürünün içerisinde . Yani stacki derleyip toparlama işi çağrım yapılan fonksiyonun görevidir.

Son olarak STDCALL ise bunların ikisinin karışımıdır. Yine örnekle açıklarsak

**pla(int par1,int par2,int par3) prosedürü asm'de

push [par3]
push [par2]
push [par1]
call **pla

dır.

C çağrım şartı, fonksiyon veya prosedürle verilen operatörlerin en sağından başlayarak stacke koyma işlemini yapar ve fonksiyondan sonra stacki düzenler.Ama Pascal bunun tam tersini yapar ve stacke koyma işlemini soldan sağa yapar ve stacki fonksiyonun içinden çıkmadan düzenler.Stdcall ise C gibi stacke alma işlemini sağdan başlar ama pascal gibide fonksiyon içerisinde stacki düzenler.

Bu anlatılanları bir debuger'la sınarsanız mantığı daha iyi kavrayacağınıza eminim.

Evet bu kısmıda anladıysak devam ediyoruz..

option casemap:none

Bu yönerge programcının isteğine bağlıdır. Şöyleki Bununla compilere dersinizki: "Yazdığım tüm komutlar ve ne kadar şey varsa bunları küçük büyük harf ayrımına tutma. Ben acaip bi insanımdır bazen "push" yazarım bazende "PuSh" sen benim keyfime karışma" der. Bunuda anladıysak kaynak kodumuzdan bir satır daha aşağıya iniyoruz.

include \masm32\include\windows.inc
include \masm32\include\kernel32.inc
include \masm32\include\user32.inc

Yukarıdaki komutlar compilere (derleyiciye) bizim hangi yardımcı komutlarla çalışacağımızı söyler. Bu .inc dosyalarının içerisinde bazen komut makroları bazende işletim sistemi fonksiyonlarının komutun kaç paramtre ve hangi tipte boyda veri alacağını belirten tanımlamalar yer alır. İlgili dizindeki dosyaları açarak ne demek istediğimi daha iyi anlayacağınıza inanıyorum.

includelib \masm32\lib\user32.lib
includelib \masm32\lib\kernel32.lib

includelib komutuda compilere çalıştığımız yardımcı komut kütüphanelerinin hafızadan veya dosyadan çağrılacak offset tanımlamalarını belirtir.

.DATA
.DATA?
.CONST
.CODE

Evet EXE'ler nasıl çalışır adlı dokümanımı okumayanlar için bir daha tekrarlayayım . Her çalıştırılabilir dosya ki buna .dll'lerde dahildir, içlerinde programcı tarafından önceden tanımlanmış bilgiler ".data" veya kullanıcıdan veyahut etkileşimli bir komuttan alacağı verileri muhafaza için ".data?" ve program içinden dahi değiştirilemeyecek readonly, gerekli ön tanımlama bilgileri ".const" ve tüm yazılımsal kodları içeren ".code" gibi alanlara sahiptir.

Özetle

.DATA Kullanıcıya iletilecek önceden tanımlanmış veriler veya program içerisinde kullanılacak bazı ön tanımlı değerleri tutar. Buna örnek olarak kaynak kodumuzda belirttiğimiz

.data
Baslik db "Ben bir başlığım",0
Mesaj db "Selamün Aleyküm Dünya!",0

gibi bir tanımlama verilebilir.

.DATA? ise hafızada yeri ve mekanı belli ama içerisinde hiç bir bilgi olmayan , dışarıdan gelecek her veriye "gel ne olursan ol yine gel" diyen bir alandır Örneğin

.data?
buffer db 512 dup(?)

.code
mov dword ptr[buffer],'X'

Yukarıdaki gibi bir kodda programı ilk çalıştırdığınızda buffer alanı hafızada ayrılmış ancak hiç bir bilgi içermeyecektir. Ta ki yukarıdaki "'mov"' komutu icra edilene kadar.

.CONST Komutu ise program icra edilirken, ne kendi içerisinde ki bir müdahaleyle ne de dışarıdan alınacak bir girişimle değiştirilemez verileri tanımlar. Mesela bir web server yazdık bunun portunun değiştirilmez bir şekilde 80 olmasını istedik. Bunu :

.CONST
webport equ 080h

diyerek yapabiliriz.

Her programlama dilinde olduğu gibi assembly'de de data tanımlama belirteçleri vardır. Bunlar:

db = Define Byte (8Bit)
dw = Define Word (16Bit)
dd = Define Dword(32Bit)
..
dup(?) = Define memory up (miktar)

Yukarıdaki tanımlamalar hafızada belirtilen değerlerde veri girişi sağlar.

Elinize bir kalem kağıt alın yada paint'i açın. Büyük bi dikdörtgen çizin . Bu çizdiğiniz şey sizin programınızın kullanacağı hafıza alanı . Evet windows sizin programınızı böyle bir şey gibi görür. Sizin yapmanız gereken az önce bazılarını yukarıda da anlattığım .data .data? .const .code gibi sınır çizgileri ile bunları bölmek. Yani programınız hafızada artık en basitinden ".data .code ve .stack" gibi görünecektir.

Evet artık size düşen bu alanlarla oynamak. Yukarıdaki kodumuzu inceleyin o hem .data section için hafızada ayrılan boşluğa veri yazar, hemde .code içinde belirtilen kodlar için hafızada kod bloğu oluşturur. Bu data yazma işlemini örneğin

mesaj db "Selam millet",0
veya
sayi dd 0125468984h
veya
handle dw 015fah

gibi yazarız . Bunlar ne anlama gelir.

Eğer hafızaya bir string girecekseniz bunu db ile yapmalısınız. Niyemi? hatırlayın her ascii harfinin tekinin boyutu nedir? 1Byte!. Öyle ise ben :

mesaj db "Selam",0

dediğimde bu hafızaya byte byte yazılacaktır . Şöyleki:
Hafıza:

00403000 53 65 6C 61 6D 00 00 00 00 00 00 00 00 00 00 00 Selam

gibi olacaktır.

Ama bunu gidip
mesaj dd "Selam" deseydim hafıza:

00403000 53 00 00 00 65 00 00 00 6c 00 00 00 00 61 00 00 S...T...R

gibi birşey olacaktı ve programınızın ekrana S yazıp bitecekti. Çünki windows stringler için 00'ı terminated data(sonlandırıcı) olarak tanır.

Evet artık .code .stack. data .const compile, verilerin hafızada nasıl yerleştiği, çalışan processin bir debuggerda nasıl gözüktüğü,sectionlar anlamış olmalısınız ve evet artık sizinle güzel örneklere başlayabiliriz.

Burada şöyle bir yöntem kullanacağım . Sizinle birlikte daha kolay anlayasınız diye masm32'nin içinde yer alan icztutes klasörünün içindeki Iczelion'un yazdığı örnekler üzerinde çalışacağız .

Şimdi ilk önceliğimiz size göre tute02 almalıydı ama o zaten yukarıda verdiğim örneklerle birebir aynı ben onu geçip doğrudan TUTE03 klasöründe yer alan WIN.asm uygulamasının üzerinde çalışmayı yeğliyorum.

Win.asm'nin içeriği aşağıdaki gibidir.

.386
.model flat,stdcall
option casemap:none
include \masm32\include\windows.inc
include \masm32\include\user32.inc
include \masm32\include\kernel32.inc
includelib \masm32\lib\user32.lib
includelib \masm32\lib\kernel32.lib

WinMain proto :DWORD,:DWORD,:DWORD,:DWORD

.data
ClassName db "SimpleWinClass",0
AppName db "Our First Window",0

.data?
hInstance HINSTANCE ?
CommandLine LPSTR ?
.code
start:
invoke GetModuleHandle, NULL
mov hInstance,eax
invoke GetCommandLine
mov CommandLine,eax
invoke WinMain, hInstance,NULL,CommandLine, SW_SHOWDEFAULT
invoke ExitProcess,eax

WinMain proc hInst:HINSTANCE,hPrevInst:HINSTANCE,CmdLine:LPSTR,CmdShow:DWORD
LOCAL wc:WNDCLASSEX
LOCAL msg:MSG
LOCAL hwnd:HWND
mov wc.cbSize,SIZEOF WNDCLASSEX
mov wc.style, CS_HREDRAW or CS_VREDRAW
mov wc.lpfnWndProc, OFFSET WndProc
mov wc.cbClsExtra,NULL
mov wc.cbWndExtra,NULL
push hInstance
pop wc.hInstance
mov wc.hbrBackground,COLOR_WINDOW+1
mov wc.lpszMenuName,NULL
mov wc.lpszClassName,OFFSET ClassName
invoke LoadIcon,NULL,IDI_APPLICATION
mov wc.hIcon,eax
mov wc.hIconSm,eax
invoke LoadCursor,NULL,IDC_ARROW
mov wc.hCursor,eax
invoke RegisterClassEx, addr wc
INVOKE CreateWindowEx,NULL,ADDR ClassName,ADDR AppName,\
WS_OVERLAPPEDWINDOW,CW_USEDEFAULT,\
CW_USEDEFAULT,CW_USEDEFAULT,CW_USEDEFAULT,NULL,NULL,\
hInst,NULL
mov hwnd,eax
invoke ShowWindow, hwnd,SW_SHOWNORMAL
invoke UpdateWindow, hwnd
.WHILE TRUE
invoke GetMessage, ADDR msg,NULL,0,0
.BREAK .IF (!eax)
invoke TranslateMessage, ADDR msg
invoke DispatchMessage, ADDR msg
.ENDW
mov eax,msg.wParam
ret
WinMain endp

WndProc proc hWnd:HWND, uMsg:UINT, wParam:WPARAM, lParam:LPARAM
.IF uMsg==WM_DESTROY
invoke PostQuitMessage,NULL
.ELSE
invoke DefWindowProc,hWnd,uMsg,wParam,lParam
ret
.ENDIF
xor eax,eax
ret
WndProc endp
end start

Program çok basit bir windows penceresidir. içinde hiç bir şey yoktur ve kapat komutundan başka hiç bir komuttan anlamaz.

Windows'ta işler çoğunlukla pencerelerle yürür. Örneğin siz şu anda bu sayfayı Windows işletim sistemi yardımıyla görüntülüyorsanız bu Pencerelerin sayesinde oluyor. Yani şu anda bu okuduğunuz doküman bir pencerenin içinde yer alıyor ve bu pencere genel olarak "açma,kapama,ölçekleme,büyütme ve küçültme, üzerinde yapılan değişiklikleri algılama,fare hareketleri,klavye gönderimleri, başka pencerelerle veri akışı vs.. bir çok yapıyı idare eden bir yapıdadır. Penceremizi yöneten ve onunla çalışmamızı sağlayan GUI'dir, iş akışını idare eden ise Win32 Messaging sistemidir. Yani siz bu pencerenin üzerinde her mouse hareketi yaptığınızda win32 subsystem bu pencereyi kontrol eder ve mouse koordinatlarını yine bu pencereye mesaj olarak iletir ve eğer bu pencereyi yazan programcı bu hareketler için özel tepkiler programladıysa onları pencerenin icra etmesini sağlar. Yukarıdaki örnekteki kodda penceremiz sadece gelen kapat bildirimini almakta ve pencereyi yok etmektedir. Bundan başka gelen her komutu ise DefWindowProc prosedürüne ileterek isteğin Win32 tarafından denetlenmesini ister. GUI kütüphanesi ile pencerelerinizin tasarımını yönetirsiniz. İkonu, şekli, üzerinde yer alacak butonlar,resimler vs.. sizin için hazır olarak bulunan Api'ler ile bunları rahatlıkla yapmanız için GUI tarafından desteklenir.

Her pencere standart olarak bir çerçeveye o çerçeve üzerinde bir başlık çubuğuna, başlık çubuğu üzerinde opsiyonel olarak kapatma,ölçekleme ve simge durumuna alma tuşlarına sahiptir. Bu Windows'un pencere standartıdır. Ama biz gerçekte daha zengin pencerelerle karşılaşabiliyoruz. İşte buda pencerelerin opsiyonelleştirilebilmesi gerçeğini ortaya koyuyor. Evet pencereler aslında her özellikleri ile değiştirilebilecek nesnelerdir.

Windows'da pencere oluşturmak istersek yapmamız gereken bazı zorunlu haller vardır onlar her pencere için bir ana prosedür olan WinMain proceduru ve o pencereye gelecek mesajları irdeleyecek WndProc prosedürü. Bu ikili bir pencerede birlikte olmak zorundadırlar. Biri ki bu WinMain oluyor Pencere ve özelliklerini ayarlayıp pencereyi kullanıcıya sunar ve gelen her isteği dinler, diğer yani Wndproc ise bu gelen mesajlara göre programcının tepkisini yansıtır. Aslında pencere konusunu biraz daha açarsak, bir pencere oluşumu için gerekenler şunlardır.

1. Win32'nin programımıza bağlı pencere ile iletişime geçebilmesi için bir instance handle alınır. Bu handle vasıtası ile penceremizin ana fonksiyonuna ulaşırız.
2. Penceremiz için bir class name ve de bir class yapısının içini oluşturmalıyız. Bu class, penceremizin temeli niteliğindedir. Penceremiz için gereken görsel ve yapısal ayarların geneli burada yapılmalıdır. Örneğin: Penceremize gelen mesajları hangi prosedürün inceleyeceği, mouse imlecinin şekli,arkaplan rengi gibi çoğunu örnek kodumuzda da göreceğiniz ayarları bu sınıfta tanımlarız.
3. Oluşturduğumuz Class'ı Register etmeliyiz. Bu RegisterClassEx api'si ile yapılır. Böylece penceremizi oluşturduğumuzda ne tür bir yapı ile çalışacağını windows'a belirtmiş olacağız.
4. Penceremizi oluştururuz. CreateWindowEx api'si ile bunu yapabiliriz. Bu komut ile birlikte artı penceremiz hafızada yapısal olarak son şeklini almıştır.
5. Pencere görünür hale getirilir. Hafızada yapısal olarak bitmiş penceremizi ShowWindow komutu ile artık kullanıcılara sunarız.
6. Bir defaya mahsus Windowsun penceremiz için Refreshing işlemi yapmasını sağlarız. Bu sayede penceremiz artık gerçekten desk**pumuzda aktif işlem olur.
7. Penceremiz için istekleri dinleriz. Evet artık penceremiz hazır ve aktif olduğuna göre penceremiz için kullanıcı bazlı veya diğer programlardan gelebilecek istekler için sonsuz bir dinleme haline girmeliyiz. Bunu GetMessage ve DispatchMessage api'leri vasıtası ile yaparız. GetMessage api'si penceremize uğrayan her mesajı Windows'un mesaj kuyruğundan alır ve DispatchMessage gönderir. DispatchMessage işe gelen isteği irdeler ve 2. adımda belirttiğimiz Pencere prosedürüne gönderir.
8. Ve penceremiz ile işimiz bittiğinde onu sonlandırırız.

Şimdi kodu inceleyelim:

.386
.model flat,stdcall
option casemap:none
include \masm32\include\windows.inc
include \masm32\include\user32.inc
include \masm32\include\kernel32.inc
includelib \masm32\lib\user32.lib
includelib \masm32\lib\kernel32.lib

WinMain proto :DWORD,:DWORD,:DWORD,:DWORD

Buraları anlatmıştım o yüzden es geçiyorum.

.data
ClassName db "SimpleWinClass",0
AppName db "Our First Window",0

ClassName pencereler için çok önemlidir. Çünkü her pencere Windows iyi bir kategorilendirme yapabilsin diye ve de mesajlaşma sistemi kullanılabilsin için bu class name ve application name ihtiyaç duymaktadır . Hani bilirsiniz kendi uygulamanızdan başka bir uygulamaya mesajlar gönderirsiniz FindWindow ile bu iş, işte böyle yürür.

.data?
hInstance HINSTANCE ?
CommandLine LPSTR ?

hInstance daha öncede bahsettiğim gibi Windows'un programımızın varlığını bilsin için ve kendi içinde haberleşmelerde kullanması hasebiyle kullanmak zorunda olduğumuz bir değer. Bu değer Win32 tarafından bize sağlanan 32 bitlik sayısal bir değerdir ve çoğunlukla win32 altında bu değer programımızın hafızadaki doğrusal adresidir.

CommandLine ise tamamen programcının isteğine bağlı tek amacı programınıza dışarıdan gelen komut parametrelerini almak olan bir api'dir. Örneğin programınızın adının spy.exe olduğunu düşünürsek, kullanıcı bu programa doğrudan çalıştırma yoluna gitmeyip parametre ekleyerek(ör:spy.exe minimize) çalıştırırsa siz bu ilave parametreyi CommandLine sayesinde programınızın içerisinde değerlendirip tepki verebilirsiniz.

.code
start:
invoke GetModuleHandle, NULL
mov hInstance,eax
invoke GetCommandLine
mov CommandLine,eax
invoke WinMain, hInstance,NULL,CommandLine, SW_SHOWDEFAULT
invoke ExitProcess,eax
.....
end start

Evet sonunda bizi gerçekten ilgilendiren yere yani kodumuza girmiş bulunuyoruz. Şu unutulmamalıdır ki masm32 ile programla yaparken icra edilecek kodlarımız .code section'da iki ana etiket arasında bulunmalıdır . Bu programımızın iskeleti niteliğindedir. Ön tanımlı olarak masm32'de bu etiketler start: end start olarak tanımlanmıştır ve bu isimleri rahatlıkla dilediğiniz gibi değiştirebilirsiniz. GetModuleHandle komutumuz yukarıda da belirttiğim gibi bizim için windowstan bir başlık alır. Bu komutun icrasından geri dönen değer "'eax"' yazmacında dır.

Not: Windows kendi tanımlaması olarak fonksiyon dönüşlerini eax'ta alır .Bizde bu mimariye uymak zorundayız.

Eax'te ki değeri "'mov"' komutu ile ileride kullanabilmek için hInstance değişkenimize alıyoruz. Ardından GetCommandLine ile programımıza dışarıdan gelen isteklerin bulunduğu hafıza alanına ait değeri yine "'eax"' vasıtası ile alıp CommanLine değişkenimize gönderiyoruz. Dilersek daha sonra bu alandaki verileri değerlendirip özel işlemler yapabiliriz ancak bu örneğimizde böyle bir şey yok.

WinMain penceremizi oluşturmamız için giriş noktamızdır. WinMain ismi tamamen isteğe bağlıdır yine diğerlerinde olduğu gibi bunu da dilediğiniz gibi değiştirebilirsiniz. WinMain 4 parametre alır. Bunlar sırası ile
1. Win32'den aldığımız handle'mız,
2. Win16 günlerinden kalma ama artık kullanılmasının pek esprisi olmadığını düşündüğüm yedek handlemiz,
3. Komut satırı verilerini barındıran parametrelerimizin yerini gösteren pointerimiz.
4. Penceremizin başlangıçta hangi biçimde görüneceğini belirten CmdShow belirtecimiz.

ExitProcess ile de programımızı güvenle terk ederiz.

LOCAL wc:WNDCLASSEX
LOCAL msg:MSG
LOCAL hwnd:HWND

LOCAL komutu biz herhangi bir fonksiyonda yalnızca o fonksiyonun kullanması için değişkenler atadığımızda bizim için stackten hafıza ayırır. Bizi ilgilendiren yer ise penceremiz olduğundan daha öncede bahsettiğim pencere sınıfımız için yapılması gereken bazı tanımlamaların kullanması gereken bir yapının kurulması. Windows bu yapıyı WNDCLASSEX içinde görmek istediğinden onu ve ona point olan "'wc"' değişkenimizi yazdık. Ayrıca mesajlarımız için yine win32 ön tanımlı olarak MSG yapısı ve penceremizi için mesajlaşmalarda kullanacağımız 32 bitlik bir dword olan HWND'yi belirttik. Biz bunları local ile yaptığımızdan bu fonksiyonun dışında başka yerde kullanılmaları söz konusu değildir.

mov wc.cbSize,SIZEOF WNDCLASSEX
mov wc.style, CS_HREDRAW or CS_VREDRAW
mov wc.lpfnWndProc, OFFSET WndProc
mov wc.cbClsExtra,NULL
mov wc.cbWndExtra,NULL
push hInstance
pop wc.hInstance
mov wc.hbrBackground,COLOR_WINDOW+1
mov wc.lpszMenuName,NULL
mov wc.lpszClassName,OFFSET ClassName
invoke LoadIcon,NULL,IDI_APPLICATION
mov wc.hIcon,eax
mov wc.hIconSm,eax
invoke LoadCursor,NULL,IDC_ARROW
mov wc.hCursor,eax

Yukarıdaki komut kümesi tamamı ile sık sık kendinden bahsettiğimiz pencere sınıfımızın içeriğini doldurmak ile ilgilidir. WNDCLASSEX gibi bir yapıyı doldurmamızın amacı ileride aynı şablonda birden fazla pencere oluşturacağımız anlarda bunu bir çok hafıza alanı tüketmektense varolan bir hafıza alanında onu point ederek üretmek olacaktır. Ayrıca yine belirtmeliyim ki WNDCLASSEX yapısı gibi Windows'ta hazır olarak ön tanımlı bir çok pencere sınıfı vardır. Örneğin editbox, button bu gibi sınıflardır ve sadece CreateWindowEx api'si ile herhangi bir yapının içini doldurma gereği olmadan oluşturulabilirler. Şimdi herşeyin neden object olduğunu anlamışsınızdır umarım J . WNDCLASSEX yalın halde aşağıdaki gibi bir yapıdır.

WNDCLASSEX STRUCT DWORD
cbSize DWORD ?
style DWORD ?
lpfnWndProc DWORD ?
cbClsExtra DWORD ?
cbWndExtra DWORD ?
hInstance DWORD ?
hIcon DWORD ?
hCursor DWORD ?
hbrBackground DWORD ?
lpszMenuName DWORD ?
lpszClassName DWORD ?
hIconSm DWORD ?
WNDCLASSEX ENDS

mov wc.cbSize,SIZEOF WNDCLASSEX ile kullanacağımız yapının boyutunu alırız. Bu bound ayarı ve windows'a register ederken doğru tanımlama yaptığımızı garantilemek açısından önemlidir.

mov wc.style, CS_HREDRAW or CS_VREDRAW, ise pencerelerimizin ölçeklendirme işlemlerinin her taraftan yapılabileceğini belirtir. Dilerseniz farklı bir çok seçenek daha eklenebilir. İlgili opsiyonlar Windows.inc dosyasında yer alırlar.

mov wc.lpfnWndProc, OFFSET WndProc penceremize uğrayacak her türlü mesajın işlenmek için hangi prosedüre yollanacağını belirtir.

mov wc.cbClsExtra,NULL işletim sistemi tarafından boş bırakılır . Extra sınıf tanımlamaları için sonradan kullanılması planlanan veriler buraya point edilir.

mov wc.cbWndExtra,NULL. Eğer class tanımlaması ayrı bir dosyada (*.rc) yapılmış bir dialog kutusu sınıfı ile çalışacaksanız bu alanı doldurmak zorundasınızdır.Tabi bizim ilgi alanımız şimdilik yalın pencereler olduğundan boş bırakıyoruz.

push hInstance
pop wc.hInstance ile programımıza ait handle'i pencere sınıfımıza atıyoruz.

mov wc.hbrBackground,COLOR_WINDOW+1 penceremizin arka plan renk seçimini yapıyoruz. Daha fazla renk seçeneği için include dosyaları incelenebilir.

mov wc.lpszMenuName,NULL Eğer pencerenizde tıpkı internet explorerda veya office programlarında olduğu gibi Dosya,Düzen,Görünüm,Yardım gibi ilave araçlar içeren bir menü çubuğu istiyorsanız ilgili yapının adresini de buraya belirtmelisiniz.

mov wc.lpszClassName,OFFSET ClassName. Bu pencere sınıfımızı register edebilmek ve ileride program içinden veya dışından penceremizin görsel ayarları ile oynamak istediğimizde kolayca ulaşabilmemizi sağlayan bir belirteçtir.

invoke LoadIcon,NULL,IDI_APPLICATION
mov wc.hIcon,eax
mov wc.hIconSm,eax ile penceremizin sol üst köşesinde veyahut ta minimize edilirken ki halinde gözükmesini istediğimiz icon'u belirtiriz.

invoke LoadCursor,NULL,IDC_ARROW
mov wc.hCursor,eax burada da tıpkı LoadIcon api'sinde olduğu gibi pencere içinde mouse'mizin almasını istediğimiz şeklini çizdirebiliriz.

invoke RegisterClassEx, addr wc ve artık istediğimiz ayarlamaları yaptıktan sonra bu komut ile penceremizi windows'a kayıt ettiriyoruz.

INVOKE CreateWindowEx,NULL,ADDR ClassName,ADDR AppName,\
WS_OVERLAPPEDWINDOW,CW_USEDEFAULT,\
CW_USEDEFAULT,CW_USEDEFAULT,CW_USEDEFAULT,NULL,NULL,\
hInst,NULL

ve artık penceremizi servise sunma zamanı geldi. CreateWindowEx fonksiyonu 12 parametre içerir . Genel yapısı şöyledir.

CreateWindowExA proto dwExStyle:DWORD,\
lpClassName:DWORD,\
lpWindowName:DWORD,\
dwStyle:DWORD,\
X:DWORD,\
Y:DWORD,\
nWidth:DWORD,\
nHeight:DWORD,\
hWndParent:DWORD ,\
hMenu:DWORD,\
hInstance:DWORD,\
lpParam:DWORD

.dwExStyle: Bu parametreyi biz boş geçtik ama dilerseniz siz pencerenizin sürekli ekranın üstünde görünmesi gibi özel ayarlamalar yapabilirsiniz.

.lpClassName: Bu mutlaka gerekli bir parametredir. Çünkü hangi pencere sınıfının gösterileceğini daha önceden kayıt ettirdiğiniz pencere sınıfı ismini alarak yapmaktadır.

.lpWindowName: Pencerenizin başlık çubuğunda yazmasını istediğiniz string ifadeyi alır. Eğer NULL geçerseniz başlık çubuğunuzda hiçbir şey yazmaz.

.dwStyle: Bu parametreyi doldurmazsak başlık çubuğunda ne kapama nede büyültme ve küçültme tuşları olmazdı. Biz ortak bir tanımlama olan WS_OVERLAPPEDWINDOW ile standart butonların olmasını istedik.

X,Y: Pencerenin sol üst köşesin bulunacağı koordinatı verir. Biz default değeri vererek bu işi windowsun gönlüne bıraktık

.nWidth,nHeight: Kısaca penceremizin eni ve boyu. Biz yine bu işi windowsa bıraktık.

.hWndparent: Eğer aynı özelliklerde ana pencerenize bağlı başka bir alt pencere oluşturmak isterseniz bu değeri ilgili child pencerenin handle ile doldurmalısınız. Bu bir nevi MDI tarzı bir görüntü oluştursa da child pencere hiçbir zaman ana pencerenin boyut sınırları arasında değildir. Yani istediğiniz yere masa üstünde sürükleyebilirsiniz. Ancak bu şekilde üretilen child pencereler ana pencere kapandı anda otomatik olarak kapanacaktır.

.hMenu: Eğer zaten WNDCLASSEX ile pencere sınıfınıza menü eklediyseniz bu parametreyi boş geçebilirsiniz. Menü kullanmak istemediğinizde de boş tur. Ancak menu kullandığınızı ve menu sisteminizi sayısal değerlere sahip id ler ile yönetmek istediğinizi varsayarsak o zaman bu parametre sizin için kullanışlı olabilir.

.hInstance:Bu da yine kalıtımsal olarak hiyerarşik bir şekilde programımızın başında windowstan elde ettiğimiz handle'dir.

.lParam: Kendi tasarladığınız veya ön tanımlı yapıların mesaj olarak pencerenize iletilmesinde kullanacağınız bir parametredir. Örneğin çok pencereli MDI formlarda CLIENTCREATESTRUCT yapısını pencerenize vererek daha sonra client lara GetWindowLong ve SetWindowLong api'leri vasıtası ile değişiklikler yapabilirsiniz.

Evet ayrıntılı bir şekilde de CreateWindowEx api'mizi inceledikten sonra devam ediyoruz.
CreateWindowEx apiside çalıştıktan sonra yine "'eax"' içinde hafıza oluşmuş penceremizi gösteren pointer'i dönderiyor. Artık penceremizin hafıza belli bir imajı çıktı ve bizim onu görücüye çıkartmamızı bekliyor. Bunu yapmanın yolu ShowWindow api'si. ShowWindow api'si iki paramtre alır bunlardan ilki hafıza yer alan ve bize ait olan pencerenin handle'ı, diğer ise pencerenin kullanıcıya sunum şeklini belirten CmdShow parametresi.

İnvoke ShowWindow,hwnd,CmdShow ; diyerek penceremizin kullanıcıya daha önceden WinMain içinde verdiğimiz CmdShow değişkeninde belirtilen niteliğe göre gösterilmesini sağlarız.

Artık penceremiz gözüküyor ancak bu kaba bir tabirle kuru bir yaprak sayfası gibidir. Bu pencereyi kullanıcıdan mesaj alıp verebilmesi için bir kere tetiklememiz lazım ve bunu

İnvoke UpdateWindow,hwnd; ile yapıyoruz.

Artık program emir almaya hazır ancak bu gelecek olan istekleri ne ile **playacak ve ne ile işleyecek. İşte buraya sıradaki adamlarımız mesaj komutları devreye girer. Kısaca şöyledir.

.WHILE TRUE
invoke GetMessage,Addr msg,NULL,0,0
.BREAK .IF(!eax)
invoke TranslateMessage,addr msg
invoke DispatchMessage,addr msg
.ENDW

Gördüğünüz gibi bu işlemi sonsuz bir döngüde yapmak zorundayız aksi halde dakikada binlerce mesaj akan bu win32 sisteminden bize ait olan mesajları almamız olanaksız olurdu.GetMessage api'si penceremize ait bir mesaj gelene kadar bekler. Yani kod akışı orada durur. Ta ki dışarıdan bir müdahale gelsin ve gereken prosesler başlasın.

İnvoke GetMessage,addr msg,NULL,0,0 Win32'nin mesaj kuyruğundan bir mesaj alır ve eğer mesaj bizim penceremize ait ise msg yapısının için doldurarak bir alt yordama havale eder. GetMessage geriye eğer WM_QUIT gibi bir çıkış mesajı alır ve False döndürürse bu döngüden çıkılması anlamına gelir.

.invoke TranslateMessage api'si aslında kullanılması zorunlu olmayan bir api'dir. Tek amacı pencerenize klavyeden gelen klavye vuruşlarını ascii kod olarak doğrudan işlemesidir. Dilerseniz kullanmayabilirsiniz.

İnvoke DispatchMessage ise mesajı alır ve Mesajları işlemekle yükümlü fonksiyona gönderir. Bizim örneğimizde bu WndProc'tur.

mov eax,msg.wParam
ret
WinMain endp

Mesaj döngüsünden çıkılıp program sonlandırılacağında msg yapısının wParam parametresinde çıkış kodu yer alır. Aslında windows bu değer bir daha kullanmaz ama oyunun kuralı gereği güvenli çıkış adına bunu şart koşmuştur. Keşke her işlerinde bu kadar sağlam olsalar J .

WndProc proc hWnd:HWND, uMsg:UINT, wParam:WPARAM, lParam:LPARAM

Bu bizim pencere işleyicimiz. Bu yapının anlaşılması çok önemlidir. Fonksiyonun aldığı parametreler şunlardır.

HWND: Her fonksiyonda olduğu gibi buradada ilgili handle'mızı kullanıyoruz.

.umsg:UINT: Gördüğünüz gibi bu msg yapısı gibi bir şey değil sadece bir sayısal ifade. Windows'ta binlere mesaj vardır ancak programlarımız sadece kendilerini alakadar eden mesajlarla ilgilenirler. Bu UINT değeri sayesinde sadece istediğimiz ilgili mesajın sayısal ifadesine denk gelen mesajla ilgilenebileceğiz anlamına gelir. Örnekleri ileride görecekseniz.

WParam,LParam: Bazı mesajlarla birlikte bazı ilave bilgiler de gelir. Örneğin pencerenizde yer alan bir butona basıldığında bunun mouse ile mi yoksa klavye ile mi gelen bir mesaj olduğunu wParam ve lParam öğeleri ile birlikte gelen değerlerden anlarız.

.IF uMsg==WM_DESTROY
invoke PostQuitMessage,NULL
.ELSE
invoke DefWindowProc,hWnd,uMsg,wParam,lParam
ret
.ENDIF
xor eax,eax
ret
WndProc endp
end start

Bu kısım en can alıcı noktayı içeriyor. Burayı iyi anlamınız şart. Ne demiştik! Her pencere devamlı mesajlarla meşgul olur. Bunu bir debugger'la daha iyi anlayabilirsiniz. Siz pencereleriniz üzerinde işlem yapıldığında gelen isteklere gerekli yanıtı verebilmek adına bir filitre belirlemelisiniz. Örneğin siz programınızı her ne kadar da sakin rahat rahat çalışıyo sansanız da, programınız kendisi ile alakalı veya alakasız binlerce mesaj bombardımanına tutulur. Üziernde fare ile gezerken,bir click atarken, bir yerde bir yere taşırken,klavye ile bazı tuşlara basarken, siz programınıza bu isteklere karşı cevap verecek bir modül yazmasanız dahi bu istekler ile programınız meşgul olur. Peki bu kadar mesaj nasıl oluyorda siz bir şey yapmadan işleniyor. Yani pencereyi sürüklüyorsunuz ve istediğiniz yere gidiyor ama bunu siz yazmamıştınız. İşte bunu DefWindowProc halleder. Bu api sizin programınızda belirttikleriniz dışında programınıza gelen mesajları windows'a yönlendirir ve onun muhatap olmasını sağlar sizde böylece sadece kendi belirlediğiniz mesajlar ile rahatça ilgilenebilirsiniz. Tıpkı .IF uMsg==WM_DESTROY da ki gibi. Biz bu komutla uMsg'ya gelen sayısal değeri WM_DESTROY mesajına denk düşen mesajları işleyeceğimizi belirttik ve eğer mesaj gelirse şu işlemi yap dedik.

Evet bu yazınında sonuna geldik. Yazım hataları ve anlam karmaşası olan yerler için özür dilerim. Bir daha ki bölümlerimizde kaldığımız örneklerden devam etmeye çalışacağız inşAllah.

....

Not: Döküman biraz karışık ve birbirinden kopuk ilerliyor farkındayım. Ancak üzülerek söylemeliyim ki bu dökümanı bile iş aralarından fırsat bulup ilerletebiliyorum o yüzden inşAllah döküman bittiğinde baştan aşağı bir tarama yapıp gerekli düzenlemeyi yapıcam. kod:

Evet uzun süredir dökümanı editliyemiyorum ve sizde haliyle yeni şeyler bekliyorsunuz. Bu kısa ara, benim içinde dökümanda takip etmem gereken yol hakkında inceden inceye düşünmeye itti, ve artık stilde bazı değişiklikler yapmak zorunda hissettim açıkcası kendimi.

Yukarıdaki yazıyı okuyan arkadaşlar artık kısaca assembly ile bir mesaj kutusu nasıl çıkartılıyor biliyor. Bu aşamaya gelene kadar ise hafıza da veriler nasıl ve hangi tanımlayıcılar la tanımlanır, derlenmiş dosyanın hafızadaki şablonu nasıl bir hal alır, Stack nedir,section nedir,veriler hafızada nasıl dizilir,byte,word,dword tanımlamalar arasındaki fark ve bir çok kafa karıştıran konu artık bana göre kafanızdan silinmiş olmalı. Olmalı ki artık verilen örneklerden ve incelediğiniz kodlardan daha çok şey çıkarabileseniz.

Şimdi benim bu yazıda anlatmak istediklerim ise yine konumuzla bağımlı ve öğrenme sürecinizi maximum seviyeye çıkarmaktır. Örneğin bu yazımızda sizlere Win32 programlama yaparken API'lerin ne olduğu,nasıl çalışıldığı Win32 için olan önemleri ve kategorizasyonları. Kaç çeşit oldukları,kaç şekilde ulaşılabildikleri, hafızada ki konumlarının değişkenlik haritasının tanımı gibi kafanızı darman durman edecek bilgileri anlatmaya çabılayacağım. Ve artık bunları siz iyi kavradıktan sonra hangi dil ile olursa olsun win32 programlam yapmanız çok daha basit olacaktır. Ama tabi ben isterimki programlama dili seçeneğiniz Masm32 olsun .

API'ler

Application Programming Interface(Uygulama Programlama Arayüzü) de derler bu arkadaşa. Ama ben de bir tanım eklersem "Programcıların başka programcılara kıyak olsun "zaten ben bi tane yazmışım gariplerim uğraşmasın" diye ve üstelik kendi programlarının veya yapılarınında bütünlük garantisi olsun diye geliştirip export ettikleri bir fonksiyonlar destesi" diyebiliriz. Şöyleki siz kullandığınız işletim sisteminde olmayan bir disk onarım programı yazdınız ama dedinizki "yaw ben bunun görselliğini iyi yapamadım hem bu fonksiyonları yazana kadar göbeğim çatladı bi de kullanılabilirliğilemi uğraşacaktım bi çok yeride eksik kaldı,banane canım: "ederim işlevsel fonksiyonları export uğraşsın başkası "" derseniz bu yaptığınız şeye api denir. millet sizin dll'yi çeker programına import eder ve o fonksiyonları kullanır ve sizinkinden daha janjanlı program yazar ise o vatandaş sizin api'lerle bu işi yaptı demektir.Ve üstelik bu sayede de hem sizin geliştirdiğiniz teknoloji dehası kodlarınız bütünlüğü ve yapısallığı ile korunmuş olacak hemde sizin şablonunuz üzerinden kim bilir daha ne proglar geliştirlecek.

İşte Win32 Api'leride kendi yeteneklerini programcılara sunan geniş bir yelpazeyle yapar bu API işini. Aslında buna pek sunmak değilde dayatmak desek daha yerinde olur. Yani win32 açıkcası programcıların ince mevzularla kendi başlarına fazla haşır neşir olmasını istemez ve illa benim yeteneklerimi kullan der. Örneğin winnt serisinde seri porta dahi direk çıkış yapamazsınız illa bunu win32api leriyle yapıp bill gates'i rahatlatmanız lazım .

API'ler yukarıda yapılarından da bahsettiğimiz gibi programcısının yazdığı ve export ettiği bir fonksyionlar yumağıdır ve bu api'ler executable dosyalar içerisinde hizmet etmek için depolanırlar. Kernel32.dll,ntdll.dll,gdi32.dll,user32.dll ve bazı *.exe'lerin içlerinde hayatlarını idame ettirirler. Windows amca bu api'leri bazı kategorilere ayırmıştır. örneğin

Bir nesne veya dosya oluşturuken
Bir dosya ararken
Parametre yollar veya alırken
Sürücülerle çalışırken
Programlar arası veri transferi yaparken
Programdan girerken veya çıkarken
Hafıza ayırırken
Sistem mesajlarıyla boğuşurken
vb.. daha buna benzer veya daha farklı yaklaşık 949 ince tefferuatlı iş için KERNEL32.DLL

String çevrim işleri yaparken
Kullanıcı etkileşimli dialoglar görüntülerken
Klavye düzeni ve mouse hareketleriyle haşır neşir olurken
Cut+copy+paste işlemlerini yönetirken
Ekrana kalıp şekiller çizerken
Mesajların istenilen yerlere yönlendirmesini sağlarken
Başka programlara erişirken
ekrana yazı yazdırıken
vb.. daha buna benzer veya daha farklı yaklaşık 732 ince tefferuatlı iş için USER32.DLL

Fontlarla çalışırken
Ekrana cicili bicili şeyler çıkartırken
grafiklerle boğşurken
vb.. daha buna benzer veya daha farklı yaklaşık 609 ince tefferuatlı iş için GDI32.DLL

gösterilebilir.

Yukarıdakine benzer neredeyse x:\windows klasörünüz altında ki executable sayısına eşit oranda api'ler mevcuttur, ve bunları kullanmak ve keşfetmek sizin programcılık ve ihtiyaç merakınıza doğru orantılıdır.

Benim gibi işi sadece şifre kırmak,exploit yazmak,hinliklerle uğraşmak gibi tembel işleriyle uğraşanlar için yukarıdaki api'ler yeterde artar bile. Ama unutulmamalıdırki iyi bir win32 programcısı api'leri kullandığı programlama dilinin komutları kadar iyi bilmeli ve kullanabilmelidir. Ancak o zaman ortaya yetenkli ve işlevsel bir program çıkar.

Evet kaldığımız yerden devam edersek. Programcılar WinApi'leri ile çalışmadan önce kullandıkları programlam diline hangi api'ler ile çalışacaklar ise bunu compilerlerine belirtmek zorundadırlar. Tabi bazı programlama dilleri bunu otomatik yapmıyor değil ama şunu unutmayınki ne kadar hazır o kadar çok filesize demektir. Sadece size yarayan api'leri import etmeniz hem kodunuzun boyutunu korur hemde hızını.

devam edecek... yoruldum :)

7 yıl sonra gelen edit: yalana bak devam edecek demişim 7 sene geçmiş hala devam edicek :p

Passworks for Enterprise Domain (Active Directory)

noreply@blogger.com (kernelturk) — Tue, 20 Oct 2009 11:16:00 +0300

Büyük ölçekli domain yönetmiş arkadaşlar bilirler, piyasada bilinen mevcut domain member olan computer'lara local admin parolası çakmak için en sık kullanılan yöntem group policyler vasıtası ile bilgisayar ilkesi üzerine basılan script vasıtası ile yapılır. Bir başka yöntem ve biraz daha güvenli olanıda aslında Wmi'lar vasıtası ile yapılanı'dır, ancak onuda aşmanın yolları fazlaca mevcut.

En sık kullanılan ve kolay olan yöntemin scriptler vasıtası ile yapıldığından bahsettik peki ama neden bu bir açık teşkil ediyordu ki? Domain Admin'i olan arkadaşımız Active Directory Users and Computers altından ilgili pc'lerin toplandığı OU üzerinde group policy atarken aşağıdakine benzer bir kodu kullanır:

strPassword = "p455w0rd" 'uygulanacak şifre
set objUser = getobject("WinNT://./Administrator,user") 'hangi user?
objUser.SetPassword strPassword 'şifreyi ata
objUser.SetInfo ' Değişiklikleri kaydet

Artık domaine üye olan her pc açıldığında ilk olarak bu scripti uygular ve böylece local admin şifresi değişmiş olur. Böylece sistem üzerinde yer alan tek tam denetimli kullanıcı güvene alınmış olunur!!!mu acaba?

Bu tip bir password distributed mekanizması uygulanan domaine üye bilgisayar açıldığında ilk olarak üyesi bulunduğu domain server rolünü üstlenmiş pc de bulunan sysvol klasörü üzerinde yer alan computer policylerini barındıran oid klasörüne bağlanır ve adminin aslında group policy editoru vasıtası ile gösterdiği script var ise bunu local yönetici hesap hakları ile çalıştırır ve uygular sonrasında ise tipik gpo ayarları alınır ve oturum açan kullanıcı üzerindeki hakların alınması ile süreç devam eder. İşte bu aşamada burada kritik rol üstlenen sysvol klasörünün public erişime mecburi olarak readonly de olsa açık olması bir zaafiyeti ortaya çıkarıyor. Bu scriptin burada yer aldığını bilen kullanıcı en kısıtlı kullanıcı hakları ile bile çalışsa bu dizine erişerek passwordu ele geçirebiliyor.

Olayın birde ERD Commander tarzı bootable programlar vasıtası ile yapılan local admin parolası sıfırlama kısmı var ki bunun önüne geçmek neredeyse imkansız ancak monitoring uygulamaları ile hemen bu tip bir değişiklik algılanıp denetleyici server'a bildirimi yapılarak suçu işleyen kişinin yakayı ele verdirmesini sağlayabilirsiniz.

Bu aşamada nacizane bende üstüme düşen görevi yapmak için basit bir tool hazırladım. Gelişim aşaması içerisinde Dameware tarzı bir ürün ortaya çıkarmak istiyorum ama bakalım süreç neyi gösterecek. Reklam kuşağını hızlıca geçip kısa bir tanıtımının ardından programımın buglar ve hatalarla dolu ama işinizi görecek sürümünü buradan sunuyorum.

Tüm os'ler ile rahatça çalışabilmesi için en son .net framework olan 3.5 derledim. Bu yüzden çalıştırmadan önce .net framework 3.5'i kurmanızı tavsiye ederin. Kabaca program'ın özellikleri şunlar:

- Bağlantı protokolleri olarak tüm Ldap servislerini çalıştıran server'lardan computer ve user bilgilerini alıp üzerinde işlem yapabiliyor

- Ldap connection için şu an her ne kadar programa Ldap 2 seçeneğini eklesem de sadece Ldap 3 protokolü ile bağlanıyor.

- Yine bağlantı metodları olarak Negotiate, SimpleAuthenticate ve SSL destekli olarak domain server'ina bağlanabiliyor.

- Şimdilik amaca uygun olarak sadece Computer ve User nesnelerini ekledim ancak tüm active directory destekli işleri yapmaya müsait bir taban üzerine inşaa etmeye çalışıyorum

- Tüm domainde ki açık olan pc'lere sıralı olarak istenilen local admin parolasını çakıyor ve raporluyor.

- İstenilen pc'de istenilen local user için parola doğrulama testi yapılabiliyor

- User'lar da parola sıfırlama işlemi yapılabiliyor

- Seçilen pc'ye varsayılan remote monitor tool ile erişim imkanı..

Programla alakalı olumlu/olumsuz görüşlerinizi ve esprilerinizi :p bekler iyi çalışmalar dilerim.

Download link: Passworks Download