One of the many new features of Windows 8 is a new stock photo viewing application called Photos. With the inclusion of a new photo viewer comes the creation of new artifacts resulting from its use. Specifically, I’ve found that the Windows 8 Photos app stores usage history information within a user’s UsrClass.dat registry hive. Buried within this hive is a wealth of information about files that have been viewed using Photos (specifically by double-clicking an image). By “wealth of information”, I mean information about each file viewed using the Photos app. This includes the file name, path to the image file, timestamps associated with the image file, the last time the file was viewed using Photos, the type of device from which the file was opened, and more.
Based on my research, if an image file has been opened using the Photos app via double-clicking the file in Explorer, a subkey named using a {GUID} value will be added to the “Local SettingsSoftwareMicrosoftWindowsCurrentVersionAppModelSystemAppDatamicrosoft.windowsphotos_8wekby3d8bbwePersistedStorageItemTableManagedByApp” subkey located in the user’s UsrClass.dat hive. The screenshot below is a depiction of the values and value data from a ManagedByApp{GUID} subkey as viewed with regedit.
Based on my research, each {GUID} subkey beneath the ManagedByApp subkey corresponds to an image that has been opened using the Photos app and includes six values. The table below includes information about each value located within one of these {GUID} subkeys.
|
Value Name
|
Value Type
|
Value Data
|
|
FilePath
|
REG_SZ
|
Full
path to the file |
|
Flags
|
REG_DWORD
|
Appears
to relate to the media type from which the image was opened |
|
LastUpdatedTime
|
REG_BINARY
|
64-bit
FILETIME value; appears to reference last time the file was opened |
|
Link
|
REG_BINARY
|
Variation
of Windows LNK file [MS-SHLLINK] |
|
Metadata
|
REG_SZ
|
Holds
the name of the file |
|
PackageFamilyName
|
REG_SZ
|
microsoft.windowsphotos_8wekyb3d8bbwe
|
File Path Value
If you guessed that the FilePath value data includes the path to the image file, you’d be correct. Based on my testing, the full path (including drive letter) is included in this data if the image file was opened from the C: drive, external hard drive, or network share. If the image file was opened from a flash drive, the volume GUID is listed instead of the drive letter (e.g. ?Volume{D729662E-868D-11E2-BE69-000C29930361}file1.jpg). The inclusion of the volume GUID here will allow an examiner to corroborate this data with information from the MountPoints2 subkey of the user’s NTUSER.DAT hive as well as the MountedDevices subkey from the SYSTEM hive. The drive letter assigned to the media where the file was stored can also be found in the Link value data within the same {GUID} subkey.
Flags Value
The Flags value data appears to relate to the type of media from which the image file was opened. Based on my testing, a flag value of 13 (0x0000000D) indicates that the image file was located on the internal C: drive at the time it was opened. A flag value of 9 (0x00000009) is assigned when the image file is opened from some type of external media (such as a flash drive or external hard drive), including network shares. This should be easy to verify by checking the FilePath value data (or the Link value data) stored in the subkey.
LastUpdatedTime Value
The LastUpdatedTime value data is a 64-bit FILETIME value and appears to be updated each time the image file referenced by the {GUID} subkey is opened using the Photos app. Since this value is updated each time the image file is opened, the LastWrite time of the {GUID} subkey to which this value belongs is also updated. In my [fairly limited] testing, I have yet to come across a case where the LastUpdatedTime value data is different than the LastWrite time of the {GUID} subkey to which the value belongs.
With the exception of the first 16 bytes, the Link value data appears to follow the MS-SHLLINK file format (see this document provided by Joachim Metz for more info on this format). The first 16 bytes of the Link value data appear to hold the LNK class identifier and are the same as bytes 20-35 of the value data (where one would expect to find the LNK class identifier based on the MS-SHLLINK file format). After the first 16 bytes, we can find much of the same useful information here as would expect to find in Windows shortcut files (target file timestamps, full path to target file, etc.). The value data alone provides a great deal of insight into the opened file.
Forensic Implications
Using the values from these {GUID} subkeys related to the Windows 8 Photos app, an examiner can determine not only what files were viewed using the app, but also the last time each file was viewed, the type of device from which each image was viewed, the path to each file, timestamps associated with each image, and much more. This information can be used to track user activity surrounding image files, corroborate USB device activity found in other locations, as well as provide useful timestamps for inclusion within a timeline. A RegRipper plugin or otherwise some other means of quickly harvesting this information will need to be written (it’s on my TODO list unless someone beats me to it), but knowledge of these artifacts will be important when examining a Windows 8 machine (particularly when image files are of interest).As an aside, I have yet to determine if there is a maximum to the number of {GUID} subkeys created before they begin to be cycled out, but I have populated more than 200 subkeys without the oldest entry being removed. This indicates that an examiner may encounter a large number of these subkeys during an investigation, depending on how often the user views images using the Photos app. Additionally, this information does not appear to be removed when the user clears their app usage history (using any of the stock options that I’ve tried to date).
Update: 07/08/2014: As pointed out in a comment to this post, this information does not appear to be recorded in the same manner in Windows 8.1.
Great stuff! Love it!
gud work
Any idea why Microsoft is tracking that information?
Is this tracking still active at Windows 8.1? Or has this changed? I dont find the PersistedStorageItemTableManagedByApp path.
Hi,
A bit of quick testing indicates that this may not be tracked/recorded in the same manner in 8.1 as it is in 8. Thanks for pointing this out. This is a great example of yet another change in artifacts that an examiner should expect based on the specific version of operating system.