Tuesday, 10 December 2013

Apple Safari update and fsCachedData

Recently I have had cause to look again at how the Apple Safari web browser stores cache. Surprisingly much of what I wrote concerning Safari back in 2010 still holds true.  The introduction of OSX Lion brought some changes in that a new table cfurl_cache_receiver_data was created within the SQLite cache.db database and used to store the cached item as a binary large object in the receiver_data field.   Previously this field was within the cfurl_cache_blob_data table.

I have now looked at Safari version 7 running in OSX Mavericks and found that not all cached data is now stored as binary large objects within cache.db.  In Figure 1 we can see a number of entries in the cfurl_cache_receiver_data table.  A number of them contain BLOBs as expected but in entry 18109 we can see that the new field isDataOnFS has a value of 1 and the receiver_data field has a value of ED6AC03A-4E37-46E2-8C95-E29EDC92BF6E.

Figure 1

In Figure 2 we can see that the new fsCachedData folder contains the file ED6AC03A-4E37-46E2-8C95-E29EDC92BF6E.

Figure 2

It appears that any file 4,096 bytes and larger is now cached externally in the fsCachedData folder.  I note that the files do not have file extensions so a file signature analysis will be required.  The file name is structured like a GUID. It does not appear to be a hash of the relevant URL.

The eagle eyed amongst my readers will have already spotted another type of entry within the receiver_data field in Figure 1.  Figure 3 shows more of them.

Figure 3


It can be seen that the data in the receiver_data field has the structure '474946.................................3B'. Seasoned forensicators will recognise this data as hex and that contained within it is the header and footer of a gif file. This data is stored within the Sqlite database as a BLOB however the SQLite utilty reading the BLOB has been configured to display BLOBs less than 50 bytes in size as a string.

Until next time.