目grep入門があまりにもKernelVM::入門だという指摘があったため、解説をつけてよりstd::入門に近づけてみました。

1. 目grep入門
+解説
murachue
1 / 83

2. いいわけ 1
• なぜかよくわからないけど好評だったらしい
• でも
– いみわかんねｗｗｗ
– 後半が意味不明
– つーかそれ目grep言わないでしょ
• というツッコミが…
• 頭おかしいというのがうけたらしい?
– 全然おかしくないよ!
• が、人によっては「ためになる資料です！！」というコ
メントもあったり
2 / 83

3. いいわけ 2
• これはこまった
• そもそも、自分で発表を見返して何言ってい
るのかわからなかった件について
じゃあ解説つければいいんじゃね<いまここ>
3 / 83

4. と、いうわけで
解説付きはじまりー
4 / 83

5. 何が必要?
5 / 83

6. はい、ヘキサエディタですね
6 / 83

7. • テキストエディタでもなんとかなる時はありま
すが、基本的に辛いので無難にヘキサエディ
タを選びましょう。
– Null文字が消えたりするし
– プロポーショナル文字使われるし
– 折り返し位置がばらばらだし
– などなど…?
7 / 83

8. 8 / 83

9. 9 / 83

10. 10 / 83

11. • 3枚ほどhexdumpを見ていただきましたが、い
かがでしょうか。
– さっぱり
– 何の形式かは分かった
– 個人特定した (こわい)
11 / 83

12. • 「おまいらバイナリアンはこんなものばっかり
見ているんじゃねーの」と思うかも知れません
– 実際そういう時もあるけれど
– ツール使うよ！！
• その一つが…
12 / 83

13. 見える化(笑)
13 / 83

14. BZやstirlingにはビットマップ表示という機能があるので、
それを使ってみましょう。BZの方がちょっぴり高機能です。
14 / 83

15. わかりやすい！
(笑)なんてつけて正直スマンカッタ
15 / 83

16. ひたすら同じものが
並んで退屈なものが…
一目でデータの違いがわかる！！
(矢印の部分がそれぞれ違いますよね)
16 / 83

17. 目grepに必要な知識
•シグネチャ(マジックナンバー)
•見た感じ(パターン)
あくまで個人的な意見なので、人によって違うと思います。
17 / 83

18. ちなみに私の場合は、
18 / 83

19. ひたすらファイルを見る作業
によって鍛えられました…
19 / 83

20. というわけで、いろいろなファイルを見ていきましょう
sample
20 / 83

21. • txt
– Shift_JIS, EUC-JP, UTF-8, UTF-16…
• ゲームが使うファイル
• bmp
• wav
• exe, com, bin…
• jpg, png, gif...
• lzh, zip, cab, rar...
下に行くほど規則性が無くなっていく(高エントロピー)ように並べて
みました。あくまで感覚です。
21 / 83

22. 説明があまかった…
• このスライドで説明するときに使うビットマップビューは
Binary Editor BZのものです。
– stirlingも同じ色づけらしい….?
• 1ドット1バイトに相当します。横幅128ドット。
• 1ドットごとの色はその部分に当たるデータの値により
ます。
• 色づけは以下の通り
– 白 : 0x00 (NULL文字)
– 水色 : 0x01～0x1F (ASCII制御文字)
– 赤 : 0x20～0x7F (ASCII普通の文字)
– 黒 : 0x80～0xFF (MSBが立っている)
• 詳しくはBZのヘルプをご覧ください。
22 / 83

23. • txt
– Shift_JIS, EUC-JP, UTF-8, UTF-16…
• ゲームが使うファイル
• bmp
• wav
• exe, com, bin…
• jpg, png, gif...
• lzh, zip, cab, rar...
23 / 83

24. テキストファイルなの
で普通に読めます。
ASCIIの普通の文字と
たまにCR/LFの制御文字があるので
赤(ちょっと水色)になります
ASCII
24 / 83

25. ASCII文字だけのUTF-16は
1文字ごとに0x00が入るので
こんな感じになります。
BOM
ASCII(UTF-16)
ビットマップは縦縞になります。
25 / 83

26. 日本語はMSBが立つことが多いので
ビットマップは黒くなってきます。
日本語だけだとほとんど黒(+水色)に。
以降、ここはShift_JISで表示します。
これはShift_JISなので普通に読めます。
Shift_JIS
Shift_JISは
81、82が多い感じ
(=ひらがな)。
26 / 83

27. EUC-JPは、Shift_JISより
もうすこし黒いですね。
半角カナが多いです。
Ax、Bx、Cxが多い?
EUC-JP
27 / 83

28. EUC-JPよりもうちょっと黒い?
糸へんの漢字が多くなります。
E3 xx xxが多いです。
UTF-8
28 / 83

29. ASCII文字があると縦線が見えます。
日本語があるのに黒くない(赤い)。
(このサンプルではHexdump側は
ASCIIしか見えない…)
UTF-16
29 / 83

