EXE dosyasını çalıştırmadan inceleme: PE başlıklarını okumak

Statik triyaj ne yapar, ne yapmaz

Elinize adını tanımadığınız bir .exe geçtiğinde ilk refleks çift tıklamak olmamalı. Dosyayı çalıştırmadan da hakkında çok şey öğrenebilirsiniz, çünkü Windows çalıştırılabilir dosyaları belgelenmiş bir yapıya sahiptir: Portable Executable, kısaca PE. Yükleyicinin dosyayı belleğe almak için okuduğu her alan, siz de aynı baytları okuyabildiğiniz için size açıktır.

Baştan net olalım: statik inceleme bir dosyanın zararsız olduğuna dair karar değildir. Temiz görünen bir PE pekala zararlı olabilir, garip görünen bir PE ise yalnızca eski bir derleyiciyle üretilmiş olabilir. Statik analiz size soru üretir, cevap değil. Şüpheniz sürüyorsa dosya izole bir kum havuzuna ya da çok motorlu bir tarama servisine gider; çalışma makinenize değil.

PE dosyasının anatomisi

DOS başlığı ve stub

Her PE dosyası iki baytlık MZ imzasıyla başlar. Bunun ardındaki 64 baytlık DOS başlığının son alanı e_lfanew, yani gerçek PE başlığının dosya içindeki ofseti. Arada kalan "DOS stub" bugün yalnızca DOS altında çalıştırıldığında "This program cannot be run in DOS mode" yazdıran küçük bir koddur. Stub'ın kendisi ilginç değildir; ilginç olan, bazı derleyicilerin stub ile PE imzası arasına bıraktığı ek verilerdir. Bu boşlukta beklenmedik büyüklükte veri görmek, dosyanın sonradan elden geçtiğine dair ilk ipucu olabilir.

PE imzası ve COFF başlığı

e_lfanew ofsetinde dört bayt bulunur: PE\0\0. Hemen ardından 20 baytlık COFF dosya başlığı gelir ve burada dört alan işinize yarar. Machine hedef mimariyi söyler: 0x014c x86, 0x8664 x64, 0xAA64 ARM64. NumberOfSections bölüm tablosunun kaç satır olduğunu verir; normal bir derleyici çıktısında bu sayı genelde 4 ile 8 arasındadır. TimeDateStamp derleme anını Unix epoch olarak tutar. Characteristics bayrakları ise dosyanın çalıştırılabilir mi yoksa DLL mi olduğunu ve büyük adres alanı desteğini bildirir.

Opsiyonel başlık: aslında zorunlu

Adı yanıltıcıdır, çalıştırılabilir dosyalarda opsiyonel değildir. İlk iki bayt olan magic alanı dosyanın PE32 mi (0x10b) PE32+ mı (0x20b) olduğunu söyler. Fark yalnızca 32 ve 64 bit değildir: PE32+ başlığında BaseOfData alanı yoktur ve ImageBase gibi alanlar 8 bayta çıkar. ImageBase modülün tercih ettiği yükleme adresidir; AddressOfEntryPoint ilk çalışacak kodun sanal adresidir. Subsystem alanı ise dosyanın konsol (3), pencereli GUI (2) ya da sürücü olarak mı çalışacağını belirler. Kendini kurulum sihirbazı diye tanıtan ama konsol alt sistemiyle işaretlenmiş bir dosya, açıklama gerektirir.

Bölüm tablosu

COFF başlığından sonra her bölüm için 40 baytlık bir kayıt gelir: ad, sanal boyut, sanal adres, ham veri boyutu, ham veri ofseti ve karakteristik bayrakları. Alışılmış isimler .text (kod), .rdata (salt okunur veri), .data, .rsrc (kaynaklar) ve .reloc şeklindedir. İki şey dikkat çeker. Birincisi, aynı anda hem yazılabilir hem çalıştırılabilir işaretlenmiş bölümler: çalışma anında kod üreten ya da kendini açan dosyaların klasik izidir. İkincisi, sanal boyutun ham boyuttan çok büyük olması: dosya çalışırken kendini açacak alan ayırıyor demektir.

Import tablosu: davranışa en hızlı bakış

Bir binary hakkındaki en yoğun bilgi import tablosundadır. PE, kullandığı her DLL ve her fonksiyon adını açıkça listeler, çünkü yükleyicinin bunları çözmesi gerekir. Dosyanın ağ kullanıp kullanmadığını, kayıt defterine yazıp yazmadığını, süreç oluşturup oluşturmadığını bu listeden dakikalar içinde anlarsınız.

• ws2_32.dll, wininet.dll, winhttp.dll: ağ trafiği. Çevrimdışı çalışması beklenen bir araçta bunlar açıklama ister.
• advapi32.dll içindeki RegSetValueEx ailesi: kalıcılık veya yapılandırma yazımı.
• CreateProcess, ShellExecute, WinExec: başka program başlatma.
• VirtualAlloc, VirtualProtect, WriteProcessMemory: bellek izinlerini değiştirme ve enjeksiyon kalıpları.
• LoadLibrary ve GetProcAddress ikilisi dışında neredeyse hiçbir import yoksa: gerçek import tablosu gizlenmiştir.

