OUTPUT

EXPLANATION OF 'lifer' OUTPUT
-----------------------------

**SUMMARY**
The fullest possible information about a link file can be obtained using:
  $ lifer -i {link file(s)}|{directory containing link files}

Basic details can be obtained using:
  $ lifer -s {link file(s)}|{directory containing link files}

Output to tab separated text file can be obtained using:
  $ lifer -o tsv {link file(s)}|{directory containing link files} > {output file}

Output to an XML file can be obtained using:
  $ lifer -o xml {link file(s)}|{directory containing link files} > {output file}

**TEXT OUTPUT (option: '-o txt')**

  This is the default output so the option does not need to be explicitly stated
  in the command line. 
  In this case output is to stdout which is (usually) the terminal window.
  Everything that can be output is printed to the screen. Redirection to a file
  is generally a good idea if there is more than one link file so:

      $ lifer ./Test/WinXP > WinXP.txt

  is a good way to redirect all the text to the 'WinXP.txt' file. This also has
  the advantage of separating the good text (stdout) from any error messages
  which are sent to stderr and usually appear in the terminal window too.

  The output in this format should be read in conjunction with the Microsoft
  open document named MS-SHLLINK available from:
  https://msdn.microsoft.com/en-us/library/dd871305.aspx
  Particular reference should be made to Section 2 of that document which
  explains the structure of a link file in detail.

  Any text enclosed in curly braces '{}' is purely an informational header and is
  used to orient yourself with where you are within the link file. Generally
  anything related to the text in the header is indented after it. So the general
  structure is:
  {header}
    Data Item 1:          Data1
    Data Item 2:          Data2
    {sub-header}
      Data Item 2.1       Data2.1
      {sub-sub-header}
        Data Item 2.1.1   Data2.1.1
      Data Item 2.2       Data2.2
    Data Item 3:          Data3

  Where possible, I have tried to refer the header to the specific section in the
  MS-SHLLINK document.

  A link file has a set structure and in order for a forensic investigator to
  follow the content in a hex viewer, she or he need to know how large each
  section is; to this end I have included (as the first part of any section) the
  size, in bytes, of that header. Any sizes of sub-headers are WITHIN the size of
  the overall section header.
  Following on from there, each data element is in the same order as it can be 
  found within that structure. The representation of the data is purely arbitrary
  on my part so for example:
    •  Unicode Strings appear to be the same as ANSI strings (in my
       'en-gb' locale at any rate, hopefuly if yours is a more enriched locale it
       will be represented correctly). All strings are printed 'as is'.
    •  Boolean values are 'TRUE' or 'FALSE'
    •  Values best represented as a decimal are just a pure number (e.g. '42')
    •  Values best represented in hexadecimal are preceded with '0x' and then
       with the requisite number of hexadecimal characters (e.g. decimal 15 in 4
       byte [32 bit] representation is: 0x000000FF)
    •  Any value enclosed in square brackets does not exist within the link file
       but is there for information so for example a value shown as '[N/A]' 
       means that this value is not applicable in the current context.
  The exception to the rule that data is in the same order as it is within the
  link file the ExtraData structure; here the position of the sections that are
  in this structure are not defined. In this case I have included an offset from
  the start of the file to the structure so that anyone can identify the
  particular Extradata section in question.

  TEXT SECTION LABELLED "{**OPERATING SYSTEM (stat) DATA**}"
  The very first part of lifer output however is nothing to do with the internal
  structure of the link file but rather, shows data relating to the link file
  itself from the perspective of the file system where the link file is located.
  This data is known as the 'stat' data. I have chosen just to display the 
  following:
    •  File Size       (of the link file itself)
    •  Last Accessed   (The time the operating system updated the access time)
    •  Last Modified   (The time the operating system decided that the file
                        had been modified)
    •  Last Changed    (Not the same as Last Modified time!)

    *A SIDE NOTE ABOUT TIMES...*
    Modern Windows file systems record these three times and in addition record 
    the 'Created' time. some of the older FAT systems may not record them all
    though. Conversely, *nix file systems have only recently moved to record
    the 'Created' (or 'Birth' in *nix parlance) time and even then, require the
    option to be turned on explicitly.
    As lifer was originally a Linux tool I voted to keep the three times I
    could most easily capture in that particular operating system.
    Incidentally, for forensic purposes I have found the 'created' time to be
    VERY troublesome and inconsistent; I tend to avoid relying on it anyway.

    All times output by lifer are in UTC. This is a common forensic process
    whereby all times from disparate machines that are separated by time zones
    can be compared together using a single common time zone.

  TEXT SECTION LABELLED "{**LINK FILE EMBEDDED DATA**}"
  The data in this section is the information and printed values contained in
  the body of the link file. The printed data follows the rules set out above.
  Any sections from the specification that are missing in the output are
  probably optional and are missing from within the link file itself.


