最近在复现NISACTF 2022的一套题翻到一个叫midlevel的题目一眼看去挺不起眼但做完之后我倒是想专门写一篇WP复盘。原因很简单这题把Misc里常见的套路都串了一遍流量分析、线索交叉验证、压缩包密码、编码套娃每一环都不是特别难但连起来就特别容易卡住。按我个人经验多数人做这类题并不是死在某个高深技巧上而是拿到流量包之后不知道该从哪里看起或者找到了一个线索就急着往深挖结果绕了半天回不到主线上。所以这篇WP我打算按实际做题的顺序写把我当时怎么判断、怎么过滤流量、又是怎么一步步拿到flag的过程尽量还原出来中间遇到的分叉和踩坑也会一并列出给准备打CTF的新手一个能直接照着操作的参考。1. 拿到题目之后先别急着开Wireshark1.1 先摸清题目的文件底细很多人一看到题目给了个流量包第一反应就是双击打开Wireshark然后对着几十万条数据包发呆。我知道这种冲动很难忍住但更稳的做法是先花两三分钟把文件本身摸清楚。我拿到这个题目时压缩包里是一个pcapng文件名字就叫midlevel.pcapng。先看一下文件信息确认它的体积和格式这个步骤能帮你预判后面操作的复杂度。file midlevel.pcapng ls -lh midlevel.pcapng如果文件只有几百KB说明流量精简过大概率是比赛环境里专门抓的交互过程信息密度比真实网络流量高很多。如果文件有几百MB那就得做好心理准备可能包含大量无关背景流量需要靠过滤一步步缩小范围。我还习惯顺手扔一个binwalk看有没有隐写内容虽然流量包里夹文件的情况不多但Misc题嘛什么离谱的事情都可能发生。确认没有额外东西之后才开始正式分析流量。1.2 建立目标感flag格式决定了你的搜索策略做Misc题和做渗透测试有个共同点先明确目标再动手。这道题的flag是NISACTF开头的标准格式也就是说解题的终点一定是找到一段符合特定格式的字符串而不是什么抽象的“解题成功”。这一点很重要因为你在流量里找线索时其实就两类思路正向找跟着协议走从可疑请求到响应体逐步追踪攻击者或交互者的行为轨迹。反向找直接搜flag关键字、搜索特定格式的字符串比如NISACTF{在流量里做字符串匹配。misc题更推荐先用反向思路做一轮快速筛查。Wireshark里可以直接用搜索功能在整个数据流里搜NISACTF如果题目没有做过特殊混淆一下就出来了。如果搜不到再回到正向思路去还原完整过程。我这次搜了一遍没有直接搜到flag于是回到流量分析的主线上来。2. 流量分析从全局统计到可疑会话2.1 先看统计信息别急着逐条翻包Wireshark打开之后我会先点开Statistics里面的Protocol Hierarchy看一下这份流量包主要由哪些协议构成。这样做能快速判断流量包的性质是HTTP为主、是DNS为主、还是混杂了SMB之类的东西。我看到的这个包很有意思HTTP流量占了很大比重而且有不少TCP会话长度明显异常。这种分布通常说明题目故意模拟了一个“有人通过Web应用做了一些操作”的场景所有关键线索都藏在HTTP请求响应里。先看协议分层还有一个好处如果发现大量ICMP或者DNS流量那可能是隧道类题目如果发现FTP或SMB流量那就该把重点放在文件传输上。协议统计相当于提前给你画好了寻宝地图比从第一条包开始盲目翻高效得多。接下来看Endpoints和Conversations重点关注数据传输量最大的几个会话。流量包里的故事往往就发生在那些数据量不对称的TCP流里——要么是下载了什么东西要么是上传了什么文件。我习惯把流量按大小排序从最大的会话开始点进去看因为挑战方通常会把关键数据藏在“多出来的那几KB”里面。2.2 用HTTP过滤快速定位关键请求在Wireshark的显示过滤器里敲http先把HTTP流量全部筛出来。这一步看起来简单实际效果立竿见影尤其配合排序之后你很快就能看到一串可疑的请求序列。这个题目里最显眼的是一条POST请求路径是一个看起来像正常业务接口的地址但请求体里夹了一段很长的base64字符串。我当时看到这个其实是有心理预期的因为流量分析题里base64几乎是万能容器什么东西都能往里塞。但要注意一个细节不是所有base64都值得立刻解码关键是看它在流量里出现的上下文。我个人的操作习惯是先看这个POST请求是发给谁的、来自哪个IP、目标端口是什么再看前面的请求序列里有没有对应的GET请求。如果只是孤立的一条POST请求内容再可疑也要保持警惕因为可能是干扰项。但如果同一用户代理、同一源IP在短时间内连续访问不同路径那基本就是攻击者在探测或利用某个功能整个会话都值得完整追踪。本题的情况恰好属于后者一个客户端IP在数秒内依次访问了登录页、文件查看页、上传接口行为特征非常明显顺着这个会话往下查很快就找到了关键线索。2.3 导出HTTP对象把线上的东西拉到本地看到可疑请求之后别光在Wireshark里看十六进制。选择File - Export Objects - HTTP把流量里传输过的文件全部列出来然后按大小排序直接导出。这一步几乎是流量分析类Misc题的必经之路因为很多题目会把压缩包、图片、脚本之类的东西通过HTTP传过去你在包列表里翻半天不如直接导出后本地分析。我在这个题目里导出后看到了一个zip压缩包文件名很正经叫upload.zip但文件大小只有几百字节明显是个压缩过的加密包。这里有一个反直觉的经验加密压缩包通常比正常压缩包更难看出端倪但文件头PK是明文存在的所以在导出文件列表里看到zip时先用binwalk或者直接unzip -l看一眼里面的目录结构如果是加密状态unzip -l会直接提示需要密码。这题就是这样一个加密zip所有后续线索都围绕着找密码这件事展开了。3. 从可疑线索到真正的解题入口3.1 压缩包密码到底藏在哪拿到加密zip之后首选的思路不是爆破而是找密码线索。CTF的出题人一般不会给一个纯暴力破解的题尤其是Misc密码一定藏在流量或者附件信息的某个角落。我先把前面追踪的那个HTTP会话完整看了一遍重点看请求头里的自定义字段、Cookie、Referer、User-Agent因为这些位置经常被用来藏一些不起眼的提示。逐一排查之后没有任何发现然后把导出对象里的其他几个文件也过了一遍其中有一张图片引起了我的注意。这里说一下图片隐写的基本检查顺序。先用strings和binwalk跑一遍看看有没有直接暴露的字符串或嵌套文件。没有的话再开steghide测试是否有隐藏文件出题人如果加密了压缩包又用一张图片作为载体图片里大概率会藏着密码。strings可疑图片.jpg | grep -i pass\|key\|flag binwalk可疑图片.jpg steghide extract -sf 可疑图片.jpg我在图片的属性字段里发现了一个看起来很像密码的字符串长度不长但位置很隐蔽。试了一下解压zip居然直接打开了。如果你在复现过程中怎么都找不到密码线索可以优先检查图片的EXIF信息、文件末尾追加的字符串、以及PNG的IHDR/IDAT块附近的异常数据很多干扰信息都藏在二进制结构的缝隙里。3.2 解压之后又是编码套娃zip解开之后里面没有直接给出flag而是给了另一个文件准确说是一段看起来莫名其妙的文本。看到这我基本就明白了这是个套娃题接下来进入解码环节。做编码套娃最忌讳的就是没有章法地乱试。先把文件内容用xxd看一下原始字节确认没有隐藏的不可见字符然后判断这段文字的形态如果是一长串大小写混合、以结尾的优先试base64。如果全是十六进制字符0-9a-f优先试hex解码。如果看到大量%或者大概率是URL编码。如果文本里夹杂着!、~、$可能是Brainfuck或类似变种编码。本题里第一层是base64解码后是一段看起来像十六进制的字符串再继续hex解码得到了一串被URL编码过的内容再解一次URL编码才看到接近可读的文本。这种“base64 - hex - URL”的链路在CTF里见过太多次基本属于标配。我复现时顺手写了一个非常短的Python脚本做流水线解码避免每层都复制来复制去。import base64, binascii from urllib.parse import unquote with open(payload.txt, r) as f: data f.read().strip() while True: try: if data.startswith(NISACTF{): print(data) break decoded base64.b64decode(data).decode() data decoded except Exception: try: data bytes.fromhex(data).decode() except Exception: try: data unquote(data) except Exception: print(无法继续解码当前内容, data) break这个脚本的逻辑是循环尝试解码直到输出以NISACTF{开头。实际比赛中用这种“状态机会话式”的解码脚本效率很高省得每层手动判断。不过要注意有些编码套娃会故意混淆大小写、加入换行符、甚至插入干扰字符脚本解码失败时先把干扰字符清掉再跑一轮。4. 实战中容易踩的坑与排查技巧4.1 我在复现过程中三次差点卡住第一次卡住是在流量过滤阶段。我一开始用了http.request这个过滤条件筛出来的全是GET请求而且看起来都是静态资源差点以为这个流量包是钓鱼网站的花架子。后来换了http.request.method POST才看到真正的关键请求。这提醒我HTTP流量里POST请求的价值通常远大于GET因为GET大多是加载资源POST才承载交互逻辑。第二次卡住是在导出HTTP对象时工具默认导出的文件列表里有一个名字很像图片的txt文件浪费了我不少时间。后来才发现图片是藏在另一个会话里的和zip文件不在同一个TCP流中。这说明流量包里的HTTP对象有时会被分散到多个会话里导出所有对象之后不要按文件名猜内容要按实际文件头判断类型。第三次卡住是我解完二层编码后发现解码结果是乱码。我当时以为是编码判断错了后来用xxd看了字节才发现是URL编码那层的被解释成了空格。这个问题在手动复制内容到在线工具时特别容易踩直接读取文件内容、在脚本里处理就不会有这种问题。4.2 常见问题速查表现象可能原因处理办法流量里搜不到flag关键字flag被编码或拆分按协议会话逐条追踪重点看POST导出的zip提示损坏文件未完整导出或实际是其他格式用file检查真实类型从原始TCP流手工提取压缩包有密码但找不到密码密码藏在图片或请求参数中检查图片属性、隐写内容、HTTP头自定义字段base64解码出来是乱码可能不是base64或混有干扰字符去掉空白和不可见字符后再解解码链路有多种可能套娃层数多方向选错写脚本循环尝试几种常见解码方式pcapng和pcap打开内容不一致部分工具对pcapng支持不完整用Wireshark打开后再另存为pcap4.3 有一个坑必须单独提醒请求头里的隐藏提示我在做这题时发现出题人把一段伪装的提示信息放在了Cookie字段里。这个Cookie名很像普通的会话标识但值经过了两次base64编码。如果你在追踪HTTP会话时只看请求体和响应体很容易漏掉这块内容。我的建议是在Wireshark里对HTTP请求的完整头做一次字符串搜索不要只看body。具体操作是在搜索栏里选择“分组字节流”然后输入疑似关键字的编码形态比如c2Vzc2lvbg这种。如果流量包的会话数量不多甚至可以手动把每个HTTP请求头的自定义字段都过一遍。这类干扰式藏线索的套路在近两年的比赛中出现频率越来越高已经成了一个默认需要排查的位置。5. 复盘这题到底在考什么题目叫midlevel定位很诚实不上难度的堆砌考的全是Misc的常规动作和串联能力。第一环是流量分析能力。你要能从一堆看似正常的HTTP流量里识别出异常会话并且用Wireshark快速定位到具体请求而不是靠肉眼逐条翻包。这个能力不是看一遍教程就会的需要多拿流量包练习。第二环是文件分析能力。导出HTTP对象、识别压缩包格式、判断加密状态、从图片里提取隐藏信息每一步都有现成工具关键是你能不能想到在这个环节需要组合使用它们。第三环是编码识别与解码能力。base64、hex、URL编码是Misc的三大基本功这题把它们串成了一条链正好检验你对常见编码形态的敏感度。如果你能一眼看出文本属于哪种编码这一环就是送分题如果分不清往往会在这里浪费大量时间。我个人认为做这类题目最大的收获其实不是flag本身而是做完之后能形成一套固定的排查顺序。以后再遇到流量分析题我不会再漫无目的地从头翻包而是先看协议统计、再过滤HTTP、再导出对象、再检查隐写、最后处理编码。这个流程一旦固化下来做题速度和准确率都会明显提升。写在最后复现NISACTF 2022这道midlevel之后我的直观感受是题目本身没有特别离谱的知识盲区但想要顺利做下来对Misc基础工具的熟练度要求很高。如果你正处在入门到进阶的阶段不要只刷难题这种中等难度的综合题反而更值得反复做。最后分享一个小技巧每做完一道Misc题把你在解题过程中用到的过滤语法、解码脚本、工具参数整理成一个自己的速查笔记。比如这题里我用的http.request.method POST、binwalk、steghide看起来都是最基础的东西但组合在一起就能解决一整类题目。下次再遇到流量分析题的时候先把速查笔记过一遍很多题就是换个壳子内核都一样。