@port139 Blog

基本的にはデジタル・フォレンジックの技術について取り扱っていますが、記載内容には高確率で誤りが含まれる可能性があります。

exFATディレクトリエントリ

exFATのディレクトリエントリは、1レコード16バイト長、先頭バイトの値でタイプが示されており、一般的なファイルなどは、それぞれ 85, C0, C1 というタイプの順序で並ぶということみたいですね。
例えばこれはDesert.jpgというファイルのexFATにおけるディレクトリエントリになります。

0x85で開始されるレコードは、「exFAT構造解析」によるとFileAttributes1(ファイル属性1)として、属性値やタイムスタンプを保持するレコードということのようです。

85 02 CC 37 20 00 00 00 8B 88 14 3B 8D 6E EE 3A
8B 88 14 3B 6F 00 A4 A4 A4 00 00 00 00 00 00 00

タイムスタンプには作成日時が二カ所あることになっているのですが、分解能などはもう少し調べてみないといけないところです。CWA順にタイムスタンプが記録されている後ろの「CreationTime (10ms)」となっている1バイト分のデータは何用?

C0 03 00 0A 69 63 00 00 75 E8 0C 00 00 00 00 00
00 00 00 00 20 00 00 00 75 E8 0C 00 00 00 00 00

タイプ 0xC0 のレコードでは、ファイルサイズが二カ所(黄緑部分)に保存されていますが、ファイルサイズ2の前にある4バイト(青色)が開始クラスタ位置(CL 32)ということで、C0 レコードを見れば開始クラスタ位置とサイズを確認できるということになります。

C1 00 44 00 65 00 73 00 65 00 72 00 74 00 2E 00
6A 00 70 00 67 00 00 00 00 00 00 00 00 00 00 00

タイプ 0xC1 のレコードにはファイル名が UTF-16LE で入っていることになります。ファイル名が長い場合には更に C1 レコードが追加されることになりますが、ファイル名の長さは 0xC0 レコード(FileNameLength)で管理されている構造みたいですね。単に「exFAT 構造解析」を参考に見比べているだけだったりはしますが(^^;;

exFATの削除エントリ

exFATではファイルが削除されると、ディレクトリエントリの先頭にあるタイプを示すバイトの最上位ビットがゼロクリアされるということです。ファイルが削除されたディレクトリエントリでは下記のようにディレクトリエントリの先頭バイトの最上位ビットがゼロクリアされていることが確認できます。
Jellyfish.jpgが削除された後のディレクトリエントリ。

05 02 5C 7B 20 00 00 00 8B 88 14 3B 8D 6E EE 3A
8B 88 14 3B B3 00 A4 A4 A4 00 00 00 00 00 00 00
40 03 00 0D 9D 6C 00 00 16 D6 0B 00 00 00 00 00
00 00 00 00 4D 00 00 00 16 D6 0B 00 00 00 00 00
41 00 4A 00 65 00 6C 00 6C 00 79 00 66 00 69 00
73 00 68 00 2E 00 6A 00 70 00 67 00 00 00 00 00

ということで、ホワイトボードに2進数を書いて確認していたりしましたが、まず 0x85 の場合には 8 を2進数で表現すると「 1 0 0 0 」なので、最上位ビットがゼロになると「 0 0 0 0 」になって、0x05 となります。同じように、0xC0 の C は2進数で「 1 1 0 0 」なので、「 0 1 0 0 」となって 0x40 になると。
タイプの値だけが変化するので、ファイル名の先頭が E5 で埋められるということもないので、削除ファイルのリカバリは、ファイル名はそのまま 0x41 レコードから戻して、0x40 レコードにある開始クラスタとファイルサイズなどからデータを戻すことで、従来の FAT でのファイルリカバリと同じ流れになりそうです。

フォルダのエントリ

従来「.」と「..」のパターン検索を行うことで、FATのフォルダエントリを探したりできましたが、exFATではフォルダ内のディレクトリエントリとして「.」と「..」がなく、直接 0x85 などのレコードが記録されています。ということで、Recover Folders...が使えないというか、EnCaseの右クリックメニューにも表示が見あたりません。*1
Grep「\x05.{31,31}\x40.{31,31}\x41」で 0x05 と 0x40 と 0x41 が出てくるのを探せないこともないとは思いますが、その後を手動でやるのがちょっと大変ですかねぇ。実際に検索してみるとそこそこノイズも出るので、もう少し精査しないと駄目かも。

*1:EF6.14.1だと削除フォルダまではリカバリするんですがその中身を復元してこない気がする、ディレクトリエントリは目視で確認すると存在しているので、不具合なのか現状の制限事項なのかは不明

次回FNG02は9月5日予定

次回の FNG02 は 9月5日のまたもや土曜日8時〜12時辺りでの開催予定です。テーマは「Registory-1」ということでレジストリになります。Windows 7レジストリ*1とかちょっと眺めてみようかなぁと思っていますが、あわせて RegRipper のマルチバイト対応とかについても色々と検証することを考えています。とはいっても、FNGは講師とかいるわけではないので、参加者でレジストリを延々眺めたりツールの結果を眺めるということになるわけですが(笑)
参加者の募集は来週8/31辺りを予定。

*1:基本的にFNGでは新しいものを触ってみる的な方向で考えていたりします