**XML OUTPUT**

  This is similar to the text output except that the output is formatted as a
  well-formed xml document.


**SHORTENED TEXT OR XML OUTPUT (option: '-s')**

  With this type of output I have sought to resrict the amount of data and
  instead of printing everything, just keep it restricted to the kind of data
  I was interested in whilst working as a forensic analyst. If you think I need
  to adjust what is output here then raise it with me in github (preferably as
  a pull request)


**EXTENDED TEXT OR XML OUTPUT (IDLIST INFORMATION) (option: '-i')**

  NOTE: The '-i'option is only available with the '-o txt' (which is the
  default) or with the '-o xml' options.
  The interpretation of IDList information needs to be switched on explicitly 
  by using the '-i' option.
  Initially the application searches for property store (MS-PROPSTORE) 
  objects within the ItemID and prints out any data it finds. 
  Since v3.0.20 however, any ID List structures that do not contain
  MS-PROPSTORE structures are printed out as raw hex and ANSII


**TAB SEPARATED VALUES OUTPUT (option: '-o tsv')**
  
  This output type is designed for import into a spreadsheet. It is the
  recommended option if you are going to import into a spreadsheet because the
  output has not been tampered with (see CSV output post.)
  The first row (line) contains the column header names and each subsequent
  row are the values from each link file that has been parsed (one row [line]
  for each link file). Each value is separated by an ANSI tab character (0x09)
  from any subsequent values. 
  In order to align the values under the correct columns, any values that are
  not applicable are denoted by "[N/A]", this would normally signify that the
  value does not exist in the context of this particular link file.
  It should be noted that individual Extradata-PropertyStoreDataBlock-Property
  Stores and their values are NOT included in any TSV output. The reason for 
  this is that there can be a variable number of property stores containing a
  variable number of values, the dynamic nature of this data means that it is
  difficult to render in a flat file database such as a spreadsheet. I am
  hoping at some stage, to introduce an XML output option which will address
  some of these shortcomings.
  If it is essential that PropertyStoreDataBlock items are parsed, then for
  the moment, I suggest that you use text output and use tools like sed and
  awk to fish out the data you need.
  At the time of writing (lifer version 3.0.11) IDlists (MS-SHLLINK SS. 2.2.1
  and 2.5.11) are not parsed and ItemID values are only counted. In the
  fullness of time I will include some parsing but the same issue as with
  property stores exists in that, there can be a variable number of such
  values.


**SHORTENED TAB SEPARATED VALUES OUTPUT (option: '-so tsv')**

  This is similar to shortened text output so that some data I consider to be
  irrelevant for forensic investigations has been omitted.


**TAB SEPARATED VALUES OUTPUT (option: '-o csv')** and
**SHORTENED TAB SEPARATED VALUES OUTPUT (option: '-so csv')**

  This output is exactly the same as TSV output. Some spreadsheet and database
  programs balk at importing tab separated values and only properly accept
  comma separated values. The problem with this is that some of the strings
  embedded in link files contain commas, a csv file containing values which
  themselves contain commas can cause havoc with data field alignment.
  In order to solve this problem I have tried to identify strings that may
  contain commas and I then check those strings for commas ',' and replace them
  with semi-colons ';'.
  The upshot is that if you are going to rely on a string that was output by
  lifer as having a semi-colon then be aware that the actual character may be a
  comma. Test2.lnk in the ./Test/ directory is a sample file with this error
  whereby the string:
  "@%windir%\system32\wucltux.dll,-2"
  is changed to:
  "@%windir%\system32\wucltux.dll;-2"
  by changing the output to csv

  Incidentally there is nothing to stop Microsoft (or anyone else) from 
  inserting a TAB character into a string and messing up the formatting of any
  tsv output, in my experience I have never seen it, but it COULD happen!

Paul Tew
March 2020