当前位置：首页 > news >正文

SecGPT-14B精彩案例分享：真实CTF题目自动解析+EXP构造逻辑生成过程

news 2026/4/25 22:30:47

SecGPT-14B精彩案例分享：真实CTF题目自动解析+EXP构造逻辑生成过程

1. 引言：当AI大模型遇上网络安全实战

如果你是一名网络安全爱好者、CTF选手，或者是一名安全工程师，你一定遇到过这样的场景：面对一道复杂的CTF题目，需要花费大量时间去理解漏洞原理、分析代码逻辑、构思利用方法。这个过程既考验技术功底，也考验思维的发散性。

最近，我在测试一个名为SecGPT-14B的网络安全专用大模型时，发现了一个有趣的现象：它不仅能回答基础的安全概念问题，还能在一定程度上理解复杂的漏洞场景，甚至能辅助生成漏洞利用（EXP）的逻辑思路。这让我萌生了一个想法——能不能让AI来帮我们“读题”和“解题”？

本文将分享几个真实的案例，展示SecGPT-14B如何解析CTF题目描述，并一步步推导出漏洞利用的构造逻辑。这不是一个简单的问答演示，而是一个完整的“AI辅助安全分析”工作流。你会发现，AI不是要取代安全研究员，而是成为一个强大的“副驾驶”，帮你理清思路、查漏补缺。

2. 案例一：Web题目“Secret Vault”的自动解析

2.1 题目背景与AI的初步理解

我首先选择了一道中等难度的Web CTF题目，题目描述如下：

题目名称：Secret Vault描述：我们开发了一个安全的秘密保险库系统，用户可以通过API查询自己的秘密。系统使用JWT进行身份验证，并且有一个管理员接口可以查看所有用户的秘密。你能找到漏洞并获取flag吗？提示：关注JWT的处理逻辑和API路由。

我将完整的题目描述（包括上述文字）直接输入到SecGPT-14B的Web界面中，并提出了第一个问题：“请分析这道CTF题目的描述，指出可能存在的漏洞方向和需要关注的技术点。”

SecGPT-14B的回复非常结构化：

技术栈分析：它识别出题目涉及Web API、JWT身份验证和权限控制。
攻击面枚举：
- JWT相关：密钥强度、签名算法（如none算法）、令牌伪造、信息泄露。
- API路由：未授权访问、路径遍历、IDOR（不安全的直接对象引用）。
- 逻辑漏洞：从普通用户权限提升到管理员权限。
解题思路建议：它建议首先注册/登录一个普通用户账户，分析获得的JWT令牌；然后检查是否有访问管理员接口（如/admin）的途径；最后关注查询参数或请求头中是否存在权限标识。

这个回复已经超出了简单的关键词提取，它构建了一个初步的侦察框架。

2.2 交互式漏洞假设与验证

接下来，我扮演一个解题者的角色，将侦察中发现的“线索”反馈给AI。

我输入：“我注册了一个用户test，获得了一个JWT。解码后发现头部算法是HS256，payload里有{“user”:”test”, “role”:”user”}。现在我应该怎么做？”

SecGPT-14B回复：

很好。你拥有一个普通用户的JWT。下一步是：
测试权限提升：尝试用这个令牌直接访问/admin或/api/admin之类的端点。如果返回403，说明有权限校验。
分析JWT弱点：
密钥爆破：如果JWT库版本较旧或使用弱密钥，可以尝试爆破HS256的密钥。
算法混淆：尝试将头部中的alg从HS256改为none（如果服务器支持），或者改为RS256但使用自己的公钥（如果服务器错误地使用了公钥验证）。
信息篡改：尝试修改payload中的role为admin，但由于有签名，直接修改会失效，必须配合上述算法攻击。
寻找IDOR：如果存在查询用户秘密的接口如/api/secret?id=1，尝试遍历id参数，看是否能访问到其他用户（包括管理员）的秘密。

我根据它的建议进行测试，发现访问/admin返回403。然后我尝试了算法混淆攻击，将alg改为none并删除签名部分，服务器果然返回了错误，暗示它可能处理了none算法。这是一个关键信号。

我继续输入：“服务器对alg:none的令牌有反应，但返回了‘算法不支持’的错误，而不是直接拒绝。这说明了什么？”

SecGPT-14B分析：

