使用 GDB 查看程序的棧空間
昨天我和一些人在閑聊的時候，他們說他們并不真正了解棧是如何工作的，而且也不知道如何去查看棧空間。
這是一個快速教程，介紹如何使用 GDB 查看 C 程序的棧空間。我認為這對于 Rust 程序來說也是相似的。但我這里仍然使用 C 語言，因為我發現用它更簡單，而且用 C 語言也更容易寫出錯誤的程序。
我們的測試程序
這里是一個簡單的 C 程序，聲明了一些變量，從標準輸入讀取兩個字符串。一個字符串在堆上，另一個字符串在棧上。
#include <stdio.h>#include <stdlib.h>int main() {char stack_string[10] = "stack";int x = 10;char *heap_string;heap_string = malloc(50);printf("Enter a string for the stack: ");gets(stack_string);printf("Enter a string for the heap: ");gets(heap_string);printf("Stack string is: %s\n", stack_string);printf("Heap string is: %s\n", heap_string);printf("x is: %d\n", x);}
這個程序使用了一個你可能從來不會使用的極為不安全的函數 gets 。但我是故意這樣寫的。當出現錯誤的時候，你就知道是為什么了。
第 0 步：編譯這個程序
我們使用 gcc -g -O0 test.c -o test 命令來編譯這個程序。
-g 選項會在編譯程序中將調式信息也編譯進去。這將會使我們查看我們的變量更加容易。
-O0 選項告訴 gcc 不要進行優化，我要確保我們的 x 變量不會被優化掉。
第一步：啟動 GDB
像這樣啟動 GDB：
$ gdb ./test
它打印出一些 GPL 信息，然后給出一個提示符。讓我們在 main 函數這里設置一個斷點：
(gdb) b main
然后我們就可以運行程序：
(gdb) b mainStarting program: /home/bork/work/homepage/testBreakpoint 1, 0x000055555555516d in main ()(gdb) runStarting program: /home/bork/work/homepage/testBreakpoint 1, main () at test.c:44 int main() {
好了，現在程序已經運行起來了。我們就可以開始查看棧空間了。
第二步：查看我們變量的地址
讓我們從了解我們的變量開始。它們每個都在內存中有一個地址，我們可以像這樣打印出來：
(gdb) p &x$3 = (int *) 0x7fffffffe27c(gdb) p &heap_string$2 = (char **) 0x7fffffffe280(gdb) p &stack_string$4 = (char (*)[10]) 0x7fffffffe28e
因此，如果我們查看那些地址的堆棧，那我們應該能夠看到所有的這些變量！
概念：棧指針
我們將需要使用棧指針，因此我將盡力對其進行快速解釋。
有一個名為 ESP 的 x86 寄存器，稱為“棧指針”。 基本上，它是當前函數的棧起始地址。 在 GDB 中，你可以使用 $sp 來訪問它。 當你調用新函數或從函數返回時，棧指針的值會更改。
第三步：在 main 函數開始的時候，我們查看一下在棧上的變量
首先，讓我們看一下 main 函數開始時的棧。 現在是我們的堆棧指針的值：
(gdb) p $sp$7 = (void *) 0x7fffffffe270
因此，我們當前函數的棧起始地址是 0x7fffffffe270，酷極了。
現在，讓我們使用 GDB 打印出當前函數堆棧開始后的前 40 個字（即 160 個字節）。 某些內存可能不是棧的一部分，因為我不太確定這里的堆棧有多大。 但是至少開始的地方是棧的一部分。
我已粗體顯示了 stack_string，heap_string 和 x 變量的位置，并改變了顏色：
x是紅色字體，并且起始地址是0x7fffffffe27cheap_string是藍色字體，起始地址是0x7fffffffe280stack_string是紫色字體，起始地址是0x7fffffffe28e
你可能會在這里注意到的一件奇怪的事情是 x 的值是 0x5555，但是我們將 x 設置為 10！ 那是因為直到我們的 main 函數運行之后才真正設置 x ，而我們現在才到了 main 最開始的地方。
第三步：運行到第十行代碼后，再次查看一下我們的堆棧
讓我們跳過幾行，等待變量實際設置為其初始化值。 到第 10 行時，x 應該設置為 10。
首先我們需要設置另一個斷點：
(gdb) b test.c:10Breakpoint 2 at 0x5555555551a9: file test.c, line 11.
然后繼續執行程序：
(gdb) continueContinuing.Breakpoint 2, main () at test.c:1111 printf("Enter a string for the stack: ");
好的！ 讓我們再來看看堆棧里的內容！ gdb 在這里格式化字節的方式略有不同，實際上我也不太關心這些（LCTT 譯注:可以查看 GDB 手冊中 x 命令，可以指定 c 來控制輸出的格式）。 這里提醒一下你，我們的變量在棧上的位置：
x是紅色字體，并且起始地址是0x7fffffffe27cheap_string是藍色字體，起始地址是0x7fffffffe280stack_string是紫色字體，起始地址是0x7fffffffe28e
在繼續往下看之前，這里有一些有趣的事情要討論。
stack_string 在內存中是如何表示的
現在（第 10 行），stack_string 被設置為字符串stack。 讓我們看看它在內存中的表示方式。
我們可以像這樣打印出字符串中的字節（LCTT 譯注：可以通過 c 選項直接顯示為字符）：
(gdb) x/10x stack_string0x7fffffffe28e: 0x73 0x74 0x61 0x63 0x6b 0x00 0x00 0x000x7fffffffe296: 0x00 0x00
stack 是一個長度為 5 的字符串，相對應 5 個 ASCII 碼- 0x73、0x74、0x61、0x63 和 0x6b。0x73 是字符 s 的 ASCII 碼。 0x74 是 t 的 ASCII 碼。等等...
同時我們也使用 x/1s 可以讓 GDB 以字符串的方式顯示：
(gdb) x/1s stack_string0x7fffffffe28e: "stack"
heap_string 與 stack_string 有何不同
你已經注意到了 stack_string 和 heap_string 在棧上的表示非常不同：
stack_string是一段字符串內容（stack）heap_string是一個指針，指向內存中的某個位置
這里是 heap_string 變量在內存中的內容：
0xa0 0x92 0x55 0x55 0x55 0x55 0x00 0x00
這些字節實際上應該是從右向左讀：因為 x86 是小端模式，因此，heap_string 中所存放的內存地址 0x5555555592a0
另一種方式查看 heap_string 中存放的內存地址就是使用 p 命令直接打印 ：
(gdb) p heap_string$6 = 0x5555555592a0 ""
整數 x 的字節表示
x 是一個 32 位的整數，可由 0x0a 0x00 0x00 0x00 來表示。
我們還是需要反向來讀取這些字節（和我們讀取 heap_string 需要反過來讀是一樣的），因此這個數表示的是 0x000000000a 或者是 0x0a，它是一個數字 10;
這就讓我把把 x 設置成了 10。
第四步：從標準輸入讀取
好了，現在我們已經初始化我們的變量，我們來看一下當這段程序運行的時候，棧空間會如何變化：
printf("Enter a string for the stack: ");gets(stack_string);printf("Enter a string for the heap: ");gets(heap_string);
我們需要設置另外一個斷點：
(gdb) b test.c:16Breakpoint 3 at 0x555555555205: file test.c, line 16.
然后繼續執行程序：
(gdb) continueContinuing.
我們輸入兩個字符串，為棧上存儲的變量輸入 123456789012 并且為在堆上存儲的變量輸入 bananas;
讓我們先來看一下 stack_string（這里有一個緩存區溢出）
(gdb) x/1s stack_string0x7fffffffe28e: "123456789012"
這看起來相當正常，對嗎？我們輸入了 12345679012，然后現在它也被設置成了 12345679012（LCTT 譯注：實測 gcc 8.3 環境下，會直接段錯誤）。
但是現在有一些很奇怪的事。這是我們程序的棧空間的內容。有一些紫色高亮的內容。
令人奇怪的是 stack_string 只支持 10 個字節。但是現在當我們輸入了 13 個字符以后，發生了什么？
這是一個典型的緩沖區溢出，stack_string 將自己的數據寫在了程序中的其他地方。在我們的案例中，這還沒有造成問題，但它會使你的程序崩潰，或者更糟糕的是，使你面臨非常糟糕的安全問題。
例如，假設 stack_string 在內存里的位置剛好在 heap_string 之前。那我們就可能覆蓋 heap_string 所指向的地址。我并不確定 stack_string 之后的內存里有一些什么。但我們也許可以用它來做一些詭異的事情。
確實檢測到了有緩存區溢出
當我故意寫很多字符的時候：
./testEnter a string for the stack: 01234567891324143Enter a string for the heap: adsfStack string is: 01234567891324143Heap string is: adsfx is: 10*** stack smashing detected ***: terminatedfish: Job 1, './test' terminated by signal SIGABRT (Abort)
這里我猜是 stack_string 已經到達了這個函數棧的底部，因此額外的字符將會被寫在另一塊內存中。
當你故意去使用這個安全漏洞時，它被稱為“堆棧粉碎”，而且不知何故有東西在檢測這種情況的發生。
我也覺得這很有趣，雖然程序被殺死了，但是當緩沖區溢出發生時它不會立即被殺死——在緩沖區溢出之后再運行幾行代碼，程序才會被殺死。 好奇怪！
這些就是關于緩存區溢出的所有內容。
現在我們來看一下 heap_string
我們仍然將 bananas 輸入到 heap_string 變量中。讓我們來看一下內存中的樣子。
這是在我們讀取了字符串以后，heap_string 在棧空間上的樣子：
需要注意的是，這里的值是一個地址。并且這個地址并沒有改變，但是我們來看一下指向的內存上的內容。
(gdb) x/10x 0x5555555592a00x5555555592a0: 0x62 0x61 0x6e 0x61 0x6e 0x61 0x73 0x000x5555555592a8: 0x00 0x00
看到了嗎，這就是字符串 bananas 的字節表示。這些字節并不在棧空間上。他們存在于內存中的堆上。
堆和棧到底在哪里？
我們已經討論過棧和堆是不同的內存區域，但是你怎么知道它們在內存中的位置呢？
每個進程都有一個名為 /proc/$PID/maps 的文件，它顯示了每個進程的內存映射。 在這里你可以看到其中的棧和堆。
$ cat /proc/24963/maps... lots of stuff omitted ...555555559000-55555557a000 rw-p 00000000 00:00 0 [heap]... lots of stuff omitted ...7ffffffde000-7ffffffff000 rw-p 00000000 00:00 0 [stack]
需要注意的一件事是，這里堆地址以 0x5555 開頭，棧地址以 0x7fffff 開頭。 所以很容易區分棧上的地址和堆上的地址之間的區別。
像這樣使用 gdb 真的很有幫助
這有點像旋風之旅，雖然我沒有解釋所有內容，但希望看到數據在內存中的實際情況可以使你更清楚地了解堆棧的實際情況。
我真的建議像這樣來把玩一下 gdb —— 即使你不理解你在內存中看到的每一件事，我發現實際上像這樣看到我程序內存中的數據會使抽象的概念，比如“棧”和“堆”和“指針”更容易理解。
更多練習
一些關于思考棧的后續練習的想法（沒有特定的順序）：
- 嘗試將另一個函數添加到
test.c并在該函數的開頭創建一個斷點，看看是否可以從main中找到堆棧！ 他們說當你調用一個函數時“堆棧會變小”，你能在 gdb 中看到這種情況嗎？ - 從函數返回一個指向棧上字符串的指針，看看哪里出了問題。 為什么返回指向棧上字符串的指針是不好的？
- 嘗試在 C 中引起堆棧溢出，并嘗試通過在 gdb 中查看堆棧溢出來準確理解會發生什么！
- 查看 Rust 程序中的堆棧并嘗試找到變量！
- 在 噩夢課程 中嘗試一些緩沖區溢出挑戰。每個問題的答案寫在 README 文件中，因此如果你不想被寵壞，請避免先去看答案。 所有這些挑戰的想法是給你一個二進制文件，你需要弄清楚如何導致緩沖區溢出以使其打印出
flag字符串。
