@port139 Blog

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

SANS ポスター：Windows Artifact Analysis(36) CFB（Compound File Binary）

フォレンジック

Jumpリスト、LNKファイルに関連し、CFB（Compound File Binary）形式のデータを扱えるツールをメモしておきたいと思います。

  1. Structured Storage Viewer
    http://www.mitec.cz/ssv.html
  2. Compound File Explorer
    http://sourceforge.net/projects/openmcdf/files/Sample%20Compound%20File%20Viewer/
  3. Compound File Explorer
    http://compound-file-explorer.software.informer.com/
  4. Structured Storage Extractor
    http://www.simplecarver.com/tool.php?toolname=Structured Storage Extractor
  5. Office ビジュアライザー ツール（offvis.exe）
    http://msdn.microsoft.com/ja-jp/library/office/gg615407(v=office.14).aspx
    http://download.microsoft.com/download/1/2/7/127BA59A-4FE1-4ACD-BA47-513CEEF85A85/OffVis.zip

 

SANS ポスター：Windows Artifact Analysis(35) Jump Lists

AutomaticDestinations、CustomDestinationsは共にファイル名にアプリケーションのIDが付与されます。

このIDについては、既知のリストが下記で参照できますので、この値からどのアプリケーションのJummp Listであるかを確認する事が出来ます。

List of Jump List IDs
http://www.forensicswiki.org/wiki/List_of_Jump_List_IDs

別途、この AppID を算出できるツール appid_calc.pl も出ています。

単純にパスの文字列だけが使われる場合だけでなく、アプリケーション ユーザー モデル ID (AppID)形式？や、KNOWNFOLDERIDを使ったパターンもあるようですので、パスで値が一致しない場合には工夫する必要がありそうです。

 

JumpLists file names and AppID calculator
http://www.hexacorn.com/blog/2013/04/30/jumplists-file-names-and-appid-calculator/

KNOWNFOLDERID

http://msdn.microsoft.com/en-us/library/windows/desktop/dd378457%28v=vs.85%29.aspx

jumplistforensics.pdf

https://github.com/blakelyh/Jumplist/blob/master/doc/references/Forensics/jumplistforensics.pdf

 

 

 

SANS ポスター：Windows Artifact Analysis(34) Jump Lists

フォレンジック

customDestinations の内部構造としては SHLINK 構造ですが、ツールによっては一部パースしていない情報があるようですので、少し確認しておきます。
下記は 4119a98bddddcdb4.customDestinations-ms の ShellLinkHeader（76byte分）を抜粋したものになります。

4C 00 00 00 01 14 02 00 00 00 00 00 C0 00 00 00
00 00 00 46 E3 40 20 00 20 20 00 00 6E 51 F2 D9
F0 2B CC 01 30 52 CD A4 65 87 CF 01 C2 31 02 41
C6 80 CF 01 48 21 0D 00 00 00 00 00 01 00 00 00
00 00 00 00 00 00 00 00

オフセット 20 からの 4byte が LinkFlags で E3 40 20 00 がフラグになります。これを2進数に戻すと以下のビットがセットされている状況になります。

1000000100000011100011
VUTSRQPONMLKJIHGFEDCBA

上記では、FとGのフラグが立った状態になっています。

F
HasArguments
G
HasIconLocation

これらのデータはどちらも StringData 構造になります。
構造としては、LinkInfoの次にVolumeIDがあり、その続きにStringData構造が続くことになります。この場合、LocalBasePathのデータが終わった箇所から引き続きUnicode文字列が続く形になるので目視でも確認が可能です。
ただ、手元でテストしている範囲では、JumpListerはこのStringData構造をパースしていないようで、ArgumentsやIconLocationの文字列がデータとしては存在していても、出力結果の画面上ではこれを確認できませんでした。
TZworks の jmp コマンドでは、extra info のカラムに以下のようにStringData構造が出ますので、ツールによるパース結果の差異には注意が必要です。

[CmdArgs]: http://www.example.co.jp/; [IconName]: C:\Users\forensics\AppData\Local\Google\Chrome\User Data\Default\JumpListIcons\78A5.tmp

 

