TZWorks LLC
System Analysis and Programming
www.tzworks.com
(Version 1.07)
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.
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.
lp is a command line version of a Windows SHLLINK parser that was designed to operate on shortcut files, but can parse SHLLINK artifacts from files that generate Jump Lists as well. Originally inspired by the forensic class taken from the SANS Institute back in Jan 2010, lp is a useful tool for any computer forensic toolkit.
While shortcut files can reside in just about any directory, the primary location for many shortcut files is: %APPDATA%\ Microsoft\ Windows\ Recent\ <shortcut files>, where the %APPDATA% is resolved to C:\Users\<user account>\AppData\Roaming. This is where the operating system automatically creates a shortcut based on a user double clicking on an application to launch it.
Of interest to the forensic investigator is the metadata associated with this type of file, since they offer many useful artifacts when determining activity on a computer. Some of these artifacts include:
When trying to parse out the above artifacts, one can turn to the Microsoft open specification agreement, where there is a published version of the Windows SHLLINK format. From this specification, one can see many of the details needed to understand the structures of the format.
The parsing engine of lp makes use of the Microsoft specification to extract much of the shortcut internals. Where the specification lacked details, we ended up using empirical data to help understand some of the opaque data structure types allowing us to parse the SHLLINK format more fully.
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.
When analyzing lp's output, a number of timestamp data is shown, including the shortcut file timestamps as well as the target (what the shortcut file points to) timestamps. The output should contain the size of the target, if it is a file versus a directory, and will contain a path to the target. As part of the SHLLINK specification, there is also what Microsoft calls a TrackerDataBlock. This is what we refer to as the object identifier (ID), since it is really the object ID of the NTFS MFT record associated with the target file or directory.
The object ID is another way to reference the target file/directory and ultimately allows the operating system a straight forward way to 'track' the target file, or directory, at the lower level NTFS object ID/MFT entry level. This object ID is part of the target file and moves where the target moves. In the SHLLINK metadata there are two object IDs: (a) one that is recorded when the shortcut is created, and (b) one that is the current one. For the most part these two object IDs are the same and will only differ in certain conditions. Internally, lp makes note of both object IDs, however, it will only display both if they are different.
Associated with the object ID is a creation timestamp and media access control (MAC) network interface identifier that were present during the object ID creation. The format of the object ID follows the Type 1 specification outlined in RFC 4122 (Universally Unique Identifier URN Namespace). Using this specification, one can extract the object time and MAC address from the object ID itself. What this means is there is NO timestamp or MAC network interface artifact explicitly present in the SHLLINK metadata. Any data shown in lp's output for these fields comes from implicitly deriving it from the object ID itself.
For starters, lp is a console application. Therefore, to be able to access, and thus parse, shortcut files across all computer accounts, one will need to open the command prompt with administrator privileges first. Without administrator privileges, one will be restricted to only accessing your account's shortcut files or those common to the operating system.
One can display the menu options by typing in the executable name without parameters. By using the options in various ways, one can process SHLLINK metadata with six general 'use-cases': (1) processing an individual shortcut file, (2) carving from a captured image, (3) extracting from Jump List files, (4) processing a collection of files, (5) carving from a mounted volume, and (6) carving from a VMWare volume.
For output options, there are four possible formats to choose from: (1) default output, which is an unstructured output. This information is useful if not trying to parse the artifacts into a database. (2) -csv (comma separated value) option will render the output so that all the metadata is rendered with one record per line with each field separated with a comma. The last two are: (3) -csvl2t and (4) -bodyfile. Each will attempt to conform to either the log2timeline format or the SleuthKit's body-file format, as appropriate.
Below is the menu with the various options. Details of each option can be found here.
Usage lp <filename> lp <dd image> [-ntfs_scan [-offset <vol>] | -rawscan] [-outdir <dir>] lp -partition <drv letter> [-ntfs_scan|-rawscan] = mounted volume lp -vss <index> [-ntfs_scan|-rawscan] = *** Volume Shadow lp -vmdk "<file1>|..." [-ntfs_scan|-rawscan] [-offset <vol>]= VMWare image lp <jmplist file> -deepscan dir C:\Users\*.lnk /b /s | lp -pipe [-csv] dir "C:\Documents and Settings\*.lnk" /b /s | lp -pipe [-csv] lp -enumdir <location lnk files> -num_subdirs <#> -filter "*.lnk" [-csv] Basic options -csv = output is 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 -ntfs_scan = scans volume or image using MFT [default] -rawscan = scans file, carving LNK metadata -deepscan = for JumpLists or packed LNK metadata -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 = only available for csv option -csv_separator "|" = use a pipe char for csv separator -filter <*partial*|*.ext> = filters stdin data from -pipe option -out <results file> = output result to a specified file Experimental options -idltimes = add IDList embedded data [default|-csv] -include_unalloc_clusters = incl unalloc clusters [reqs -ntfs_scan] -include_vss_clusters = incl vol shadow clusters [reqs -ntfs_scan]
The most basic option is to parse an individual shortcut file. To do so, just pass the name as the parameter to lp, as shown below, and the output will default to the long form.
lp <shortcut filename>
To parse an entire image of a drive that is contained in a file (eg. a 'dd' type image), one can either use the -rawscan or the -ntfs_scan option. This first option ignores volume boundaries and file system internals and does a brute force scan, by looking for any SHLLINK signatures. For each signature found, lp will attempt to carve out any SHLLINK metadata. This type of scan will carve out signatures from allocated, unallocated or slack space. The second option assumes the image contains an NTFS volume, and uses the file system internals to find LNK and/or Jump List files that contain SHLLINK data.
lp is able to scan very large files by reading a manageable chunk from the file, one at a time and outputting the results as they are generated. So if your image is many gigabytes in size, lp should be able to process the entire image without using too much memory or system resources.
If using the -rawscan option, lp is agnostic as to the file system type, as it treats all disk formats the same. While this is good news in that it can work on any file system, it is also bad, in that it does not try to reconstruct files that are fragmented across non-contiguous clusters. Empirical results show, however, that since the SHLLINK metadata is relatively small, the fragmentation of these files is close to nil. Thus, this type of scanning/carving/parsing shows a high success rate in gathering the artifacts.
When parsing a large image, there will presumably be many SHLLINK entries carved out, thus it is recommended to: (a) use the -csv option to place one record per line, and (b) redirect the output into a separate file. Below is an example:
lp c:\temp\dd_imagefile.bin -rawscan -csv > results.csv
The -ntfs_scan option targets a specified mounted NTFS volume or an image with an NTFS volume. This option starts by scanning the $MFT. Once it finds LNK and/or JumpList files, it will extract their data so it can parse the SHLLINK internals. This is more reliable than using the -rawscan option discussed above, since this approach allows the data to be fully reconstructed prior to parsing it.
If the image one want to analyze is a disk containing multiple volumes, one needs to specify the offset of the volume that will be scanned. This is done via the optional parameter -offset <disk offset of volume>.
The -ntfs_scan option also allows for two sub-options. They allow one to analyze the unallocated clusters associated with the volume and/or any Volume Shadow clusters. These sub-options are -include_unalloc_clusters and -include_vss_clustsers. Using these options together will yield will maximize your chance of getting all the SHLLINK metadata.
Jump Lists are a new feature, starting with Windows 7. They are similar to shortcuts files in that they take one directly to the files that are used on a regular basis. They are different than the normal shortcut files in that they are more extensible in what information they display. For example, in Internet Explorer, the Jump Lists will display websites frequently visited; for Microsoft Office products like Excel, PowerPoint and Word, they 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.
Windows derives the Jump List content from two sets of Destination files:
%APPDATA% is resolved to C:\Users\<user account>\AppData\Roaming. One can see that each user account (or profile) has its own set of Destination files.
For most automaticDestinations type files, lp can find and parse the SHLLINK metadata with no special command line options (eg. the default settings). This is because the automaticDestinations type files have a compound file signature, which is built into the lp scanning engine. lp will recognize this signature, reconstruct the allocated/unallocated sectors within the compound file and scan the chunks appropriately. On the other hand, the customDestinations type files only have SHLLINK signatures which do not necessarily occur on sector boundaries. Therefore, to assist lp, to parse this type of file, one invokes the -deepscan switch. This tells lp to scan in a mode that is in-between a normal LNK file scan and a captured image type scan. This switch has no effect on normal shortcut files, so it can be used to handle both shortcut files as well as automatic/custom Destinations files.
While lp does a good job at pulling out the SHLLINK metadata from both automatic and custom Destinations type files, it does not attempt to parse the MRU/MFU data from the automatic Destinations files. To parse these files in a complete fashion, one can use the jmp tool from TZWorks LLC. The jmp tool understands how to parse both Destinations type files in a manner to extract all pertinent metadata for the investigator.
Sometimes, one just wants to parse a bunch of shortcut files that are in a directory or a collection of subdirectories. Compared to the partition scan discussed above, this option is much faster. The disadvantage with this approach over the partition scan, is that one does not get artifacts that have been deleted and are still in unallocated or slack space.
To use this option, one will make use of the operating systems ability to pipe data from one application's output to another application's input. In this case, the source of the data will be the Windows shell command dir. By adding some special options to the dir command, one can output only the path/filename without any extra data. This result will be consumed by lp, and each path/filename passed in will be analyzed. To invoke this behavior in lp, one will use the -pipe switch and use some special options in the dir command.
Below is an example of traversing the user's directory and redirecting the output to a results file. The first example is for pre-Vista machines; the latter is for Vista and later operating systems.
dir "c:\documents and settings\*.lnk" /b /s | lp -pipe -csv > results.csv dir c:\users\*.lnk /b /s | lp -pipe -csv > results.csv
A variant of parsing a captured image is to parse an active Windows partition or a mounted volume on Linux. The Windows version is invoked by using the -partition <drive letter> option. On Linux, this is handled by passing in the device name of the disk and/or volume as the filename without the use of the -partition keyword. The other option that needs to be set is to identify whether to use the -rawscan or -ntfs_scan option.
Below is an example of lp carving out SHLLINK signatures from a USB drive mounted as drive H for Windows and /dev/sbd1 on Linux. The Windows version is using the -ntfs_scan option, while the Linux version is using the -rawscan option.
lp -partition H -ntfs_scan -csv > results.csv [Windows version] lp /dev/sdb1 -rawscan -csv > results.csv [Linux version]
To find where the drive is mounted on Linux or Mac, one can use the built-in tool df to enumerate what devices are used for the mount. While the df command is to display free disk space, it does this by displaying all the devices mounted followed by their statistics. For the Mac OS-X case, one could also use the diskutil list to enumerate all drives and volumes mounted.
The Mac OS-X has an additional nuance in that one needs to specify raw I/O versus the standard buffered I/O. So for the example above, if /dev/sdb1 was specified as the device for the drive, then one would issue /dev/rsdb1.
Occasionally it is useful to analyze a VMWare image, both from a forensics standpoint as well as from a testing standpoint. When analyzing different operating systems, and different configurations, a virtual machine is extremely useful in testing out different boundary conditions. This option is still considered experimental since it has only been tested on a handful of configurations. Furthermore, this option is limited to monolithic type VMWare images versus split images. In VMWare, the term split image means the volume is separated into multiple files, while the term monolithic virtual disk is defined to be a virtual disk where everything is kept in one file. There may be more than one VMDK file in a monolithic architecture, where each monolithic VMDK file would represent a separate snapshot. More information about the monolithic virtual disk architecture can be obtained from the VMWare website.
When working with virtual machines, the capability to handle snapshot images is important. Thus, for processing a VMWare snapshot, one needs to include the parent snapshot/image as well as any descendants.
lp can handle multiple VMDK files to accommodate a snapshot, and its descendants, by separating each VMDK filename with a pipe character and enclosing the expression in double quotes. For example: -vmdk "<VMWare NTFS virtual disk-1> | ... | <VMWare NTFS virtual disk-x>".
To aid the user in defining the chain of descendant images, lp can take any VMDK file in a chain of snapshot VMDK files and determine what the descendant chain is. lp will analyze the chain, and if incomplete, will suggest a chain to use. This assumes, however, all the VMDK files are in the same directory.
For starters, to access Volume Shadow copies, one needs to be running with administrator privileges. Also, it is important to note that, Volume Shadow copies as is discussed here, only applies to Windows Vista, Win7, Win8, and beyond. It does not apply to Windows XP.
To tell lp to look at a Volume Shadow, one needs to use the -vss <index of volume shadow> option. This will point lp at the appropriate Volume Shadow and it will start analyzing the various user directories for LNK files, and if any are found, parses them. Below is an example of traversing Volume Shadow Copy #1 and rendering the CSV results to a file called vss1_out.csv.
lp -vss 1 -ntfs_scan -csv > vss1_out.csv
As another option, one can use the -vss option in conjunction with the -rawscan switch to scan the entire volume at the cluster level instead and carving the LNK files out.
If one only wants to look for a particular LNK file in a particular 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. Below is an example of telling lp to parse the LNK file at Volume Shadow Copy #1.
lp %vss%1\users\testuser\AppData\Roaming\Microsoft\Windows\Recent\out.txt.lnk
The %vss% keyword, in combination with the number that follows the keyword, is expanded internally to point to the proper Volume Shadow.
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.
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:
The date fields "file modified/accessed/created" relate to the actual LNK file itself, while the "target modified/accessed/created" relate to the target file the LNK refers to. Therefore, when copying a LNK file from a target system to another system for offline analysis, this date will reflect the date you created it on the offline system. The Object ID 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 references. The ID List is usually a mix of class identifiers (eg. GUIDs) and named nodes, which 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: c:\dump\testcases\win8.tests\Asgard.lnk file modified: 12/28/2013 20:37:48 [UTC] file accessed: 01/07/2014 15:21:54 [UTC] file created: 01/07/2014 15:21:54 [UTC] MFT Entry: 0x2d2d4 <-- references the target MFT entry MFT Sequence#: 0x4 <-- references the target MFT entry Target flags: HasLinkTargetIDList, HasLinkInfo, HasRelativePath, HasWorkingDir, IsUnicode, DisableKnownFolderAlias Target attributes: FILE_ATTRIBUTE_ARCHIVE Target modified: 09/11/2013 16:19:56.420 [UTC] Target accessed: 09/11/2013 16:19:56.403 [UTC] Target created: 09/11/2013 16:18:15.661 [UTC] Target ObjID time: 09/04/2013 17:22:08.941 [UTC] <-- derived from the Object ID below Parsed size: 0x000003e9 [1001 bytes] Target file size: 0x00009a2f [39471 bytes] Show cmd: [SW_SHOWNORMAL] ID List: {CLSID_UsersFiles}\AppData\Roaming\Microsoft\Signatures\Asgard.htm Volume Type: fixed Volume serial num: 7e58-aab0 Volume label: Windows8_OS Local base path: C:\Users\Donald\AppData\Roaming\Microsoft\Signatures\Asgard.htm Relative path: ..\..\Signatures\Asgard.htm Working directory: C:\Users\Donald\AppData\Roaming\Microsoft\Signatures NETBIOS name: bifrost Volume ID: 6bc0ab92-f111-496f-9067-ec5c94ffa9f5 Object ID: 87349aeb-1586-11e3-be7d-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
For the 'full' version of the tool, the embedded ID List information is broken out. 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. Other data besides timestamps can be found 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 (ref: second example below). Where these properties are used, lp will extract them and display the information, as shown below:
Case 1. Showing additional timestamps ...
source path/filename: c:\dump\testcases\win8.tests\Camera Photos.lnk
file modified: 12/28/2013 20:37:49 [UTC]
file accessed: 01/07/2014 15:21:54 [UTC]
file created: 01/07/2014 15:21:54 [UTC]
Target flags: HasLinkTargetIDList, HasLinkInfo, HasRelativePath, IsUnicode, DisableKnownFolderAlias
Target attributes: FILE_ATTRIBUTE_DIRECTORY
Target modified: 10/17/2013 19:27:23.602 [UTC]
Target accessed: 10/17/2013 19:27:23.602 [UTC]
Target created: 10/17/2013 19:25:48.214 [UTC]
Target ObjID time: 10/17/2013 21:03:21.428 [UTC]
Parsed size: 0x00001268 [4712 bytes]
Target file size: 0x00005000 [20480 bytes]
Show cmd: [SW_SHOWNORMAL]
ID List: {CLSID_Libraries}\{CLSID_Pictures}\::{3ADD1653-EB32-4CB0-BBD7-DFA0ABB5ACCA}\iCloud Photos\Shared\Camera Photos
Embedded ID List info:
[1] Path* : C:\Users\Donald\Pictures
[2] Created : 08/10/2013 03:03:24.000 [UTC]
[3] Modified : 10/17/2013 19:05:48.231 [UTC]
[4] Name : Pictures
[5] Path* : C:\Users\Donald\Pictures\iCloud Photos
[6] Created : 10/17/2013 19:05:50.000 [UTC]
[7] Modified : 10/17/2013 19:05:48.241 [UTC]
[8] Accessed : 10/17/2013 19:05:50.000 [UTC]
[9] Name : iCloud Photos
[10] Path* : C:\Users\Donald\Pictures\iCloud Photos\Shared
[11] Modified : 10/18/2013 01:38:50.358 [UTC]
[12] Accessed : 10/18/2013 01:38:52.000 [UTC]
[13] Name : Shared
[14] Path* : C:\Users\Donald\Pictures\iCloud Photos\Shared\Camera Photos
[15] Name : Camera Photos
[16] Created : 10/17/2013 19:25:50.000 [UTC]
[17] Modified : 10/17/2013 19:27:23.602 [UTC]
[18] Accessed : 10/17/2013 19:27:24.000 [UTC]
Volume Type: fixed
Volume serial num: 7e58-aab0
Volume label: Windows8_OS
Network name: \\BIFROST\Users
Local base path: C:\Users\
Common path: Donald\Pictures\iCloud Photos\Shared\Camera Photos
Relative path: ..\..\..\..\..\Pictures\iCloud Photos\Shared\Camera Photos
NETBIOS name: bifrost
Volume ID: 6bc0ab92-f111-496f-9067-ec5c94ffa9f5
Object ID: 8dfc97c1-376f-11e3-be88-24fd52566ede
Case 2. Showning other metadata, where a portable device was involved....
source path/filename: c:\dump\testcases\win8.tests\Documents.LNK
file modified: 12/28/2013 20:37:49 [UTC]
file accessed: 01/07/2014 15:21:54 [UTC]
file created: 01/07/2014 15:21:54 [UTC]
Target flags: HasLinkTargetIDList, IsUnicode, DisableKnownFolderAlias
Target attributes: not specified
Target modified: not available
Target accessed: not available
Target created: not available
Parsed size: 0x00000b98 [2968 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] UniqueId : SID-{10001,MTP Volume - 65537,31268536320}
[8] {00010000-0514-0000-0000-000000000000}
[9] ObjId : o1
[10] UniqueId : {00010000-0514-0000-0000-000000000000}
Case 3. Showning each of the Shell ItemID segements, using the -idltimes switch
source path/filename: e:\testcase\lnk\Asgard.lnk.bin
file modified: 12/11/2013 03:14:28 [UTC]
file accessed: 10/01/2014 14:05:45 [UTC]
file created: 10/01/2014 14:05:45 [UTC]
MFT Entry: 0x0002d2d4
MFT Sequence#: 0x0004
Target flags: HasLinkTargetIDList, HasLinkInfo, HasRelativePath, HasWorkingDir, IsUnicode, DisableKnownFolderAlias
Target attributes: FILE_ATTRIBUTE_ARCHIVE
Target modified: 09/11/2013 16:19:56.420 [UTC]
Target accessed: 09/11/2013 16:19:56.403 [UTC]
Target created: 09/11/2013 16:18:15.661 [UTC]
Target ObjID time: 09/04/2013 17:22:08.941 [UTC]
Parsed size: 0x000003e9 [1001 bytes]
Target file size: 0x00009a2f [39471 bytes]
Show cmd: [SW_SHOWNORMAL]
ID List: {CLSID_UsersFiles}\AppData\Roaming\Microsoft\Signatures\Asgard.htm
Volume Type: fixed
Volume serial num: 7e58-aab0
Volume label: Windows8_OS
Local base path: C:\Users\Donald\AppData\Roaming\Microsoft\Signatures\Asgard.htm
Relative path: ..\..\Signatures\Asgard.htm
Working directory: C:\Users\Donald\AppData\Roaming\Microsoft\Signatures
NETBIOS name: bifrost
Volume ID: 6bc0ab92-f111-496f-9067-ec5c94ffa9f5
Object ID: 87349aeb-1586-11e3-be7d-24fd52566ede
MAC address: 24:fd:52:56:6e:de
IDList subpath breakout
segment: {CLSID_UsersFiles}
segment: AppData
modify [UTC]: 08/10/2013 03:03:24
access [UTC]: 08/10/2013 03:03:24
create [UTC]: 08/10/2013 03:03:24
mft entry#: 0x00000fb3 [4019]
mft seq#: 0x0002 [2]
segment: Roaming
modify [UTC]: 09/03/2013 02:12:48
access [UTC]: 09/03/2013 02:12:48
create [UTC]: 08/10/2013 03:03:24
mft entry#: 0x000013e5 [5093]
mft seq#: 0x0008 [8]
segment: Microsoft
modify [UTC]: 09/10/2013 01:30:00
access [UTC]: 09/10/2013 01:30:00
create [UTC]: 08/10/2013 03:03:24
mft entry#: 0x000013e6 [5094]
mft seq#: 0x0008 [8]
segment: Signatures
modify [UTC]: 09/11/2013 16:19:58
access [UTC]: 09/11/2013 16:19:58
create [UTC]: 08/12/2013 02:39:44
mft entry#: 0x0002e0b3 [188595]
mft seq#: 0x0005 [5]
segment: Asgard.htm
modify [UTC]: 09/11/2013 16:18:16
access [UTC]: 09/11/2013 16:18:16
create [UTC]: 09/11/2013 16:18:16
mft entry#: 0x0002d2d4 [185044]
mft seq#: 0x0004 [4]
For some LNK files, 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. In some cases, the data is just redundant.
source path/filename: c:\dump\testcases\win8.tests\DECISION MAKING CONTINGENCIES.lnk
file modified: 12/28/2013 20:37:49 [UTC]
file accessed: 01/07/2014 15:21:54 [UTC]
file created: 01/07/2014 15:21:54 [UTC]
Target flags: HasLinkInfo, IsUnicode, HasExpString
Target attributes: FILE_ATTRIBUTE_ARCHIVE
Target modified: 10/21/2013 19:46:54.626 [UTC]
Target accessed: 10/21/2013 19:46:54.425 [UTC]
Target created: 10/21/2013 19:46:54.425 [UTC]
Target ObjID time: 10/20/2013 13:27:24.505 [UTC]
Parsed size: 0x00000727 [1831 bytes]
Target file size: 0x00025a00 [154112 bytes]
Show cmd: [SW_SHOWNORMAL]
Network name: \\VALHALLA\USERS
Common path: Public\Documents\Articles\DECISION MAKING CONTINGENCIES.doc
Environment DataBlk: \\VALHALLA\Users\Public\Documents\Articles\DECISION MAKING CONTINGENCIES.doc
NETBIOS name: valhalla
Volume ID: 3499381e-92d7-4236-9fc9-79e377f2430a
VistaAndAboveIDList: {CLSID_ComputersAndDevices}\VALHALLA\Users\Public\Documents\Articles\DECISION MAKING CONTINGENCIES.doc
VistaAndAboveIDList-info:
[1] \\VALHALLA\Users
[2] Microsoft Network
[3] @shell32.dll,-21816
[4] @shell32.dll,-21801
Object ID: 5b3a9788-398b-11e3-be82-000af7048353
MAC address: 00:0a:f7:04:83:53
In some cases, the LNK file will make use of what is called a Property Store Data Block. This block encapsulates much metadata that could be useful in an analysis. For this example, this particular LNK file did not target a file with target dates or other metadata common to most LNK files. In this case, most of the data was in the PropertyStoreDataBlk. Below is an example:
source path/filename: c:\dump\testcases\win8.tests\com.amazon.kindle.lnk
file modified: 12/28/2013 20:37:49 [UTC]
file accessed: 01/07/2014 15:21:54 [UTC]
file created: 01/07/2014 15:21:54 [UTC]
Target flags: IsUnicode
Target attributes: not specified
Target modified: not available
Target accessed: not available
Target created: not available
Parsed size: 0x00000513 [1299 bytes]
Target file size: 0x00000000 [0 bytes]
Show cmd: [SW_SHOWNORMAL]
PropertyStoreDataBlk: format guid/id [value]
[1] 9f4c2855-9f79-4b39-a8d0-e1d42de1d5f3/Family* [AMZNMobileLLC.KindleforWindows8_stfe6vwa9jnbp]
[2] 9f4c2855-9f79-4b39-a8d0-e1d42de1d5f3/Name* [AMZNMobileLLC.KindleforWindows8_2.1.0.1_neutral__stfe6vwa9jnbp]
[3] 9f4c2855-9f79-4b39-a8d0-e1d42de1d5f3/Id [AMZNMobileLLC.KindleforWindows8_stfe6vwa9jnbp!com.amazon.kindle]
[4] 9f4c2855-9f79-4b39-a8d0-e1d42de1d5f3/InstallPath* [C:\Program Files\WindowsApps\AMZNMobileLLC.KindleforWindows8_2.1.0.1_neutral__stfe6vwa9jnbp]
[5] 86d40b4d-9069-443c-819a-2a54090dccec/Icon* [images\logo\metro-regular-logo.png]
[6] 86d40b4d-9069-443c-819a-2a54090dccec/Icon* [images\logo\metro-small-logo.png]
[7] 86d40b4d-9069-443c-819a-2a54090dccec/Icon* [images\logo\metro-start-menu-wide.png]
[8] 86d40b4d-9069-443c-819a-2a54090dccec/Type* [Kindle]
[9] b725f130-47ef-101a-a5f1-02608c9eebac/Name [Kindle]
[10] 841e4f90-ff59-4d16-8947-e81bbffab36d/Publisher* [AMZN Mobile LLC]
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. |
-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. |
-rawscan | Scan a large file or captured image looking for SHLLINK signatures and when found parse them. This option is not meant to be used for individual shortcut files |
-ntfs_scan | Scan a NTFS volume looking for SHLLINK signatures and when found parse them. The basic option scans the $MFT data. There are suboptions to do a more extensive scan: (a) -include_unalloc_clusters and (b) -include_vss_clusters. The first will scan the unallocated clusters and carve out any LNK data and the second will scan the Volume shadow clusters and carve out any LNK data. |
-outdir | Used in conjunction with the -rawscan option to store carved LNK files to the specified directory. The syntax is -rawscan -outdir <directory>. |
-deepscan | Added just for Destinations files used for Jump Lists. Since Destinations can have many SHLLINK signatures embedded into one file, this option handles parsing these types of files correctly. Note: the -deepscan option and the -rawscan option cannot be used together. |
-partition | Used to scan a mounted Windows volume for LNK signatures and parse them. When this option in invoked, the option -rawscan is implicitly invoked. Since this option is traversing a mounted volume at the cluster level, it requires the tool to be running at administrative privileges. The syntax is -partition <drive letter>. |
-vmdk | Extract artifacts from a VMWare monolithic NTFS formatted volume. The syntax is -vmdk "disk". When this option in invoked, the -rawscan option is implicitly invoked. Use the suboption -offset <volume offset> to specify which NTFS partition to use (if more than 1), otherwise it just defaults to the first NTFS partition found. For a collection of VMWare disks that include snapshots, one can use the following syntax: -vmdk "disk1 | disk2 | ..." |
-vss | Experimental. Parse LNK 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. |
-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 |
-no_whitespace | Used in conjunction with -csv option to remove any whitespace between the field value and the CSV separator. |
-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. |
-dateformat | Output the date using the specified format. Default behavior is -dateformat "yyyy-mm-dd". Using this option allows one to adjust the format to mm/dd/yy, dd/mm/yy, etc. 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 |
-out | Output the data to the specified file. The syntax is -out <results file>. |
-utf8_bom | All output is in Unicode UTF-8 format. If desired, one can prefix an UTF-8 byte order mark to the output using this option. |
Field | Definition |
---|---|
source type | Where the LNK data was defined (separate file or carved) |
file mdate | LNK file modify date |
time-UTC (after file mdate) | LNK file modify time |
file adate | LNK file access date |
time-UTC (after file adate) | LNK file access time |
file cdate | LNK file 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) | LNK file 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 contains the field names, and the rest of the records are the data. |
lp doesn't parse some of the SHLLINK structures documented in the Microsoft specification. As time permits, future versions will incorporate incremental capabilities to handle these structures.
For csv (comma separated values) output, there are restrictions in the characters that are outputted. Since commas are used as a separator, any data that had a comma in its name is changed to a semicolon. For the default (non-csv) output no changes are made to the data.
For carving options from an image or a volume, lp can encounter boundary conditions that we did not experience during our testing phase. For these cases, lp will most likely crash. As we discover new untested boundary conditions, new updates will be rolled out.
For Linux and Mac builds, the file cdate & time reported in the output is the date and time of the metadata change of the file (not the creation time of the file). This behavior is different in Windows, where the file cdate & time reported in the output is the date and time of the creation of the file.
(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.
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.