This is just a quick look at the Safari FavIcon database - There isn't a tonne of data here but what there is may just be useful.

I first saw this database many months ago, but it wasn't until I was recently asked a question by another forensicator, Eric Jollymore of Vermont State Police, that I took a closer look at it. And over the next few days, Eric and I were in contact discussing the various tests we had performed and what our results were.

As it's name suggests, the database is related the the FavIcon's in Safari. For anyone who doesn't know what a FavIcon is, it's the small icon that displays in the tab of a web browser. It's the same icon that shows up when you start a new browser window and it is populated with icons of the website you visit the most.

Doesn't sound too useful right? Easy to ignore? Maybe. But maybe it has the data you need.

The Database

To begin with, the database is found at private/var/mobile/Containers/Data/Application/XXXX/Library/ImageCache/Favicons/FavIcon.sql (Where XXXX is the folder where Safari is installed) and is made up of only a handful of tables.

When you visit a webpage, the link to the favicon is provided as a meta tag. Something like:

<link rel="icon" type="image/png" href="favicon.ico">

When you visit a site for the first time, the browser builds the full URL and downloads the icon, saving it locally on your device for future use.

This causes a problem as multiple files cannot be saved with the same name of "favicon.ico". To get around this, the image is hashed using MD5. The resulting value is used to name the file, which is saved inside a "Favicons" folder without a file extension.

The same hash value is then used as the unique idenitifer within the database as the UUID field.

The icon_info table contains the hash value (as UUID), the URL that the image originated from and details about the icon such as dimensions. It also contains the timestamp of when the image was downloaded (ie when the site for visited for the first time).

The page_url table contains the hash value (as UUID) and the page that was visited that prompted the download to occur. Records are also kept of visits to the same site which do not prompt the download to occur.

For example:

I visit the website "www.doubleblak.com" for the first time. As a result, the favicon.ico file is downloaded and hashed and saved. For arguments sake, lets say the hash value is 12345.

A record is created in page_url that looks like this:

A record is also created in icon_info that looks like this:

If I then visit www.doubleblak.com/blogs.php, the icon is downloaded again and hashed. But because a file with the same name already exists, the file is not saved. Nor is a record created in icon_info.

A new record is created in page_url which now looks like this:

Because the page_url table doesn't have a timestamp, we can only know the time of the first visit to this site (ie. when the icon was downloaded). Which may or may not be helpful.

But we can also make assumptions about the page_url entries based on the order of the records and relating them back to icon_info. For example, given the following information:

We know that www.doubleblak.com was first visited at 613238540.
We do not know when www.doubleblak.com/blogs.php was visited but it was obviously after www.doubleblak.com otherwise these records would be ordered differently.

By the same logic, we also know that www.doubleblak.com/blogs.php was visited before www.apple.com. And because we know that apple.com was visited at 613238550, it's reasonable to assume that www.doubleblak.com/blogs.php was visited between 613238540 and 613238550.

Another trick to try to work out the time that a site was visited is to look at the URL itself. Many URL's include a timestamp embedded within the querystring and we can simply use that to work out when a page was visited.

For example, let's take a simple Google Search:

https://www.google.ca/search?sxsrf=ALeKk027R2L4KdP81yOYTjrow4DnbKktlw%3A1591554613140&source=hp&ei=NTLdXu7qBcLS-gTghprACA&q=test+search&oq=test+search&gs_lcp=CgZwc3ktYWIQAzICCAAyAggAMgIIADICCAAyAggAMgIIADICCAAyBggAEBYQHj
IGCAAQFhAeMgYIABAWEB46BAgjECc6BQgAELEDOgUIABCDAToECAAQCjoICAAQFhAKEB5Q8wFYhQ1g0g5oAHAAeACAAXqIAc
EGkgEEMTAuMZgBAKABAaoBB2d3cy13aXo&sclient=psy-ab&ved=0ahUKEwiu2er6qvDpAhVCqZ4KHWCDBogQ4dUDCAk&uact=5

Once we break the URL into it's various parts (seperated by both ? and &) we get:

While most of these are outside of the scope of this document, the one we do need to pay attention to is the forth line down; the ei parameter.

The ei parameter is a combination of 4 values, one of which is a Unix Timestamp. More information on the EI timestamp can be found at https://cheeky4n6monkey.blogspot.com/2014/10/google-eid.html

The EI parameter can be easily decoded using my free EPOCH tool available in the software section of the site.

Something else I have noticed about the Favicons database is that it can sometimes still contain data that has been deleted from safari. Whether this is by design, a bug, oversight or simply that garbage collection runs at a different time is yet to be seen. But it history.db is empty, favicons.db may be worth a look.

The rejected_resources contains URL's and timestamps that don't save icons. Most likely due to the way the icons are presented. For example, if it's not a straight forward ico or image file.

Also note, that as expected, websites visited in Private Mode do not record anything in these databases.

Wrapping Up

Favicons will usually not be very exciting. But that doesn't mean that it can't be useful at all and yet not all tools parse Favicons or help you understand there relevance.

Either way, it's good to know it exists and may just hold the data you need.

Thank you for reading! Don't forget that ArtEx can be download FREE from the 'Software' section of my site.