the 1st edition: 20220329
gcc 從某個版本之後預設開啟了 –enable-default-pie, 從那一版開始我不知道, 但是 gcc 5 沒有開啟這功能。可以用 gcc -v 來查看有沒開啟這功能。
gcc’s enable “–enable-default-pie” option make you stuck at “relocation R_X86_64_32S against …” error
這個參數主要影響是編譯之後的組合語言是不是和位址有關, 也就是這個變數的位址不是寫死, 是透過一些方法去取得, 所以這個執行檔不管被載入到哪裡, 裡頭的變數都可以正常取得, 如果是寫死這個變數的位址, 那這個執行檔被載入到不同位址時, 這個寫死的變數位址就不見得正確。
這會影響什麼呢? 如果你是單純的使用者就沒什麼差異 (程式執行慢了一點), 我的話有時候要看反組譯的組合語言, 有著 pie 的組合語言會比較難看懂, 所以我一般都會下 -fno-pic, -no-pie 來觀察 objdump 之後的組合語言。
通常會影響到全域變數的觀察。我是透過 bare-metal 程式來觀察 elf, bare-metal 的程式很簡潔, 所以很好觀察 elf 所有欄位。
cb.c L10 定義了一個 bbb 全域變數, L42 ++ 它。
先觀察使用 -fno-pic 編譯出來的版本。
可以從 list 2 L82 看到 bbb 的位址是 0x7d10, 對照 list 1 L22, L23, 可以看到就是把 bbb 做 +1 的動作。
再來看看 list 3, list 4 使用了 -fpic 的版本, bbb 位址在 0x7d6c, 但是在 list 3 卻看不到存取這個位址的程式碼。 list 3 L24 ~ 26 一樣做 bbb +1 的動作, 但用到 edx 是從 L18 來的, 一個很特別的 function - _x86.get_pc_thunk.dx, 細節就不說了, 反正就是運用這個 fuction 間接取得 bbb 的位址。
沒有留言:
張貼留言
使用 google 的 reCAPTCHA 驗證碼, 總算可以輕鬆留言了。
我實在受不了 spam 了, 又不想讓大家的眼睛花掉, 只好放棄匿名留言。這是沒辦法中的辦法了。留言的朋友需要有 google 帳號。