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 に割り込む代わりに) 子が終了します。サーバーが子から分岐する前にブレークポイントを設定すると、それらをうまくヒットできますが、「続行」を押した後、子は接続の処理を続行しません (つまり、パスワードを要求したり、ハングマンを実行したりすることはありません) ）。
デーモンは新しい接続を受信すると fork するため、次のコマンドで gdb に子をフォローするように指示します。
(gdb) set follow-fork-mode child
しかし、分岐後の命令をシングルステップ実行した後、これが機能していないように見えます。
への呼び出しを探してみましたがsignal、カスタム SIGINT ハンドラー (または同様のもの) を実装していると思いましたが、signalSIGCHLD を処理していることを確認できる唯一の呼び出しです。
現在、gdb のブレークポイントは次のようになっています。
(gdb) info breakpoints
Num Type Disp Enb Address What
1 breakpoint keep y 0x080497d0
そして0x080497d0、クライアント処理コードで中断したいアドレスです。
私は、* nix システムでソフトウェアを分析するのが初めてで、いくつかのポインターを使用できます。 GDB がブレークポイントにヒットしない理由をトラブルシューティングするには、他にどのようにすればよいですか? それとも、私が見落としている大きな何かがありますか？
直接バイナリを見ることに興味がある人のために、すべてのゲーム バイナリで利用できるtorrentがあります。