This is the last post I’m going to write about this artifact. But after 2 previous posts, and 2 live demonstrations during a trial, it seems its still not understood or still not believed.
This is by far the most divisive piece of data I’ve ever presented in court, which is crazy to me because it’s so easy for anyone to test for themselves.
During my testimony, I used my tool ArtEx to do the live demonstration. It wasn’t about preferring one tool over another, marketing of my own tool, or “controlling and manipulating the data”. The reasons were actually totally pragmatic.
I know of no other tool that would allow me to so quickly and easily demonstrate the issue - Because I was using a JailBroken device, the live connection feature of ArtEx allowed me to see the data on the device within seconds of using the device, without having to do a full extraction and decoding - a process that would take at least 20 minutes and would be boring for everyone watching.
ArtEx is a free tool, available to anyone. If anyone doubted what I was saying/showing, they could easily download the tool and test it for themselves; an iTunes backup is all that is needed.
And that’s the point of this last post. To walk through the steps so that anyone (examiner or not) can replicate my findings and hopefully put this whole issue to bed once and for all.
Don’t get me wrong, I actually love that it’s being questioned. I believe it should be questioned, and it should be something that examiners seek to validate and understand.
But there is a very well-known and well-documented phenomenon called “the CSI Effect” where crime investigations on TV shows influence the expectations of the general public. This means that jurors (or any person observing the trial) has unrealistic expectations from the evidence based on what they saw on TV. And I think this goes double for digital evidence where not only is it misrepresented on TV, but there is an additional hurdle because everyone owns a cell phone and there is an inherent belief that “as a user of a device, I understand it”.
Several people on YouTube have already made videos showing their results matched my own. But I want to make sure everyone knows that this is a test that anyone can do and satisfy their own curiosity. And maybe learn something about digital forensics too.
What you need
An iPhone. Preferably one running iOS15 or above (iOS14 behaves differently).
A windows computer with iTunes (or any tool that can do an iTunes backup - including ArtEx).
ArtEx.
That’s all.
Step 1- Creating the Test Data
There are multiple scenarios that can play out here depending on how you use the device. And you will no doubt find there are times when the timestamp does appear correct. I’ll try to outline the main scenarios here.
Ultimately though, you should see that although the timestamp can be correct, it can be incorrect and there is no way from this database alone, to understand which is which. Hence, the timestamp is unreliable.
Scenario 1
Open Safari.
Note the time and create a new Tab.
Visit any websites you want. I always like to google search the time just to make it easier to look back at later.
My search was at 9:25am for "9:25".
MINIMIZE safari. Do not close it entirely.
Let some time pass. However long you want. Feel free to keep using the device for other things, just don’t let Safari close.
At some point later in the day, reopen safari.
In the same tab you were in earlier, visit a new website / google search the current time.
I had reopened Safari at 9:35am and searched for "9:35" in the same tab as I had earlier used for "9:25".
Once the page loads, close the tab.
This scenario will create a record in the BrowserState.db database that shows the time the tab was opened in step 2 but the URL that was visited in step 7.
This timestamp should be well before the time the URL was actually visited. Thus proving that the timestamp here is unrelated to the time the website shown.
Scenario 2
Open Safari.
Note the time and create a new Tab.
Visit any websites you want. Again. I find it easier to google search the time.
At 9:36, I searched for "9:36".
Completely close Safari.
Let some time pass. However long you want. Feel free to keep using the device for other things, just don’t open Safari until you are ready for the next step.
At some point later in the day, reopen safari.
At 9:58am, I reopened Safari and saw the same page I had open earlier.
Do nothing except close the tab.
This scenario will create a record in the BrowserState.db database that shows the time the tab was refocused when Safari reopened step 6 but the URL that was visited in step 3.
This timestamp should be well after the time the URL was actually visited. Thus proving that the timestamp here is unrelated to the time the website shown.
Scenario 3
Open Safari.
Note the time and create a new Tab.
Visit any websites you want. Again. I find it easier to google search the time.
At 10:34am, I searched for "1034".
Once the page loads, close the tab.
This scenario will create a record in the BrowserState.db database that shows the time the tab was opened in step 2 and the URL that was visited in step 3.
This timestamp should be very close to the time the URL was actually visited. This is the only scenario where the timestamp is reasonably close to the time of the visit and is only because there was no further navigation after the first page.
Bonus
As an extra test, I visited www.doubleblak.com/large.php. This page does nothing except take a long time to load (assuming it doesn’t crash). And that’s the point.
Start navigation to that page and then kill the tab.
Other Scenarios
Other scenarios are possible, such as switching between existing tabs or closing tabs that are already in a background state etc. But ultimately whatever you do should leave you with the opinion that with the exception of single visits (such as Scenario 3) this timestamp cannot be used to show when a website was visited.
Run the Setup. Note that it may complain about the exe being unsigned and it Windows defender may even complain about detecting a virus. Tthis is not uncommon for forensic tools. Although it may seem concerning, run the exe through websites such as virustotal if you are concerned. Either way, you will have to white list the application to allow it to work or find an alternative tool.
Once ArtEx starts, you will be presented with options for Air-Gapped or Internet Connected use.
Internet connected is the easiest way to proceed. So hit Internet Connected and then “Click Here to configure ArtEx for online use”
ArtEx will check online for parsers and ask to download them. Say OK.
After a minute or so, you will be notified that ArtEx needs to restart. Press OK. ArtEx will close and reopen, presenting the list of parsers that were installed.
Now the real testing can begin.
Step 3 - Back up your device
There are several methods for doing this. You can use iTunes or free tools such as 3u. You can even use ArtEx itself. The important thing here though is to make sure you encrypt the backup.
Non-encrypted backups contain less data and don’t include the files we really want to look at.
Here, I will walk through using ArtEx to do the backup.
Press Begin
Connect the phone to the computer.
Select the “ArtExtraction” tab and press Backup
Your device should be detected
Press Start and select a Backup location.
If the device has no password, ArtEx will recommend setting one (it defaults to “1234”).
Using a password will encrypt the backup and result in more data being extracted. You WILL need to use a password to get the data we are interested in.
Either press “Set Passsword” to accept “1234” or enter the previously set password.
ArtEx will start the backup.
Once the backup completes, it will automatically start processing.
Step 4 - Processing the Backup
If you used ArtEx to obtain the backup, you can skip this step as it will automatically process upon completion of the extraction.
If you used a different tool, then folllow these instructions:
Press Begin and choose the "Backup" tab.
Use the Browse button to find the folder where the backup exists.
Enter the backup password and press "Test Password".
Assuming the test completes successfully, press Open.
Step 5 - Review the Data
If you used ArtEx to obtain the backup, you can skip this step as it will automatically process upon completion of the extraction.
Once processing is completed, you will be presented with a device summary.
Now we have the extraction loaded, ensure you select your appropriate time zone either from the pop-up or the menu in the top right of the screen.
Then head to the Directory Tab and search for “browserstate.db” and press enter.
Double click the BrowserState.db database to open it in the Database viewer.
From here you can select the various tables using the icons on the left. Select “tabs”.
You will see the 3 tabs we created earlier during each of the scenarios.
As a quick refresher, these were my three scenarios;
Scenario 1: Opened tab at 9:25 and googled “9:25”. Minimized Safari for 10 minutes. Reopened Safari at 9:35 and googled “9:35”. Closed tab.
Scenario 2: Opened tab at 9:36 and googled “9:36”. Closed safari. Reopened Safari at 9:58 and closed the tab.
Scenario 3: Opened a tab at 10:34 and googled “1034”. Immediately closed the tab.
Now let’s look at the results in my database.
The first record shows the URL related to the 9:35 search but with a timestamp of 9:25 (when the tab was created).
The second record shows the URL related to the 9:36 search but with a timestamp of 9:58 (when Safari was reopened).
The third record shows a URL related to the search at 10:34 and the timestamp of 10:34 (the time the tab was created).
There is NO record for the visit to the large webpage.
Hopefully by this stage, you’re convinced that these are not reliable timestamps to show when a webpage was visited. So, what are good timestamps?
History.db
Use the Directory tab to search for “History.db”. You may be presented with 2 results, but it’s the one with the uppercase H that we are interested in.
This will present all pages that completed loading. If you search for “history.db” you’ll find it and can open it by double clicking it.
This has two tables;
history_items: is the list of URLs visited but excludes the times of the visits.
history_visits: is the list of visit times.
These tables need to be read together, joined by the history_items.id and history_visits.history_item fields.
Ie. Find the appropriate URLs you are interested in on the history_items table and take note of the ID. Here, I’m interested in records 118, 119 and 120.
Again, note that the visit to the Large website is NOT present, because the page didn’t completely load (or completely fail).
Now go to the history_visits table and find all records with a history_item value equal to the ID you noted above.
You should see the times that the webpages were actually visited.
This is a source of reliable timestamps (assuming the page loaded and was not visited in private browsing mode).
com.apple.mobilesafari.plist
If you used the Safari Search bar to do the search, you can check this file to see the Recent Searches.
Use the Directory view to search for “com.apple.mobilesafari.plist”
Double click to open it. This is a plist file that needs navigating and expanding. Find the Recent Searches node and click it.
When you expand the RecentWebSearches node, you will see a list of SearchStrings and Dates. One for each search that was conducted.
Click the SearchString and Date to expand further.
Note that these times are presented in UTC and you will need to manually adjust them to match your local time zone.
In my case, I have to subtract 6 hours from each value because I'm in Mountain Daylight Time.
That means:
“1034” was searched at 16:34:27 -6 hours = 10:34:27.
“9:36” was searched at 15:36:11 - 6 hours = 9:36:11.
“9:35” was searched at 15:35:09 - 6 hours = 9:35:09.
“9:25” was searched at 15:25:16 - 6 hours = 9:25:16.
These are all accurate timestamps.
Wrapping Up
There are multiple files on a device where you can find accurate timestamps for when a website was visited. BrowserState.db is not one of them and it’s a simple test as shown above to prove it.
If however, you see BrowserState.db records showing anything other than what I described above, I’d be very interested to hear from you. Because in over 2 years of testing, I’ve never seen them provide accurate data except in the one, limited scenario described.