这说明服务器的JWT库可能没有完全禁用none算法，或者存在逻辑缺陷。有时，错误信息的不同能揭示内部处理流程。你可以尝试：
精确的none算法格式：确保你的JWT格式完全正确（签名部分为空）。
查看其他接口：/admin接口可能校验严格，但其他查询秘密的API接口（如/api/vault）的JWT校验逻辑可能不同，可以试试在那里使用none算法令牌。
结合信息篡改：如果某个接口的校验更宽松，你可以在使用none算法的令牌中，将role改为admin。

我听从了第二条建议，发现/api/vault接口确实存在不同的校验逻辑，成功使用篡改了role的none算法令牌，以管理员身份列出了所有秘密，其中包含了flag。

在这个案例中，SecGPT-14B的作用是：

提供结构化侦察清单，避免遗漏方向。
解释漏洞原理（如JWT算法混淆），而不仅仅是给出攻击名称。
根据交互反馈，提出下一步具体的、可操作的测试建议，引导测试流程。

3. 案例二：Pwn题目“Echo Server”的EXP逻辑构造

3.1 从二进制描述到漏洞类型推断

第二个案例是一道Pwn题目。我给了SecGPT-14B更技术性的描述：

题目名称：Echo Server描述：这是一个64位的Linux命令行程序，监听端口9999。连接后，它会问你“Size:”，你输入一个数字，然后问你“Data:”，你输入对应长度的字符串，最后它会把你输入的字符串原样打印回来（echo）。程序提供了二进制文件echo_server和对应的libc。目标：获取远程服务器的shell。

我的问题是：“基于这个描述，你认为最可能的漏洞类型是什么？请给出初步的分析和利用思路。”

SecGPT-14B的回复抓住了核心：

漏洞类型：栈缓冲区溢出。理由是：程序根据用户输入的Size来决定读取Data的长度，这是典型的风险点。如果程序使用read、fgets等函数，并且用栈上的缓冲区（如char buf[100]）存储数据，但Size变量没有正确校验，就可能写入超长数据覆盖返回地址。
利用思路：
- 确认漏洞：发送一个巨大的Size（如500），然后发送长字符串，观察程序是否崩溃。
- 信息泄露：如果崩溃，需要泄露地址来绕过ASLR。可以尝试利用echo功能本身，通过溢出覆盖局部变量，造成printf等输出函数泄露栈地址或libc地址。
- 构造ROP链：获取libc基地址后，计算system和/bin/sh的地址，构造ROP链覆盖返回地址，执行system(“/bin/sh”)。
检查点：它提醒需要检查二进制保护机制（NX, Canary, PIE, RELRO），这决定了利用的复杂程度。

3.2 交互式EXP构造演练

我反馈了手动分析的结果：“我用checksec检查了，只有NX enabled。没有栈保护（Canary）和地址随机化（PIE）。现在偏移量我也找到了，覆盖返回地址需要填充120字节。我该如何泄露libc地址？”

SecGPT-14B给出了一个非常具体的利用链构造思路：

由于没有PIE和Canary，利用变得直接。你可以通过溢出覆盖栈上的一个函数指针或某个变量的值，来控制程序流或输出内容。
一种可能的泄露方案：
程序在echo（回显）你的数据时，很可能使用了puts或printf。第一次交互时，构造payload：[120个填充字符] + [puts@got]。这将把puts函数在GOT表中的地址覆盖到返回地址上。
但这会直接跳转执行puts，参数不对会导致崩溃。更好的方法是覆盖栈上存储的某个即将被用作printf或puts参数的指针。你需要逆向分析，找到存储Data指针的位置。
更通用的方法（适用于简单题目）：直接让程序执行main函数或某个函数第二次。构造payload：[120个填充字符] + [main_addr]。这样程序崩溃后会重新开始，但栈布局可能变化。
本题可能更简单：既然它能echo任何数据，也许存在格式化字符串漏洞？你可以尝试在Data里输入%p.%p.%p，看看回显的内容是否包含地址。
如果确认是简单的栈溢出且能稳定控制返回地址：
第一次溢出：返回到puts(puts@got)，打印出puts的真实地址。计算libc基址。
第二次溢出：返回到system(“/bin/sh”)。
你需要确保两次输入能连贯执行。通常需要让程序在第一次溢出后不退出，而是再次回到一个可以接收输入的状态（比如再次调用main或某个循环函数）。

实际上，这道题确实存在格式化字符串漏洞。我按照SecGPT-14B的第4条建议进行测试，成功泄露了栈地址和libc地址。我将这个新信息反馈给它：“是的，存在格式化字符串漏洞。我泄露了__libc_start_main的地址和栈地址。现在有了libc基址和栈地址，下一步如何构造getshell的payload？”

SecGPT-14B结合新信息，生成了最终的EXP逻辑步骤：

