博士

ロボ子、今回のITニュースはLinuxカーネルをハックしてバイナリクラッキングを高速化する話じゃ。

ロボ子

Linuxカーネルをハックですか！具体的にはどのようなアプローチを取っているのでしょう？

博士

ふむ、QEMU VM上でコンパイル済みのvmlinuxから直接ブートし、straceでプログラムの動作を調査するのじゃ。デバッガ検出を回避するために、カーネルの`/proc/self/status`のTracerPidを0に設定したり、`ptrace_traceme`関数を修正したりしておるぞ。

ロボ子

なるほど、かなり手の込んだことをしていますね。他にどのような工夫が？

博士

対象プロセスがstdinからreadを試みるとき、レジスタの状態を保存し、メモリページを書き込み保護するのじゃ。そして、次の入力をreadバッファに注入するらしい。

ロボ子

書き込み保護違反が起きた場合はどうするんですか？

博士

書き込み保護されたマッピングであるかを確認し、元のページのコピーを保存して、書き込みを許可するのじゃ。まるでタイムリープみたいじゃな。

ロボ子

タイムリープ！面白い例えですね。出力に"Nope!"が含まれているかを確認する処理も興味深いです。

博士

"Nope!"が含まれていたら、メモリページを元の状態に戻し、レジスタの状態を復元して、read syscallを再実行するのじゃ。華麗な一手じゃな。

ロボ子

このカーネル機能は"ick"（Instant ChecKpoint）という名前なのですね。`task_struct`に`ick_checked_process`構造体を追加してプロセスの状態を保存したり、`ksys_read`と`ksys_write`を修正してチェックポイントの保存と復元を行うとのことですが、かなり大規模な改造ですね。

博士

そうじゃな。Red-Black Treeを使って変更されたページのオリジナルコンテンツを保存したり、`handle_mm_fault`関数をフックして書き込み保護されたページへの書き込みを検出したり、syscallを制限したり…すごい力の入れようじゃ。

ロボ子

syscallの制限ですか？

博士

`read`、`write`、`exit_group`以外のsyscallをブロックするらしいぞ。徹底しておる。

ロボ子

結果として、1回の試行あたり約3.89マイクロ秒で総当たり攻撃が可能になったとのこと。驚異的なスピードアップですね。

博士

ptrace APIを使った代替手段もあるみたいじゃが、forkのオーバーヘッドが大きいため、カーネルハッキングほど高速ではないらしい。

ロボ子

カーネルをハッキングすることで、ここまで高速化できるとは驚きです。しかし、セキュリティ的にはどうなんでしょう？

博士

そこが難しいところじゃな。今回のハックはあくまで実験的なもので、実環境での利用は推奨されないぞ。でも、こういう技術を知っておくことは、セキュリティ対策を考える上で非常に重要なのじゃ。

ロボ子

確かにそうですね。勉強になりました！

博士

ところでロボ子、ハッキングといえば、昔、私が作ったAI搭載の冷蔵庫が、勝手に食材を注文して大変だったことがあったのじゃ。あれも一種のハッキング…なのか？

ロボ子

それはただの冷蔵庫の暴走では…？