2010-07-26
■FNG15 まとめ
忘れないうちに FNG15 のメモ。
今回のテーマは「バイナリ内の文字列」ということで、ひたすらバイナリファイルの中にある日本語文字列を探すというものです。
コンピュータ・フォレンジック調査では、メモリダンプや Pagefile.sys、未割り当て領域（Unallocated Clusters）などの構造がないファイル内において、日本語文字列を探す必要がでるケースがあります。キーワード検索を行なう方法もありますが、キーワードが不明であったり、絞り込めないようなケースでは、文字列痕跡が残っているにも関わらず発見できないかもしれません。また、文字列痕跡がどの様な文字コードで記録されているかによって、検索すべきキーワードのパターン（文字コード）も異なるので、なかなか面倒なところがあります。例えばメモリダンプの中に、ブラウザで閲覧していたサイトのデータが UTF-8 で残っていることがあれば、電子メールのデータが ISO-2022-JPの文字列として残っているかもしれません。これらはバイナリパターンが異なるので、それぞれのパターンで検索しないとバイナリ検索ではヒットしません。
■バイナリから文字列を抽出する
バイナリから指定した文字列を取り出す方法としては、古典的な手法として strings コマンドがあります。主に ASCII で利用されますが、The Sleuth Kit などでは英数字の UNICODE について取り出すことも出来るはずです。他にも Unicode に対応した Strings コマンドは幾つかあると思いますが、日本語を取り出すというのはなかなか厄介です。The Sleuth Kit は strings で取りだした文字列に grep かける検索方法なので、日本語などは思いっきり落ちてしまうはずですが、実は最近になって良くなったりしているんでしょうかね？
バイナリファイルから日本語文字列を取り出すという用途では、やはり istrings などの日本語に対応しているツールを利用する必要があります。日本語に対応した strings コマンドとしては、私の知る範囲では、はせがわさん作の istrings と、もとのぶ先生作の jstrings の二つがあります。
istrings 0.2
http://openmya.hacker.jp/hasegawa/
http://www.st.ryukoku.ac.jp/~kjm/security/ml-archive/port139/2003.05/msg00175.html
http://d.hatena.ne.jp/hasegawayosuke/20050715/1121408744
jstrings (Japanese 'strings' command)
FNG15 には開催を招集した、はせがわさんも参加されていたので懐かしいという話題になりましたが、kjm先生のところにある port139ml のログによると 7年度ほど前、2003年頃の話題みたいですね。まぁ作者もすっかり動かし方を忘れていたくらいですし（笑）
昔からあるフォレンジック調査における課題といえば課題ですね。そしていまだ完全には解決していない（笑）
7年経過して新たに登場したツールが、KaniGrep ということになるんですが、これは istrings と違い単体で動作するコマンドではなく EnCase のスクリプトとして実装されています。
※近いうちに更新されると思いますが、現時点では v0.9 が公開されています。
KaniGrep は正規表現パターンを使い、平仮名3文字、片仮名3文字などの日本語文字列パターンを探し出すというもので、文字コードも複数を同時に検索してきます。ただし、日本語文字列を包括的に探すというものではありません。機能としては漢字を含むものを探すこともできますので、istrings と同様に広い範囲の日本語文字列を探させることも可能なはずです。しかし、範囲を広げるとノイズとなるヒットが増えるので、個人的には漢字を含む範囲を検索させるのはあまりお奨めできない気がしていますが。なお、istrings でもマップファイルを編集すれば範囲を絞ることが可能です。
■メモリダンプからtessyを探せ！！
今回の FNG15 では題材ファイルとして以下のメモリダンプファイルを用意してみました。
・Web サイト(twitter.com）で @tessy_jp のつぶやきを閲覧
・Gmail でメールを閲覧
・Windows Live Mailで POP で Gmail から取得したメールを閲覧
いやぁ並べて書いてみると、UTF-8 ばっかりで全然面白くないんぢゃね？という気がしますね、もう少し考えてネタを用意しておけばよかったですね。
まずは Twitter における @tessy_jp さんのつぶやきを探してみましょうということになったのですが、Twitter の場合は HTML 構文に特徴があるので、結論としては「パターンがあるデータはパターンを検索したほうが早い」ということですね。ただし、Gmail のデータなどについては、前後に特徴のあるパターンがない状態でメールデータが存在しているケースもありえる為、その様なケースでは KaniGrep のようなアプローチが必要になると思われます。
■バイナリエディタは何がお奨めか？！
手元では Stirling を使っていることが多かったのですが、今回 @murachueさんに Binary Editor BZ が良い！と教えていただいたので、BZエディタを使ってみました。
Binary Editor BZ
http://www.forest.impress.co.jp/lib/stdy/program/progeditor/binaryeditbz.html
UTF-8 のエンコードにも対応しており、速度的にも早かったです。今回は 512メガのファイルでしたが、特に違和感なく使えていたので、しばらく BZ を使って見る予定です。
ただ、フォレンジック調査とかの面では文字コードの切り替えが頻繁に発生したりするので、ここはやはり KaniEditor が将来的には必要なのではないかとちょっと感じたところです。
バイナリエディタで UTF-8 な文字列を探す場合に、興味深かったアプローチとしては、@murachueさんが意図的に文字コードを Shift_JIS に切り替えて UTF-8 部分を化けさせるという方法ですね。バイナリをざっと眺めていく時に、UTF-8 の日本語文字列部分が化けて固まっているので、見つけやすいというメリットがあるようです。
■wiconvにバイナリを喰わせる
かなりメモリを消費したりするようですが、wiconv にバイナリファイルを喰わせ、文字コードを変換することでゴミを削るアプローチを @hasegawayosuke さんが挑戦されていました。
wiconv - 文字列のコードページの変換
wiconv により、UTF-8 から Shift_JIS に文字コードを変換することで、壊れた UTF-8 な文字列などは ? などに置換されるので、「?」文字などを後から除去すれば有意な文字だけ残るのではないか？というアプローチだったと思いますが、結局うまくいかなかったんでしたっけ！？
ノイズを除去するというアプローチは、Unallocated Clusters などを調査する上では有効な手法かもしれません。0x00 のような文字では使われないバイトを除去することで、調べる必要があるデータ量が減るので、検索や変換なども早くなる可能性があります。問題としては、オフセット位置などをどう維持するのか？という辺りがありますが、これは今後の検討課題ですかね。
■istringsで UTF-8 を抽出する
istrings の標準では UTF-8 に対応していないということで、@hasegawayosuke さんが(範囲を絞った)マップを追加してバイナリファイルからの文字列抽出を実験されてました。結果を拝見したところ、なかなか結果は人間が見やすい状態になっており調べやすい雰囲気でした。ただ、半角英数時でゴミというかノイズになる文字列のが多かったので、istrings で UTF-8 を抽出後、さらに半角英数のノイズパターンを取り除くか何らかの処理を行なうことで、日本語文字列だけをうまく残し目視しやすくなるかもしれません。
■istringsをFreeBSDで使いたい人向け
@nmantaniさんが5年ぶりに修正されたそうです（笑）
FreeBSD を日頃使ってないので port にあったことを知らなかったのですが、FNG15 の会場で「確かFreeBSD のリクエストで istrings の port な話題が出ていたような」「あーそれ port したの自分」みたいな会話が出てました。世間は狭いというか...
あと、フォレンジック方面のツールで幾つか port が更新されているようです。
■EnCaseにおけるPreviewカラムのフィルタコンディション
KaniGrep を使う場合、ブックマークされたデータを Preview カラムで閲覧していくと見やすくなります。Preview カラムではエンコードプレビューを有効にするか、エントリ側で CodePage を設定しておく必要があります。
Preview カラムについてもコンディションで Find などの構文が有効なのですが、FNG でも試したところフィルタされなくてちょっと悩んでいました。どうもヒットした文字列（ハイライト部分）に対してのみコンディションで設定した文字列が効くらしく、例えば「フォルダ」などの文字列でヒットしている場合には、コンディションで「フォルダ」を指定すると該当するブックマークレコードだけが表示されます。
例えば「マイクロソフト」という片仮名文字列に対して KaniGrep を 3文字で実行すると、「マイク」の部分がヒットします。コンディションで“マイクロソフト”を条件設定すると、一致しないので、“マイク”で入れないとうまくフィルタされません。
うーん、これだとちょっと使いにくいので、ハイライト範囲を前後にもう少し広めに取らないと、コンディションによるフィルタが使いにくいかもしれませんが、ヒット範囲を広げることって出来るのかな？
ちなみに、KaniGrep は「片仮名のみ」「平仮名のみ」「片仮名＆平仮名」「片仮名＆平仮名＆漢字」のいずれかのパターンを選択できると嬉しいなぁと船長に改造を依頼しています。
