TZWorks LLC software and related documentation ("Software") is governed by separate licenses issued from TZWorks LLC. The User Agreement, Disclaimer, and/or Software may change from time to time. By continuing to use the Software after those changes become effective, you agree to be bound by all such changes. Permission to use the Software is granted provided that (1) use of such Software is in accordance with the license issued to you and (2) the Software is not resold, transferred or distributed to any other person or entity. Refer to your specific EULA issued to for your specific the terms and conditions. There are 3 types of licenses available: (i) for educational purposes, (ii) for demonstration and testing purposes and (iii) business and/or commercial purposes. Contact TZWorks LLC (info@tzworks.com) for more information regarding licensing and/or to obtain a license. To redistribute the Software, prior approval in writing is required from TZWorks LLC. The terms in your specific EULA do not give the user any rights in intellectual property or technology, but only a limited right to use the Software in accordance with the license issued to you. TZWorks LLC retains all rights to ownership of this Software.

Export Regulation

The Software is subject to U.S. export control laws, including the U.S. Export Administration Act and its associated regulations. The Export Control Classification Number (ECCN) for the Software is 5D002, subparagraph C.1. The user shall not, directly or indirectly, export, re-export or release the Software to, or make the Software accessible from, any jurisdiction or country to which export, re-export or release is prohibited by law, rule or regulation. The user shall comply with all applicable U.S. federal laws, regulations and rules, and complete all required undertakings (including obtaining any necessary export license or other governmental approval), prior to exporting, re-exporting, releasing, or otherwise making the Software available outside the U.S.

The user agrees that this Software made available by TZWorks LLC is experimental in nature and use of the Software is at user's sole risk. The Software could include technical inaccuracies or errors. Changes are periodically added to the information herein, and TZWorks LLC may make improvements and/or changes to Software and related documentation at any time. TZWorks LLC makes no representations about the accuracy or usability of the Software for any purpose.

ALL SOFTWARE ARE PROVIDED "AS IS" AND "WHERE IS" WITHOUT WARRANTY OF ANY KIND INCLUDING ALL IMPLIED WARRANTIES AND CONDITIONS OF MERCHANTABILITY, FITNESS FOR ANY PARTICULAR PURPOSE, TITLE AND NON-INFRINGEMENT. IN NO EVENT SHALL TZWORKS LLC BE LIABLE FOR ANY KIND OF DAMAGE RESULTING FROM ANY CAUSE OR REASON, ARISING OUT OF IT IN CONNECTION WITH THE USE OR PERFORMANCE OF INFORMATION AVAILABLE FROM THIS SOFTWARE, INCLUDING BUT NOT LIMITED TO ANY DAMAGES FROM ANY INACCURACIES, ERRORS, OR VIRUSES, FROM OR DURING THE USE OF THE SOFTWARE.

The Software are the original works of TZWorks LLC. However, to be in compliance with the Digital Millennium Copyright Act of 1998 ("DMCA") we agree to investigate and disable any material for infringement of copyright. Contact TZWorks LLC at email address: info@tzworks.com, regarding any DMCA concerns.

jmp is a command line version of a Windows parser that operates on files that are used to generate Jump Lists. Jump Lists are a new feature, originating with Windows 7. They are similar to shortcuts in that they take one directly to the files or directories that are used on a regular basis. They are different than the normal shortcut in that they are more extensible in what information they display. For example, Internet Explorer will use Jump Lists to display websites frequently visited; Microsoft Office products like Excel, PowerPoint and Word, on the other hand, will show most recently opened documents.

From a user's standpoint, Jump Lists increase one's productivity by providing quick access to the files and tasks associated with one's applications. From a forensics standpoint, Jump Lists are a good indicator of which files were recently opened or which websites were visited frequently.

The Windows operating system derives the Jump List content from two sets of Destination files. (a) The first set is the automaticDestinations type files; these are the ones the operating system creates and maintains. They store information about data file usage. Items are sorted either by Most Recently Used (MRU) or by Most Frequently Used (MFU), depending on the application. (b) The second set is the customDestinations type file. The content contained within, and the tasks specified by this category of file, are maintained by the specific application responsible for that specific Destination file. Suffice to say, both formats rely on the SHLLINK structure to store much of their information.

These two categories of files are located in the following areas on the file system.

    a. %APPDATA%\Microsoft\Windows\Recent\AutomaticDestinations\[AppID].automaticDestinations-ms
    b. %APPDATA%\Microsoft\Windows\Recent\CustomDestinations\[AppID].customDestinations-ms

%APPDATA% is resolved to C:\Users\<user account>\AppData\Roaming. From the path, one can see that each user account (or profile) has its own set of Destination files.

The AppID (or application identifier) is used as part of the name in the construction of the Destination filename. This is a 16 character name and is usually based on the process name, but ultimately can be specified by the application.