SANS ポスター：Windows Artifact Analysis(33) Jump Lists

フォレンジック

Jump Listsには、AutomaticDestinationsフォルダとは別にCustomDestinationsフォルダがあり、こちらにも 4119a98bddddcdb4.customDestinations-ms といったファイルが保存されています。
AutomaticDestinations は CFB 形式でしたが、customDestinations の内部構造としては SHLINK 構造が複数存在する状況になっています。以下は 4119a98bddddcdb4.customDestinations-ms ファイルの先頭部分を抜粋したものになります。

02 00 00 00 03 00 00 00 00 00 00 00 00 00 00 00
0B 00 88 30 4F 30 A2 30 AF 30 BB 30 B9 30 59 30
8B 30 DA 30 FC 30 B8 30 04 00 00 00 01 14 02 00
00 00 00 00 C0 00 00 00 00 00 00 46 4C 00 00 00
01 14 02 00 00 00 00 00 C0 00 00 00 00 00 00 46
E3 40 20 00 20 20 00 00 6E 51 F2 D9 F0 2B CC 01
30 52 CD A4 65 87 CF 01 C2 31 02 41 C6 80 CF 01
48 21 0D 00 00 00 00 00 01 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00

上記のうち、下記のバイト列部分は Unicode で“よくアクセスするページ”という文字列になります。

88 30 4F 30 A2 30 AF 30 BB 30 B9 30 59 30 8B 30
DA 30 FC 30 B8 30

この続きに、4C 00 00 00 があり、これがHeaderSizeになります。この次にLinkCLSID (16 bytes):00021401-0000-0000-C000-000000000046 が続きますので、この LinkCLSID が目印になるかと思います。

例えば、JumpLister ツールを利用すれば、customDestinations ファイル内に複数含まれている SHLINK 構造をパースした結果を簡単に確認する事が可能ですね。

JumpLister
http://www.woanware.co.uk/forensics/jumplister.html

 

SANS ポスター：Windows Artifact Analysis(32) Jump Lists

フォレンジック

LinkInfo構造の続きとしては、VolumeID構造に続きLocalBasePath (variable)が続きます。LocalBasePathにファイルパスが記録されています。

データとしては更にPage 28のExtraData構造が続く形になります。ExtraDataには幾つかのプロパティデータブロックがありますが、これらはBlockSignatureで区別する事になります。以下はExtraData部分を抜粋したものですが、先頭4バイト 39 00 00 00 が BlockSize ですので、57byte 分になります。

39 00 00 00 09 00 00 A0 2D 00 00 00 31 53 50 53
55 28 4C 9F 79 9F 39 4B A8 D0 E1 D4 2D E1 D5 F3
11 00 00 00 07 00 00 00 00 0B 00 00 00 FF FF 00
00 00 00 00 00 00 00 00 00

先頭4バイトの次にある 4 バイトが BlockSignature になります。上記では 09 00 00 A0 ですので、0xA0000009 になり、PropertyStoreDataBlock という事になります。（Page 39）
Property storage structure になりますので、レジストリのWindows Shell Item構造として出てきた MS-PROPSTORE 構造としてパースしていく事になります。

いずれにしても、ExtraData構造が続く場合には、BlockSignature の値を確認して、MS-SHLINKで該当構造を確認する事になります。手元のデータでは、0xA0000009 の次には、0xA0000003 のブロックシグネチャが出現し、TrackerDataBlock（Page 41）が続いている状況でした。TrackerDataBlock には MachineID として NetBIOS name が収納されていたりします。

SANS ポスター：Windows Artifact Analysis(31) Jump Lists

フォレンジック

LinkInfo構造の内容を確認してみます。（MS-SHLINK の Page 15）
先頭4バイトがLinkInfoSizeですので、下記では 7F 00 00 00 という値から 128byte分のデータ範囲を抜粋しています。

