Windows etiketine sahip kayıtlar gösteriliyor. Tüm kayıtları göster
Windows etiketine sahip kayıtlar gösteriliyor. Tüm kayıtları göster

PE ve ELF Çalıştırılabilen Dosyalarındaki Bölüm (Section) Kavramı

06:59 , ,

PE (Portable Executable) | ELF (Executable and Linkable Format) 



Bugün için en çok kullanılan çalıştırılabilir (executable) dosya formatları PE ve ELF’tir. PE formatını Microsoft 32 bit Windows sistemleri ilk çıktığında tasarlamıştır.  Microsoft daha önce 16 bit Windows 3.X sistemlerinde NE (New Executable) denilen bir format kullanmıştır. Microsoft’un DOS’ta kullandığı çalıştırılabilen dosya formatı da MZ (by Mark Zbikowski = aynı zamanda exe'yi tasarlayan kişi) formatıydı. 


UNIX/Linux dünyasında da pek çok çalıştırılabilir dosya formatı denenmiştir. "a.out" isimli format uzun süre pek çok UNIX türevi sistemde kullanılmıştır. Linux'te başlangıçta bu formatı kullanıyordu. Artık UNIX türevi sistemlerin büyük kısmı ELF formatını birincil çalıştırılabilen format olarak desteklemektedir. Ayrıca bir işletim sistemi birden fazla çalıştırılabilen dosya formatını destekliyor olabilir. Örneğin Linux sistemleri ELF formatının yanı sıra hala klasik "a.out" formatını da desteklemektedir. Windows’un pek çok versiyonu NE ve MZ formatlarını da desteklemiştir. PE ve ELF formatlarının 32 bitlik ve 64 bitlik birbirine çok benzeyen biçimleri de vardır. Böylece bazen bu formatlar PE32, PE64, ELF32, ELF64 isimleriyle de belirtilmektedir. PE ve ELF formatları genel tasarım olarak aslında birbirlerine benzemektedir. Her iki formatta da önemli bilgilerin dosyanın neresinde bulunduğunu gösteren bir başlık (header) kısmı vardır. Her iki format da bölümlerden (sections) oluşmaktadır. Bu formatlara sahip bir program çalıştırılmak istendiğinde işletim sistemi çalıştırılabilen dosyayı açar formattaki bölümleri inceler ve bölümleri belleğe (RAM’e) yükler.



İşletim sisteminin çalıştırılabilen dosyayı okuyarak çalıştırmak üzere belleğe yükleyen kısmına kavramsal olarak yükleyici (loader) denilmektedir. Bölümler aynı özelliklere sahip ardışıl sayfalardan (page) oluşmaktadır. Bölümlerin birer isimleri vardır. ELF ve PE formatında geleneksel olarak bölümler başında "." olacak biçimde isimlendirilmektedir. Tabii aslında böyle bir zorunluluk yoktur. İşletim sistemi bölümler için bellekte yer ayırıp içini çalıştırılabilen dosyadan ilgili alanları okuyarak yüklemektedir.

PE ve ELF Formatlarındaki Çok Karşılaşılan Bölümler



PE ve ELF formatlarında en çok karşılaşılan bölümler şunlardır:

.text Bölümü: 

Bir programın bütün makine kodları (yani kaynak kodları) bu bölümde bulunur. Yani yukarıdaki C programında programdaki main, foo, bar ve tar fonksiyonlarının kodları .text bölümüne yerleştirilmektedir.

.data Bölümü:

Bu bölümde ilk değer verilmiş global değişkenler ve static yerel değişkenler tutulmaktadır. Yani örneğin yukarıdaki C programında g_a ve count değişkenleri derleyici tarafından tipik olarak ".data" bölümünde tutulacaktır. Derleyiciler ilk değer verilmiş global değişkenleri ilk değerleriyle birlikte çalıştırılabilen dosyanın ".data" bölümüne yerleştirirler. İşletim sisteminin yükleyicisi de onları bu bölümden alıp blok olarak fiziksel belleğe yüklemektedir. Bu nedenle ".data" bölümündeki değişkenlerin çalıştırılabilen dosyada yer kaplamaktadır. Ancak bazı çalıştırılabilen dosya formatları bölümler içerisinde hangi ilk değerden ne miktarda olduğunu tutma yeteneğine sahiptir (örneğin Windows’un PE formatı böyledir). Böylece aşağıdaki gibi global bir dizi bu sistemlerdeki çalıştırılabilen dosyalarda çok fazla yer kaplamayabilir:

int g_x[1000000] = {1, 2, 3};

Ancak ELF gibi bazı formatların bu yeteneği yoktur. Dolayısıyla bu formatlarda yukarıdaki dizinin hepsi ".data" bölümünde ilk değerleriyle bulunacak, dolayısıyla bu da çalıştırılabilen dosyanın uzunluğunu büyütecektir.

.rdata | .rodata Bölümleri: 

PE formatındaki ".rdata", ELF formatındaki ".rodata" bölümleri global ve static read-only verileri tutmak için düşünülmüştür. String ifadeleri genellikle bu sistemlerdeki derleyiciler tarafından bu bölümlerde saklanmaktadır. Örneğin yukarıdaki C programında g_b, g_name ve ival değişkenleri derleyici tarafından tipik olarak ".r(o)data" bölümünde tutulacaktır. Windows ve Linux’un yükleyicileri bu bölümlerdeki bilgileri "read-only" sayfalara yüklerler. Dolayısıyla programın çalışma zamanı sırasında buradaki değerler değiştirilmek istenirse exception (page fault) oluşur.

.bss Bölümü: 

Bu bölümde ilk değer verilmemiş global değişkenler (g_c, g_d) ve ilk değer verilmemiş static değişkenler tutulmaktadır. Bunlara ilk değer verilmediği için bunların çalıştırılabilen dosyalarda boşuna yer kaplamasına gerek de yoktur. PE ve ELF formatlarında bu bölümün yalnızca uzunluğu çalıştırılabilen dosya içerisinde tutulur. İşletim sisteminin yükleyicisi bu uzunluğa bakarak ".bss" bölümünü bellekte (RAM) tahsis eder ve orayı sıfırlar. (C ve C++’ta ilk değer verilmemiş global ve static yerel nesnelerini içerisinde 0 değeri bulunmaktadır. || bss alanının sıfırlanması henüz akış main fonksiyonuna girmeden derleyicilerin başlangıç kodları (startup codes) tarafından da yapılabilmektedir.)


32 Bit Intel Ailesinde çağırma biçimi (calling convention) kavramı

06:53 ,
Fonksiyonların çağrılması ve geri dönüş değerlerinin alınması konusundaki belirlemelere çağırma biçimi (calling convention) denilmektedir. Derleyicilerin bir fonksiyonu derlerken stack'e parametreleri hangi sirayla push edeceginin veya parametrelerin kullanılacak register'a hangi sıraya göre atılacağı gibi kuralların belirlendiği modeldir. Dolayisiyla farkli diller arasinda veya farklı ortamlar arasinda kullanilacak olan fonksiyonlarin bildiriminde bunu belirtmek gerekir.


Her programlama dilinde veya sistemde farklılık gösterebilir. Her dillin kendine ait çağırma biçimi olabilir hatta assembly ile istedigimiz biçimde convention oluşturabilir ve kullanabiliriz. Fakat bunların taşınabilir ve farkllı dillerle kullanılabilir olması durumunda standartlara uyma yükümlülüğü vardır. Özetle şu sorulara cevap bulmaya çalışır:

  • Çağrılan fonksiyon hangi yazmaçları bozma hakkına sahiptir, hangi yazmaçları korumak zorundadır?
  • Çağıran fonksiyon ile çağrılan fonksiyon arasında parametre aktarımı nasıl yapılacaktır?
  • Çağrılan fonksiyonun geri dönüş değeri çağrılan fonksiyona nasıl aktarılacaktır?
  • Parametre aktarımı için Stack kullanıldı ise stack'i düzenleme işi kime aittir?


Çağırma biçimi konusu C standartlarını ilgilendiren bir konu değildir. Çünkü C standartları böylesi aşağı seviyeli belirlemeleri derleyicilere bırakmıştır. Dolayısıyla çağırma biçimlerini oluşturmak için gereken anahtar sözcükler derleyicilerde bir eklenti (extension) biçiminde bulunurlar. Çağırma biçimlerine ilişkin anahtar sözcükler genel olarak tür belirten sözcük ile fonksiyon isimlerinin arasına yerleştirilmektedir. Örneğin:

  • Microsoft derleyicilerinde çağırma biçimleri yukarıdaki örnekte olduğu gibi iki alt tire ( __ ) ile başlayan anahtar sözcüklerle temsil edilmektedir. 

void __cdecl foo(int a, int b) {
   
}


  • gcc derleyicilerinde ise fonksiyon özellikleri (function attributes) biçimindeki bir sentaks ile temsil edilir. 

void __attribute__((cdecl)) foo(int a, int b) {
   
}

API ve ABI Kavramları Üzerine

Yazılımların tüm mimarilerde çalışması ve geriye doğru uyumlu (backward compatibility) olması en çok istenen özelliklerdir. Geliştirilen yazılımın belirli bir dağıtım veya mimariye bağımlı olmayıp, taşınabilir olması büyük kolaylık sağlayacaktır. Sistem seviyesinden bakıldığında taşınabilirlikle ilgili 2 farklı özellik bulunması gerekir. Bunlar;
  • Application Programming Interface (API)
  • Application Binary Interface (ABI)
Şimdi sırasıyla bu kavramları inceleyelim;

ABI ( Application Binary Interface )

ABI, yazılım bileşenleri arasında belirli bir mimari için amaç dosyalar (object file) arasında arayüz  (interface) tanımlamaktadır. ABI demek ayrı ayrı derlenmiş modüllerin bir arada çalışabileceklerine dair alt seviyeli ve detaylı teknik kurallar bütünüdür. ABI uygulama bileşenleri arasında makine kodu seviyesinde uyumluluğu sağlar. Bu uyum korunduğu müddetçe aralarında etkileşim bulunan yazılım bileşenlerinin arka planı değişse de yeniden derlenmeye ihtiyaç duymaksızın eskisi gibi kulanmaya devam ederler.

  • Fonksiyonların nasıl çağrılacağı (calling convention), 
  • Parametrelerin nasıl geçirileceği, 
  • Yazmaçların kullanım şekilleri,
  • Sistem çağrılarının gerçekleştirilme biçimi, 
  • Amaç dosyaların bağlanması (linklenmesi), 
  • Amaç (object dosya) formatı gibi konular ABI kavramı içerisinde değerlendirilebilir. 
Yazılım geliştirme sürecinde ABI kavramı çok karşımıza çıkmaz. Kullanılan geliştirme araçları hedef platform için belirlenen ABI kurallarına uygun kod üretirler. Alt seviye işler yapanlar için bu genelleme doğru değildir. Sistem düzeyinde kod geliştirmek isteyenlerin üzerinde çalıştığı ve diğer çalışmasını istediği sistemlerin ABI standartlarını bilmesi gerekir.


API ( Application Program Interface )

API, uygulamaların kaynak kod seviyesinde birbirleriyle iletişim kurabilmelerine imkan sağlayan, önceden kararlaştırılmış arayüzler (interface) olarak tanımlanabilir. Genellikle her bir API, daha karmaşık ve alt seviye detaylar içeren bir sürecin, çeşitli arayüzlerle (fonksiyon çağrıları gibi) soyutlanmasını sağlar. Bu şekildeki bir soyutlama üzerinden kullanılan API'yi hizmet olarak veren yazılım bileşenleri güncellense ve alt tarafta yapılan işlemlerle ilgili yöntemler değiştirilmiş bile olsa, API seviyesinde aynı arayüz sağlandığı müddetçe bu API'yi kullanan uygulamalar için bir değişiklik yapılmasına gerek olmayacaktır.




Kısaca bir yazılımın, kullandığı kütüphanelerin,servislerin sonraki versiyonlarında herhangi bir değişikliğe gitmek zorunda kalmadan problemsiz çalışabilmesini sağlayan bir arayüz tanımlanması API kavramının ürünüdür.

Fonksiyon Çağrılarında Yazmaç Değerlerinin Korunması

07:09 , ,

Sembolik makine dilinde bir fonksiyonu CALL ettikten sonra akış geri döndüğünde yazmaçların durumu ne olacaktır? CALL edilen fonksiyon yazmaçların değerlerini değiştirmiş olabilir. Bu durumda CALL etmeden önce çağıran fonksiyon yazmaçlarda belli değerleri saklamışsa CALL işleminden sonra artık o değerlerin yazmaçlarda olmayabileceğini göz önüne almalıdır. İşte bu konuda da çağıran fonksiyonla (caller) çağrılan fonksiyon (callee) bir anlaşma yapabilirler. Bu anlaşmaya göre çağrılan fonksiyon bazı yazmaçları koruyabilir, bazılarını korumayabilir. Örneğin C derleyicilerinde pek çok çağırma biçiminde çağrılan fonksiyonun EAX, ECX ve EDX yazmaçlarını bozmasına izin verilmiştir. Ancak diğer yazmaçları çağrılan fonksiyon korumalıdır. Yani onların değerleri akış fonksiyona girdiğinde neyse çıktığında da aynı olmalıdır. Tabii bazı yazmaçların korunmasında bir anlaşma yapılmışsa bu durum çağrılan fonksiyonun o yazmaç değerlerini hiç değiştirmeyeceği anlamına gelmez. Çağrılan fonksiyon eğer bu yazmaçların değerlerini değiştirecekse önce onların değerlerini saklaması gerekir. Bunun için stack kullanılmaktadır. Korunması istenen register değerleri fonksiyona girmeden push eder ardından fonksiyondan çıkmadan önce de pop eder geri yükleyebilir. Ancak onları bu biçimde koruma sorumluluğu çağrılan fonksiyona aittir.

Çağıran ve çağrılan fonksiyonların her ikisini de biz yazacaksak hangi yazmaçların çağrılma sırasında çağrılan fonksiyonlar tarafından korunucağını yine biz kendimiz belirleyebiliriz. Eğer biz yalnızca çağrılan fonksiyonu yazacaksak bu durumda çağıran fonksiyonun hangi yazmaçların korunacağı konusundaki beklentisini karşılamamız gerekebilir. Eğer biz yalnızca çağıran fonksiyonu yazacaksak çağrılan fonksiyonun hangi yazmaçları koruduğunu bilmek yine bize fayda sağlayabilir. Örneğin biz programın büyük kısmını C’de yazmış olalım ve oradan sembolik makine dilinde yazmış olduğumuz fonksiyonu çağırmak isteyelim. Bu durumda bizim C derleyicisinin yazmaç koruması konusundaki beklentilerini karşılamamız gerekir. Çünkü derleyici bazı yazmaçların fonksiyon tarafından bozulmayacağı beklentisiyle fonksiyon çağrısından sonra o yazmaçlardaki değerleri kullanıyor olabilir. 

Sonuç olarak ileride karşımıza çokça çıkacak yazmaç değerlerinin korunması ile ilgili kullanılan yöntemler bu şekilde daha anlaşılır hale gelecektir umarım.

32 Bit Windows Sistemler için "Hello World" Assembly Programı


Tamamen sembolik makine diliyle yazılmış ekrana "Hello World" yazısını çıkartan temel assembly  programı Windows'ta şöyle yazılabilir:


  • Aşağıdaki resimde görüleceği gibi ilk adım olan yazılan kodu 1 numaralı komutta olduğu gibi nasm ile derlenebilir:


Buradan ürün olarak HelloWorld.obj dosyası elde edilecektir. Komuttaki –f win32 seçeneği amaç kodun 32 bit Windows sistemleri için COFF formatında olmasını sağlar.

  • Yukarıdaki resimde görüleceği gibi 2 numaralı komutta olduğu gibi Microsoft’un link.exe programı ile link edilmelidir.

Komuttaki /entry:start seçeneği programın başlangıç noktasını belirlemek için kullanılır. HelloWorld.asm programının başlangıç noktası _start etiketinin bulunduğu yerdedir. Windows uygulamaları “GUI” ve “Console” olmak üzere ikiye ayrılmaktadır. Console uygulamalarında işletim sistemi programı yüklendiğinde bir console ekranını kendisi oluşturmaktadır. Console uygulaması için /subsystem:console seçeneği kullanılmalıdır. Link edilecek dosya HelloWorld.obj dosyasıdır. "Hello World" programında kernel32.dll içerisindeki çeşitli API fonksiyonları (sistem fonksiyonları) kullanılmıştır. Bu nedenle link aşamasına "kernel32.lib" isimli import kütüphanesinin dahil edilmesi gerekmektedir. Bu programda üç API fonksiyonu çağrılmıştır. Önce GetStdHandle API fonksiyonuyla (kodun içerisinde 1 numaralı kısım) console ekranının handle değeri elde edilmiş, sonra WriteFile API fonksiyonu (kodun içerisinde 2 numaralı kısım) ile oraya yazma yapılmıştır. Prosesin sonlanması için ExitProcess API fonksiyonuyla (kodun içerisinde 3 numaralı kısım) gerçekleştirilmiştir. C’nin standart exit fonksiyonu da zaten ExitProcess API fonksiyonu çağırır. Ve link işleminden sonra üretilen exe dosya çalıştırıldığında aşağıdaki gibi başarıyla çalıştığı görülebilir.





Assembly' de yazılıp derlenen bir fonksiyonu Windows'ta çağırma

Windows sistemlerde assembly' de yazdığımız bir fonksiyon C içerisinden aşağıdaki gibi çağrılır;


Derleme işlemi yapıldıktan sonra oluşan .obj dosyasını Visual Studio'da açılan C projesine dahil edelim.


 Aşağıdaki gibi örnek bir kod derleme&link işleminin ardından çalıştırıldığında hatasız bir şekilde çalıştığı gözükecektir.


Kısaca fonksiyonun ne yaptığını anlatırsak:
  1. Parametreler stack'e sağdan sola doğru aktarılmış yani fonksiyonla gönderilen iki parametre stack'in üstüne sırasıyla konulmuş.
  2. EBP değeri stack'e konulmuş /*geri dönüş yapıldığında akışın sorunsuz devam etmesi için*/ 
  3. ESP değeri EBP değerine atanmış
  4. EDX'e sağdan ilk parametrenin adres değeri atanmış
  5. EDX'in içinde bir adres bulunmakta bu adresin gösterdiği değer EAX'e atanmış. ( Yani ilk parametrenin değeri EAX'e atanmış )
  6. EAX içindeki değer EBP-4'e konulmuş. ( birinci parametre'nin gösterdiği adresteki değer artık burada )
  7. İkinci parametrenin adresi ECX'e atanmış
  8. İkinci parametrenin değeri EAX'e atanmış
  9. İkinci parametre' nin değeri EDX (edx'in içinde 1. parametrenin adresi var) aracılığıyla 1. parametrenin gösterdiği yere atanmış. (ilk değişim gerçekleşti)
  10. Stack'te saklanan birinci parametre'nin değeri de [ EBP-4 ]  EAX yazmacına atandı. 
  11. ECX yazmacında ikinci parametrenin adresi olduğuna göre şimdi de EAX (birinci parametrenin değeri bunun içindeydi) yazmacındaki değer ikinci parametrenin gösterdiği yere aktarılmış oldu.
  12. EBP'nin değeri de ESP'ye aktarıldı. 
  13. Ardından stack'te tutulan eski ebp değeri de pop ile geri alınmış oldu.  /*geri dönüş yaptığında akışın sorunsuz devam etmesi için*/


Not1: Yukarıdaki işlemlerden anlayacağınız üzere stack'i düzenleme işi çağrılan (callee) fonksiyon tarafından gerçekleştirilmiştir. Fonksiyon çağrılarında stack düzenlemesi önemli bir konudur ve ileride daha detaylı anlatılacaktır.

Not2: Bu swap işlemi daha basit şekilde yazılabilmektedir. Bu yazıda en kısa biçimde kod yazılmaya çalışılmamıştır.