To use this tool, an authentication file is required to be in the same directory as the binary in order for the tool to run.

The automaticDestinations file consists of a Compound File Binary (CFB) structure as the container for a DestList stream and individual SHLLINK streams. The CFB acts like a file system within a file, and each SHLLINK structure can be referenced individually via a separate stream. Both the CFB and SHLLINK specifications are individually published by Microsoft as part of their open specifications agreement.

The DestList stream is a collection of MRU/MFU entries whose format is still being investigated, but contains a timestamp, MRU/MFU entry, corresponding SHLLINK stream, NETBIOS name, target file name, object/volume identifiers, and some other unknown information. Combining the DestList information with that of the SHLLINK information, one can have a useful set of forensic artifacts when determining activity on a computer.

The customDestinations file uses a container structure that is quite different, but simpler, than that of the automaticDestinations file. Aside from the initial header at the beginning of the file, the SHLLINK structures do not follow the orderly grouping like that of the Compound File Binary used in the automaticDestinations file. Instead, the SHLLINK structures are packed sequentially. Secondly, additional custom metadata can be inserted into these types of files. The contents of this custom data are controlled by the application logging the data. jmp, however, only parses the SHLLINK type metadata from these types of files and not any of the unique metadata that may have been placed there by the application.

When designing the jmp tool, the SHLLINK parsing engine was taken from the TZWorks LLC LNK parsing tool coined lp. This engine was wrapped in a compound file stream parsing engine to extract the appropriate streams so the SHLLINK structures could be parsed with assured accuracy.

As an aside, the lp tool also has an option (unlike the jmp tool) to parse SHLLINK structures from raw unstructured data. Using this capability, one can pull out SHLLINK metadata that is buried within an image of a volume (or drive). Furthermore, lp can also parse SHLLINK structures from within a compound file, similar to that of an automaticDestinations file. The lp tool, however, does not associate the automaticDestinations file's MRU/MFU data for each SHLLINK structure parsed, and hence, the reason that the jmp tool was created. More information about what the lp tool can do is discussed on the TZWorks LLC website at http://tzworks.com/prototype_page.php?proto_id=11.

While the jmp tool doesn't require one to run with administrator privileges, without doing so will restrict one to only looking at your account's Destinations files or those common to the operating system.

One can display the menu options by typing in the executable name without parameters. Below is the menu that is displayed. Details of each option can be found here.

    Usage

      jmp <filename> [-csv]
      jmp -vss <index>           = *** parse Users dir in Volume Shadow
      dir C:\Users\*ions-ms /b /s | jmp -pipe [-csv]
      jmp -enumdir <location jmp files> -num_subdirs <#> [-csv]

     Basic options
      -csv                       = output in comma separated value format
      -csvl2t                    = log2timeline output
      -bodyfile                  = sleuthkit output

     Additional options
      -username <name>           = output will contain this username
      -hostname <name>           = output will contain this hostname
      -base10                    = use base10 for file size instead of hex
      -pipe                      = pipe files into app for processing
      -dateformat mm/dd/yyyy    = "yyyy-mm-dd" is the default
      -timeformat hh:mm:ss       = "hh:mm:ss.xxx" is the default
      -pair_datetime             = combine date/time into 1 field for csv
      -no_whitespace             = remove whitespace between csv delimiter
      -quiet                     = don't display status during run
      -csv_separator "|"         = use a pipe char for separator
      -show_offset               = include file offset of the entry
      -filter <*partial*|*.ext>  = filters stdin data from -pipe option
      -translate_appid           = uses default AppID translation

     Experimental options
      -slack                     = parse slack [automaticDestinations only]
      -appid <pathfile>          = compute AppID for given path/file
      -appid_ref <file> -appid_separator "|" = ref for AppID translation
      -idltimes                  = incl the IDList times (only [default|-csv])

To parse an individual Destinations file, use the following notation:

        jmp <Destinations filename> > results.txt

Without specifying one of the format options, the output is rendered in a default, unstructured output. This information is useful if one is not trying to parse any artifacts into a database. Notice that in the example above the output is redirected to a text file called 'results.txt'. Since the output that is generated is usually very long (and wide, if using the CSV option), it is recommended that one redirect the output of the command into a file as show above.

The -csv (comma separated value) option will render the output so that all the metadata is rendered with one SHLLINK record per line, where each field is delimited by a comma. The other two output formats are the: (a) -csvl2t and (b) -bodyfile. Each will attempt to conform to either the log2timeline format or the SleuthKit's body-file format, as appropriate.

