iOS 16 - Breaking Down the Biomes (Part 4) - Surfin' with Safari

 Oh Safari, I once thought your worst change was moving the navigation bar to the bottom of the screen. Turns out you said "Hold My Beer" with iOS 16 and decided to throw some switcharoos on us. To be honest, Safari has always been an interesting albeit annoying browser for iOS. It has some pretty strict limits when it comes to storing data including keeping history for only 30 days and downloads for 24 hours. It also mimics its history over into the KnowledgeC database which is great when you're trying to confirm that history came from a specific device (and the origin column isn't available that is). 

As this series has explored though, KnowledgeC has changed. Also, KnowledgeC syncs now so that means using it to show device attribution may be difficult too. That being said, the new biome changes give us some flexibility with this as well as give us some new artifacts to track through as well on top of the old favorites.

Safari History

The previous /safari/history data from the ZSTREAMNAME column of KnowledgeC has gone missing and been replaced with a biome: _DKEvent.Safari.History which can be found within /private/var/db/biome/streams/restricted/. This file is going to contain a lot of the same protobuf structure as mentioned previously, but there are some more interesting things going on here with Safari too. First, let's break down the protobuf within the SEGB file. 

Like many other protobuf records before it in the post series, this one will store an identifier "/safari/history" as well as a date and time in Apple Time format. IMPORTANT NOTE: In my testing, the dates and time listed in the beginning of the file appear to be DIFFERENT from the main Safari History.db file records. They seem to only be off by a few seconds but they are coming AFTER the record within the Safari database. The URL for the page is recorded as well as the title of the page later down the protobuf. 

The other important thing to note about the SEGB files is that where previously the KnowledgeC database records confirmed this came from one device, the location of the SEGB files within the biome directory can confirm if these records were generated on this device or on other devices. Remember that any file within the local directory came from the local device while SEGB files within the remote directory were synced to this device from others. 

But what happens when Safari history is cleared? Or if the data is viewed in private browsing mode? When the Safari history is manually cleared from the settings application in iOS, it triggers some deletions within the biome for Safari history. In testing, a tombstone record (a separate SEGB file cerated within he tombstone folder) got created during the destruction event and records were written to it but they did NOT contain the original URLs. 

In addition to the tombstone file being created, there is also changes to the original SEGB files too. What is interesting is that the records are modified in place, and not just simply destroyed or the entire file replaced. Each individual protobuf is written over and replaced with 0x00 within the leftover bytes. 

What makes this even more interesting is what happens when you delete individual records, not through the Settings app, but through the history area of the Safari browser. When this is done, the record within the SEGB file will NOT get removed immediately or overwritten. 

Now, when the same area of Safari issued to purge ALL the history, it has the same response as when you clear it from the Settings. The records in place within the local/{SEGB} file get overwritten with 0x00. 

BEFORE

AFTER

So to recap: delete ALL the records, SEGB gets overwritten; delete individual records, SEGB does NOT get overwritten. 

It should also be noted that records that are done in private browsing tabs never seem to get written to the SEGB files in the first place. This doesn't mean they can't be recovered, but we'll get to that later. 

One last thing to mention on this, is that if you don't also close the tabs, there might still be traces of the data behind even after the HISTORY is cleared. 

SafariPageView

The SafariPageView biome can also contain pieces of the safari history, but can give more context to the URLs. The SafariPageView biome will record the page's textual content without any formatting or images. This allows the examiner to see some of the content of the page as well as use this as a great place to get keyword hits back. 

The data will contain a date and time of when the information is "donated" to the biome, the title of the page, and the textual content of the website. These protobufs can be large, but at the end of the data should be the URL that this content belongs to. 

Aligning with the history, private browsing mode records did not appear in this file and after a full deletion of the history these records were also purged. 

Shared With You 

The "Shared With You" feature that was added in iOS 15 also lives within the biome data so we might as well break that down here since I haven't seen a lot on it. Records that are shared via iMessage show up in separate "Shared With You" areas depending on the content that is sent. For Safari, these website shared from contacts via iMessage will appear on the new tab Home Screen. More information on Shared With You can be found on Apple's website here. 

The records are stored within a SEGB file in the location /private/var/mobile/Library/Biome/streams/restricted/feedbackSocialHightlights. There are both local and remote subdirectories in this location. The URLs that are shared as well as who did the sharing are available within the protobuf records inside this file. 

Note there are two timestamp records inside the protobuf. In fact, there will be multiple records of the same shared URL in the SEGB file in separate protobufs. The first timestamp is the written time to the SEGB file while the second timestamp stored within the main Message block is when the message was sent. 

Speaking of Shared With You data, each application that can handle that information will react differently. For information on how the Photos app is handling it, go check out Scott's post on it over here.  

Some Other Safari Stuff!

Let's face it. I love tracking Safari information. I've done multiple posts on Safari information and some webinars. I might as well take the opportunity to share some information on some more recent Safari changes. Unlike the biome data which can only be extracted from file system level examinations, this one is going to be available in Quick style images as well. 

In many versions of iOS, turning the BrowserState.db was a great location to go and find records of websites that were beyond 30 days old as well as records of private browsing history. This is still partially true, but not the only place to look anymore. The BrowserState.db will continue to track tabs from iOS 15 that has been restored to iOS 16 devices but will also now only track tabs once they have been closed. 

The new go-to spot for currently open tabs is in the same directory (private/var/mobile/Library/Safari) but called SafariTabs.db. The bookmarks table will store information relating to all of the currently open tabs. The first key is understanding how to categorize the tabs. 

The parent column for all of the following tab information will reflect the "id" column value that relates to one of the above shown categories. This allows us to track pinned, recently closed, local, and even private browsing records within this database. 

In the above screenshot you can see that id 12 relates to a page that is in private browsing mode while id 13 relates to parent 10 which is our "local" meaning just standard tab. The "order_index" column tracks the order the tabs were opened and you may see repeat values because of both normal and private browsing tabs. 

There are two BLOBS in the bookmark table, extra_attributes and local_attributes. The local_attributes BLOB is the most important as it will store information about the tab itself as well as all of its session data. These BLOBs are binary plist files.

The BLOB data contains good information such as the LastVisitTime but the "SessionState" key is what we're really after here. This contains ANOTHER binary plist file, but like the old BrowserState.db used to do to us, this is not all it stores. The first 4 bytes are actually padding so you can't just save the bytes of the SessionState key as a plist then open it normally. After removing the extra padding, the file can then be opened in your plist program of choice. 

Conclusion

Safari certainly knows how to keep it interesting for us, doesn't it? Even though we have lost the Safari history data within KnowledgeC, the web usage data is still there so that's a start. By parsing the biome data we are able to get the information we lost from KnowledgeC and then some! The PageView has been an interesting one for me and I'm curious to see how many folks will find that contextual keyword that helps their case when getting a look at what the user may have seen on the page. 

There's also the newer Shared With You (Me?) data that we can track now too thanks to our biome information. This is handle especially when tracking potentially deleted messages that might still leave the links behind. 

Speaking of deleted, it was really interesting (for me at least because I'm a big nerd) to see how the biome data is treating Safari history when it's individually removed versus removing the entire history. Combine that with not tracking the private mode data and it's really going to be an "it depends" situation for us, but we're used to those right? 

Finally, speaking of private mode, Apple didn't TOTALLY leave us out with that one. While the BrowserState.db's function has seemed to change a bit at least now we can track the same information in a separate database with a little bit of additional digging. Surf safely friends! Until next time!