PatrickLi2021/sgtech-ctf-challenge-1

# 缓冲区溢出 CTF 挑战 (S&G Tech CTF 2026) ## 概述 这是一个经典的缓冲区溢出挑战。一个存在漏洞的 "Greeter App" 二进制程序使用了不安全的 `gets()` 函数。目标是溢出 `greet()` 函数中的栈缓冲区，以将执行流重定向到隐藏的 `win()` 函数，该函数会读取并打印 flag。 ## 架构 ``` sgtech-ctf-challenge-1/ ├── Dockerfile.server # Server container: compiles and serves the vulnerable binary over TCP ├── docker-compose.yml # Two services: interactive CTF env + challenge server ├── challenge/ │ ├── vuln.c # Vulnerable C source code │ ├── vuln # Compiled binary (x86-64 ELF) │ └── Makefile # Builds the vulnerable binary with protections disabled └── solution/ └── exploit.py # pwntools exploit script └── README.md # Exploit writeup └── participant-download/ └── Dockerfile # Solver environment with GDB, pwntools, checksec └── README.md # Participant-facing instructions ``` ## Docker 服务 | 服务 | 容器名称 | 用途 | |---------|------|-------------| | `ctf` | `sgtechctf-solver` | 用于解决挑战的交互式 shell | | `server` | `sgtechctf-server` | 通过 socat 在 1337 端口上通过 TCP 暴露二进制文件 | ### 服务器工作原理 `server` 服务： 1. 在一个 x86-64 Ubuntu 22.04 容器内禁用所有保护措施，编译 `vuln.c`。 2. 在二进制文件的工作目录中放置一个 `flag.txt` 文件。 3. 使用 `socat` 在 1337 端口上监听。对于每个传入的 TCP 连接，它会 fork 一个运行 `./vuln` 的新进程，将二进制文件的标准输入/输出桥接到 TCP 套接字。 当参与者使用 `nc 1337` 连接时，他们会与一个全新的二进制文件实例交互，就像它在本地运行一样。 ## 求解环境工作原理 `ctf` 服务为参与者提供： - 预编译的 `vuln` 二进制文件（用于本地分析和调试） - 源代码 `vuln.c` - 工具：GDB、pwntools、checksec、ropper、capstone、qemu-user ## 入门指南 ### 前置条件 确保你已安装 Docker Desktop 和 Docker Compose（v2 插件或独立的 `docker-compose`）（不确定 Colima 是否可行，但有可能）。 ### 步骤 1. **构建容器：** 运行 `docker compose build --no-cache` 来构建容器 2. ## Apple Silicon 注意事项 此容器专为 **x86-64** (`--platform=linux/amd64`) 构建。在 Apple Silicon Mac 上，这有重要影响： ### x86-64 二进制文件问题及 QEMU 的使用 当你编译一个 C 程序时，编译器会为特定的 CPU 架构生成机器指令。例如，x86-64 指令专门针对 Intel 和 AMD CPU 设计。ARM CPU（例如你的 Apple M1-M4 Mac 使用的）根本无法理解这些指令。 即使我们在 Docker 容器内运行程序，它也不会工作，因为 Docker 容器共享宿主机的内核和 CPU 架构。所以，原生容器仍然以 ARM64 方式运行。x86-64 容器需要在底层使用模拟器/翻译层。 要在基于 ARM 的 Mac 上运行 x86-64 二进制文件，Docker 必须依赖模拟器或翻译层，例如 QEMU 或 Rosetta 2。这些工具在程序运行时动态地将 x86-64 指令翻译成 ARM64 指令。对于这个挑战，我们使用 QEMU。 ### 使用 GDB 及 GDB 的问题 GNU 调试器 (GDB) 是一个低级程序调试器，主要用于 Linux 系统上的 C、C++ 和系统编程语言。它基本上允许你在程序执行时观察和控制另一个程序。你可以设置断点、检查寄存器/变量中的值以及分析函数地址等。 现在，**即使** 使用了 QEMU，我们仍然不幸地遇到了问题，因为 GDB 对这个挑战至关重要。当 Docker 使用 QEMU 时，整个 Linux 客户机运行在一个 QEMU 进程内。这意味着 GDB 无法直接附加到该进程，因为它运行在另一个 QEMU 进程内部（在 Linux 上，一次只能有一个进程 ptrace 另一个进程）。你可以把它想象成两个人同时试图握住方向盘——这根本行不通。 ### 最终解决方案及挑战运行方式 QEMU 用户模式 (`qemu-x86_64`) 不使用 ptrace 来控制目标。相反，它在**单个进程**内运行所有内容，并提供其自己的调试接口。因此，在那个单一进程内，我们拥有软件模拟的 x86-64 CPU **和** GDB 远程协议服务器。GDB 客户端监听一个特定的 TCP 端口，你的进程本质上会连接到它。结果，当 GDB 查询某个特定寄存器的值时，QEMU 会从其自己的内部数据结构中读取它——而不是从硬件或操作系统内核读取。

标签：checksec工具, CTF挑战, Docker容器, ELF文件, GDB调试, pwntools框架, socat工具, TCP服务, x86-64架构, 二进制安全, 堆栈溢出, 安全挑战, 安全教育, 攻击面发现, 标志获取, 漏洞分析, 版权保护, 缓冲区溢出, 编程竞赛, 网络安全, 解题环境, 请求拦截, 路径探测, 身份验证强制, 逆向工具, 隐私保护, 黑客技术