Son madde önemlidir. Kısa bir import tablosu, temizlik değil, genelde paketleme işaretidir. Dosyayı EXE ve PE görüntüleyici ile açtığınızda başlıkları, bölümleri ve import listesini tek ekranda görürsünüz; dosya tarayıcınızda çözümlenir ve hiçbir aşamada çalıştırılmaz.

Entropi ve paketleyiciler

Bölüm başına Shannon entropisi 0 ile 8 arasında bir sayıdır ve baytların ne kadar öngörülemez olduğunu ölçer. Derlenmiş x86 kodu genelde 6,0 ile 6,8 arasında gezinir; sıkıştırılmış ya da şifrelenmiş veri 7,5 üzerine çıkar. Bir .text bölümünün 7,9 olması, içinde makine kodu değil, açılmayı bekleyen bir blok olduğunu düşündürür.

Yüksek entropi tek başına suç değildir: gömülü PNG, sıkıştırılmış kaynaklar ve dijital imzanın kendisi de yüksek entropilidir. Değerlendirmeyi bağlamla yapın. UPX0 ve UPX1 gibi tanıdık paketleyici bölüm adları, entropiyle birlikte ve kısa bir import tablosuyla birleştiğinde tablo netleşir. Paketleme başlı başına zararlı da değildir; ticari yazılım koruma ürünleri de aynı şeyi yapar.

Derleme zaman damgası bir kanıt değildir

TimeDateStamp dosyada düz bir 32 bit sayıdır ve herhangi bir hex düzenleyiciyle değiştirilebilir. 1992 tarihli bir zaman damgası gördüğünüzde "eski program" değil, "bu alan ya sıfırlanmış ya da elle yazılmış" diye düşünün. Bazı derleyiciler yeniden üretilebilir derleme için bu alanı bilerek sabit bir değere ayarlar. Yine de değeri okumak faydalıdır: kaynak zaman damgalarıyla tutarsızlık bir işarettir. Ham epoch sayısını okunur tarihe çevirmek için zaman damgası dönüştürücü yeterlidir.

İmzanın varlığı ile geçerliliği ayrı şeylerdir

Opsiyonel başlığın veri dizinlerinden biri sertifika tablosunu gösterir. Bu dizinin dolu olması dosyanın imzalandığı anlamına gelir, imzanın doğrulandığı anlamına gelmez. Doğrulama için özetin yeniden hesaplanması, sertifika zincirinin güvenilen bir köke kadar takip edilmesi, iptal listelerinin kontrol edilmesi ve zaman damgasının değerlendirilmesi gerekir. Bunu yapan taraf işletim sistemidir. Bir görüntüleyicide "imzalı" ibaresi görmek, yalnızca "burada bir imza bloğu var" demektir. Ayrıca çalınmış sertifikalarla imzalanmış zararlı yazılım örnekleri tarihte defalarca görülmüştür; geçerli imza bile kimliği doğrular, niyeti değil.

Stringler neden yanıltır

Bir dosyanın içindeki okunabilir metinleri çıkarmak kolaydır ve bağımlılık yaratır. Sorun şu ki bu metinlerin çoğu sizinle konuşmak için orada değildir. Derleyici çalışma zamanı kitaplığı, hata mesajları, kaynak dosyalardaki lisans metinleri ve sıkıştırılmış bloklardan tesadüfen okunabilir çıkan baytlar listeyi doldurur. Bir alan adı görmeniz dosyanın oraya bağlandığını göstermez; o metin hiç kullanılmayan bir veri bölümünde duruyor olabilir. Tersi de doğrudur: bağlanacağı adresi çalışma anında üreten bir dosyanın stringleri tertemiz görünür.

Stringleri hipotez üreteci olarak kullanın, kanıt olarak değil. Bulduğunuz bir URL veya IP'yi whois ve DNS kontrolü ile ayrıca inceleyin; dosyanın gerçekten nereye bağlandığını ise ancak izlenen bir ortamda trafiği kaydedip pcap dosyasını okuyarak görürsünüz.

Pratik bir triyaj akışı

1. Dosyanın SHA-256 özetini alın ve not edin. Hash üreteci bunu tarayıcıda yapar; özet, çok motorlu tarama servislerinde arama yapmanın da en temiz yoludur.
2. Başlıkları okuyun: mimari, alt sistem, PE32 mi PE32+ mı, bölüm sayısı.
3. Bölüm tablosuna bakın: yazılabilir ve çalıştırılabilir bölüm var mı, entropi nerede yüksek.
4. Import tablosunu tarayın: ağ, süreç oluşturma, bellek izni değişimi, kayıt defteri.
5. Kaynakları ve sürüm bilgisini karşılaştırın: şirket adı, ürün adı ve simge, dosyanın iddia ettiği kimlikle uyuşuyor mu.
6. İmza bloğunun varlığını not edin, geçerliliğini işletim sistemine doğrulatın.
7. Hâlâ şüphe varsa durun. Dosyayı kum havuzunda çalıştırın veya çok motorlu taramaya gönderin.

Bu akış on beş dakika sürer ve çoğu zaman dosyayı hiç çalıştırmadan kararı verecek kadar bilgi verir. Bir kurulum dosyasının neden ağ kitaplıklarına ihtiyaç duyduğunu açıklayamıyorsanız, cevabı çalışma makinenizde aramayın. Token ve kimlik bilgisi taşıyan araçlarla çalışıyorsanız JWT incelemesindeki aynı ilke burada da geçerlidir: çözümlemek doğrulamak değildir.