Forensicist

Ext4の動向ですが、Fedora 11, Ubuntu 9.10ではインストール時のファイルシステムとしてデフォルト設定
されるようになり、徐々に普及してきています。今回主にiノード周りの変更を調べてみましたが、タイムスタ
ンプの扱いとして大きく2点拡張されていました。

• ナノ秒までの情報を格納
• 作成日時(crtime)の追加

inode構造体の宣言部分のソースコード(fs/ext4.h)を以下に示します。

これまでのi_atime, i_ctime, i_mtime, (i_dtime)の位置はそのままですが、後方にi_ctime_extra,
i_mtime_extra, i_atime_extraという変数が追加されており、作成日時もi_crtime, i_crtime_extraとして
追加されています。
# extraの並びがa, c, mでないのが気になりますが..何か理由でもあるのでしょうか

そして以下はテスト用に作成したforensics.txtというファイルに対するstatコマンドの実行結果です。

画面より、秒未満の9桁の値(つまりナノ秒まで)が記録されていることがわかります。このinodeに相当すると
思われる領域をEnCaseのhexビューで表示した画面が以下です。
# EnCaseはまだExt4のパースに対応していないのでSingle Fileで追加してそれらしき場所を目視で探しました

オレンジ線がタイムスタンプ関連の情報です。"91 CE D6 41"はunix epochで変換すると2005/01/02
01:23:45(+0900)となります。以下はDCodeで変換した時の結果です。

extraの方の変数には"18 9E D5 4A"と"1C A7 2E 9B"の2パターンが記録されています。構造体の並びと
statの実行結果から、"18 9E D5 4A"はctimeとmtimeで313878406、"1C A7 2E 9B"はatimeの
650881479に相当するデータであると考えられます。

少し試行錯誤しましたが、結局構造体の宣言部に書いてあるコメント(nsec << 2 | epoch)のおかげで解決
しました。

"18 9E D5 4A" -> 並び替え -> "4A D5 9E 18" -> 10進変換 -> 125513624 -> 4で割る(2ビット右シフト) -> 313878406
"1C A7 2E 9B" -> 並び替え -> "9B 2E A7 1C" -> 10進変換 -> 2603525916 -> 4で割る(2ビット右シフト) -> 650881479

この変換でナノ秒としての値が取り出せます。後ろのepochとのOR演算部分(| epoch)の意味はよくわかり
ませんでした。ext4のタイムスタンプの範囲が1901-2514年と拡張されていることに関連しているとの
予想ですが、現状のLinuxではいわゆる2038年問題(http://ja.wikipedia.org/wiki/2038年問題)があり、
2039年以降に設定するとOSの動きがおかしくなり検証できませんでした。

ちなみに上の例では作成日時(crtime)もmtime, ctimeと同じ値(2005/01/02 01:23:45.313878406
+0900)が格納されていることがわかります。ただ、現状はcrtimeをネイティブのコマンド等で確認する
方法はなさそうです。フォレンジック調査ツールがcrtimeを取得するように実装されるといいのですが...
さすがに大丈夫かな??