雙擊圖標到執行main函數,這之間發生了什麼?

我們需要運行一個程序或者軟件,雙擊圖標即可完成。不過從你雙擊到程序的窗口產生的這“短暫”的時間內,這背後發生了什麼事?

首先,系統有一個進程監測到了你的雙擊操作,這個進程就是系統shell,沒錯,就是資源管理器explorer.exe,不是IE瀏覽器了,那是另一個進程iexplorer.exe。你可以嘗試打開任務管理器將這個進程結束掉,然後桌面的一切元素都沒有了,任務欄,圖標什麼的都消失了。只剩下牆紙一張,此時,右鍵菜單也不復存在···因爲平時負責這些東西的explorer.exe已經被你幹掉。要恢復的話,在任務管理器中新建任務,運行explorer.exe即可。

系統shell感知你雙擊的操作後,取得你雙擊對象的完整路徑,然後最終會調用一個叫做CreateProcessA/CreateProcessW的函數來創建一個新的進程。這個函數是ring3上的API函數,在內核中,即ring0裏,與之對應的是NtCreateProcess函數來完成創建進程的任務(此爲Windows 2000的做法,XP和Win7後稍有差別)。閱讀WRK的源碼可以知道,NtCreateProcess對參數做一個簡單的驗證隨即轉而調用NtCreateProcessEx。再看NtCreateProcessEx的源碼,可以發現,真正完成進程創建的是PspCreateProcessa函數。所以說,你所雙擊而運行的所有進程都是資源管理器的子進程。

懂點進程知識的應該知道,創建進程的幾個關鍵是建立新的運行環境,即建立4GB虛擬地址空間給進程使用,然後創建進程內核對象,以及內核管理進程的數據結構,這包括內核層的KPROCESS和執行體層的EPROCESS。然後是主線程的創建以及相關內核數據結構,同樣是內核層的KTHREAD和執行體層的KTHREAD。主線程創建完成後將兩個內核對象的句柄即進程ID和主線程ID封裝在PROCESS_INFORMATION結構體中,然後CreateProcess函數返回。創建進程過程完成。這一部分主要是內核來完成,大概過程如此,細節過程這裏不展開了。

主線程創建後,就得到了時間片,開始參與系統的線程調度。那麼程序從哪裏開始執行呢。PE文件中有一個OEP的術語描述的便是這個概念,OEP便是指的程序入口點。所謂入口點便是顧名思義就是主線程最開始執行的地方,許多病毒加殼技術其中一點就是對這個OEP進行處理。現在,我們來使用PEID來看一個程序(VC8.0編譯)的OEP如圖:

圖片

0x00011078乃是RVA(相對虛擬地址),要看在進程地址空間中的起始地址,還得加上PE文件的映射基址,默認爲0x00400000,不過,可以通過編譯器選項進行調整。不知道也沒關係,將程序放入OllyDbg,在內存映射中可以看到程序的映射基址:

圖片

由圖看到映射基址是0x00400000。那麼由前面所述,程序執行的第一條指令應該位於0x00400000  +  0x00011078  =  0x00411078。沒錯,就是這樣。切換到OllyDbg的主窗口,我們發現了,程序確實初始停在了這裏,並且這裏是一條jmp指令。

圖片

我們到Jmp的目的地0x00411800去看看那裏是什麼東東?

圖片

這是什麼東西?先賣個關子,總之,這裏是程序進來之後真正做的第一件事。

換個思路,我們打開VS2008寫一個簡單的程序,程序做什麼並不重要,我們要看它的啓動原理。

圖片

注意看調用堆棧窗口,因爲我是使用UNICODE編碼環境,故 _tmain()就是wmain(),如果是ANSI編碼就是最開始學程序時的 main()函數了。以前寫程序就想過一個問題,我們寫的所有函數都會被我們自己直接或間接調用,但有一個函數例外,那就是 main()函數。我們寫了它但從不會去調用它,事實上也不可能去調用它,它是我們寫來供操作系統調用的。這個說法很籠統,操作系統調用是什麼意思?今天就來弄清這個疑問。從調用堆棧看到,我們的wmain函數是被_tmainCRTStartup函數調用的,這是個什麼東西?再往前推是wmainCRTStartup調用的_tmainCRTStartup。這兩個函數是做什麼的,他們之間有什麼關係?雙擊調用堆棧裏的項即可轉到對應的源代碼,我們可以發現,這兩個函數是在crtexe.c文件中實現的。閱讀源碼可以發現,有四個啓動函數分別是:

  • mainCRTStartup()       ANSI  +  控制檯程序
  • wmainCRTStartup()       UNICODE  +  控制檯程序
  • WinMainCRTStartup()    ANSI  +  GUI程序
  • wWinMainCRTStartup()    UNICODE  +  GUI程序