While parsing one Destinations file is useful, one will usually want to parse all the Destinations files that are on a system or in a set of directories. One way to do this is to pipe in all the paths/filenames of the Destinations type files one wishes to parse into jmp. To allow jmp to receive data from an input pipe, one needs to invoke the -pipe switch. This will allow jmp to receive a separate path/filename per line as input. To provide this input, one can use the Windows built-in dir command along with some of its own switches to get the desired result. Below is an example:

        dir c:\users\*ions-ms /b /s | jmp -pipe -csv > results.csv

Note: the above syntax has NO dot between the asterisk and the letters 'ions-ms'. The dir command also uses the '/b' and '/s' switches to ensure only the bare path/filename is displayed while recursing the subdirectories. This command will find all the Destinations-ms files that are located anywhere in the c:\users directory or subdirectories. This assumes, of course, that one is running with administrator privileges.

When analyzing the CSV output, the automaticDestinations metadata will include the MRU/MFU index, stream and timestamp.

The MRU/MFU index is a chronological list of entries, where #1 is the latest. Each application ID has its own sequential list. Following the index value is the stream number (or directory name) that holds the data in the compound file. It is not uncommon to find hundreds of streams, where each stream (with a couple exceptions) contains a SHLLINK data structure. The MRU/MFU entry has a unique timestamp that shows when that entry was updated. Combining the MRU/MFU data with that of the SHLLINK metadata provides a wealth of forensic information to the investigator.

Using a File to Translate AppID to Applcation Name

To translate the AppID hex number to an application name, one can use the -appid_ref <file> option, where the file is the mapping between AppID and the application name. The file is strickly text base with no special characters except for the pipe '|' delimiter between the AppID number and the applicatio name. If another delimiter is desired, then invoke the -appid_separator option to specify which delimiter to use.

There is another experimental option -appid <pathfile> to help determine what the AppID is based on the path and name of the application.

One can parse the JumpList files stored in a Volume Shadow via the -vss <index of volume shadow> option. This will then direct jmp to the appropriate Volume Shadow where it starts processing the various user's automatic and custom destination files.

In addition to the -vss <index of volume shadow>, we've built in a shortcut syntax in order to more easily access a specific file in a specified Volume Shadow copy, via the %vss% keyword. This internally gets expanded into \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy. Thus, to access index 1 of the volume shadow copy, one would combine the keyword and index, index, (eg. %vss%1) in front of the normal path of the file. For example, to access a file located in the testuser account from the HarddiskVolumeShadowCopy1, the following syntax can be used:

    jmp %vss%1\Users\testuser\AppData\Roaming\Microsoft\Windows\Recent\AutomaticDestinations\1b4dd67f29cb1962.automaticDestinations-ms

To determine which indexes are available from the various Volume Shadows, one can use the Windows built-in utility vssadmin, as follows:

    vssadmin list shadows

    -- or to filter out extraneous detail --
    
    vssadmin list shadows | find /i "volume"

While the amount of data can be voluminous from that above command, the keywords one needs to look for are names that look like this:

    Shadow Copy Volume: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1
    Shadow Copy Volume: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy2
    ...

From the example above, notice the number after the word HarddiskvolumeShadowCopy. This would be the number that is passed as an argument to the previous options.

Aside from the additional data unique to jump list, the rest of the data is identical to that contained in the LNK file. Depending on the data embedded into a link file the output will vary. Below are a couple of samples parsed from the SANS Forensics 408 Windows 8 exemplar image:

Example of a more common automatic JumpList file's output

The date fields "file modified/accessed/created" relate to the actual Jump List file itself, while the "target modified/accessed/created" relate to the target file the LNK refers to. Therefore when copying a Jump List file from a target system to another system for offline analysis, this date will reflect the date you created it on the offline system. For Automatic type Jump Lists, the MRU/MFU index and Most Recently Used (MRU) time is useful. The Object ID, if present, is unique to the target file and one can derive the creation of this object identifier from the actual object ID as well as the MAC address of the target system the object ID was created on. The fields for MFT Entry and Sequence number refer to the actual MFT (or inode) number of the target file that the LNK data embedded into the Jump list refers to. The ID List is usually a mix of class identifiers (eg. GUIDs) and named nodes, when combined together provide a path to the target file. Embedded into this list are other metadata that contain details about the target. The other fields should be self explanatory.

    source path/filename:     e:\testcase\jmp\fb3b0dbfee58fac8.automaticDestinations-ms
    AppID:                    fb3b0dbfee58fac8
    MRU/MFU index:            13
    MRU time:                 08/01/2013 19:21:18.540 [UTC]
    file modified:            11/18/2013 20:26:01 [UTC]
    file accessed:            10/01/2014 14:04:33 [UTC]
    file created:             10/01/2014 14:04:33 [UTC]
    MFT Entry:                0x0000bce9                            <-- references the target MFT entry
    MFT Sequence#:            0x0009                                <-- references the target MFT entry
    Target flags:             HasLinkTargetIDList, HasLinkInfo, IsUnicode, DisableKnownFolderAlias, UnaliasOnSave
    Target attributes:        FILE_ATTRIBUTE_ARCHIVE
    Target modified:          08/12/2013 03:39:23.540 [UTC]
    Target accessed:          08/08/2013 19:18:11.402 [UTC]
    Target created:           08/08/2013 19:18:11.402 [UTC]
    Target ObjID time:        10/21/2013 16:14:28.758 [UTC]         <-- derived from the Object ID below
    Parsed size:              0x00000422 [1058 bytes]
    Target file size:         0x00059625 [366117 bytes]
    Show cmd:                 [SW_SHOWNORMAL]
    ID List:                  {CLSID_UsersFiles}\Dropbox\Shared Documents\Confidential Analysis Data\Blue Harvest Business Plan.docx
    Volume Type:              fixed
    Volume serial num:        7e58-aab0
    Volume label:             Windows8_OS
    Network name:             \\BIFROST\Users
    Local base path:          C:\Users\
    Common path:              Donald\Dropbox\Shared Documents\Confidential Analysis Data\Blue Harvest Business Plan.docx
    NETBIOS name:             bifrost
    Volume ID:                6bc0ab92-f111-496f-9067-ec5c94ffa9f5
    Object ID:                dc8ffc9d-3a6b-11e3-be8a-24fd52566ede  <-- unique to the target file this LNK file refers to
    MAC address:              24:fd:52:56:6e:de                     <-- derived from the Object ID above

