@port139 Blog

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

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