为了更好地了解FreeBSD和*nix系统，我开始查看DEFCON 17 Capture The Flag游戏中的二进制文件。目前，我正在反向分析tucod二进制文件。以下是关于tucod的一些可能有用的信息：
tucod: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), for FreeBSD 7.2, dynamically linked (uses shared libs), FreeBSD-style, stripped
一些简短的静态分析中得到的可能有用的信息是tucod绑定在端口0xDEAD上（很可爱，对吧？）如果您提供一个特定的密码（“HANGEMHIGH！”），它将与您玩hang-man游戏。
我遇到的问题是在gdb中没有达到我的断点。具体来说，我试图到达的断点位于处理客户端连接的代码中。没有断点时，代码按预期执行。当我在该代码上设置断点时，子进程退出（而不是像预期的那样跳入gdb）。如果我在服务器fork子进程之前设置断点，则可以很好地命中这些断点，但在点击“继续”后，子进程不会继续处理我的连接（也就是说，它不会要求我输入密码或玩hang-man）。
由于守护程序在接收新连接时进行fork，因此我尝试使用以下命令告诉gdb跟随子进程：
(gdb) set follow-fork-mode child
但是在分叉后单步执行指令后，似乎这并不起作用。
我试图寻找对 signal 的调用，以为它们实现了自定义的 SIGINT 处理程序（或类似），但我能看到的唯一对 signal 的调用处理 SIGCHLD。
我在 gdb 中设置的断点目前看起来像这样：
(gdb) info breakpoints
Num Type Disp Enb Address What
1 breakpoint keep y 0x080497d0
0x080497d0是我想在客户端处理代码中断点的地址。
我对*nix系统上的软件分析还比较新，需要一些指导。除了这种方法，我还应该如何解决GDB无法触发我的断点的问题？或者我是否忽略了什么重要的东西？
对于那些有兴趣亲自查看二进制文件的人，可以使用torrent下载所有游戏二进制文件。