這一點在 《windows核心編程》 中也有提到。不過我們可以更進一步一窺它們的實現代碼:

圖片

就這麼簡單,先調用了 __security_init_cookie(),然後是我們前面看到的 _tmainCRTStartup()

第一個函數是做什麼的呢?這個是微軟在VS2003後引入的防止緩衝區溢出攻擊的技術。簡單的說就是在調用函數的時候在棧裏安裝一個隨機的cookie值,這一cookie值在內存的一個地方有備份,函數調用完成後需要檢測這個cookie和備份的一不一致,以此來判斷有沒有棧溢出發生。那麼,這個函數就是來初始化這個備份區域的數據的。

然後第二個函數調用 _initterm()進行全局變量、對象初始化。之後,我們可以看到纔是真正調用了我們的main()/wmain()/WinMain()/wWinMain()的地方。饒了一大圈,回答了開始的疑問了。

圖片

這兩個函數是鏈接器在生產可執行文件的時候給我們鏈接進來的。

至此,我們來看看第一個函數wmainCRTStartup的彙編代碼。如圖:

圖片

請注意和我們前面使用OllyDbg調試時的圖對比:

圖片

發現沒有?一樣的!我們之前留的那個問題的答案想必已經出來了,程序一進來從OEP處執行了jmp指令,這條指令轉向了wmainCRTStartup開始了程序真正的起點!

小結:編譯生成的exe文件,雙擊運行後,建立新進程的地址空間,然後主線程開始運行,程序一進來通過jmp指令來到前面列出的四個啓動函數,它們進行 __security_init_cookie操作後便調用最終的啓動器 _tmainCRTStartup。這個啓動器幹了幾件大事,分別是,使用GetStartupInfo獲取進程啓動信息,然後使用 _inititem初始化全局變量和對象,最後調用我們main、wmain、WinMain、wWinMain進入我們的程序。。。

說明:這裏談到的是使用VC編譯器生成的exe文件形態,如果採用其他編譯器,甚至直接採用彙編程序情況就不同了。甚至於 .net平臺的託管程序運行於CLR上,則又是另外一回事了。

 

內存分頁不就夠了?爲什麼還要分段?

關於內存訪問你可能聽過分段,分頁,還有段頁式。

但是爲什麼要分段?又爲什麼要分頁?

有了分頁爲什麼還要分段?

這就需要看一看歷史的發展,知曉歷史之後就知道這一切其實都是自然而然的。

這些概念也不是硬塞出來的。

正文

1971 年 11 月 15 日,Intel 推出世界第一塊個人微型處理器 4004(4位處理器)。

隨後又推出了 8080(8 位處理器)。

那時候訪問內存就只有直白自然的想法,用具體物理地址。

所有的內存訪問就是通過絕對物理地址去訪問的,那時候還沒有段的概念。

段的概念是起源於 8086,這個 16 位處理器。

限於當時的技術背景和經濟,寄存器只有 16 位,而地址總線是 20 位。

那 16 的位的寄存器如何能訪問 20 位的地址?

2 的16 次方如果直着來如何能訪問到 2 的 20 次方所表達的數?

直着來是不可能的,因此就需要操作一下。

也就是引入段的概念,讓 CPU 通過「段基地址+段內偏移」來訪問內存。

有人可能就問你這都只有 16 位,兩個 16 位加起來最多隻能表示 17 位呀。

你說的沒錯。

所以再具體一點的計算規則其實是:段基地址左移 4 位(就是乘16)再加上段內偏移,這樣得到的就是 20 位的地址。

比如現在的要訪問的內存地址是0x05808,那麼段基地址可以是 0x0580,偏移量就是 0x0008。

圖片

這樣內存的尋址空間就擴大到 20 位了。

至於爲什麼稱之爲段,其實就是因爲寄存器只有 16 位一段只能訪問 64 KB,所以需要移動基地址,一段一段的去訪問所有的內存空間。

對了,專門爲分段而生的寄存器爲段寄存器,當時裏面直接存放段基地址。

不過漸漸地人們就考慮到安全問題,因爲在這個時候程序之間的地址沒有隔離,我的程序可以訪問你的程序地址,這就很不安全。

於是在 1982 年 80286 推出時,就有了保護模式。

圖片

其實就是 CPU 在訪問地址的時候做了約束,會判斷地址是否在允許的範圍內,會判斷當前的程序對目的地址是否有訪問權限。

搞了個 GDT (全局描述符表)存放所有段描述符。

圖片

段寄存器裏面也不是直接放段基地址了,而是放了一個叫選擇子的東西。