Example of ID List embedded into a VistaAndAboveIDList

For some LNK files embedded into a JumpList, the ID List is stored within the VistaAndAboveIDList data block. This, like the ID List example before, can have extra metadata which may provide additional insight to the target file. The ID List usually contains DOS timestamps, which can be extracted as well. The timestamps shown below, however, represent Windows FILETIME timestamps pulled from properties embedded into the each of the nodes that make up the ID List. In some cases, the data is just redundant.

    source path/filename:     e:\testcase\jmp\fb3b0dbfee58fac8.automaticDestinations-ms
    AppID:                    fb3b0dbfee58fac8
    MRU/MFU index:            8
    stream #:                 42
    MRU time:                 10/21/2013 19:52:51.020 [UTC]
    file modified:            11/18/2013 20:26:01 [UTC]
    file accessed:            10/01/2014 14:04:33 [UTC]
    file created:             10/01/2014 14:04:33 [UTC]
    Target flags:             HasLinkInfo, IsUnicode, HasExpString, DisableKnownFolderAlias, UnaliasOnSave
    Target attributes:        FILE_ATTRIBUTE_ARCHIVE
    Target modified:          10/21/2013 19:46:54.813 [UTC]
    Target accessed:          10/21/2013 19:46:54.635 [UTC]
    Target created:           10/21/2013 19:46:54.635 [UTC]
    Target ObjID time:        10/20/2013 13:27:24.505 [UTC]
    Parsed size:              0x00003b74 [15220 bytes]
    Target file size:         0x00012a63 [76387 bytes]
    Show cmd:                 [SW_SHOWNORMAL]
    Network name:             \\VALHALLA\USERS
    Common path:              Public\Documents\Articles\Jordan Boone Article.docx
    Environment DataBlk:      \\VALHALLA\Users\Public\Documents\Articles\Jordan Boone Article.docx
    NETBIOS name:             valhalla
    Volume ID:                3499381e-92d7-4236-9fc9-79e377f2430a
    VistaAndAboveIDList:      {CLSID_OtherUsers}\Donald Blake\VALHALLA\Public Documents\Articles\Jordan Boone Article.docx
    VistaAndAboveIDList-info: 
     [1] Name : Donald Blake
     [2] Name : VALHALLA
     [3] Embedded Path : {CLSID_ComputersAndDevices}\VALHALLA\Users\dblak_000\AppData\Roaming\Microsoft\Windows\Libraries\Documents.library-ms
     [4] Created : 10/01/2013 18:44:34.000 [UTC]
     [5] Modified : 10/21/2013 19:50:36.000 [UTC]
     [6] Accessed : 10/21/2013 19:50:36.000 [UTC]
     [7] \\VALHALLA\Users
     [8] Microsoft Network
     [9] @shell32.dll,-34575
     [10] Path* : \\VALHALLA\Users\Public\Documents
     [11] Created : 08/22/2013 15:36:32.000 [UTC]
     [12] Modified : 10/21/2013 19:47:29.000 [UTC]
     [13] Accessed : 10/21/2013 19:47:30.000 [UTC]
     [14] Embedded Path : {CLSID_OtherUsers}\Donald Blake\VALHALLA
     [15] url : \\VALHALLA\Users\Public\Documents
     [16] serializedLink : MBAAAEAFCAAAAAAAADAAAAAAAYkgCAQDRAAAAYGep+VTf6cAlt0...
     [17] Embedded Path : {CLSID_ComputersAndDevices}\VALHALLA\Users\Public\Documents
     [18] Modified : 10/21/2013 19:47:30.000 [UTC]
     [19] @shell32.dll,-21801
     [20] Path* : \\VALHALLA\Users\Public\Documents\Articles
     [21] Name : Articles
     [22] Created : 10/21/2013 19:46:56.000 [UTC]
     [23] Modified : 10/21/2013 19:46:55.238 [UTC]
     [24] Accessed : 10/21/2013 19:46:56.000 [UTC]
     [25] Embedded Path : {CLSID_ComputersAndDevices}\VALHALLA\Users\Public\Documents\Articles
     [26] Modified : 10/21/2013 19:46:56.000 [UTC]
     [27] Size : 76387
     [28] Path* : \\VALHALLA\Users\Public\Documents\Articles\Jordan Boone Article.docx
     [29] Modified : 10/21/2013 19:46:54.813 [UTC]
     [30] Name : Jordan Boone Article
     [31] Embedded Path : {CLSID_ComputersAndDevices}\VALHALLA\Users\Public\Documents\Articles\Jordan Boone Article.docx
     [32] Word.Document.12
    Object ID:                5b3a9789-398b-11e3-be82-000af7048353
    MAC address:              00:0a:f7:04:83:53