7F 00 00 00 1C 00 00 00 01 00 00 00 1C 00 00 00
2D 00 00 00 00 00 00 00 7E 00 00 00 11 00 00 00
03 00 00 00 FD 7B EA 05 10 00 00 00 00 43 3A 5C
55 73 65 72 73 5C 68 68 68 68 68 68 5C 41 70 70
44 61 74 61 5C 52 6F 61 6D 69 6E 67 5C 4D 69 63
72 6F 73 6F 66 74 5C 57 69 6E 64 6F 77 73 5C 4C
69 62 72 61 72 69 65 73 5C 44 6F 63 75 6D 65 6E
74 73 2E 6C 69 62 72 61 72 79 2D 6D 73 00 00

LinkInfoSize に続く 4バイトは LinkInfoHeaderSize という事になっていますので、1C 00 00 00 が該当箇所になり 28byte になります。Page 20 の説明によると、0x0000001C はオプションフィールドの有り無しとしては、オプションフィールド無しの場合になります。

次の4バイトは LinkInfoFlags で 01 00 00 00 となります。フラグとしてはビット 0,1 で A と B の区別だけになります。上記では 01 で 0 ビット目の A が立っていますので、A：VolumeIDAndLocalBasePath がセット状態になります。（Page 21）

VolumeIDAndLocalBasePathがセット状態の場合、VolumeIDとLocalBasePathフィールドが存在する事になります。
LinkInfoFlags で A が立っている状態で、VolumeIDとLocalBasePathフィールドが存在する事になるので、LinkInfoFlags に続くデータは、VolumeIDOffset (4 bytes) と LocalBasePathOffset (4 bytes) となります。

VolumeIDOffset：1C 00 00 00
LocalBasePathOffset：2D 00 00 00

それぞれオフセット位置を示していますが、これは LinkInfo構造の先頭（0x7F）からのオフセット位置となります。

次の4バイトは CommonNetworkRelativeLinkOffset ですが、フラグが設定されていませんので、ここはゼロになります。続きの4バイトは CommonPathSuffixOffset になりますが、これもLinkInfo構造の先頭（0x7F）からのオフセット位置となります。

CommonNetworkRelativeLinkOffset：00 00 00 00
CommonPathSuffixOffset：7E 00 00 00

LocalBasePathOffsetUnicode、CommonPathSuffixOffsetUnicodeはオプショナルなフィールドになります、今回LinkInfoHeaderSizeが0x00000024以上ではないので、このフィールドはありません。

続いて出てくるのは VolumeID になりますが、これは Page 22 に構造が出ています。

03 00 00 00 FD 7B EA 05 10 00 00 00 00

 

SANS ポスター：Windows Artifact Analysis(30) Jump Lists

フォレンジック

Jump Listsファイルの内部では、データとしてMS-SHLINK構造でデータが保存されていますが、ShellLinkHeader のオフセット 20 からの 4byte LinkFlags を確認する事で LinkInfo が存在するか確認できます。
下記は ShellLinkHeader の 76byte 分ですが、LinkFlags は 83 00 00 00 になっている事が分かります。

4C 00 00 00 01 14 02 00 00 00 00 00 C0 00 00 00
00 00 00 46 83 00 00 00 20 20 00 00 A7 CA 99 AF
03 03 CC 02 35 81 7D 25 19 70 CF 02 35 81 7D 25
19 70 CF 02 C8 0D 00 00 00 00 00 00 01 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 36 00 14 00

LinkFlags が 83 00 00 00 の場合、1000 0011 ですので、0と1と7のビットが立っていますので、フラグとしてはA,B,Hが該当します。MS-SHLINK の Page 11 によると、それぞれ以下のフラグとなります。

A：HasLinkTargetIDList
B：HasLinkInfo
H：IsUnicode

このヘッダ内の LinkFlags フラグ値から HasLinkInfo が存在している事がわかりますので、HasLinkTargetIDList に続いて HasLinkInfo 構造を確認していく事になります。

ShellLinkHeader
↓
HasLinkTargetIDList（フラグAが立っている）
↓
HasLinkInfo（フラグBが立っている）

LinkInfo構造は MS-SHLINK の Page 15 から構造が説明されています。

SANS ポスター：Windows Artifact Analysis(29) Jump Lists

フォレンジック

Jump Listsファイルの内部では、データとして MS-SHLINK 構造でデータが保存されていますが、ShellLinkHeader の後には（ヘッダ内のLinkFlagsの値に依存しますが）LinkTargetIDList と LinkInfo 構造が続く事になります。

