繼上一次做了一半實驗後發現系統居然是x64的後。。。重新開始實驗。前面重複部分不再贅言。
又是一番重複，終於出現
崩潰地方一樣。
使用offset指令獲得偏移位址
此處計算出返回值覆蓋點為140後面。也即是構造a*140+ret的位址就好。
然而gdb除錯時跟實際環境還有區別。也即gdb除錯時buf在記憶體中的位置會受到影響。
安裝蒸公尺前輩的文章中的意見於是決定使用core dump。
（簡單解釋下core dump：中文翻譯叫做核心轉儲。也即程式在崩潰時會記錄下來關鍵資訊用以分析）
開啟core dump 並讓其輸出資訊輸入到tmp裡。此處sh -c 也即命令從『 』中執行。
所謂開始core dump其實是不對的，預設只是把大小上限設定為了0.第一條指令也就是將其設定為無限大。
此時可以計算出buf的真正位址為0xbf9bdb20
此處解釋下gdb x指令即以16進製表示變數。 數字即表示多大的範圍。 後續可以跟u，s（字串），i（指令）
$表示暫存器 之所以此處是esp-144需要好好計算一下。
首先esp指向的位址是棧頂，而第乙個進棧的資料是棧底。棧底是高位址，棧頂是低位址。而棧又是從高位址向低位址伸展的。
看來還是有問題存在，暫時先
貼上**
需要注意的是p32即將ret位址轉換為32位可以使用的位址。也即轉換為字串
u32即反之。
然而出現了問題
實驗到這裡又出現了問題....解決了半天解決不了。於是先繼續看教程了。
下面開啟dep保護buf則無法執行。於是就使用ret2libc方法進行繞過
方法即載入level2 然後在main函式下斷點。在使用print system 列印出來system函式在記憶體的位置，然後再使用print __libc_start_main來列印出lib.so的起始位址。最後通過find命令 在libc.so的起始位址到220000的範圍內尋找「/bin/sh」的位置。
exp如下：
接著再次開啟aslr保護。此時就該使用rop了！
思路如下：
因為程式本身在記憶體中是不隨機的。所以我們只要找到lib.so洩露出來的某些函式的位址，然後根據位址計算偏移量計算出system位址和/bin/sh的位址。緊接著參照ret2libc既可。
使用objump查詢
發現其中使用了write@plt read@plt函式。
通過write@plt 我們可以把write（）函式位址得到，也就是write.got。因為linux使用了延時繫結的機制，所以當呼叫wirte@plt時，系統會將真正的wirte（）位址link到got表中。因為system（） 和wirte（）函式在lib.so中的offset是不變的。所以就可以計算出system的位址了。
ps：plt表為內部函式表，got表為全域性函式表。plt表跟got表對應。
學習筆記 nginx再探
上篇nginx初識說了nginx配置http反向 本篇先說https的反向 以及利用nginx搭建檔案伺服器。https使用了ssl通訊標準，需要引入安全證書，且其埠號與http也不相同。其他基本一樣。server autoindex on 顯示目錄 autoindex exact size on ...
學習筆記二 轉戰CSDN
近來開發專案比較多，學習筆記 心得都沒有來得及更新了，在群裡也看了許多小夥伴的優秀文章，自己也學習到許多，所以我要也得行動起來了。近一周，根據自己的情況做了下規劃。首先是自己買的spring boot書籍，本來是想著邊學習邊做記錄，不過初略過了一遍後，發現裡邊的大多為設計思想，自己的能力暫達不到此水...
虛樹學習筆記（洛谷2495 消耗戰）
題目鏈結 因為辣雞csdn，導致之前快寫好的部落格沒了 qwq悲傷逆流成河qwqqq 首先虛樹，這個東西，我感覺是一種思想，或者是方法，而並不是乙個資料結構什麼的。他主要是用來解決 給出一棵樹，每次詢問選擇一些關鍵點，求一些資訊。這些資訊的特點是，許多未選擇的點可以通過某種方式剔除而不影響最終結果。...