Example of pulling out the metadata for each of the segments in the ItemIDs

To create a path, a series of Shell ItemIDs are usually embedded as IDList. Each of these ItemID's can have additional metadata, such as: MAC times, MFT entry and MFT sequence number. To pull out this data use the -idltimes switch.

    source path/filename:     e:\testcase\jmp\fb3b0dbfee58fac8.automaticDestinations-ms
    AppID:                    fb3b0dbfee58fac8
    MRU/MFU index:            13
    stream #:                 37
    MRU time:                 08/01/2013 19:21:18.540 [UTC]
    file modified:            11/18/2013 20:26:01 [UTC]
    file accessed:            10/01/2014 14:04:33 [UTC]
    file created:             10/01/2014 14:04:33 [UTC]
    MFT Entry:                0x0000bce9
    MFT Sequence#:            0x0009
    Target flags:             HasLinkTargetIDList, HasLinkInfo, IsUnicode, DisableKnownFolderAlias, UnaliasOnSave
    Target attributes:        FILE_ATTRIBUTE_ARCHIVE
    Target modified:          08/12/2013 03:39:23.540 [UTC]
    Target accessed:          08/08/2013 19:18:11.402 [UTC]
    Target created:           08/08/2013 19:18:11.402 [UTC]
    Target ObjID time:        10/21/2013 16:14:28.758 [UTC]
    Parsed size:              0x00000422 [1058 bytes]
    Target file size:         0x00059625 [366117 bytes]
    Show cmd:                 [SW_SHOWNORMAL]
    ID List:                  {CLSID_UsersFiles}\Dropbox\Shared Documents\Confidential Analysis Data\Blue Harvest Business Plan.docx
    Embedded ID List info:    Word.Document.12
    Volume Type:              fixed
    Volume serial num:        7e58-aab0
    Volume label:             Windows8_OS
    Network name:             \\BIFROST\Users
    Local base path:          C:\Users\
    Common path:              Donald\Dropbox\Shared Documents\Confidential Analysis Data\Blue Harvest Business Plan.docx
    NETBIOS name:             bifrost
    Volume ID:                6bc0ab92-f111-496f-9067-ec5c94ffa9f5
    Object ID:                dc8ffc9d-3a6b-11e3-be8a-24fd52566ede
    MAC address:              24:fd:52:56:6e:de
    IDList subpath breakout
     segment: {CLSID_UsersFiles}
     segment: Dropbox
      modify [UTC]: 08/08/2013 19:17:00
      access [UTC]: 08/08/2013 19:17:00
      create [UTC]: 08/08/2013 19:17:00
      mft entry#:   0x0000bc5c [48220]
      mft seq#:     0x0004 [4]
     segment: Shared Documents
      modify [UTC]: 08/08/2013 19:18:12
      access [UTC]: 08/08/2013 19:18:12
      create [UTC]: 08/08/2013 19:18:12
      mft entry#:   0x0000bce6 [48358]
      mft seq#:     0x0004 [4]
     segment: Confidential Analysis Data
      modify [UTC]: 08/08/2013 19:18:12
      access [UTC]: 08/08/2013 19:18:12
      create [UTC]: 08/08/2013 19:18:12
      mft entry#:   0x0000bce7 [48359]
      mft seq#:     0x0004 [4]
     segment: Blue Harvest Business Plan.docx
      modify [UTC]: 08/08/2013 19:18:12
      access [UTC]: 08/12/2013 03:39:24
      create [UTC]: 08/08/2013 19:18:12
      mft entry#:   0x0000bce9 [48361]
      mft seq#:     0x0009 [9]

