裝載機(Windows操作系統的一部分)「修補了」開始樣品程序之前導入地址表(IAT),這時候的庫過程的實際地址出現在存儲器位置0x402068和0x402068。請注意,進口存在於部分NOBITS在simple.asm:
section nobits vstart=IMAGEBASE + 2 * SECTIONALIGN align=FILEALIGN
與負荷後進口的部分開始於虛擬地址(基址=爲400000h)+ 2 *(SECTIONALIGN = 1000H)= 0x402000。
這個例子的yasm源是非常不尋常的,圖也不是最好的學習場所PE格式從。請首先閱讀Wikipedia:Portable_Executable(短文)。它鏈接到full documents,所以我只會在這裏做一些簡短的註釋。
您可能還想使用Cheat Engine檢查樣本。啓動simple.exe,然後附加到進程與作弊引擎,按內存查看,然後進入菜單工具 - >剖析PE頭,按鈕,然後信息,看標籤進口。在內存轉儲,去解決00402000(CTRL + 摹輸入:
00402068:E4 39 75 69 5F 47 77 00 00 00 00 65 6B 72 65 6E 33 6C 32 2E
注意在這些位置處的值
- 00402068:0x75BE39E4(我的電腦)= KERNEL32.ExitProcess
的地址
- 00402070:0x77475F69(只在我的情況)= user32.MessageBoxA
的地址
通知文本「KERNEL32 .dll user32。DLL」後,他們的權利。現在來看simple.exe(我會使用Far Manager)的hexdump都與現貨字符串之前同一位置‘kernel32.dll中user32.dll中’。值有
0000000450: 69 74 50 72 6F 63 65 73 │ 73 00 00 00 4D 65 73 73 itProcess Mess
0000000460: 61 67 65 42 6F 78 41 00 │ 4C_20_00_00 00 00 00 00 ageBoxA L
0000000470: 5A_20_00_00 00 00 00 00 │ 6B 65 72 6E 65 6C 33 32 Z kernel32
0000000480: 2E 64 6C 6C 00 75 73 65 │ 72 33 32 2E 64 6C 6C 00 .dll user32.dll
- 0000000468:0x0000204C - DW 0的相對虛擬地址; DB 'ExitProcess的',0
- 0000000470:0x0000205A - 在相對虛擬地址DW 0的; DB「MessageBoxA」,0
loader已經從什麼人在文件中加載到內存中後改變這些值。微軟公司的文件pecoff.doc說:
6.4.4。 導入地址表 導入地址表的結構和內容與導入查找表的結構和內容相同,直到文件被綁定。綁定期間,導入地址表中的條目被導入的符號的32位(或64位)地址覆蓋:這些地址是符號本身的實際內存地址(雖然從技術上講,它們仍然是稱爲「虛擬地址」)。綁定的處理通常由加載器執行。
您是否下載了PE101.zip並檢查了來源?他們很不尋常。 – MKaama