舒克和贝塔全维度深度技术手册

一、 题目背景与初始环境分析

1.1 挑战基本信息

• 题目名称：舒克和贝塔。
• 题目类型：Web 安全（前端逻辑/API 漏洞）。

1.2 环境接入障碍

在解题初期，最常见的错误是直接访问容器内部地址 0.0.0.0:33517，这会导致浏览器报错 ERR_CONNECTION_RESET。

• 物理意义 ：0.0.0.0 在网络协议中代表本地所有 IPv4 地址，无法作为远程访问目标。
• Kali 实践 ：必须识别靶机的真实公网 IP（如 122.51.209.95）进行访问。

二、环境侦察与网络取证（Reconnaissance）

在 Kali Linux 中，面对一个给定的 IP 和端口，解题的第一步永远是确认服务的本质。

2.1 端口与服务确认

虽然你已经知道 Web 服务在 33517 端口，但使用 nmap 可以确认后端容器的指纹信息。

# 扫描端口详细信息及服务版本
nmap -p 33517 -sV 122.51.209.95

• 关键点 ：观察 Server 响应头。如果是 nginx 或 Apache，可能涉及配置文件漏洞；如果是 Node.js 或 Python/Werkzeug，则可能涉及服务端逻辑漏洞。

2.2 目录与敏感文件爆破

即使页面是一个游戏，后台也可能残留开发文件。

# 使用 dirsearch 进行目录扫描
dirsearch -u http://122.51.209.95:33517 -e php,js,json,txt,bak,zip

• 预期目标 ：.git（源码泄露）、robots.txt、config.js、package.json（泄露依赖库及 API 路由）。

---

三、前端逆向工程（Front-end Reverse Engineering）

从你提供的截图看，题目使用了 Vite + React + TS。这是现代 Web 开发的主流组合，对 CTF 选手来说，这意味着逻辑被高度模块化和混淆了。

3.1 绕过"反调试"脚本

页面弹出的"此操作已被禁用"是由 JavaScript 监听 contextmenu 和 keydown 事件实现的。

• 绕过技巧 ：在 Kali 浏览器（Firefox）地址栏输入 about:config，将 javascript.enabled 设置为 false，此时可以右键查看源码。或者直接在控制台使用命令绕过：

// 在浏览器控制台强制开启右键
window.oncontextmenu = null;
window.onkeydown = null;

3.2 静态资源还原

在 Vite 构件中，所有的业务逻辑都会被打入 assets/index-xxxxx.js。

• 分析流程：

1. 打开 Network 标签，找到加载最大的 .js 文件。
2. 将其右键"Save as"到本地 Kali 目录。
3. 使用 prettier 工具进行代码美化（Kali 自带 node 环境）：

npx prettier --write index-xxxxx.js

3.3 逻辑定位与断点调试

在美化后的代码中搜索关键逻辑：

• **搜索 victory 或 win**：寻找触发胜利条件的 if 语句。
• **搜索 fetch 或 axios**：寻找前端是如何将游戏结果提交给后端的。
• 设置断点 ：在 Debugger 中找到负责敌人碰撞或死亡计数的函数，手动修改变量。

---

四、动态交互与漏洞利用（Exploitation）

4.1 逻辑篡改（Cheat Engine 思想）

如果游戏通过 enemies.length === 0 来判断胜利：

1. 在 Console 输入：window.enemies = []。
2. 或者直接赋予玩家无敌状态：window.player.hp = 999999。

• 进阶 ：利用 React 的调试插件（React Developer Tools）直接修改 Component 的 State。

4.2 拦截并重放请求（Burp Suite）

这是 Web 题目的"大杀器"。

1. 配置：打开 Burp Suite，开启拦截（Intercept On）。
2. 触发动作：在游戏中随便玩一下，然后故意死掉。
3. 修改：观察发出的 POST 请求。

POST /api/game/result HTTP/1.1
Host: 122.51.209.95:33517
Content-Type: application/json

{"score": 10, "is_win": false}

将其修改为 {"score": 999999, "is_win": true}，点击 Forward 。

4. 收获 ：在 Response 包中寻找 flag{...}。

---

五、针对"Failed to fetch"的专项分析

图片中红色的 Failed to fetch 往往是解题的关键暗示。

5.1 跨域或路径错误

这可能意味着前端代码写死了一个错误的 API 地址（例如 localhost），或者该 API 只有在特定条件下（如带有特定的 Cookie 或 Token）才能被访问。

• 操作 ：查看 Console 的报错详情。如果报错显示 404 Not Found，尝试访问其父目录（如 /api/）查看是否开启了 Directory Listing。

5.2 接口隐藏漏洞

如果 /api/rank 报错，尝试猜测其他常见的 CTF 路径：

• /api/flag
• /api/admin
• /api/debug

---

六、解题思维导图总结

6.1 核心检查清单

• [ ] 是否查看了 HTTP 响应头（Server, X-Powered-By）？
• [ ] JS 文件中是否隐藏了 Base64 编码的字符串？
• [ ] LocalStorage 或 SessionStorage 中是否有加密的 Token？
• [ ] 游戏是否存在溢出漏洞（如分数超过一定数值变为负数）？

---

结语与后续建议

"舒克和贝塔"这种带有小游戏性质的 CTF 题，本质上是考察选手对前端执行流的控制能力。在 Kali Linux 下，你拥有完整的工具链（从自动化扫描到手动抓包分析）来破坏这种控制流。

目前最迫切的下一步：

在开发者工具的 Network 选项卡中，找到那个状态为红色、导致 Failed to fetch 的请求。请复制它的 Request URL 发给我。那大概率就是通往 Flag 的大门。