Quick Look Cache Parsing

June 4th, 2018 Posted by Uncategorized 0 thoughts on “Quick Look Cache Parsing”

In our intellectual property theft investigations, our clients will often ask us about specific file names they care about, especially when data theft or destruction is suspected. Often these files are keys to the kingdom: proprietary engineering plans, customer lists, or confidential financial information.

Finding file names under the Quick Look cache

We used test data to recreate a recent case which had us searching for specific file names on a Mac OS system. Among the search hits in our forensic suite was a file at this path:

Macintosh HD\private\var\folders\n9\9wyq0m052y9cg_jfvh21mk2m0000gp\C\com.apple.QuickLook.thumbnailcache\index.sqlite>>tables>>files>>rows_0000000_0000014.html

Note how the subitems are displayed with carrots >> underneath the “com.apple.QuickLook.thumbnailcache” Quick Look folder and the “index.sqlite” database file. One of the “tables” in that SQLite database is called “files” which has 15 rows (the 14 in “0000014” above could be due to the forensic suite counting to 15 starting from zero).

This is our entry of interest, as seen inside the “rows_0000000_0000014.html” file in this forensic suite:

15
/Volumes/Spaceship Plans
Space1.jpeg
/.file/id=7329707.103
[BLOB]

Alone, this information doesn’t seem to give us much information about the “Space1.jpg” file we care about, so our next step was exporting the SQLite database for viewing in a third party tool.

Making sense of SQLite Quick Look content

After exporting the “index.sqlite” database, this is what the top of the “files” table looks like in the free tool DB Browser for SQLite:

Note the row # at the left (default sort) and BLOB data at the right.

From left to right in the “files” table we see:

  • path, including non-local volume paths
  • file name
  • fs_id consisting of a volume identifier to the left of the dot, and a Catalog Node ID a/k/a CNID to the right
  • BLOB – which we’ll soon see is binary plist data

 

Now let’s examine our entries of interest, in this scenario we’re looking for any “space” related plans:

Note when we view the “BLOB” in binary and see the hex interpretation, it becomes clear from the “bplist00” header that this is really  binary plist data.

From here we click “Export” to examine the binary plist data in a plist viewer. Using Xcode from the Apple App Store we can more easily interpret what just looked like a “BLOB” previously:

The “date” is the Last Modified date of the “Space1.jpeg” file being referenced and “size” is the size of that file in bytes.

From here we can use a number of tools to interpret the date and time which is in seconds from Jan 1, 2001 00:00:00, a/k/a Cocoa/Webkit Date, Mac Absolute Time, or NSDate.

Cocoa date as seen in BlackBag Technologies Epoch Converter.

Cocoa date as seen in BlackBag Technologies Epoch Converter on macOS.

 

Digital Detective DCode showing Mac Absolute Time.

Digital Detective DCode on Windows showing Mac Absolute Time.

 

Sanderson DateDecoder showing NSDate.

Sanderson DateDecode on Windows can check many formats at once and will filter on a user defined “valid” date range.

Because the above example recreates what we observed on our case, we can compare to the known original file and validate the converted timestamp and size:

 

When was this Quick Look data recorded?

Great, so now we know how to read what’s inside the Quick Look “index.sqlite” files table, but why is that data recorded there in the first place? In our example with the “Space1.jpeg” file, that file was on a removable USB thumb drive, the drive was double-clicked on the Desktop displaying files in the root of the USB, then the window was closed.

The JPEG wasn’t even opened and we have information about the file!

This information was generated just by opening the parent folder, creating the above Quick Look path, size, and timestamp information. Along with metadata, a small icon sized preview of the file itself is stored in the “thumbnails.data” file also in the Quick Look folder and with further analysis we would be able to recover the thumbnail as well!

Where the Quick Look data lead in our case and beyond

We saw something incredibly interesting to our client in the case where we first looked at the Quick Look cache. We were able to observe the file of interest go from the Desktop into the Trash! The file was first under the folder:

/Users/[USERNAME]/Desktop

and in a subsequent entry in the “files” table, then seen in:

/Users/[USERNAME]/.Trash

While this was observed on an older Mac OS 10.9.x system, we recently became curious if the Quick Look cache had the same structure in the most recent macOS High Sierra. From our testing, yes, this same type of Quick Look analysis can be applied to the latest macOS systems!

In our next blog post we’ll share some details about collecting and testing Quick Look data on High Sierra.

Tools:

 

Further Resources:

 


 

Please support us, as we work to make maximum exploitation of electronic evidence more accessible, by learning more about the powerful and unique functionality our tools provide. You can learn more about our tools at https://ArsenalRecon.com/#products. Thank you!

Tags: , , , ,