バイナリダンプの模様を読む

以下動画のスライドです
https://youtu.be/0coXcaoMSjw

Transcript

1. バイナリダンプの模様を読む Jul. 2nd, 2026 Satoru Takeuchi X: satoru_takeuchi 1
2. • 任意のデータを数値や文字として出力したもの • 人間が与えた意味(どのオフセットどんなデータがあるとか)をツールが解釈せず、 データをただのバイト列という形で読むためのもの • 使用例 ◦ データが期待通りのかたちでバイト列に変換されているかの確認 ◦ データ破壊が起きた場合の調査 ◦ 何を意味しているのか分からないデータの解析 バイナリダンプとは 2
3. 文字列データのバイナリダンプ 3 $ cat hello.txt Hello, world! $ xxd hello.txt 00000000: 4865 6c6c 6f2c 2077 6f72 6c64 210a Hello, world!. $
4. 画像データ(png)の先頭部分 4 $ xxd -l 64 niconico.png 00000000: 8950 4e47 0d0a 1a0a 0000 000d 4948 4452 .PNG........IHDR 00000010: 0000 0058 0000 0050 0806 0000 009d c6b2 ...X...P........ 00000020: 5900 0000 0173 5247 4200 aece 1ce9 0000 Y....sRGB....... 00000030: 0004 6741 4d41 0000 b18f 0bfc 6105 0000 ..gAMA......a… $
5. ランダムデータの場合 5 $ dd if=/dev/random of=random.data bs=64 count=1 … $ xxd random.data 00000000: 2f5c 7530 7953 159a 4e13 516b a5be 618c /\u0yS..N.Qk..a. 00000010: d012 9c19 a8b8 ef57 dcdc ea85 4b86 fa80 .......W....K... 00000020: 1a45 9e84 bed4 38dd 93f2 17d0 a2aa 5d1d .E....8.......]. 00000030: 84f7 7fbb 8f74 734a 19e1 f754 1632 2e26 .....tsJ...T.2.& $
6. バイナリダンプの模様 • 同じような形式のバイナリダンプを眺め続けると次第に浮かんでくるもの ◦ バイナリダンプのどこにどんなデータがあるかが識別できる • 正式に定義された言葉ではない ◦ たぶん「目grep」という言葉のほうが有名 • 📝 メモリダンプと模様が見える男 ◦ https://note.com/hkamezawa/n/na4a01c712142 6
7. わたしが見える模様を実例として紹介 • Linuxカーネルのプロセスのスタックをバイナリダンプしたときに見える模様 ◦ スタックは関数呼び出し履歴やローカル変数などコンテキストを保存する領域 ◦ Linuxカーネルはプロセス (正確にはスレッド)ごとにスタックが存在する • 例えばどういうときに読むか ◦ Linuxカーネルに問題が発生して異常終了した (Windowsでいうブルースクリーン )ときにkdumpと言 うツールでシステムのメモリを全てファイルにダンプする ◦ 再起動後に、そのファイルを crashなどのツールを使って解析する ▪ 📝 その80 動作中にLinux環境の全メモリを見る ◦ 解析の一環としてプロセスのカーネルスタックをバイナリダンプして読むことがある • カーネル: Ubuntu 24.04同梱のLinux v6.8.0-117-generic • ややこしい話なので完全理解しようとせずフィーリングで観てほしい 7
8. 状況 • ファイルコピーなどに使うddコマンドがwriteシステムコール呼び出しの延長で長時 間戻ってこない状態になる ◦ SIGKILLでも殺せない、いわゆる D state • その後システムが異常終了 • 異常終了に上記プロセスが関わっているかを知りたい ◦ 📝 わかりやすさのために通常の調査の流れと変えているところが多々あります 8
9. ddのスタックのバイナリダンプの抜粋 • スタックが0xffffd137cbfd8000から16KiBだとする 9
10. ぐっとにらむと模様が見える 10
11. ぐっとにらむと模様が見える 11 • プロセスごとに存在するアーキテクチャ依存の情報を保持する thread_infoという構造体へのポインタ • スタックの頂上(最低位アドレス)に置くことが決まっている
12. ぐっとにらむと模様が見える 12 • システムコールを呼び出し時のシステムコールおよびレジスタの値 (ピンクの部分) • CPU、およびentry_SYSCALL_64_after_hardwareが • スタックの底(最高位アドレス)から数十バイトに積むことが決まっている
13. ぐっとにらむと模様が見える 13 • entry_SYSCALL_64_after_hwframeからdo_syscall_64を呼んだ際の戻りアドレス • CPUのCALL命令を呼んだら自動的に積まれるようになっている
14. ぐっとにらむと模様が見える 14 • do_syscall_64のスタックフレーム(ローカル変数などが入る領域 )へのポインタ • カーネルのビルド設定 CONFIG_FRAME_POINTERが有効ならこうすると決まっている do_syscall_64から何らかの関数を呼んだときの戻りアドレス
15. ぐっとにらむと模様が見える 15 do_syscall_64から何らかの関数を呼んだときの戻りアドレス • do_syscall_64のスタックフレーム(ローカル変数などが入る領域 )へのポインタ • カーネルのビルド設定 CONFIG_FRAME_POINTERが有効ならこうすると決まっている • スタックフレームのポインタらしきものとコードのアドレスらしきものが並んでいれば関数呼び 出しと、その後に呼ばれる呼び出し元のスタックフレームのアドレスが並んでいると推測できる • どのアドレスがどこの領域のものかはルールが決まっている ◦ https://github.com/torvalds/linux/blob/v6.8/Documentation/arch/x86/x86_64/mm.rst
16. ぐっとにらむと模様が見える 16 前述のルールに従うとこのデータ (0xffff8dc8105a5840)も恐らくカーネ ル内のコード or データであろうことがわかる
17. ぐっとにらむと模様が見える 17 • schedule関数からプロセスをスリープさせる __scheduleを呼んだ時の戻りアドレス • プロセスのスリープ前に呼ぶ関数は schedule → __scheduleなので、スタックフレームをこれ 以上先にたどれないときは、これらが最後 2つの関数だと推測できる
18. 重要なポイント • 一種の覚えゲーである ◦ データのバイトオフセットやデータのパターンは何らかの仕様で決まっていることが多い • できると万能感と多幸感がある • たくさん同じようなデータを眺めていれば自然とできるようになる ◦ できる人は天才とかそういうことはない ◦ どこまで模様が鮮明なのかは人による • 普通はできなくても困らず、だいたいは楽できるコマンドがある ◦ 例: crashでスタックを見るにも関数呼び出し履歴を出力する btコマンド • 稀にバイナリダンプが最後の望みの綱ということがある 18
19. まとめ • バイナリダンプを眺めていると模様が浮かぶことがある ◦ 目grepができる、とも表現する • 模様が浮かぶと便利だが、いつも必要というわけではない • 慣れると誰でもできるが鮮明度は人それぞれ • できるとかっこいいので、興味があればフォーマットが決まっている適当なバイナリ ダンプを何十個か眺めてみてほしい 19