2009-10-06 マックタイムに関する古典的な話題のまとめ
会社では14時頃から気分転換をかねた勉強会？とかしているのですが、最近 Timeline 系の話題がよく出るので、MAC time のおさらいをかねて、古典芸能な内容をメモ的に取りまとめ中。*1突っ込みとかコメントなどありましたら大募集ということで ;-)
■MACtimeのお話
フォレンジック調査ではよく耳にすることが多い MAC time や timeline というお話ですが、原典が何かはよく知らないのですが、私が勉強を開始した頃の資料としては、The Coroner’s Toolkit (TCT)*2 でのお話がメジャーでした。あれ？確か TCT ツールキットの中に mactime ってスクリプトが入っていたんでしたっけ？記憶が...
Forensic Discovery 本は内容が Web で公開されているみたいですが、MAC time 関連としては以下が参考になるお話ですかね。
Forensic Discovery
http://www.porcupine.org/forensics/forensic-discovery/
Chapter 2: Time Machines
http://www.porcupine.org/forensics/forensic-discovery/chapter2.html
TCT 方面の動きなどについては、不正アクセス調査ガイド―rootkitの検出とTCTの使い方で渡辺さんが詳しく解説されていたと思うので、そちらを読んでいただくといいかもしれません。
大雑把な説明からいくと、そもそもの MAC という単語は、UNIX が持つ以下の三つのタイムスタンプの頭文字を取って MAC とフォレンジック調査方面では呼ばれています。Apple の OS や、NICなどが持つ MAC とか、強制アクセス制御の MAC とか、ハンバーガーでもない MAC ですね。
http://en.wikipedia.org/wiki/MAC_times
Modification time (mtime)
Access time (atime)
Change time and creation time (ctime)
私が最初に混乱したのは、M の Modification と、C の Change の単語はどう違うのか？という点で、どちらも更新とかって意味ではないのか？！という基本的な辺りでしたが、M は“更新”、C は“変更”のような日本語にトレーニングなどではしています。それぞれのタイムスタンプ毎に、どのタイミングで更新されるかが決まっていますが、大雑把にいくと、M はファイルの内容が更新された場合、A はファイルがアクセスされた場合、C はファイルを管理しているレコードが更新された場合、に変化することになります。この辺りの詳細は mtime とかを man で引くか、Google などで検索するともっと詳しい説明が出てくると思いますが、stat とかいうコマンドもありましたね。
この辺りのファイルシステム毎の MAC の関連性については、「フリーツールを活用したディスクフォレンジック解析」の資料で、スライド番号13〜の辺りの資料で詳しく解説されているのでそちらを参照いただくとよいかもしれません。
もともとが UNIX 系からきているので、MAC は Windows ではそのまま当てはまらない部分があります。Windows XP から NTFS 上のファイルをエクスプローラからプロパティを表示した場合には、以下の三つが表示されます。
作成日時
更新日時
アクセス日時
まず最初の作成日時というのは UNIX 系ではお見かけしたことがありません。ひょっとすると持っているファイルシステムもあるかもしれませんが、思わず MAC の C を Creation とかで間違えてしまいそうですが、すくなくとも Ctime は inode 更新日時ですので作成日時とは異なります。C を Creation とかで読み替えて Windows の場合には C は作成という形に無理やりあてはめるってのもありかもしれませんが...*3
更新日時は Mtime と同じで、ファイルの内容が更新された場合のタイムスタンプで、アクセス日時も Atime で意味としては最終アクセス日時なので基本的な意味合いとしては同じです。
基本的なという書き方をしたのは、ファイルシステムによって分解能というか記録している精度が異なったりもするのでまぁだいたいの意味としてはという趣旨です。
Windows のエクスプローラから見た場合のタイムスタンプには、Ctime に相当する時刻情報は表示されません。
FAT ファイルシステムでは、ファイルはディレクトリエントリで管理されていますが、ディレクトリエントリのそれぞれのレコードが何時更新されたのかという時刻情報は記録されていません。ですので FAT では Ctime に相当する時刻情報がそもそもありません。
しかし、NTFS では MFT ファイルのレコードでファイル情報を管理していますが、MFT レコードの更新日時*4が記録されています。ファイルシステムでは記録していますが、エクスプローラのプロパティ情報では表示されないだけです。NTFS の MFT レコードの更新日時が Ctime とほぼ同じような意味になると思いますが、わかりにくいので、ツールによってはエントリモディファイ（'Entry Modified')などの表現を使っているケースもあるようです。下記の Wiki だと'MACE'とかにしているみたいですね。
MAC times
まぁ、長いと画面で表示しにくなどの理由で省略形が使われることが多いとは思うのですが、C とかは意味が違ってくることがあるので、使うツールがどのタイムスタンプをどのカラムで表示しているかや意味はマニュアルで確認した方がいいかもしれません。その昔、M と C を逆にして表示しているツールとかあって困ったんですけど、サポートからの回答は「読み替えて使ってくれ」ということだった気がする(--;;
UNIX 方面での mactime に関するもう少し詳しいお話は下記 URL を参照いただいた方がいいかもしれません。
mactime
■作成日時
Windows における“作成日時”は、ファイルシステム上でそのファイルが作成された日時を示していて、純粋にそのファイルが作成された日時とは異なります。ファイルがコピーや移動されたりした時に、異なるファイルシステム上に新たに作成されるとその作成日時が入ります。
この為、作成日時より更新日時のほうが“古い”という現象が発生しますが、作成日時が更新日時より新しい場合には、更新日時以前にそのファイルはどこか別のファイルシステム上で作成されていたとかそいうことですかね。もしくはタイムスタンプが変更されているとか...
■FATの最終アクセス日時
FAT ファイルシステムの場合、ディレクトリエントリの構造としてそもそも最終アクセス日までしか記録されていません。ディレクトリエントリでは最終アクセスに関しては時刻がそもそも記録されてないので取れないということになりますが、ツールによっては便宜上 0時0分0秒（00:00:00）という扱いや表示になる場合があります。
タイムラインなどを表示するツールによっては、これが影響してアクセス時間が全て 0時扱いになってしまうケースもあるのでちょっと注意が必要かもしれません。
■NTFSの最終アクセス日時
NTFSでは最終アクセス日時の分解能が1時間となっています。これは、1時間以内の同種のアクセスについては最終アクセス時間を更新しないというパフォーマンス向上を目的としたものになります。最終アクセス日時の更新基準については、以下の記述が参考になります。
http://msdn.microsoft.com/ja-jp/library/cc429752.aspx
プラットフォーム SDK GetFileTime
lpLastAccessTime
1 個の 構造体へのポインタを指定します。関数から制御が返ると、この構造体に、最終アクセス日時が格納されます。最終アクセス日時は、最終書き込み日時、最終読み取り日時、最終実行日時（実行可能ファイルの場合）のいずれかに基づいて決定されます。この情報が不要な場合、NULL を指定します。
以前にプリフェッチ機能のところでも書いていますが、NTFS ではアクセス日時の分解能は1時間となっています。この為、1時間以内に同種のアクセスがあった場合にはディスク上のタイムスタンプが更新されません。ディスク上ではない、メモリ上のタイムスタンプは更新されていきますので、ディスクに記録されていないタイムスタンプは電源断により失われることになります。
例えば、ファイルのタイムスタンプを確認するツールを使ってアクセス日時を確認した場合、メモリ上に保持されている時間が表示されいて、ディスクにはそれより古い時間が記録されているケースでは、電源を切ってから稼働中に得た時間と、ファイルシステムが記録しているアクセス時間とのズレが発生するかもしれません。
■分解能
FAT・NTFSの分解能はプラットフォーム SDK GetFileTime で下記のように説明されています。
注意 すべてのファイルシステムが、作成時刻と最終アクセス時刻を記録できるわけではありません。また、すべてのファイルシステムがそれらの時刻を同じ形式で記録しているわけでもありません。たとえば、Windows NT の FAT では、作成時刻の分解能は 10 ミリ秒（ms）、最終更新時刻の分解能は 2 秒、最終アクセス時刻の分解能は 1 日（実質的にはアクセス日付）です。NTFS では、アクセス時刻の分解能は 1 時間です。したがって、GetFileTime 関数は、SetFileTime 関数を使って指定したのと同じ時刻を返すとは限りません。さらに、FAT はローカルの時刻をディスクに記録します。それに対し、NTFS は世界協定時刻（UTC）をディスクに記録するので、タイムゾーンまたは夏時間の変化による影響を受けません。
NTFS では4つのタイムスタンプがありますが、いずれも 12:00 A.M. January 1, 1601 (UTC)からの 100ns でのインターバル,FAT はローカル時刻を記録しています。FAT の場合には設定可能な範囲が1980年1月1日〜2107年12月31日までということみたいですが、まぁローカル時間が DOS 日付形式でそのまま記録されていますね。
FileTimeToDosDateTime
Windiws Vista 以降ではデフォルトですが、最終アクセス日時の更新をレジストリで無効化することも可能ですので XP などでもレジストリを確認した方がよいケースもあるかもしれません。関連する情報は「NtfsDisableLastAccessUpdate」をキーワードに検索すると色々と発見できます。
Disabling Last Access Time in Windows Vista to improve NTFS performance
ファイルシステムの分解能の差による影響としては、NTFS から FAT ファイルシステムへファイルコピーした時にタイムスタンプが変化するという点もありますね。
[NT] NTFSからFATへのファイルのコピー時に日時が変わる
http://support.microsoft.com/kb/402160/ja
この現象は、 NTFS ファイルと FAT ファイルとのファイルのタイムスタンプの情報量の差によって生じます。 NTFS ファイルは、ファイルの作成日時を、 100 ナノ秒単位で記録していますが、 FAT ファイルは 偶数秒単位でしか記録することができません。そのため、奇数秒に作成されたファイルを NTFS パーティションから FAT パーティションにコピーすると、作成日時の繰り上げが発生します。 FAT パーティションから NTFS パーティションへのコピー時にはこの現象は発生しません。
あと、タイムゾーンによる影響としてはこんなお話もあるようですが、直接影響を受けるケースというのはマレでしょうかね。マルウェアが適当に変なタイムスタンプ付けたりした場合？通常、システム時刻を 1601/01/01 に設定するケースってのはありませんよね。
DIR コマンドを実行したときファイルの日付と時刻が間違って表示される
http://support.microsoft.com/kb/314048/ja
システム時刻が 1601 年 1 月 1 日午前 0 時 00 分 (UTC) に設定されている場合、ファイルが作成されると、そのファイルに対して保存されるさまざまなファイル時刻は、値がゼロ (0) の FILETIME となります。その後、ユーザーが dir コマンドを実行してファイルの一覧を表示すると、ファイルから UTC 時刻が読み取られ、現地時刻への調整が行われます。現地時刻に正のオフセットが加算される場合、有効な FILETIME が算出されます。しかし、負のオフセットが加算されるようにコンピュータのタイムゾーンが構成されている場合、無効な FILETIME 値が算出されます。
■Dtime
ext2fsなどでは、MAC 以外のタイムスタンプとして Dtime も存在しているかと思います。使われているのかよく知らないのですが、The Sleuth Kit などを使っていると、ext2 ファイルシステムで Dtime の値が表示されてくることがあると思うので、値としては入っているケースがあるということかと思いますが、検索しても詳細を解説したページが発見できず。その昔、定義はされているが使われてない、ということを伺ったこともあるのですが、どこかに詳細情報あれば教えていただければです。
■ファイルシステム トンネリング機能
以前に書いてありましたので、こちら参照ください。
このファイルシステム トンネリング機能と同じようにタイムスタンプを維持する機能が、Linux 系のファイルシステムでも存在していると思ったのですが、何という機能？になるのか失念して関連するURLを発見できず...orz
■NTFS 代替データストリームの日時
NTFS 代替データストリーム（NTFS Alternate Data Streams ）のデータにはタイムスタンプがありません。メインストリームのファイルについてはタイムスタンプがありますが、追加ストリームにはタイムスタンプ情報などが無いので代替データストリームにあるデータについては時刻情報が表示されません。
■なぜBODYファイルなのか
記憶が定かではないのですが、確か TCT の出力で body ファイルを作ることになっていて、後から開発された TSK なども、その歴史的な経緯から body というファイルを引き続きタイムライン情報の出力用ファイルとして使っているということでしょうかね。
そもそもなんで“body”なのか謎ですが、TCT が検死官ツールキットというくらいなので、“body”というか遺体とか死体とかの単語が使われているのかなと。Autopsy（検死）とかの単語はイノセントゲリラの祝祭とか、映画『ジェネラル・ルージュの凱旋』などでも単語として出てきて一瞬「お！」とか思ったりもします。
■タイムスタンプの検索
EnCase でしか使えませんが、64bit タイムスタンプ値を検索する EnScript などもあります。
Search for Windows 64 bit TIMESTAMPS
http://www.forensickb.com/2008/01/search-for-windows-64-bit-timestamps.html
指定した時間範囲にあるタイムスタンプと考えられるバイト部分をブックマークしてくれるのだと思いますが、これはこれで中々興味深いアプローチですね。メモリフォレンジックなどの分野では考え方として面白いかもしれません。
NTFS の場合には 100ns でのカウント値が 64bit 整数値で入っていますが、例えば 2009/10/06 13:14:32 +0900 の作成日時を持つ下記三つのファイルがあるとします。64bit タイムスタンプ値はディスク上には以下のバイト列で記録されています。この三つのファイルはいずれも秒数表示でいくと 13:42:32 となりますが、ナノ秒でいくと C → A → B の順に作成されたことが 64bit 整数値とかに変換すれば簡単にわかります。
FA8B78813B46CA01 a.txt
9439C7813B46CA01 b.txt
000450813B46CA01 c.txt
ただし、手元の EnCase では上記タイムスタンプ（File Created）でソートした場合に、A → C → B の順にソートするので、ナノ秒での順序とは違う結果になるようです。Windows のエクスプローラで作成日時順にソートした場合には、ちゃんと C → A → B の順に表示してくれるようです。エクスプローラがナノ秒まで識別しているのかは謎ですが並びは正しくなっています。エクスプローラでも駄目な様子。
Windows の 64bit タイムスタンプをナノ秒単位まで表示するツールがないなぁなどと呟いて言たら、斜め後ろの席の人が画面作ってくれました。*5ありがとうございます！！
tsconv
EnCase とかで 64bit タイムスタンプを 16進数でコピーして貼り付ければコンバートしてくれます。便利デースといいつつ、クリアボタン付けて欲しいとか、タイムゾーンの値は調整できる方が嬉しいとか言ってみたり。
■タイムスタンプの改ざん
タイムスタンプ自体は容易に変更が可能ですし、アンチフォレンジックツールとしては Timestomp があります。Timestomp は意図的に $FILE_NAME 属性のタイムスタンプはそのまま残して $SIA のみ変更してくれますが、$FILE_NAME のタイムスタンプとかまで引っ張ってくるフォレンジックツールは少ない気がしています。
マルウェアによってはタイムスタンプを変更するものもあったりしますし、タイムスタンプをそのまま完全に信用しては駄目というお話はありますね。
ファイルのタイムスタンプだけに限らず、様々なタイムスタンプとの比較などによって特異点などをタイムラインから洗い出す方法などについても、前回の IDF 分科会では話題に出ていました。
自分への戒めのために書いておくと、タイムスタンプは自分の意図している方向へと容易に当てはめて考えやすいので注意が必要ですね。なんとなく並びがおかしくなければ、自分の都合が良いように繋げて考えてしまう傾向が出るので注意と。