30. WindowsのexeファイルにはUTF-16な文字列が
入っていることが多いのでサンプルとして
持ってきてみました。
(x86実行可能部分)
UTF-16
0が多く見えますね!
30 / 83

31. • ここで紹介したtxtファイルは、あくまで日本語
が多い時の話です。
• 韓国語や中国語など別の言語はあまり見な
いのでよく知りません…
– また別の見え方になると思います。
31 / 83

32. txt
– Shift_JIS, EUC-JP, UTF-8, UTF-16…
• ゲームが使うファイル
• bmp
• wav
• exe, com, bin…
• jpg, png, gif...
• lzh, zip, cab, rar...
32 / 83

33. ゲームが使うファイルは
モノによるので説明は適当…
PNGの部分 このファイルには
PNGファイルがありますね。
(臼NG、IHDR、IDATなど…)
よくあるのはパラメータとかが
書いてあるパターンで、
固定長(縦か斜めに揃う)で
疎な感じに見えます。
33 / 83

34. txt
– Shift_JIS, EUC-JP, UTF-8, UTF-16…
ゲームが使うファイル
• bmp
• wav
• exe, com, bin…
• jpg, png, gif...
• lzh, zip, cab, rar...
34 / 83

35. BMPのシグネチャ
この画像の場合
カーブの部分が
ビットマップビューに見えます
BMPのようなべた画像の場合は
繰り返しが見られます。
35 / 83

36. BZの色づけで残念な例は
白っぽい画像は真っ黒になってしまい、
ビットマップと気づきにくい所です。
36 / 83

37. txt
– Shift_JIS, EUC-JP, UTF-8, UTF-16…
ゲームが使うファイル
bmp
• wav
• exe, com, bin…
• jpg, png, gif...
• lzh, zip, cab, rar...
37 / 83

38. wavファイルのようなべた音声は
まだら模様が見えます。
wavファイルの
同じ文字が繰り返される シグネチャ
ことが多い
PCM 11k 8bit mono
38 / 83

39. 16bitはまだら+点々が見えます。
PCM 11k 16bit mono
39 / 83

40. (拡大)
PCM 11k 16bit mono
40 / 83

41. ADPCMは水色が多いことが
多かったです。
ADPCMの場合、
まだら模様は見えにくいです。
でも水色率の波は見えたかも。
ADPCM 11k 4bit mono
41 / 83

42. txt
– Shift_JIS, EUC-JP, UTF-8, UTF-16…
ゲームが使うファイル
bmp
wav
• exe, com, bin…
• jpg, png, gif...
• lzh, zip, cab, rar...
42 / 83

43. 黒っぽい 白・水色っぽい 赤っぽい ぐちゃー
ごま塩
ARM、MIPS、SPARCは x86は命令が
命令が固定長(32bit)なので縦に揃う 可変長なので
揃わない
(ここではTHUMBモードは無かったことに…)
43 / 83

44. x86-64は赤っぽい
ですね。 (ごま塩)
ごまではない塩。
白の部分が
多いような
気がします。
44 / 83

45. txt
– Shift_JIS, EUC-JP, UTF-8, UTF-16…
ゲームが使うファイル
bmp
wav
exe, com, bin…
• jpg, png, gif...
• lzh, zip, cab, rar...
45 / 83

46. ヘッダ部分
JPGなど圧縮された JPEGのシグネチャ
データがあるファイルは
ぐちゃぐちゃに見えます。
jpg
(元画像)
46 / 83

47. やはりデータ部は
ぐちゃぐちゃ
ZIPファイルの
シグネチャ
ヘッダ部 zip
47 / 83

48. gzipのシグネチャ
1F 8B (08)はあまりにも有名
やはりデータ部は
ぐちゃぐちゃ
(おまけ)gzip
48 / 83

49. (PDFの一部より、選択部分)
zlibのシグネチャ。78 9Cは有名。
他にも78 DA、78 01などたまにあり
やはりデータ部は
ぐちゃぐちゃ
(あ、ここPDF部分ですね…)
(おまけ) zlib
49 / 83

50. • まめちしき: zip、gzip、zlibのデータ部分はどれ
もdeflateという同じアルゴリズムで圧縮されて
います。
• 圧縮されている部分はさすがに読めないので、
これらは(私の場合)ヘッダを頼りに探していく
ことになります。
50 / 83

51. • ちなみに、圧縮されているデータの他に、暗
号化されたデータも同じようにぐちゃぐちゃに
見えます。
• 見分けはつかないと思います…。(ヘッダ等を
参考にできるなら別)
51 / 83

52. 実践
52 / 83

53. 某ルータのファームウェア
53 / 83

54. おなじみgzipのシグネチャだ!!
54 / 83

55. (展開後)
むむっ、縦に並んでいて
水色っぽい…MIPSだな!?
55 / 83

