→ Schottky: 這個 exploit 根本不能用吧 11/03 14:46
→ b0920075: 喔喔這個只是測試有沒有跳過去啦,我沒有截送shellcode 11/03 14:49
→ b0920075: 的圖,想說那邊不是我要問的重點 11/03 14:49
→ Schottky: 你的理解沒錯,呼叫時先 push 參數再 push ret address 11/03 14:58
→ Schottky: 所以我覺得是寫 exploit 的人完全弄反了 11/03 14:59
→ Schottky: gets 填資料是由低位址向高位址填,就算 overflow 11/03 14:59
→ Schottky: 也根本不會蓋到 gets 的 return address 11/03 15:00
→ Schottky: 你確定原始的 exploit 真的能用? 11/03 15:01
→ b0920075: 我上面那個只是擷取exploit的一部分而已,原本的測試過 11/03 15:02
→ b0920075: 可以用 11/03 15:02
→ b0920075: 等下補放完整的 11/03 15:03
※ 編輯: b0920075 (140.117.168.190), 11/03/2016 15:35:38
→ Schottky: 這 exploit 還是一樣怎麼看都不對 11/03 15:40
→ Schottky: 通常 padding 也是用 0x90 (NOP) 而不會用 'A' 11/03 15:42
→ Schottky: 不過重點還是 gets 的 return address 並不會被蓋到 11/03 15:42
→ Schottky: 會被蓋到的是 main() 的 return address 11/03 15:42
→ Schottky: 所以我有點好奇,你是怎麼確定這 exploit 可以用的 11/03 15:43
→ b0920075: 呃因為我測過可以用,然後他main ret address被蓋成get@ 11/03 16:04
→ b0920075: plt,所以後面gets的利用應該是自己做一個ret address讓 11/03 16:04
→ b0920075: 他跳而不是一般的覆蓋 11/03 16:04
→ b0920075: 至於nop sled我個人習慣也是寫\×90啦,可是那是因為之 11/03 16:06
→ b0920075: 前做的需要跳回buf讓他滑,如果沒有要跳回buf應該填A也 11/03 16:06
→ b0920075: 沒關係 11/03 16:06
→ Schottky: 那聽起來被蓋到的是 main 而不是 gets 的 return addres 11/03 16:13
→ Schottky: 但還是很不對勁,buf 裡都填滿 A 了,shell code 是寫到 11/03 16:15
→ Schottky: 哪裡去? 11/03 16:15
→ Schottky: 你既然知道 nop sled 那應該知道一般就是把 shell code 11/03 16:16
→ Schottky: 填在 stack 的 char buf[100] 裡面,免得出別的槌啊... 11/03 16:16
→ b0920075: 因為有開aslr,所以應該是寫到全域變數(即使開aslr也不 11/03 16:17
→ b0920075: 會變)那個section裡面吧 11/03 16:17
→ b0920075: 因為global不會變,所以盡量寫在global裡面,講師是這樣 11/03 16:18
→ b0920075: 講的 11/03 16:18
→ Schottky: Intel 組合語言裡叫他 data segment ... 我懂你的意思了 11/03 16:19
→ Schottky: 不過我還是覺得位置關係對不上 11/03 16:20
→ Schottky: 可能這邊的 calling convension 和我以前學的不太一樣了 11/03 16:21
→ b0920075: 啊記錯惹><我老是把section segment搞錯 11/03 16:21
→ Schottky: 那個 'A' 為什麼是填 112 個,這一點我一直想不透 11/03 16:25
→ b0920075: 這是buffer到ebp位置的byte數,測出來的 11/03 16:28
→ Schottky: 可能是 main() 的某些特殊參數吧? 雖然原始碼沒寫出來 11/03 16:31
→ Schottky: 啊,main 的參數應該放在 main 的 ret addr 前面才對 11/03 16:32
※ 編輯: b0920075 (140.117.247.163), 11/04/2016 12:01:31