下記は ShellLinkHeader の後に続いている LinkTargetIDList を抜粋したものになります。

先頭 2バイト 36 00 が IDListSize ですので、IDlist が 54byte あることになります。36 00 以降に続く 54byte が IDList で中身としては ItemIDList と TerminalID です。TerminalID は 2バイトですがここはゼロになります。

36 00 14 00 1F 42 25 48 1E 03 94 7B C3 4D B1 31
E9 46 B4 4C 8D D5 20 00 00 00 1A 00 EE BB FE 23
00 00 10 00 7D B1 0D 7B D2 9C 93 4A 97 33 46 CC
89 02 2E 7C 00 00 00 00

上記の 36 00 に続く ItemID は、ItemIDSizeとDataになります。上記では 14 00 がサイズで 20byte のデータがあると分かります。次が 20 00 でデータが 32byte あるという事になります。結果的に上記の LinkTargetIDlist をパースすると、以下の二つの ItemID になります。

14 00 1F 42 25 48 1E 03 94 7B C3 4D B1 31 E9 46
B4 4C 8D D5

20 00 00 00 1A 00 EE BB FE 23 00 00 10 00 7D B1
0D 7B D2 9C 93 4A 97 33 46 CC 89 02 2E 7C 00 00

 

 

SANS ポスター：Windows Artifact Analysis(28) Jump Lists

フォレンジック

Windows 7 の Jump Lists ファイルである、 <ApplicationID>.automaticDestinations-ms ファイル構造の続きになります。
Jump Listsファイルの内部では、データとしてMS-SHLINK構造でデータが保存されています。
下記はディレクトリエントリ名 1 の 128byte 分になります。

31 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
04 00 02 01 FF FF FF FF 02 00 00 00 FF FF FF FF
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 A0 01 00 00 00 00 00 00

オフセット 66 の値が 02 ですので、Stream Object となり、セクタ位置はMini Sectorの番号になります。
オフセット 116 からの4バイト Starting Sector Location は 00 00 00 00 となっており、オフセット 120 からの 8バイト Stream Size は A0 01 00 00 00 00 00 00 ⇒ 416byte という事になります。

Mini Sector のセクタ 0 にあるデータ内容を確認すると下記のデータ構造になっている事が確認できます。これは、[MS-SHLINK].pdf の Page 9 にある ShellLinkHeader になっています。

4C 00 00 00 01 14 02 00 00 00 00 00 C0 00 00 00
00 00 00 46 83 00 00 00 20 20 00 00 A7 CA 99 AF
03 03 CC 01 35 81 7D 25 19 70 CF 01 35 81 7D 25
19 70 CF 01 C8 0D 00 00 00 00 00 00 01 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 36 00 14 00

先頭 4バイトが HeaderSize (4 bytes) となっており、4C 00 00 00 ですので 76byte 分がヘッダという事になります。
続く 16byte は LinkCLSID で、00021401-0000-0000-C000-000000000046 が class identifier (CLSID) として設定されていますので、これが ShellLinkHeader と識別できます。

ShellLinkHeaderのデータ構造は下記になっています。（MS-SHLINK Page 10～11参照）

HeaderSize (4 bytes)
LinkCLSID (16 bytes)
LinkFlags (4 bytes)
FileAttributes (4 bytes)
CreationTime (8 bytes)
AccessTime (8 bytes)
WriteTime (8 bytes)
FileSize (4 bytes)
IconIndex (4 bytes)
ShowCommand (4 bytes)
HotKey (2 bytes)
Reserved1 (2 bytes)
Reserved2 (4 bytes)
Reserved3 (4 bytes)

 

雑談：週末サイクリング 7/6

雑談（無駄話）

今週は平日もロードバイクに乗ってましたので、 35km＋50km＋35km+50km （合計 170km）走る事ができ、仮想目標まで 515km という事になりました。

 梅雨時は晴れ間を縫って走るような感じになりますが、関東地方の梅雨明けはまだ少し先になるようですので、早く梅雨が明けてくれると嬉しいですね。

f:id:hideakii:20140706101104j:plain