56. (スクロール後)
ASCIIテキストだ!
ra、fp、hi、lo…
MIPSで間違いないな!
56 / 83

57. (さらにスクロール後)
この感じ…
音声かビットマップか?
57 / 83

58. 音声でしたー
(μ-law)
58 / 83

59. 某CTFの問題
ばらばらzip
59 / 83

60. Unallocatedって…
不吉だなあ…
56MB…
60 / 83

61. Unallocatedで不吉ってなによ
• 最近、CTF(ハッキングコンテスト)の問題として出
始めました
• ファイルシステムの未使用領域(unallocated
area)だけを切り取ったファイルを渡されるので、
そこからkeyを見つけ出す作業になります
• 削除されたファイルが鍵となることが多いです
• ファイル名、クラスタチェーンなどの情報
(metadata)が無いため、解くのはかなり難しい事
が多いです
– かなり断片化してたら解くのは無理レベル
61 / 83

62. なんじゃこりゃ?
なにか構造を持っていそうだが…
UTF-16のASCIIのようなものもあるな…
62 / 83

63. (スクロール後)
x86のコードもあるぞ…
この混沌具合、
どう見てもunallocatedです。
本当にありがとうございました。
63 / 83

64. (さらにスクロール後)
むむ、怪しいzipファイル…!
(keyfileってファイル名…!!)
ビットマップビューを参考に
切り取ってみて展開してみたが、
壊れていると表示され駄目。
64 / 83

65. (さらにさらにスクロール後)
FILEレコードがある…
どうやらNTFSの未使用領域を
集めたモノらしいな。
FILEレコードが並んでいるので
ここはMFTだった場所らしい。
ここには例のzipファイルの情報は
ありませんでした…。
65 / 83

66. (さらーーーにスクロール後)
むむっ、このぐちゃぐちゃ具合、
圧縮データor暗号化されたデータだな!?
(さっきのzipとくっつけてみたが、やはり
壊れていると表示されてだめでした。)
66 / 83

67. 一旦例のあやしいzipがあった
場所に戻ってみる
そういえば、ビットマップビューに
縞々が見えないか…?
(普通の圧縮されたデータなら
このような縞々はでないはず…)
67 / 83

68. (拡大)
こんな感じに…
68 / 83

69. (拡大)
(ディスプレイの性能に左右されるかも…)
69 / 83

70. スクロール後
気づいたら、同じような縞々が
見える場所が
ほかにもあるぞ!?
70 / 83

71. さらにスクロール後
ここも縞々だ
と思ったらzipの終わりが見えた
71 / 83

72. さっきの縞々があった部分
くっつけたらいけるんじゃね…!??
72 / 83

73. 「CRC エラーはありません。」
いけちゃった━━(ﾟ∀ﾟ)━━!!
73 / 83

74. 早速keyfileを展開してみました。
うーん、知らない形式だなあ…
でもこの感じ、べた形式に見える。
音声かビットマップかな?
74 / 83

75. スクロール後
なんとなく、
ビットマップのような気がするな…
rawファイルを表示できる
画像ビューアで見てみるか!
75 / 83

76. すごくビットマップっぽい！
幅を変えてみて…
76 / 83

77. keyｷﾀ━━━(ﾟ∀ﾟ)━━━!!
この問題の答えは
sm4rtc4rvin9でした。
77 / 83

78. 目grep入門
完
解説はもうちょっとだけ続くのじゃ
78 / 83

79. • いかがでしたか?
• すこしでも分かっていただけたら幸いです。
• 他にもPNGやGIFやmp3やLZHや7zやBZ2や
LZSS(アルゴリズム)やLZMAやXORで暗号化され
たデータなどなどなどなど…も盛り込みたい所です
が、力尽きました。
– (というより、よくこの内容8分で話したな…)
– 以上の形式はみなさまの宿題ということで。
– ＼えー／
79 / 83

80. 解決したかな?
• いみわかんねｗｗｗ
• 後半が意味不明
– おわかりいただけたと思います。
• つーかそれ目grep言わないでしょ
– 私の場合、元々CTFでkeyを探すところから知られ
たので、目grepと言われていました。
– 「というかg/re/pではないよね」というツッコミに関
しては…まあその通りだと思います。reもpもない
し…
80 / 83

81. おまけ
• 知らないファイルを知るために私がよくやるこ
と
– とりあえずヘキサエディタで開く
– ビットマップビューを眺めてみる
– [サイズ][データ]のような構造が無いか見る
– 仕様書があればそれに目を通してみる
– ググる *超重要*
81 / 83

82. と、いうわけでですね
• バイナリアンヘキサリアン(なにそれ)の生態を少
しは分かっていただけたと思います。
– 大したことないですよね。
– 昔の人は今回の内容を「普通じゃん」と思うような
スキルを持っていたらしいですし。
• それではまた～ (・∀・)ﾉｼ
82 / 83

83. 目grep入門
+解説
完
83 / 83