大致可以認爲就是段描述符的索引,也就是通過這個索引去找到段描述符,所以叫選擇子。

這個選擇子裏面還有一點屬性。

圖片

這個 T1 就是標明要去哪個表找,而 RPL 就是特權級了,一共分爲四層,0 爲最高特權級,3 爲最低特權級。

當地址訪問時,如果 RPL 的權限低於目標特權級(DPL)時,就會拒絕訪問,於是就起到了保護的作用。

所以稱之爲保護模式,之前的那種沒有判斷權限的稱之爲實模式。

圖片

當時 80286 的地址總線已經是 24 位,但是用於尋址的通用寄存器還是 16 位,雖然段基地址的位數已經足夠訪問到 24 位(因爲已經放到 GDT 中,且有 24位)。

但是因每次一段只有 64 KB,這樣訪問就很不方便,需要不斷的更換段基地址,於是 80286 很快就被淘汰,換上了 80386。

這是 Intel 第一代 32 位處理器。

圖片

除了段寄存器還是 16 位之外,地址總線和寄存器都是 32 位,這就意味着以前爲了尋址搞的段機制其實沒用了。

因爲單單段內偏移就可以訪問到 4GB 空間,但是爲了向前兼容段機制還是保留了下來,段寄存器還是 16 位是因爲夠用了,所以沒必要擴充。

不過上有政策,下有對策。

雖說段機制保留了,但是咱可以“忽悠”着用,把段基值都設置爲 0 ,就用段內偏移地址來訪問內存空間就好了。

這其實就意味着每個段的起始地址都是一樣的,那就等於不分段了,這就叫平坦模式。

Linux 就是這樣實現的。

那爲什麼要分頁?

因爲分段粒度太粗了,導致內存碎片大,不利於管理。

當時加載到內存等於一個段都得搞到內存中,而段的範圍過大,舉個例子。

假設此時你有 200M 內存,此時有 3 個應用在運行,分別是 LOL、chrome、微信。

圖片

此時內存中明明有 30MB 的空閒,但是網易雲加載不進來,這內存碎片就有點大了。

然後就得把 chrome 先換到磁盤中,然後再讓 chrome 加載進來到微信的後面,這樣空閒的 30MB 就連續了,於是網易雲就能加載到內存中了。

但是這樣等於要把 50MB 的內存來個反覆橫跳,磁盤的訪問太慢了,所以效率就很低。

總體而言可以認爲分段內存的管理粒度太粗了,所以隨着 80386 就出來了個分頁管理,一個更加精細化的內存管理方式。

簡單地說就是把內存等分成一頁一頁,每頁 4KB 大小,按頁爲單位來管理內存。

你看按一頁一頁來管理這樣就不用把一段程序都加載進內存,只需要將用到的頁加載進內存。

這樣內存的利用率就更高了,能同時運行的程序就更多了。

並且由於一頁就  4KB, 所以內存交換的性能問題得以緩解,畢竟只要換一定的頁,而不需要整個段都換到磁盤中。

對應的還有個虛擬內存的概念。

分頁機制構造了一個虛擬內存空間,讓每個進程誤以爲自己掌控所有的內存。

圖片

再具體一點就是每個進程都有一個頁表,頁表中有物理頁號和屬性,這樣尋址的時候通過頁表就能利用虛擬地址找到對應的物理地址。

屬性用來做權限的一些管理。

圖片

就理解爲進程想要內存中的任意一個地址都行,沒問題,反正背地裏偷偷的會換成可以用的物理內存地址。

如果物理內存滿了也沒事,把不常用的內存頁先換到磁盤中,即 swap,騰出空間來就好了,到時候要用再換到內存中。

上面提到的虛擬地址也叫線性地址,簡單地說就是通過繞不開的段機制得到線性地址,然後再通過分頁機制轉化得到物理地址。

最後

至此我們已經知曉了爲什麼有分段,又有分頁,還有段頁式。

一開始限於技術和成本所以寄存器的位數不夠,因此爲了擴大尋址範圍搞了個分段訪問內存。

而隨後技術起來了,位數都擴充了,寄存器其實已經可以訪問全部內存空間了,所以分段已經沒用了。

但是爲了向前兼容還是保留着分段訪問的形式,並且隨着軟件的發展,同時運行各種進程的需求越發強烈。

爲了更好的管理內存,提高內存的利用率和內存交互性能引入了分頁管理。

所以就變成了先分段,然後再分頁的段頁式。

當然也可以和 Linux 那樣讓每一段的基地址都設爲 0 ,這樣就等於“繞開”了段機制。

至此今天的內容就差不多了,這篇文章沒有深入具體的分段和分頁的細節,之後再作一篇文章來闡述細節。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章