Example of breaking out Portable Device metadata from the ID List

Other data besides timestamps can be found in the IDList as well. If a portable device was part of the target path, one can sometimes extract the USB stats, including the serial number of the device. When these properties are used, jmp will extract them and display the information, as shown below:

    source path/filename:     e:\testcase\jmp\f01b4d95cf55d32a.automaticDestinations-ms
    AppID:                    f01b4d95cf55d32a
    MRU/MFU index:            4
    stream #:                 47
    MRU time:                 10/21/2013 20:09:15.642 [UTC]
    file modified:            11/18/2013 20:22:41 [UTC]
    file accessed:            10/01/2014 14:04:33 [UTC]
    file created:             10/01/2014 14:04:33 [UTC]
    Target flags:             HasLinkTargetIDList, IsUnicode, DisableKnownFolderAlias, UnaliasOnSave
    Target attributes:        not specified
    Target modified:          not available
    Target accessed:          not available
    Target created:           not available
    Parsed size:              0x00000bc5 [3013 bytes]
    Target file size:         0x00000000 [0 bytes]
    Show cmd:                 [SW_SHOWNORMAL] 
    ID List:                  {CLSID_MyComputer}\Donald's Windows Phone\Phone\Documents
    Embedded ID List info:    
     [1] \\?\usb#vid_0421&pid_0661&mi_00#6&6d096df&0&0000#{6ac27878-a6fa-4155-ba85-f98f491d4f33}
     [2] {CLSID_PortableDevices}
     [3] SID-{10001,MTP Volume - 65537,31268536320}
     [4] Generic hierarchical
     [5] Serial# : MTP Volume - 65537
     [6] FuncObjId : s10001
     [7] {00010000-0514-0000-0000-000000000000}
     [8] ObjId : o1

An application identifier (AppID ) can be set by the application itself or it can be generated by the operating system using a set of rules. The jmp tool has two options to assist in this area.

The first option is to go from path/filename to AppID, using the -appid <pathfile> option. The algorithm first converts the path to uppercase Unicode and then substitutes any known Windows folders with the associated GUID identifier. Based on the final string generated, the CRC is computed and result is a possible AppID. Since the AppID computed this way is very sensitive to the inputted path, one needs to keep this in mind when trying to compute AppIDs from an executables name and path. Below are some examples of computing the AppID for notepad.

    > where notepad

    C:\Windows\System32\notepad.exe
    C:\Windows\notepad.exe

    > jmp -appid c:\windows\notepad.exe

    hash: 47592b67dd97a119 : {F38BF404-1D43-42F2-9305-67DE0B28FC23}\NOTEPAD.EXE
    hash: 33b1533ff9c7e8af : C:\WINDOWS\NOTEPAD.EXE

    > jmp -appid c:\windows\system32\notepad.exe

    hash: 9b9cdc69c1c24e2b : {1AC14E77-02E7-4E5D-B744-2EB1AE5198B7}\NOTEPAD.EXE
    hash: aa9870e8e6c0d630 : C:\WINDOWS\SYSTEM32\NOTEPAD.EXE

    > jmp -appid c:\windows\SysWOW64\notepad.exe

    hash: 918e0ecb43d17e23 : {D65231B0-B2F1-4857-A4CE-A8E7C6EA7D27}\NOTEPAD.EXE
    hash: c3e94993c9780ce0 : C:\WINDOWS\SYSWOW64\NOTEPAD.EXE 

From the above, one can see there are 2 paths for notepad: (a) one at the C:\windows\ directory and one at the C:\windows\System32\ directory. In this case, the Win7 box is a 64 bit OS, so there happens to be a 3rd path at the c:\windows\SysWOW64 directory. Out of these 3 paths, the AppID could be using the GUID version of the common folders or not, which gives 6 possibilities. Since notepad uses the GUID version of the path for the AppID computation one would use those.

One should note that the computation of the AppID did not care whether the application was 32 or 64 bit, but just the path it came from. This means that for a 32 bit OS, the AppID for c:\windows\system32\notepad.exe would be identical to the AppID for a 64 bit OS with the same path. So while some references show the mapping between 32 and 64 in the appid.txt file, it could be misleading.

The second option takes a file as its argument that already has the mapping of AppID's to application names in a file. This option uses the -appid_ref <file> to tell jmp to use these associations to output the mapped application name in the output.

Included in the distribution of jmp is a pre-generated file (named appids.txt) that contain the mappings included from the online forensics-wiki website (see reference 3 at the end of this document). If one desires to add new entries to this file, then use the following rules:

• Blank lines are ignored
• Lines starting with a forward double slash are ignored
• An AppID mapping to an application name is separated by a pipe character

