为了更多地了解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！”）它将玩一个挂起的游戏和你在一起。
我遇到的问题是我没有在gdb中遇到断点。具体来说，我试图触及的断点是在处理客户端连接的代码中。没有断点，代码按预期执行。当我在该代码上设置断点时，子进程退出（而不是像预期的那样进入gdb）。如果我在服务器分离孩子之前设置了断点，我可以点击那么好但是在点击“继续”之后，孩子不会继续处理我的连接（也就是说，它不会要求我输入密码或者玩挂机）。
由于守护进程在收到新连接时分叉，我尝试告诉gdb使用此命令跟踪子进程：
(gdb) set follow-fork-mode child
但是在fork之后单步执行指令后，似乎这不起作用。
我已经尝试寻找对signal的调用，认为他们实现了一个自定义的SIGINT处理程序（或类似的），但我可以看到的signal唯一调用处理SIGCHLD。
我在gdb中的断点目前看起来像这样：
(gdb) info breakpoints
Num Type Disp Enb Address What
1 breakpoint keep y 0x080497d0
0x080497d0是我想在客户端处理代码中打破的地址。
我对分析* nix系统上的软件有点新意，可以使用一些指针。 我还应该怎么做才能解决为什么GDB不会破坏我的断点？或者有什么重要的我只是忽略了吗？
对于那些有兴趣亲眼看到二进制文件的人来说，所有游戏二进制文件都有一个torrent。