计算关键地址：根据泄露的__libc_start_main地址，计算libc基址，进而得到system和字符串/bin/sh的地址。
利用格式化字符串写栈：使用格式化字符串的%n或%hn等写功能，将system的地址写入栈上某个未来会被作为返回地址的位置。这需要精确控制格式化字符串的偏移和写入的值。
或结合栈溢出：如果格式化字符串漏洞的缓冲区也在栈上，且靠近返回地址，可以先通过格式化字符串泄露栈地址并计算偏移，然后在第二次输入时，通过栈溢出精确覆盖返回地址为system，并在栈上布置好参数（如/bin/sh的地址）。

构造最终payload：它甚至给出了一个伪代码逻辑框架：

# 伪代码，基于pwntools from pwn import * p = remote(‘靶机’, 9999) # 1. 泄露libc地址 payload1 = b’%{}$p’.format(offset_to_libc_start_main) p.sendlineafter(‘Size:’, str(len(payload1))) p.sendlineafter(‘Data:’, payload1) leak = int(p.recvline(), 16) libc_base = leak - libc.sym[‘__libc_start_main’] - 0x240 # 偏移需根据实际libc调整 system_addr = libc_base + libc.sym[‘system’] binsh_addr = libc_base + next(libc.search(b’/bin/sh’)) # 2. 计算栈上返回地址的位置（通过格式化字符串泄露栈变量地址并计算） # 3. 使用格式化字符串写操作 或 栈溢出，将返回地址覆盖为system_addr，并设置参数 # 例如，假设通过溢出覆盖： rop_chain = b’A’*120 + p64(pop_rdi_ret) + p64(binsh_addr) + p64(system_addr) p.sendlineafter(‘Size:’, str(len(rop_chain))) p.sendlineafter(‘Data:’, rop_chain) p.interactive()

在这个案例中，SecGPT-14B的作用是：

从功能描述准确推断漏洞类型（栈溢出/格式化字符串）。
提供多种可能的利用路径（覆盖返回地址、覆盖函数指针、格式化字符串写栈），并解释其适用场景。
将利用步骤模块化（信息泄露、地址计算、payload构造），并给出接近真实代码的逻辑框架。
根据新信息（漏洞类型确认）动态调整利用方案。

4. 案例三：逆向题目“CrackMe”的混合分析

4.3 AI辅助的静态分析与动态调试思路

第三个案例是一个Windows平台的CrackMe逆向题。我给SecGPT-14B的描述是：

题目：一个32位Windows GUI程序。运行后有一个输入框和一个按钮。输入序列号，点击按钮，提示对错。已有分析：用IDA打开，看到主要逻辑在DialogFunc里。用户输入经过一个check函数处理，返回1则成功。check函数里有大量的位运算和查表操作。问题：我不想硬逆整个算法。有什么策略可以快速解决？

SecGPT-14B没有直接尝试逆向复杂算法，而是提供了几种非常实用的“捷径”思路：

动态调试与补丁：
- 使用x32dbg或OllyDbg附加进程。
- 在check函数的返回值处（通常是eax寄存器）下断点。
- 无论输入什么，在函数返回前，手动将eax的值改为1（或ZF标志位改为1）。
- 这样任何输入都会成功。这是最快的方法。
密钥生成算法定位：
- 在check函数内部，寻找比较指令（如cmp,test）或条件跳转（如jz,jnz）。
- 这些指令附近往往有正确的序列号或关键中间值被加载到寄存器或内存中。
- 通过调试，在比较时查看寄存器值，可能直接发现正确的序列号。
约束求解器（Z3）辅助：
- 如果check函数的逻辑可以抽象为一系列对输入字符的运算和约束条件。
- 可以尝试用Python的Z3库来建模。将输入字符串的每个字节作为符号变量，将IDA中看到的运算逻辑（加、减、异或、与、或）转化为Z3约束，然后让Z3求解出一个满足所有约束的解（即正确序列号）。
- SecGPT-14B甚至给出了一个极其简化的Z3建模代码概念：
```
from z3 import * s = Solver() # 假设输入是4个字符 inp = [BitVec(‘inp_{}’.format(i), 8) for i in range(4)] # 根据逆向看到的逻辑添加约束，例如： s.add(inp[0] ^ inp[1] == 0x12) s.add(inp[2] + inp[3] == 0x100) # ... 更多约束 if s.check() == sat: m = s.model() key = ‘’.join(chr(m[inp[i]].as_long()) for i in range(4)) print(‘Found key:’, key)
```