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
