2. 程式人生 > >PE檔案格式詳解(4)

PE檔案格式詳解(4)

阿新 • • 發佈：2019-02-04
1.RVA to RAW     PE檔案載入到記憶體時，每個節區都要準確完成記憶體地址與檔案偏移的對映。這種對映便稱為RVA to RAW，實現這個過程需要經過以下的步驟。     1.查詢RVA所在節區。     2.使用公式計算出檔案偏移。     根據IMAGE_SECTION_HEADER結構體，換算公式如下。     RAW - PoniterToRawData = RVA - VirtualAddress RAW  = RVA - VirtualAddress + PointerToRawData 2.IAT（Import Address Table,匯入地址表） IAT儲存的內容與Windows作業系統的核心進、記憶體、DLL結構等有關。（即掌握了IAT便掌握了Windows作業系統的根基）。
1.DLL（Dynamic Linked Library） 載入DLL的方式有兩種：一種是“顯式連結”（Explicit Linking），程式使用DLL時載入，使用完畢後釋放記憶體。另一種是“隱式連結”（Implicit Linking），程式開始時遍一同載入DLL，程式終止時，再釋放佔用的記憶體。IAT提供的機制便與隱式連結有關。     DLL重定位，DLL檔案的ImageBase一般為10000000.比如某個程式使用a.dll和b.dll，OE裝載器先把a.dll裝載到記憶體的10000000（ImageBase）處，然後嘗試把b.dll也裝載到該處。但是由於該地址處已經裝載了a.dll，所以PE裝載器需要查詢其他空白的記憶體空間（ex:3E000000），然後將b.dll裝載進去。這就是DLL檔案的重定位。
2.IMAGE_IMPOT_DESCRIPTOR IMAGE_IMPORT_DESCRIPTOR結構體中記錄著PE檔案要匯入哪些庫檔案。IMAGE_OPTIONAL_HEADER32.DataDirectory[1].VirtualAddress的值即是IMAGE_IMPORT_DESCRIPTOR結構體陣列的起始地址（RVA值）。（第一個4位元組為虛擬地址，第二個4位元組為Size成員。）   注：Import：匯入，向庫提供服務（函式）。                   Export：匯出，從庫向其他PE檔案提供服務（函式）。 程式碼 IMAGE_IMPORT_DESCRIPTOR
typedef struct _IMAGE_IMPORT_DESCRIPTOR{     union{     DWORD    Characteristics;     DWORD    OriginalFirstThunk;    //INT(Import Name Table) address (RVA)     };     DWORD    TimeDatastamp;     DWORD    ForwarderChain;     DWORD    Name;    // library name string address (RVA)     DWORD    FirstThunk;     // IAT( Import Address Table) address (RVA) } IMAGE_IMPORT_DESCRIPTOR; typedef struct _IMAGE_IMPORT_BY_NAME{     WORD    Hint;     // ordinal     BYTE   Name[1];  // function name string } IMAGE_IMPORT_BY_NAME , *PIMAGE_IMPORT_BY_NAME; 執行一個普通程式時往往需要匯入多個庫，匯入多少庫就存在多少個IMAGE_IMPORT_DESCRIPTOR結構體，這些結構體形成了陣列，且結構體陣列最後以NULL結構體結束。   IMAGE_IMPORT_DESCRIPTOR的重要成員如下     專案 含義     OriginalFirstThunk    INT的地址（RVA）     Name  庫名稱字串的地址（RVA）     FirstThunk  IAT的地址（RVA） 注：INT與IAT是長整型（4個位元組資料型別）陣列，以NULL結束（未另外明確指出大小）。         INT中各元素的值為IMAGE_IMPORT_BY_NAME結構體指標（有時IAT也有相同的值）。     INT與IAT的大小應相同。 3.EAT Windows作業系統中，“庫”是為了方便其他程式呼叫而集中包含相關函式的檔案（DLL/SYS）。Win32 API是最具代表性的庫，其中的kernel32.dll檔案稱為最核心的庫檔案。     EAT是一種核心機制，它使不同的應用程式可以條用庫檔案中提供的函式（即只有通過EAT才能準確求得從相應庫中匯出函式的起始地址）。PE檔案內部有且僅有一個用來說明庫EAT的IMAGE_EXPORT_DIRECTORY結構體，並且儲存著匯出資訊。   注：IAT的結構體以陣列的形式存在，且擁有多個成員。即說明PE檔案可以同時匯入多個庫。 可以在PE檔案的PE頭中查詢到IMAGE_EXPORT_DIRECTORY結構體的聞之。IMAGE_OPTIONAL_HEADER32.DataDirectory[0].VirtualAddress值即為結構身體陣列的其實地址（RVA值）。（第一個4位元組為虛擬地址，第二個4位元組為Size成員。）    程式碼  IMAGE_EXPORT_DIRECTORY結構體     typedef struct _IMAGE_EXPORT_DIRECTORY {     DWORD    Characteristics;     DWORD    TimeDateStamp;    //creation time date stamp     WORD  MajorVersion;     WORD  MinorVersion;     DWORD   Name;    //address of library file neme     DWORD   Base;  //ordinal base     DWORD   NumberOfFunctions; //number of functions     DWORD   NumberOfNames;    //number of names     DWORD   AddressOfFunctions;    //address of function start address array     DWORD   AddressOfName;  //address of function name string array  DWORD   AddressOfNameOrdinals;   //address of ordinal array } IMAGE_EXPORT_DIRECTORY, *PIMAGE_EXPORT_DIRECTORY; 其中結構體中的重要成員如下 專案 含義 NumberOfFunctions    實際Export函式的個數 NumberOfNames     Export函式中具名的函式個數 AddressOfFunctions    Export函式地址陣列（陣列元素個數=NumberOfFunctions） AddressOfNames     函式名稱地址陣列（陣列元素個數=NumberOfNames） AddressOfNameOrdinals    Ordinal地址陣列 （陣列元素個數=NumberOfNames）

相關推薦

PE檔案格式詳解(4)

1.RVA to RAW     PE檔案載入到記憶體時，每個節區都要準確完成記憶體地址與檔案偏移的對映。這種對映便稱為RVA to RAW，實現這個過程需要經過以下的步驟。     1.查詢RVA所

PE檔案格式詳解（六）

0x00 前言   前面兩篇講到了輸出表的內容以及涉及如何在hexWorkShop中找到輸出表及輸入DLL，感覺有幾個地方還是沒有理解好，比如由資料目錄表DataDirectory[16]找到輸出表表後以為找到輸入DLL就完了，其實這一流程的最終功能是通過輸入DLL找到輸入DLL呼叫的函

PE檔案格式詳解（五）

0x00 前言   前一篇瞭解了區塊虛擬地址和檔案地址轉換的相關知識，這一篇該把我們所學拿出來用用了。這篇我們將瞭解更為重要的一個知識點——輸入表和輸出表的知識。 0x01 輸入表   首先我們有疑問。這個輸入表是啥？為啥有輸入表？其實輸入表就是記錄PE輸入函式相

PE檔案格式詳解（四）

PE檔案格式詳解（四） 0x00 前言   上一篇介紹了區塊表的資訊，以及如何在hexwrokshop找到區塊表。接下來，我們繼續深入瞭解區塊，並且學會檔案偏移和虛擬地址轉換的知識。 0x01 區塊對齊值   首先我們要知道啥事區塊對齊？為啥要區塊對齊？這個問題

PE檔案格式詳解（一）

在本文中， 我並不打算大講特講PE檔案的構成是什麼，每個欄位是什麼意思， 這些資料可以說在網上是浩瀚如海，到處都是的， 用google一搜， 開啟一看， 基本講解的都是大同小異。 由於pe檔案的結構比較龐大， 結構中套結構， 有的結構多達30多個欄位， 光看這些欄位都讓人夠

PE檔案格式詳解(上)

Windows NT 3.1引入了一種名為PE檔案格式的新可執行檔案格式。PE檔案格式的規範包含在了MSDN的CD中（Specs and Strategy, Specifications, Windows NT File Format Specifications），

PE檔案格式詳解(1)

PE頭由許多結構體組成，接下來分別解釋一下各部分。 1.DOS頭 微軟最初建立PE格式的時候，DOS檔案被人們廣泛的使用，為了實現PE檔案對DOS檔案的相容性。結果是在PE頭的最前面添加了一個I

PE檔案格式詳解(2)

MS-DOS頭部/真實模式頭部 　　如上所述，PE檔案格式的第一個組成部分是MS-DOS頭部。在PE檔案格式中，它並非一個新概念，因為它與MS-DOS 2.0以來就已有的MS-DOS頭部是完全一樣的。保留這個相同結構的最主要原因是，當你嘗試在Windows 3.1以下或MS-

PE檔案格式詳解(六)

匯出資料段，.edata 　　.edata段包含了應用程式或DLL的匯出資料。在這個段出現的時候，它會包含一個到達匯出資訊的匯出目錄。WINNT.Htypedef struct _IMAGE_EXPORT_DIRECTORY {  ULONG Characteristics

PE檔案格式詳解(0)

0.介紹  PE是Windows作業系統性愛使用的可執行檔案格式。它是微軟在UNIX平臺的COFF（Common Object File Format,通用物件格式）基礎上而成的（在Windows

png檔案格式詳解【轉】

5.2.2  PNG影象檔案儲存結構（1） PNG檔案儲存結構的格式可以在http://www.w3.org/TR/REC-png.htm上找到定義。 BMP檔案總體上由兩部分組成，分別是PNG檔案標誌和資料塊（chunks），如表5-8所示。其中資料塊分為兩類：關鍵資料塊（cri

Class 檔案格式詳解

Class 檔案格式詳解 Write once, run everywhere!，我們都知道這是 Java 著名的宣傳口號。不同的作業系統，不同的 CPU 具有不同的指令集，如何做到平臺無關性，依靠的就是 Java 虛擬機器。計算機永遠只能識別 0 和 1組成的二進位制檔案，虛擬機器就是我們編寫的程式碼和計

PNG檔案格式詳解

                PNG檔案結構分析(上：瞭解PNG檔案儲存格式)前言我們都知道，在進行J2ME的手機應用程式開發的時候，在圖片的使用上，我們可以使用PNG格式的圖片（甚至於在有的手機上，我們只可以使用PNG格式的圖片），儘管使用圖片可以為我們的應用程式增加不少亮點，然而，只支援PNG格式的圖片

Android逆向之旅---SO(ELF)檔案格式詳解

第一、前言從今天開始我們正式開始Android的逆向之旅，關於逆向的相關知識，想必大家都不陌生了，逆向領域是一個充滿挑戰和神祕的領域。作為一名Android開發者，每個人都想去探索這個領域，因為一旦你破解了別人的內容，成就感肯定爆棚，不過相反的是，我們不僅要研究破解之道，也要

[一]class 檔案淺析 .class檔案格式詳解 欄位方法屬性常量池欄位 class檔案屬性表 資料型別 資料結構

ClassFile { u4 magic;//唯一作用是確定這個檔案是否為一個能被虛擬機器所接受的class檔案。魔數值固定為0xCAFEBABE，不會改變 u2 minor_version;//唯一作用是確定這個檔案是否為一個能被虛擬機器所接受的class檔案。魔數值固定為0xCAFEBABE，不會

s19檔案格式詳解

1.概述 為了在不同的計算機平臺之間傳輸程式程式碼和資料，摩托羅拉將程式和資料檔案以一種可列印的格式(ASCII格式)編碼成s格式檔案。s格式檔案是Freescale推薦使用的標準檔案傳送格式。編譯完成之後，FreescaleCodeWarrior編譯器將在bin資料夾下自動生成“*.abs.s19”檔案，

Linux下可執行檔案格式詳解

Linux下面，目標檔案、共享物件檔案、可執行檔案都是使用ELF檔案格式來儲存的。程式經過編譯之後會輸出目標檔案，然後經過連結可以產生可執行檔案或者共享物件檔案。Linux下面使用的ELF檔案和Windows作業系統使用的PE檔案都是從Unix系統的COFF檔案格式演化來的

TIFF影象檔案格式詳解(3)

基本TIFF TAGS 本頁主要摘自 http://www.awaresystems.be/imaging/tiff/tifftags/baseline.html。每一個TAG均有原始連結，可以點選檢視詳細的描述。 這些基本Tag是所有TIFF編解碼器必須支援的Tag

SAM檔案格式詳解

生物資訊上的東西，由於發展的時間不長，所以各種標準都不算是廣泛傳播。 尤其是檔案格式之類的，中文版的資料很少，不少英文版的說明也不是很清晰。 這裡對SAM格式進行一下解釋，希望對新人有所幫助。 如下是SAM檔案中的一行 FCC0YG3ACXX:2:1

GZIP壓縮原理分析（04）——第三章 gzip檔案格式詳解（三02） gzip檔案頭

檔案頭由固定長度的部分和擴充套件部分組成，擴充套件部分不一定存在，尤其是網路傳輸使用的HTTP壓縮，如果使用了gzip格式，那麼對應的壓縮報文一般都不帶擴充套件部分。gzip檔案格式通過將頭部中定長部