If we took the AppIDs computed for notepad above, one could generate a file this way:

    // appid's for notepad
    9b9cdc69c1c24e2b | notepad.exe (system32)
    918e0ecb43d17e23 | notepad.exe (SysWOW64)
    47592b67dd97a119 | notepad.exe (windows)

Option	Description
-csv	Outputs the data fields delimited by commas. Since filenames can have commas, to ensure the fields are uniquely separated, any commas in the filenames get converted to spaces.
-csvl2t	Outputs the data fields in accordance with the log2timeline format.
-bodyfile	Outputs the data fields in accordance with the 'body-file' version3 specified in the SleuthKit. The date/timestamp outputted to the body-file is in terms of UTC. So if using the body-file in conjunction with the mactime.pl utility, one needs to set the environment variable TZ=UTC.
-csv_separator	Used in conjunction with the -csv option to change the CSV separator from the default comma to something else. Syntax is -csv_separator "|" to change the CSV separator to the pipe character. To use the tab as a separator, one can use the -csv_separator "tab" OR -csv_separator "\t" options.
-base10	Ensure all size/address outputs are displayed in base-10 format versus hexadecimal format. Default is hexadecimal format.
-username	Option is used to populate the output records with a specified username. The syntax is -username <name to use> .
-hostname	Option is used to populate the output records with a specified hostname. The syntax is -hostname <name to use>.
-pipe	Used to pipe files into the tool via STDIN (standard input). Each file passed in is parsed in sequence.
-enumdir	Experimental. Used to process files within a folder and/or subfolders. Each file is parsed in sequence. The syntax is -enumdir <"folder"> -num_subdirs <#>.
-filter	Filters data passed in via stdin via the -pipe option. The syntax is -filter <"*.ext | *partialname* | ...">. The wildcard character '*' is restricted to either before the name or after the name.
-no_whitespace	Used in conjunction with -csv option to remove any whitespace between the field value and the CSV separator.
-vss	Experimental. Parse JumpList artifacts from Volume Shadow. The syntax is -vss <index number of shadow copy>. Only applies to Windows Vista, Win7, Win8 and beyond. Does not apply to Windows XP.
-slack	AutomaticDestination files retain some of their deleted entries in slack space. The -slack option traverses this slack space to extract any additional LNK entries. These entries that are retrieved do not have any MRU/MFU data associated with them.
-appid_ref	Points to a text file to translate application identifiers to application names. The syntax is -appid <file>. Distribution contains a sample file called appids.txt and the data is taken from the forensic wiki (ref: http://www.forensicswiki.org/wiki/List_of_Jump_List_IDs). The file uses a pipe delimiter between the application ID and the application name. If a different delimiter is used, one can use the option -appid_separator "," to tell jmp to use a different delimiter (in this case a comma) to parse the AppID file.
-idltimes	Experimental. Shell item identifiers are grouped together to form a path. Each Item ID can have embedded in it an associated MAC timestamps as well as MFT entry number for the segment of the path that creates the final path. Using this option will display any additional metadata associated with each segment (or Item ID) in the list
-dateformat	Output the date using the specified format. Default behavior is -dateformat "yyyy-mm-dd". This allows more flexibility for a desired format. For example, one can use this to show year first, via "yyyy/mm/dd" or day first, via "dd/mm/yyyy", or only show 2 digit years, via the "mm/dd/yy". The restriction with this option is the forward slash (/) or dash (-) symbol needs to separate month, day and year and the month is in digit (1-12) form versus abbreviated name form.
-timeformat	Output the time using the specified format. Default behavior is -timeformat "hh:mm:ss.xxx" One can adjust the format to microseconds, via "hh:mm:ss.xxxxxx" or nanoseconds, via "hh:mm:ss.xxxxxxxxx", or no fractional seconds, via "hh:mm:ss". The restrictions with this option is that a colon (:) symbol needs to separate hours, minutes and seconds, a period (.) symbol needs to separate the seconds and fractional seconds, and the repeating symbol 'x' is used to represent number of fractional seconds. (Note: the fractional seconds applies only to those time formats that have the appropriate precision available. The Windows internal filetime has, for example, 100 nsec unit precision available. The DOS time format and the UNIX 'time_t' format, however, have no fractional seconds). Some of the times represented by this tool may use a time format without fractional seconds and therefore will not show a greater precision beyond seconds when using this option.
-pair_datetime	Output the date/time as 1 field vice 2 for csv option
-quiet	Used in conjunction with -pipe option. This option suppresses status output as each file is processed.
-show_offset	Displays starting offset of the file where the parsed artifact starts. This is used primarily for verification purposes when used in conjunction with a hex-editor during the analysis. (note: the automaticDestination jumpfile does not necessarily have contiguous sectors of data for a parsed artifact. Therefore if using this option, be aware that the reconstruction of the data depends on following the allocated chain of sectors and not just looking at the starting offset in a hex-editor and assuming the rest of the data follows after the first sector or mini-sector).
-utf8_bom	All output is in Unicode UTF-8 format. If desired, one can prefix an UTF-8 byte order mark to the CSV output using this option.

Field	Definition
source type	Where the LNK data was defined (automatic or carved). Carved implies custom Jump List
appid	Application ID hash that this Jump list applies to
MRU/MFU	Most recently used / Most frequently used, ordered highest to lowest
stream#	Stream number from the Compound File binary encapsulating the JMP files
MRU date	Most recently used date
MRU-UTC	Most recently used time
file mdate	JumpList modify date
time-UTC (after file mdate)	JumpList modify time
file adate	JumpList access date
time-UTC (after file adate)	JumpList access time
file cdate	JumpList create date. Note: for non Windows builds (eg Linux and Mac OS-X), this date is the Metadata change date of the file.
time-UTC (after file cdate)	JumpList create time. Note: for non Windows builds (eg Linux and Mac OS-X), this date is the Metadata change time of the file.
tgt mdate	Target file/folder modify date
time-UTC (after tgt mdate)	Target file/folder modify time
tgt adate	Target file/folder access date
time-UTC (after tgt adate)	Target file/folder access time
tgt cdate	Target file/folder create date
time-UTC (after tgt cdate)	Target file/folder create time
ObjID date	Object ID date for the target file (derived from the Target's Object ID)
time-UTC (after ObjID cdate)	Object ID time for the target file (derived from the Target's Object ID)
tgt attrib	Target file/folder attributes
inode	Target file/folder MFT entry
seq#	Target file/folder MFT entry sequence number
file size	Target file size
target name	Target file/folder name
IDList extra info	Extra data parsed from the IDList for the target
vol type	Target volume info, such as fixed or removable
vol serial	Target volume serial number
vol label	Target volume label
local path	Target local path (taken directly from Item ID in LNK structure)
common path	Target common path (taken directly from Item ID in LNK structure)
network/device info	Target network/device info
extra info	Any extra info found that didn't fit in the other categories
netbios name	Target NETBIOS name
volume id	Target Volume ID
object id	Target Object ID
mac addr	Target MAC address (derived from the Target's Object ID)
IDList segments	Breakout of the metadata for each of the Shell ItemID's in the list. The default format is just a listing of the segmented ItemID's. The CSV format, on the other hand, allocates 1 column to this data. It is formatted the following way to record multiple records and fields within a record. It uses asterick's to delimit records (where each record is a separate segment) and semicolon's to delimit fields within a record. Finally, each record is surrounded by angle brakets (< ... >). The first record is the field names, and the rest of the records are the data.

jmp doesn't parse some of the fields in the SHLLINK structures documented by the Microsoft specification. As time permits, future versions will incorporate incremental capabilities to handle these additional fields.

For CSV (comma separated values) output, there are restrictions in the characters that are outputted. Since commas are used as a separator, any data containing commas are replaced with a space. For the default (non-CSV) output no changes are made to the data. To address this issue, an option was added to change the CSV default separator character from the comma (,) to whatever is desired. The pipe (|) character is a good choice, since it doesn't overlap with characters in filenames. (This option is discussed below).

For Linux and Mac builds, the file 'create date' is not shown, but the system 'data changed' time is instead.

(Windows only) When processing filenames with characters that are not ASCII, one option is to change the code page of the command window from the default code page to UTF-8. This can be done via the command:

    chcp 65001

If running on a Windows operating system post XP and running under admin permissions, any network shares established prior as a regular (non-admin) user, will be isolated from other accounts (including the admin account). This problem occurs because User Account Control (UAC) treats members of the Administrators group as standard users. Therefore, network shares that are mapped by logon scripts are shared with the standard user access token instead of with the full administrator access token.

This tool has authentication built into the binary. The primary authentication mechanism is the digital X509 code signing certificate embedded into the binary (Windows and macOS).

The other mechanism is the runtime authentication, which applies to all the versions of the tools (Windows, Linux and macOS). The runtime authentication ensures that the tool has a valid license. The license needs to be in the same directory of the tool for it to authenticate. Furthermore, any modification to the license, either to its name or contents, will invalidate the license.

Limited versus Demo versus Full in the tool's output banner

The tools from TZWorks will output header information about the tool's version and whether it is running in limited, demo or full mode. This is directly related to what version of a license the tool authenticates with. The limited and demo keywords indicates some functionality of the tool is not available, and the full keyword indicates all the functionality is available. The lacking functionality in the limited or demo versions may mean one or all of the following: (a) certain options may not be available, (b) certain data may not be outputted in the parsed results, and (c) the license has a finite lifetime before expiring.