摘要：

原版本中的問題主要在於除錯過程中，蠻力的痕跡太重，沒有很好地體現常用的除錯準則；本文在原版本的基礎上，融入參考文獻中提及的除錯原則，重新審視和操練該問題，希望儘量體現出除錯中常用的思維法則。

測試的平臺：
1.  ubuntu 9;   gcc 4.4.1;   Gdb 7.0-ubuntu
2.  ubuntu系統安裝在virtual box 3.2.8虛擬機器上；

問題重述：

此處簡要地描述下原來的問題，具體細節檢視原文，我們希望採用stackoverflow aaaabbbbccccddddeeee中的eeee的值覆蓋stackoverflow中overflow到main函式的返回地址，呼叫overflow返回到main函式時，控制

原因何在？

除錯過程：

除錯原則1：要去看，不是去想；

一開始，我們不能假設性地認為問題就出在overflow返回到main的過程中（既然出問題了，就說明系統的行為跟你想象的差別很大，問題發生在何處都不奇怪）而應該實際地單步執行下看看，看看問題到底在什麼地方？通過設定斷點，以及單步執行，我們發現eip的控制並不出現在overflow返回到main的過程，而是main函式退出的

過程；

除錯原則2：理解系統

根據函式的呼叫過程，在call前會將當前主函式的下一句地址壓棧；

退出函式時，mov esp, ebp; pop ebp。最後呼叫ret指令時，將call指令壓入的下一句地址彈出到eip中。根據上述系統模型，大概需要檢視的分支為：

1. main函式返回的地址被修改（也即call main時函式壓入的地址），也即esp所指向的返回地址的內容被改變；

2. 還有，返回地址中的內容沒有改變，esp所指向的返回地址被改變；

除錯原則3：先排除易於驗證的分支；

除錯原則4：非正常的情況與正常的情況進行比較；

上述的兩個除錯分支，其中2的驗證難度小，因為只需要看看esp的值是否改變，所以我們從分支2入手。採用對比的手法，將剛進入main函式後的ebp和esp記錄下來，然後再將main中的ret之前的esp和ebp記錄下來。對比兩者的值是否相同，理論上而言，兩者的值應該相同。以下是我們記錄的資料，在剛進入main函式時，ebp的值為468(省略前面部分數字)，而esp的值為43c；以下是我們記錄的正常版本和溢位版本在執行main中的ret指令之前的ebp和esp值：

圖1 正常的版本

圖2 非正常的版本

由此，我們找到問題所在：esp指向的地址被修改了，原來應該指向43c，當此處卻指向404；此時如果我們檢視下404處的值，可以發現其值正好為0x61616161，這就解釋了為什麼執行完ret指令後，eip的值變為0x61616161。在執行完overflow後，返回到main函式時，overflow之所以能返回到main就說明其esp的設定是正確的；否則overflow中執行完ret指令後，還不知道跳到哪去了。那麼此處只可能在leave指令執行完後，esp的值不正常了。考慮leave指令的等價：

mov esp, ebp

pop ebp

使得esp不正常，也即意味著ebp的值不正常；經過驗證，的確發現ebp的值從overflow返回後變得不正常。在進入overflow之前的ebp的值為0x420，但是從overflow返回到main函式後,ebp的值變為400,根據猜測，esp的確是正常的（要不怎麼返回到main呢?）。那此處的ebp為什麼會不正常？

利用除錯原則1：要去看，而不是去想。我們跟入overflow中去檢視的話，進入overflow時，ebp的值為438，隨後變為418；執行完strcpy函式後，ebp的值恢復為418，esp的值此處

肯定正常（否則不能從strcpy返回到overflow），那我們接下來要看執行完leave後，ebp是否能夠418恢復會438了，遺憾的是並沒有恢復為438，而是變為400；那麼問題只能出在leave指令部分，又因為此處的leave指令等效為：

mov esp, ebp

pop ebp

我們又知道此處的esp恢復的是成功的，那麼問題只能出在pop ebp時；pop ebp時出現問題，也只能是418這個棧裡的值被修改了，原來應該是438被修改為400。經過驗證，的確如此。根據後面的驗證，呼叫strcpy後，將418處的值被修改了，至於怎麼會修改這個位置的，那麼得深入strcpy了。

結論：

本文希望在除錯過程中，儘量展現除錯原則的作用。由於在已有工作上的重新審視，難免陷入從後視鏡看問題的陷阱，讀者大不用深究，關鍵還是原則的運用。

參考文獻：

除錯九法：軟硬體錯誤的排查之道，David J. Agans著，趙俐譯，人民郵電出版社。