Ian Whiffin - Direct

MR. WHIFFIN: I do.

MR. WHIFFIN: Good morning.

MR. WHIFFIN: Good morning.

MR. WHIFFIN: Yes. My name is Ian Whiffin. I'm a digital forensics examiner and decoding product manager for Cellebrite.

MR. WHIFFIN: It is. Yes.

MR. WHIFFIN: I am.

MR. WHIFFIN: Yes. Cellebrite provides digital forensic solutions to customers globally for access and decoding of digital artifacts from devices.

MR. WHIFFIN: Typically Cellebrite focuses on phones or iPads, but we do have some additional devices that we can also interrogate— computers, vehicles, things like that.

MR. WHIFFIN: Cellebrite is a digital intelligence company.

MR. WHIFFIN: Yeah, we create our own software to access devices and to decode the data that we pull from devices.

MR. WHIFFIN: It does. Yes.

MR. WHIFFIN: Typically the analyst would take the data that's been extracted from a device such as a cell phone, process that in software such as a physical analyzer that Cellebrite creates, and use that information to filter, to search, and to create a report for the investigator that would allow them to see what happened on the device at the time being investigated.

MR. WHIFFIN: I started my career in digital forensics in 2013.

MR. WHIFFIN: Certainly. I spent 5 years as a frontline police officer in the UK during the 2000s. In 2009, immigrated to Canada and continued policing— frontline officer in Calgary— before joining the digital forensics team in 2013. Pursued several qualifications related to digital forensics and just continued in that role until 2019, 2020 when I left the police agency and began working for Cellebrite.

MR. WHIFFIN: There were. In order to be a forensics examiner in Canada, you have to take a 3-week foundational course in Ottawa, basically covering the basics of digital forensics, and then from there other courses are available that would focus on things like cell phones— would focus on how to get data from different types of devices— and then there's industry qualifications that can be sought as well where you can focus on particular types of device or particular types of data.

MR. WHIFFIN: It does. Every time an update is released to an application or to an operating system, there's the opportunity for the foundation of that software to change. And from a forensics point of view, you have to re-understand what has changed, make sure you understand what is now happening on that device, and provide that information to the users.

MR. WHIFFIN: I've not taken a class now since I actually joined Cellebrite and did the basic foundational courses that Cellebrite offer. But prior to that, I was doing courses across the industry.

MR. WHIFFIN: I do teach webinars. I don't teach any actual courses. Although some of my research and some of my tools are taught to examiners in many of the industry standard qualifications which users seek.

MR. WHIFFIN: I do. I have a blog where I publish my research. Sometimes some of those become papers which get peer-reviewed and distributed in more academic channels.

MR. WHIFFIN: Yeah, essentially other forensics examiners would read over the paper that I've written, do their own testing, compare their testing and research to what I've conducted, and make sure that what I've said is consistent with their findings. And presuming that what they find is the same as what I found, then they would agree that it's a valid document and it gets shared.

MR. WHIFFIN: When I started there, I was considered the senior digital intelligence analyst. My role was to help the developers of the software understand the role of a digital forensics examiner— what an examiner needs from the tool, what an examiner wants to do with the tool and how they want to use it. And then since then I've progressed to the decoding product manager where I can manage the backlog of software applications that we support, decide how we should support those applications, and how that information should look to the users.

MR. WHIFFIN: I do still do research. Yes. It's not my primary function within Cellebrite. But it's something that I've continued to do throughout my career.

MR. WHIFFIN: Yes. Again, I'm not an official programmer with Cellebrite, but I do program as well. And I have several tools which I've written myself for the last few years since around 2015— tools that I wrote to do the things that the vendor tools didn't do and to offer examiners things that the vendor tools didn't offer. And I continue to maintain those tools as a learning opportunity for myself and also because other examiners can make use of these same features.

MR. WHIFFIN: I have. Yes.

MR. WHIFFIN: I've been qualified as an expert in Canada, Australia, the UK, in total around 20 times.

MR. WHIFFIN: Yes. So fundamentally when we've got data from a device, it's a series of files, a series of databases, property lists or all manner of different structured data. The software that we create knows where these files exist, knows how to read these files and what the data inside them means and provides a clear view for the user to view that data. As an example, if you were to look at the SMS database on a device, all you would see is a long list of messages that don't really have an easy way to interpret or to read them. Our software takes that information, converts it into a conversational view so that as a user you can read the data, you can see who sent what message, what time it was sent.

MR. WHIFFIN: We can do decoding and decryption of various different types of security to give the user as much information as possible.

MR. WHIFFIN: There is. There's multiple vendor supply tools and multiple tools available that are maintained by users in the community like myself.

MR. WHIFFIN: The software program is great at finding the data and displaying the data. But I always maintain it's the role of the examiner to actually understand what that data means and provide context and validation for what that data means. Making sure that the end user of the report, whether that's the investigator, a judge or a jury, can understand what that data actually means rather than just taking it at face value from the software.

MR. WHIFFIN: It does. It just creates a list of all of the results that the examiner wants to include in the report.

MR. WHIFFIN: The examiner can and should go beyond what the program provides.

MR. WHIFFIN: Yes, it was actually one of the public relations managers at Cellebrite who reached out to me, or to my team, because he'd heard about this case and about the confusion regarding a timestamp and requested if we could look into it and find out what the confusion was and how we could respond to it. At that point I contacted the investigators to get more details.

MR. WHIFFIN: Yes, there was both the troopers who had requested information about this particular artifact and also a private forensics examiner, Richard Green.

MR. WHIFFIN: He reached out to the tech support team asking basically there's a timestamp that doesn't make sense. I need to understand what this timestamp means.

MR. WHIFFIN: Essentially it is the time which is attributed to an artifact. So it should intentionally be when something happened on that device; we would show a timestamp associated to it.

MR. WHIFFIN: An artifact would be any piece of data that we pull from that device. So it could be a text message, it could be a location point, it could be a photograph.

MR. WHIFFIN: It would. Yes.

MR. WHIFFIN: I'd consider that a property of the artifact.

MR. WHIFFIN: Yes.

MR. WHIFFIN: When you look on the phone itself, no. There's usually a lot more information in the background of the phone that's available to the forensics examiner which the user wouldn't necessarily see on the device.

MR. WHIFFIN: Yes, you can see what other information is available. You can see if there's any information that's been deleted that can be recovered, and you can validate the information that's there and make sure that the timestamps are being interpreted correctly and that they mean what you think they mean.

MR. WHIFFIN: It was related to an internet query.

MR. WHIFFIN: He did. He wanted to know how accurate the timestamp was in relation to when the internet query was made.

MR. WHIFFIN: In response to Richard Green at that time, I didn't. I wasn't aware that Richard Green had made this request until several months later. But it was an almost identical question that had been asked by the troopers here. And that's the question I was able to look into and to answer.

MR. WHIFFIN: The question was related to a timestamp of 2:27:40 a.m. and an internet query that appeared to have occurred at that time. There was no other information on the device that suggested that that internet query had occurred at that time. So we wanted to know how relevant is that timestamp to when the query happened. So I was able to take test devices, recreate test data, to find out exactly what this timestamp meant, and discovered that it was actually the timestamp that the tab within the browser was brought into focus and had no relevance to when the actual web query had been made.

MR. WHIFFIN: Eventually yes, I did. After I provided information to the troopers, I wrote a blog that covered this information, because there was another examiner in Europe who had a very similar question and I realized that this is a relatively common point of confusion. And then eventually I reached out to Richard Green offering to speak to him about this issue and clear up any confusion, but never received a response.

MR. WHIFFIN: Correct.

MR. WHIFFIN: Correct.

MR. WHIFFIN: I did have the opportunity to look at the data that was extracted from that device. I never saw the device itself.

MR. WHIFFIN: Yes. I was also sent the extraction of data from John O'Keefe's phone.

MR. WHIFFIN: I did. Yes.

MR. WHIFFIN: Yes.

MR. WHIFFIN: I didn't. It was just a download of the extraction.

MR. WHIFFIN: The examiners here had done the extraction of the device, resulted in a large zip file which is a container containing all of the files extracted from the phone. They uploaded it to Cellebrite's secure portal where I was able to download it and verify what the data was in the extraction.

MR. WHIFFIN: With John O'Keefe's phone, I actually received the data on a USB thumb drive through the mail.

MR. WHIFFIN: For Jennifer McCabe's phone, it was related to the internet search that occurred, or that allegedly occurred, at 2:27:40.

MR. WHIFFIN: I did. Yes.

MR. WHIFFIN: I did. Yes.

MR. WHIFFIN: Uh, yes. This is the PowerPoint presentation I created related to Jen's phone.

MR. WHIFFIN: I do. Yes.

MR. WHIFFIN: Okay. Um, the query revolved around a database called browser state.db. Browser state stores information about Safari internet browser and about the tabs that the user has either had open or has open. Fundamentally, in this presentation I wanted to include information from iOS 14 and earlier. iOS 14 is not the version of iOS that was on Jen McCabe's phone. But iOS 14 has an easier way to understand how this database works. And then I can move on to iOS 15, which was the version installed on Jen McCabe's phone, and hopefully by that point it'll be clearer how this information is being populated on the device.

MR. WHIFFIN: IOS is Apple's proprietary operating system available on iPhones.

MR. WHIFFIN: Fundamentally, the browser state.db tabs table is shown — hopefully I can show this on here — in the top here. The real database has many more fields, but these are the fields which are important for the demonstration — to just see the row ID, the timestamp that's recorded, the URL or the web address, and the title of the page. And the example at the side there, you can see there's the browser is open but there is no tab actually in focus at this time.

MR. WHIFFIN: Yes.

MR. WHIFFIN: It doesn't create a tab just by opening the application. But there may be tabs already open in the background when you start the application, and then you can tell it to create further tabs.

MR. WHIFFIN: Correct. You can have hundreds of tabs open.

MR. WHIFFIN: They stay open until you close them.

MR. WHIFFIN: You could use that tab for as long as you wanted, or create a new tab to do additional searches while maintaining the original tab in its current state.

MR. WHIFFIN: So, as I showed, there's a field in this table called timestamp — it's actually called last viewed timestamp. And I wanted to prove — or to demonstrate — what that timestamp means, how that timestamp gets populated, and how it's relevant or irrelevant to a case.

MR. WHIFFIN: Correct.

MR. WHIFFIN: That's correct. The URL is the address of the page that's being viewed.

MR. WHIFFIN: No, it will not.

MR. WHIFFIN: Correct. That's part of the demonstration and presentation. I'm sorry to interrupt. Okay. Um, so in this instance, at 10:00 a.m., which is shown in the top of the device there, we can see I visit firstpage.com as an example website. At that time, a row is created in the database that shows row ID 1 with the timestamp 10 a.m., when the page was opened. The URL and the title are relevant to the page that was visited — so firstpage.com. A minute later — excuse me — I now use the same tab to visit secondpage.com. What actually happens in the database at this point in time is the first record is updated with new information. So we continue to see row ID 1. We continue to see the timestamp that the tab was opened at 10:00 a.m.

MR. WHIFFIN: And we now see the URL and the title that are related to secondpage.com. So I've shown it here — the first one is red to show that's no longer a live record; it's been replaced by the new record underneath it in black. A minute later again, I can visit thirdpage.com. And at that point, the record is updated a further time. So we still see that it's row ID 1 — because no new rows are being created; we're just simply updating the existing rows. So we still have row ID 1. We still have 10 a.m. as the timestamp, and we have the URL and the title that show thirdpage.com instead.

MR. WHIFFIN: Yes, this is three different pages that have been visited within the same tab, and in the data it has three timestamps but they're all the same.

MR. WHIFFIN: This database is not monitoring web navigation events. It's purely monitoring the tab events. So when the tab's brought into focus or when the tab's created is the only timestamp that's relevant here.

MR. WHIFFIN: From a non-forensic point of view, if I was looking at this database in a regular database viewing tool, all I would see is the black record at the bottom. I wouldn't see the other two records because they've been essentially overwritten by the third record. If I was to use a forensic tool, though, then I would see all of these records because the forensic tool is designed to find the older versions of these records that have been replaced. So again, from a forensic point of view, I would see all of these records. I would see all the different URLs and I would see the same timestamp and the same row ID for all of them. This fundamentally changed in iOS 15.

MR. WHIFFIN: And I've tested this on multiple versions of iOS 15, 16, 17, and 18, including iOS 15.2.1, which is the same version of iOS installed on Jen McCabe's phone. In this case, the data is not written to the database immediately. So I've tried to show here that we have some in-memory variables — essentially a short-term memory that the device knows exist but aren't written to the database yet. So they're not written long-term. So in this case, if at 10 a.m. I go to firstpage.com, we see that the in-memory variable for timestamp, URL, and title are updated to show a 10 a.m. timestamp and the firstpage.com information. But you can see at the bottom I still have the browser state tabs table, and nothing has been written to that database at this time.

MR. WHIFFIN: The browser state.db is just the name of the database that Apple are using to monitor the tab activity on the device.

MR. WHIFFIN: There are hundreds or thousands of databases, depending what applications are installed on the device. Each database typically targets a different application or a different feature.

MR. WHIFFIN: It can leave on different databases, for sure.

MR. WHIFFIN: So again, to continue this example — if I now go to secondpage.com a minute later, we can see that now the in-memory variable is updated. So the timestamp still remains 10 a.m., the same as it did previously on iOS 14, but the URL and the title are updated to reflect the current web page that's being viewed. Again, nothing has been written to the browser state database. I can go to thirdpage.com. Again, we see the in-memory variables for the URL and the title are updated, but the timestamp still remains the time that this tab was brought into focus or created — not the time that the navigational event occurred.

MR. WHIFFIN: Still nothing's being written to the browser state database, and it's not until you actually close the tab that the information gets removed from the in-memory variables and written into the database. And at that point, the information written to the database is whatever was in the in-memory variable. So right now, all we have is a single record in the database that shows the 10 a.m. timestamp. That's when the tab was opened. And we have the thirdpage.com URL and title information, which is the most recent web page visited in that tab. It wouldn't matter whether I was looking at this data using a regular database tool or a forensic database tool. The only record that I will see is this particular record.

MR. WHIFFIN: There may be multiple versions of this record, but still would only show me this timestamp and this URL information, because this is the only information that was ever committed to the database. Okay, moving on from that, there were multiple databases or multiple data sources on Jen McCabe's phone that could be used to see what actually happened on the device at this time of day that was of interest. So the analysis I did looked at the browser state database that we've just described. The history database, which is tracking the navigational events. So every time you visit a website and the website fully loads, it gets written to the history database to say this URL was visited at this time.

MR. WHIFFIN: And that's the information that as a user you can see when you look at the internet history on your device — it will list all of the web pages that have been visited. com.apple.MobileSafari.plist is a property list file — essentially a list of keys and values that would describe various settings on the device, typically, but it also stores information such as the last searches that were conducted using the Safari search feature. And then finally here we've got knowledgeC.db, which is a massive database at the heart of iOS that stores lots of types of information. It can tell you what web page was actually on the screen at any given time. It can tell you when the backlight came on, when the backlight went off, when the device was locked or unlocked, the battery level.

MR. WHIFFIN: Lots of different types of information. But useful here for the web pages that were being viewed. So using the combination of all those sources, I could see that at 2:27:09 a.m. Safari was opened from the application library on the device. At 2:27 a.m., when Safari opened, there were already numerous tabs open in the background. The browser would show in the foreground whatever browser tab was open when Safari was previously minimized. In this case, we can see looking at knowledgeC.db that the web page that was being viewed was related to Hockomock Sports Friday's schedule scoreboard. At around 2:27, that tab would have been closed. Now we don't actually have a time the tab was closed, but based on other activity this timestamp can be inferred.

MR. WHIFFIN: Essentially when this tab was closed, a record is created in the browser state database that shows the timestamp 1:59:44 a.m. — that would have been when the tab took focus — and then the Hockomock Sports Friday schedule scoreboard URL. At 2:27:31, a browser switch occurred, and the last visited timestamp that's held in memory would have taken the time that this occurred. So at 2:27:31, this URL was PayPal. There was no navigational event listed in history. So this wasn't a page that was visited from a bookmark or from typing in a URL. It was whatever was currently shown in that tab when the tab was brought into focus. And we know that this exact URL was last visited at 7:40 a.m. on the 28th of January. This is evidenced in browser state and in knowledgeC.

MR. WHIFFIN: Around a second later, that tab gets closed and that record gets written to the database with a time of 2:27:31, because that's the time the tab was brought back into focus. It gets written with the URL and the title information related to PayPal. At 2:27:33, another tab is brought into focus from the background — this one related to Eastern Bank. Again, the last visited timestamp would be updated because this tab has now been brought into focus, causing the timestamp to change. We know that this particular website was visited at 8:02 on the 27th of January, and there are no new navigational events at this time. So we know it's just brought into focus and visible on screen according to knowledgeC and browser state databases. That tab gets closed and gets written to the database.

MR. WHIFFIN: This again is going to show — and I've just noticed there's a typo on here — the timestamp at the top is showing incorrectly. But essentially it's closed at around this time. And the Eastern Bank URL is written to the browser state database with the 2:27:33 timestamp. At 2:27:35, we see that there's a YouTube video shown on screen related to "It's Raining Men." This shows in knowledgeC. There's no new navigational event for it, but there's also no timestamp in the browser state database at this point. This is because this page, or rather this tab, is brought back into focus a second time. And when it gets brought into focus the second time, the timestamp that's attributed to it overrides the timestamp that would have been written at this point.

MR. WHIFFIN: Sounds convoluted, but essentially if you imagine that the in-memory timestamp here would have said 2:27:35 — but then there's another tab that's brought into focus related to Hockomock Sports at 2:27:36.

MR. WHIFFIN: Yes.

MR. WHIFFIN: Yes. The time that the tab was brought into focus or opened.

MR. WHIFFIN: If you imagine you could have five or six or however many tabs in the background — you select one of those tabs to view, it makes it full screen. That would be considered "in focus," and that would cause the timestamp to be updated.

MR. WHIFFIN: It would. It would update the timestamp.

MR. WHIFFIN: As long as Safari doesn't close, then the timestamp will remain the same. So if I just minimize Safari, put it into the background, and start to do other things on my phone, the timestamp won't get updated. If I completely close Safari or turn the phone off, when Safari reloads, then that tab does get a new timestamp when it opens up again.

MR. WHIFFIN: Okay. Um, yes, so at 2:27:36 we've got Hockomock Sports — "gallery: Canton girls basketball, important win at Mansfield" — is the page that is visible on screen. Again, we know that there's no navigational event at this time, so the page has not been loaded as a result of a bookmark or typing the URL in. It's just showing what was on screen previously. And we know that this page was previously viewed at 22:55 on the 27th of January. This tab gets closed and gets written to the database as well, and we see it's written with the timestamp 2:27:36 when the tab was brought into focus. And then we go back to the YouTube video tab. So at this point the timestamp that had been written there gets overwritten again with 2:27:38, and it shows the YouTube video is the active page on the screen.

MR. WHIFFIN: Around 2:27:39, that tab gets closed and the record is written to the database showing a timestamp of 2:27:38 when the tab took focus, and the YouTube video URL. Then we move to 2:27:40, which was the time of interest, and we see that a browser switch occurs, causing the last visited timestamp to take on the time of 2:27:40. This is the tab that was ultimately used to search "how long to die in cold," which is the query that started all of the confusion. At this point in time there are no navigational events recorded anywhere. All we see is that the web page that was brought into view is OzoneBasketball.com/teams. This web page was last visited at 14 minutes after midnight on the 26th of January. We know that this is on screen because it tells us that in knowledgeC.

MR. WHIFFIN: And we know that the time is 2:27:40 based on knowledgeC timestamps and based on the browser state database timestamp. At 2:27:42, there is a web navigation event. Whether this is loaded from a bookmark or whether it's typed in, I can't say, but a web navigation event occurs using the same tab that's just been loaded. And now the user is loading the web page HockomockSports.com/standings. This is logged in the history database that shows what web page is visited when, and it also shows in the knowledgeC database to show what web page is on screen at this time.

MR. WHIFFIN: Yes.

MR. WHIFFIN: Yes.

MR. WHIFFIN: So at 2:27:47 there's another web navigation event as the web page HockomockSports.com/schedules is loaded. Again this is evidenced in the history database to show that a navigation event occurred and completed, and in knowledgeC to show that this is the web page viewable on screen. At 2:27:53, there's a further web navigation event, where we're now viewing or loading the page HockomockSports.com/schedules/hockey. Again, this is evidenced in the history database and the knowledgeC database to show what page loaded and what page was visible on screen. At 2:27:58, there's a further navigational event for girls hockey, Franklin, 2021-2022. Again, this is logged as a navigational event in the history database and shown on screen according to the knowledgeC database.

MR. WHIFFIN: Correct, your honor.

MR. WHIFFIN: There is no tab switch event listed. We see the tab switch event occur at 2:27:40, and then we see lots of navigational events occur.

MR. WHIFFIN: Correct. If you remove it from focus, it's essentially going into the background, but it's still open — it's in its current state, just in the background — versus if you close it completely and have to reload it later on. So in this particular state, the timestamp doesn't get changed. The timestamp remains 2:27:40 as it was earlier. Safari is then not used again until 6:23:37, when it's opened from the background using the icon in the app library. At this point, when it loads up, the same page that was open when Safari was minimized is shown. So we still see HockomockSports.com/schedules/girls-hockey/Franklin/2021-2022. There's no navigational event at this point. So we know that it wasn't completely reloaded.

MR. WHIFFIN: It's just showing what was on screen previously, and it's evidenced in the knowledgeC database. At 6:23:49, there's a cache file created. The cache files relate to how long to digest food. Now, these particular cache files show up as suggestions in Safari. So, as you're typing in a query or a word or a URL, for example, Safari tries to take that information and make suggestions based on what it thinks you might be searching for. So if, for example, you were to type in "how long to die" with the word spelled just "di," Safari can mistake that for "how long to digest food" and it could present this information. And up until about 12 months ago, this is the information that was provided by Safari if you were to do this search.

MR. WHIFFIN: If you were to type in "how long to di," you would get the result that's shown at the top of this screen, with an image of somebody eating a plate of food. And this is the image that was cached onto Jen McCabe's phone at 6:23:49.

MR. WHIFFIN: Essentially downloaded now for use later. It will download it, it will save it in case it's required again. If it is, it doesn't need to download it — it's already there. If it's not required again, eventually it will be deleted.

MR. WHIFFIN: Yes. So, at this point in time, at 6:23:49 when it downloaded it, that's the first time that it's downloaded this image, and it stores it. If an hour later, for example, I did the same search a second time, it wouldn't need to redownload the image, because it's already in cache. So the creation time of this image shows that this is the first time this cache file was downloaded. A few seconds later, at 6:23:51, the blue button at the bottom of the keyboard is used to submit a search for the term [unintelligible — first search query]. This creates a specific URL in Safari, which is shown on screen here. So, google.com/search?[unintelligible — garbled URL encoding] — "client=Safari" is the important part of this string that tells us that it's a query made using Safari.

MR. WHIFFIN: This is different to if I visited Google, for example, and just typed in the search text box in Google — it wouldn't necessarily have this same structure of the URL. So we know that this is the query created by submitting a search using the search bar here and pressing the blue button at the bottom. We know that that search was conducted at 6:23:51 according to the information in MobileSafari.plist, and knowledgeC also shows that this page was visible. Importantly, there is no history record made that shows that a navigation actually occurred to this page — to this website. Several reasons why that might happen. One could be if the device was in private browsing mode.

MR. WHIFFIN: However, it can't have been in private browsing mode, because if it was, we wouldn't have the search recorded in the MobileSafari.plist either. So we know it wasn't in private browsing. It could have been deleted at some point after the fact. That would leave a gap in the numbering. Every time a record is written, it would be consistent numbers — 1, 2, 3, 4, 5, 6 — and to delete a number would leave a gap there. So you would see 1, 2, 4, 5, and that number will pretty much never be reused. So if you don't see a gap, then you can be confident that nothing was deleted, and there are no gaps on this device. The third reason, and the one that I believe is the reason why it wasn't recorded in the database, is that the page never completely loaded.

MR. WHIFFIN: If I go to a web page and cancel the navigation prior to it completing the load, it will never get written to the history database. At 6:24:18, there's a second search submitted using the same method — so, still using the Safari search bar — this time searching for "how long to die in cold." This is evidenced in the MobileSafari.plist. Again, there is no record made in the history database. That to me suggests that the page never successfully loaded. At 6:24:24, Safari is minimized again. It gets reopened at 10:33 a.m., again loaded from the app library and brought into focus. And at that point, the previous page is shown to the user. That previous page is related to the search "how long to die in cold."

MR. WHIFFIN: This is evidenced in knowledgeC to show that this is the page that's visible on screen, but there is still no history event that shows that the page completely loaded. And around that time — so around 10:33 — that tab would have been closed, resulting in the record being written to the browser state database with the timestamp 2:27:40, when that tab was originally brought into focus several hours earlier. But it shows the most recent URL information, which is the Google search for "how long to die in the cold." It doesn't have any of the other URL information that was visited during that time period.

MR. WHIFFIN: It doesn't have the previous Google search for [unintelligible — first search query], because all it records is the most recent URL that's visited alongside the original time that the tab took focus. Importantly, there is no title information. The title information is included within the page itself. So if you do a Google search, the title of the page that showed up would show "Google search" and then it would show the query that you typed in to search for. The fact that this doesn't have a title also suggests that the page never loaded. So again, it ties back to the fact that it's not written in the history database — we have no title — both indicative that the page never successfully loaded.

MR. WHIFFIN: It will always be whatever URL is visible in the tab at the time.

MR. WHIFFIN: Yes. So from a forensic examiner's point of view, and using forensic software, I can look at the database and see the records that have been deleted and recovered. There does become a time when you're unable to recover any more records and they're now just purely deleted and unable to get back. But at this point I was able to recover a good number of records. And these were the five that I thought it was important to focus on. For here you can see that three of them occur at 2:27. So at 2:27:36, 2:27:38, 2:27:40, and these are the web pages that we've just seen in the presentation. So Hockomock Sports, the YouTube video, how long to die in the cold, and then two additional pages for cantonma.org and Ozone Basketball.

MR. WHIFFIN: The way that we're able to recover these records forensically is because of how databases work. What I've tried to display here is that when you first create a record, in this case creating record 4025, a new page is created in the database. A page is simply a block of binary data that's organized in a way that can be understood by the database as a page of data, much like it would be a ledger with a list of records. So it creates frame 181 with page 2752 and a record 4025. What is a little bit different from if you were doing this manually is when you want to add a new record, or when you want to delete a record, or when you want to update a record, it has to create an entirely new page or an entirely new version of that page. So in this case, we see that frame 194 is also page 2752.

MR. WHIFFIN: It duplicates the record 4025 and adds the record 4026. From the database's point of view, at this time, frame 181 is now dead. Like, it won't be used for anything. And a regular database tool would only refer to the most recent version of that page. So, frame 194. Forensically, I can look back at all of these different versions of the page, and I can start to see differences. Not so important in this case when all that's happening is that you're adding information, but when you start to delete or edit records, being able to go backwards and see these previous pages, you can see the records that have been changed or deleted. So, as we're moving along all of these pages, each of these refer to a time when a new record was added. Every time a new record is added, a new frame is created.

MR. WHIFFIN: It duplicates the page from before and it adds the new record. I highlighted record 4028 in green across these three frames because this is the "how long to die in cold" record that is of interest. Moving forward again, we continue to see records being added, but particularly here at frame 430, record 4029 is deleted. 4029. If I go back a few slides, we can see 4029 is the cantonma.org families index web page. As far as I know, no relevance to anything related to this case. It just so happens this is the first record deleted from the browser state database. We don't have information that tells us at what time the record was deleted. But we're able to infer what time that record was deleted based on other records in this frame.

MR. WHIFFIN: So for example, we know that at the time that record 4029 was deleted, record 4031 already existed. Record 4031 has a timestamp of 6:29 on the 31st of January. Therefore, we can summarize that record 4029 had to be deleted at some point after 6:29 on the 31st of January. We see again record 4030 is deleted on frame 468. Again, we can look at what record was the most recently created on that frame at the point that that record was deleted. And that gives us information that suggests record 4030 had to have been deleted at some point after 8:35 on the 31st of January. We can continue to go along and continue to see records being added, edited, and deleted. But the record of interest, 4028, still exists even on frame 650. And in fact, it doesn't get deleted until frame 732.

MR. WHIFFIN: By the time the record related to "how long to die in the cold" is deleted, record 4037 already exists. Record 4037 was created after 22:07 on the 31st of January. Therefore, we know that the "how long to die in the cold" record was deleted at some point after 10 p.m. on the 31st of January. Taking all of those deleted records, those five deleted records, and the earliest time that they could have possibly been deleted, we see a spread throughout the 31st of January — a few quite early on at 6:29, 8:35, a couple at 9:20, 9:40, and then finally the one that we're interested in at 22:07. For the user to cause these to be deleted, if you wanted to do it selectively and select and delete one at a time, the record has to be available in the history database.

MR. WHIFFIN: As I said earlier, it wasn't ever in the history database because there'd be a gap. So this record could not have been deleted by the user selectively. That leaves options of deleting everything from the history. But if everything was deleted, we would have none of this information. And we do. And it also leaves the option of deleting everything from what's considered today and everything that's considered today and yesterday. And again, if either of those options were the case, we'd have much less information than what we have and we wouldn't see this staggering of timestamps that we see here where the information was deleted. Ultimately, I wasn't able to say what caused these deletions at these particular times. But I'm confident that it wasn't as a result of user interaction.

MR. WHIFFIN: That's something that was brought on on purpose.

MR. WHIFFIN: Yes.

MR. WHIFFIN: Yes.

MR. WHIFFIN: I believe it was. Yes.

MR. WHIFFIN: It wasn't. No. I went into the data, looked at the various different databases, different files that were in use, tested it across many different devices to make sure that my understanding and analysis of it was correct.

MR. WHIFFIN: If either of those searches had connected, the information would have been written into the history database. The fact that it wasn't in the history database strongly suggests it never completely loaded. And the fact that there is no title information on the browser state tab as well also suggests it never loaded.

MR. WHIFFIN: Yeah, they were deleted from the device.

MR. WHIFFIN: So again, I don't believe it's possible, given the situation and the information that's available, that it would have been possible for the user to delete it. I believe it was more than likely a system event that caused that, but I've not been able to replicate that system event.

MR. WHIFFIN: Yes.

MR. WHIFFIN: The way that forensic software typically works, certainly the way that Physical Analyzer works, is we design models for the data. So we know that an SMS application, for example, will always have a message body. It will always have a sender, a receiver, a time — that kind of thing. We always know that a web visit will have a URL, a title, and a visited timestamp. In this particular case, in the database, the timestamp is called "last visited timestamp," which is indicative — you would think — of the time that the web page was visited. So when that information was being modeled within the software, the timestamp that was within the database was used and it was called "last visited timestamp."

MR. WHIFFIN: Since the investigation that I did into this case, I requested that the forensic research team at Cellebrite revisit this data and confirm if there's confusion around it. Were my findings correct? Ultimately, there are times that that information can be correct. If, for example, you create a brand new tab, visit a website, and then close the tab immediately, then that timestamp would be indicative of the time that the URL was visited. But if you were to create a tab, use it for 3 hours and then close it, the timestamp would not be indicative. Also, if you were to bring an old tab into focus that you'd used several days earlier and then close that tab, again, you're going to get bad timestamp information.

MR. WHIFFIN: So ultimately, from Cellebrite's point of view, we remove the timestamp from that data to avoid confusion in the future.

MR. WHIFFIN: There were many —

MR. WHIFFIN: No. There were thousands of records deleted ultimately for various reasons that I can follow. That would be an inaccurate assertion. To say that that's the only record that was deleted is inaccurate.

MR. WHIFFIN: Correct.

MR. WHIFFIN: I wasn't as interested in internet data. I was more interested in location and health and anything else that could be useful.

MR. WHIFFIN: I was. Yes.

MR. WHIFFIN: Typically after midnight and before 6:00 a.m.

MR. WHIFFIN: It is. Yes.

MR. WHIFFIN: Multiple ways that it can be stored. Primarily there's a database called cache.sqlite — SQLite — and every time an application requests location data from the device, a feature called location services on iOS tries to calculate the device's location using a combination of technologies — GPS, Wi-Fi, cell tower, and Bluetooth — calculates the device's location and stores that into the database as a latitude, longitude, altitude, timestamp, accuracy radius information like that.

MR. WHIFFIN: Can you define "different types," please?

MR. WHIFFIN: Yes. So the application can specify how accurate it wants the data to be. So for example, if you're using a navigational application, you'd want high accuracy data. So the application would request high accuracy data from location services. Location services would then try to use GPS primarily to get location information, versus if you were using a weather app, for example, where you don't really need to know precise information. You just need to know the approximate town maybe that the user's at. So a weather application would ask for low accuracy information. And the device may be able to calculate the location based on cell tower information, for example. Both can be stored in the database with the accuracy information that's available.

MR. WHIFFIN: Yes, for sure. And Apple actually specifies in their documentation when they specify the various different accuracy levels — they have one for navigational purposes for map applications.

MR. WHIFFIN: How do you mean? Sorry.

MR. WHIFFIN: Yes, the information is typically provided with a range of meters. So you'll have a latitude/longitude coordinate and a number of meters that you have to draw around that location or point. And the device is somewhere within that circle. It could be as accurate as 2 or 5 meters. It could be as inaccurate as several miles depending on the technology that was used to get the data.

MR. WHIFFIN: I am. Yes.

MR. WHIFFIN: Waze is a navigational tool. So you can plot a route and it will try to direct you the best way, avoiding toll roads, avoiding accidents, that kind of thing.

MR. WHIFFIN: That would be the highest level of accuracy. So it would aim to get GPS quality information of around 5 meter accuracy.

MR. WHIFFIN: Getting GPS data is not always possible. If you're in a building, in a basement for example, you may not get that. But also it can be expensive to the device in terms of processing power, in terms of battery requirements. So if it can find location information cheaper by using Wi-Fi networks, for example, then it would prefer to do that — just a lot less resource intensive than using GPS all the time.

MR. WHIFFIN: Typically not. It may do for a short time as it's still kind of working through a backlog. But fundamentally, if there's no application open that's trying to use location services, then the location information that's being requested and recorded is far more sporadic. It's typically background applications that may be requiring location data.

MR. WHIFFIN: Yes.

MR. WHIFFIN: Yeah. So pretty much all iPhones for the last 10 years or so have Apple Health included. It monitors activity on the device such as steps taken, using various sensors inside the device, looking for motion which appears to be walking. It monitors altitude, so it knows whether you've gone up a flight of stairs, for example. It uses that information in concert with the steps taken, so it knows the difference between going in an elevator versus walking a flight of stairs. And all that kind of information is available to you as a user to essentially see how far you walked each day and to monitor your own health.

MR. WHIFFIN: No, it's purely just looking for motion of the gyroscopes which appears to match the pattern that it expects of somebody who's walking. It doesn't know whether you're in a straight line, walking in zigzag circles — just number of steps.

MR. WHIFFIN: It could register some, but typically it's relatively good at picking the difference between actually walking or throwing the phone around or shaking it.

MR. WHIFFIN: So there are two locations that health data is stored. Primarily a database called healthdb_secure, and that aggregates the information into periods of time. So you may have a 10-minute period where it says 100 steps were taken. It could be that the 100 steps were taken in the first 2 minutes and then virtually nothing was done for 8 minutes. But there's another database called cache.encrypted.db which is more granular. It's where the information is written originally prior to it being aggregated and moved into the bigger health database.

MR. WHIFFIN: Sorry, are we talking about steps taken or flights climbed?

MR. WHIFFIN: A flight climbed, according to Apple, is essentially an incline of 3 meters over 16 steps taken. So it wouldn't really matter whether it was walking up a flight of stairs, walking up a steep inclined hill, on an escalator, something like that. If there is movement that appears to be walking and an incline of 3 meters, then that would be considered a flight climb event.

MR. WHIFFIN: So I did test this a few months ago, driving in my vehicle. I was able to — if I just put a phone on my dock as I'm driving around — nothing was recorded. But I found that if I was actually holding the phone while driving at the same time, then the natural suspension of the vehicle plus the movement of my arm would be considered enough to be steps. And if that motion happened while I was driving up a hill, it would also result in a flight climb event. And the testing that I did consistently resulted in — I think it was nine flights of stairs climbed while I was driving up the same hill multiple times.

MR. WHIFFIN: Again, it's just a 3 meter incline required.

MR. WHIFFIN: 3 meters.

MR. WHIFFIN: Um, sorry, can you just repeat that please?

MR. WHIFFIN: Yes.

MR. WHIFFIN: Yes.

MR. WHIFFIN: No, it was just the steps and the flight climb that I was interested in.

MR. WHIFFIN: Uh, between midnight and 6:00 a.m. or 6:30 a.m.

MR. WHIFFIN: Yes.

MR. WHIFFIN: I did. Yes.

MR. WHIFFIN: I did.

MR. WHIFFIN: They are. Yes.

MR. WHIFFIN: Uh, yes. I've also looked at battery temperature information and at a feature called Doppler, which is monitoring for Face ID.

MR. WHIFFIN: Uh, there's a battery temperature sensor built inside the phone, within the battery. And it's essentially always checking for battery overheats or battery cooldowns to the point where performance will be affected and the device needs to power off to save itself being damaged. So that temperature information isn't recording ambient temperature. It's not interested in the temperature in the room, for example. It's purely interested in the battery temperature. But it is affected by ambient temperature. And I again did lots of testing by putting the phone into controlled temperature environments — so inside a freezer for a set amount of time — to monitor how the battery temperature would decrease over time given the environment it was in.

MR. WHIFFIN: Bringing it back into a warm environment and testing how long it takes to increase. Putting the device outside. I was in Calgary, where it's pretty cold in winter. So putting it outside — it was like 40°F, I think it calculates to — and the temperature of the environment had a big impact on the battery temperature that was recorded by the device.

MR. WHIFFIN: Yes, there wasn't a massive number of records, but there were records that I've included in my report.

MR. WHIFFIN: Uh, Face ID would be the process for the unlocking, and then the locking — pressing the button on the side would lock the device.

MR. WHIFFIN: Uh, yes. So this is the Doppler function that I found within a feature called unified logs. Essentially, whenever the device receives a phone call, or when you pick up the device, an iOS — sorry — an iPhone X or above is trying to find a face to use to unlock the device. If the camera is blocked, a record is made to say that it's within a pocket state. So if my phone's in my pocket, when somebody calls me, it tries to look for a face, it immediately recognizes that the camera's blocked, and it records pocket state. As soon as I take the phone out of my pocket or unblock the camera, it records a pocket state cleared event. So we know when the camera was covered up versus when it was uncovered, if at the time it was receiving a phone call or was being picked up.

MR. WHIFFIN: Uh, no. For example, if the device is already unlocked, then it won't make a recording to say that it was within a pocket state or a pocket state cleared. And if the device isn't blocked at all — so if I have the device on a desk in front of me, for example, and a call comes in — there'll be no record that says that it's in a pocket state or a pocket state cleared. It will only record a pocket state event if the camera's blocked, and it will only record a pocket state cleared event if the camera was blocked and now isn't.

MR. WHIFFIN: They'd all result in multiple readings of pocket state. The pocket state check is conducted more than once a second. I can't remember the exact number, but it's very frequent. And an average phone call, from the start of the ring to when the device essentially hangs up, somewhere in the region of 500 checks. So if you had 10 phone calls then you'll have 5,000 checks made that would all report pocket state.

MR. WHIFFIN: That was my goal. Yes.

MR. WHIFFIN: I did.

MR. WHIFFIN: I did.

MR. WHIFFIN: I did.

MR. WHIFFIN: Yes.

MR. WHIFFIN: I did.

MR. WHIFFIN: It does.

MR. WHIFFIN: I do.

MR. WHIFFIN: I believe it does.

MR. WHIFFIN: Uh, yes. This is the presentation that I created regarding John's phone.

MR. WHIFFIN: It does.

MR. WHIFFIN: Okay.

MR. WHIFFIN: Yes.

MR. WHIFFIN: Uh, so I start the presentation with location data. As I mentioned earlier, this comes from the cache.sqlite database, which is considered the most reliable location — or the most reliable file for location data on an iOS device. It stores information whenever location information is requested. That could be through user interaction with the device using something like Waze. It could be background activity, just depending on what applications the user has open, what settings the user has chosen. This constantly trying to find its location and recording it in this database, partly for the purposes of identifying frequent locations. At 12 minutes and 5 seconds after midnight, the device shows multiple location points at Washington Street around Forge Pond.

MR. WHIFFIN: What I tried to show here — there's a kind of a gold dot in the middle which would show the actual latitude/longitude information, and then the circle around it is what's considered the accuracy radius. The smaller the accuracy radius, obviously the more accurate the information is believed to be according to the device, but ultimately if the device is anywhere within that circle, then iOS would consider it correct — it considers it an accurate record.

MR. WHIFFIN: Uh, so this wasn't a single point in time. This was multiple records at around 12 minutes and 5 seconds. No application was actually in use at this time requesting location information, but the device for whatever reason recorded multiple records with various degrees of accuracy. Typically, you would see accuracy start quite low and get better over time — which you may have seen on your own device when you open up the map application and it may show your device, you know, close to where you are but not perfectly where you are, and then wait a few seconds and that information gets refined. Essentially, this is the same thing. So low accuracy would be a wider circle and higher accuracy would be a smaller circle.

MR. WHIFFIN: Correct.

MR. WHIFFIN: It is. Yeah. Depends on the device itself.

MR. WHIFFIN: Yes.

MR. WHIFFIN: Yes.

MR. WHIFFIN: Yeah. Uh, there were multiple records between that last time and what's shown on screen now at 19 minutes and 33 seconds, but all of the records were sporadic and low accuracy with values of 1,000 m or more. But around this time, around 19 minutes and 33 seconds after midnight, is when Waze was actually brought on screen. Waze starts to ask for high accuracy data. So we see the accuracy immediately start to improve. So again we see relatively low accuracy data to begin and then over the next few seconds it begins to refine itself until it gets down to a 5 m accuracy record as the device continues up here. We'll highlight that there's a cluster of records here as the device came to either a slow or a stop momentarily.

MR. WHIFFIN: Multiple records were created and then the device continued driving up Denim Street.

MR. WHIFFIN: Yes.

MR. WHIFFIN: That's in meters. So again the records that are shown at the bottom here are around 55 m. The records shown at the top are around 5 meters.

MR. WHIFFIN: Typically, yes, that would be the goal.

MR. WHIFFIN: The database, the cache.sqlite database also calculates the average speed between two data points and also the bearing or the direction of travel between those two points. So the average speed that's shown here on the left is approximately the average of all of the records that are shown on this map at the time. And each of these map points has a directional arrow that points in the direction that the database recorded the device was traveling in.

MR. WHIFFIN: Yes, based on the speed and the location and the timestamps you can determine whether the device is moving or stopped.

MR. WHIFFIN: Also important to point out here in terms of knowing how reliable this location information is, I typically look at something along the lines of does the location think it's accurate. In this case, 5 m. So, yes. Does it make sense? Like it's on the road, it's on the correct side of the road. So, again, it kind of makes sense. It fits the pattern of the road. The cadence and the speed are what you would expect for this road, like traveling at 20 to 30 miles an hour up here seems quite reasonable. So all of these factors taken together increase my confidence that this would be reliable location data.

MR. WHIFFIN: Moving to the next slide, between 20 minutes and 19 seconds and 21 minutes and 58 seconds after midnight, the device starts on the left side — uh, sorry, on the right side at Denim Street, drives up and turns left onto Maplecroft Road. Again, we see that all of these location points match the pattern of the road layout. They all have a consistent cadence, a consistent speed traveling at between 10 and 20 mph. And we see a cluster of records here, which is around a stop sign. So again, it indicates how reliable the data is because the location data that's recorded recognized the vehicle slow, come to a stop, and then continue after the stop sign.

MR. WHIFFIN: Yes. At the end of Maplecroft Road, the device turned left onto Oakdale Road and continued heading down there. Between 21 minutes and 59 seconds and 22 minutes and 53 seconds, the device continues down Oakdale Road. Again, all of these location points show with 5 meter accuracy. They show a consistent cadence, consistent pattern to the road and again we see a cluster where we see the device come to a slow or a stop for a stop sign. The device ultimately turns right onto Cedarcrest Road, I believe. And continues down there between 22 minutes and 54 seconds and 23 minutes and 57 seconds. Again as I've said before, all of these points 5 m accurate, they all conform to the road, cadence is good and again we see a cluster on approach to a stop sign.

MR. WHIFFIN: The device shows that it overshot Fairview Road and continued turning up Cedarcrest but came to a stop somewhere between 50 and 51. And at 23 minutes and 58 seconds, the device appears to have turned around, so potentially a three-point turn, in order to head back down Cedarcrest Road and turn right onto Fairview Road. Again, accuracy 5 m, good cadence, good conformity to the road. All appears to be reliable and make sense. Traveling at an average of 20 miles an hour.

MR. WHIFFIN: This is Fairview Road here. Yes. The next few slides replay that same data, but instead of showing multiple points on one graph or on one map, it's going to show one location point per slide. So at 24 minutes and 20 seconds, we see the device is already on Fairview Road. Accuracy of 5 meters, traveling at 14.8 mph and heading south. 24 minutes and 21 seconds, now at 16.2 mph, but it's still highly accurate information. 24 minutes and 22 seconds traveling at 18.3 mph. 24 minutes and 23 seconds traveling at 16.9. 24 minutes and 24 seconds after midnight, traveling at 16.9. 24 minutes and 25 seconds traveling at 16.6. 24 minutes 26 seconds traveling at 17. 24 minutes 27 seconds traveling at 15.9 mph.

MR. WHIFFIN: At 24 minutes 28 seconds traveling at 14.5 mph, at which point it's approximately outside number 34, around the driveway area. 24 minutes and 29 seconds traveling at 12.1 mph. 24 minutes and 30 seconds traveling at 11.5. 24 minutes and 31 seconds traveling at 10.4. 24 minutes and 32 seconds traveling at 8.9. 24 minutes and 33 seconds traveling at 7. 24 minutes 34 seconds traveling at 5.2. 24 minutes and 35 seconds traveling at 3.5. 24 minutes and 36 seconds traveling at 3.2 mph. And at 24 minutes 37 seconds traveling at 1.4 mph. Finally, the device comes to a complete stop at 24 minutes and 38 seconds. I'll say from the testing that I've done related to the speed, it may not be 100% accurate, but it's a very good indicator of the speed in general.

MR. WHIFFIN: So if it says it was traveling at 10 miles an hour, it would have been traveling somewhere between 9.5 and 10.5 on average.

MR. WHIFFIN: Yes.

MR. WHIFFIN: Yes. This is the first record that shows 0 miles per hour or 0 m/s. Prior to this, there was always a record that showed some level of speed.

MR. WHIFFIN: Yes.

MR. WHIFFIN: No. According to the location and the speed data from the device, by the time it was approximately at the driveway, the phone reports it was still traveling at around 15.9 mph.

MR. WHIFFIN: I have.

MR. WHIFFIN: I have.

MR. WHIFFIN: Yes.

MR. WHIFFIN: I believe very close.

MR. WHIFFIN: No.

MR. WHIFFIN: Between 24 minutes and 39 seconds and 25 minutes and 8 seconds, there were a cluster of more records all showing 5 m accuracy but no movement. Although the center point does move around a little bit. You could interpret this as movement, but because all of the radiuses or radii overlap, there's also a good chance that there's no movement that actually occurred here. This is just the device as it's trying to refine its location. At 25 minutes and 30 seconds, we see a relatively significant change where the accuracy drops to 34 m. We do see a course or a bearing that shows that the device reported it was heading west, but again this accuracy radius includes the previous locations anyway.

MR. WHIFFIN: So it's difficult to differentiate between actual movement based on this location data or just on the fact that the accuracy reduced, the center point shifted because of the accuracy change and therefore a bearing was attributed to it when it shouldn't have been.

MR. WHIFFIN: Correct.

MR. WHIFFIN: No. Waze has been closed at this point for about 40 or 50 seconds.

MR. WHIFFIN: About 40 or 50 seconds.

MR. WHIFFIN: Waze application anymore? No — the location data never came from the Waze application. Waze was requesting location data. iOS is responding to that request and, as part of that response, would write the information to its database. Waze itself records very little location data.

MR. WHIFFIN: Correct.

MR. WHIFFIN: Yes.

MR. WHIFFIN: It doesn't. No. The center point is purely an indication of where you need to draw the center in order to draw the radius. If we didn't have a center point, how would you know where to draw this circle? And so the phone could be anywhere in that circle.

MR. WHIFFIN: It could.

MR. WHIFFIN: It could.

MR. WHIFFIN: It could.

MR. WHIFFIN: Between 25 minutes and 31 seconds and 25 minutes and 36 seconds, there's an additional cluster of location data, ranging between 61 m accuracy and 17 m accuracy. All of them roughly centered on the same point approximately. And all of the accuracy radii cover the same area — there's so much overlap in these records that the device is essentially anywhere within the smaller circle. Between 27 minutes and 35 seconds and 38 minutes and 15 seconds, there were approximately 50 low-accuracy records. Again, the device wasn't being used to ask for location data. This is completely passive and resulting in some pretty poor location data.

MR. WHIFFIN: I've highlighted with the red arrow where 34 Fairview Road is, and we can see — although a lot of these location data do overlap with that point — there is location information here that doesn't. At 38 minutes and 16 seconds, the accuracy improves again — now 18 meters accurate — but continues to show approximately the same location that we saw 10 or 15 minutes earlier, around the flag pole area. 38 minutes and 17 seconds — same general area, slightly higher accuracy, down to 14 m. 38 minutes and 18 seconds — accuracy increased to 12 meters, shifted slightly. Now the flag pole area is essentially at the lower side of this circle. Obviously, the top side of the circle now includes a part of 34 Fairview.

MR. WHIFFIN: Not necessarily. Typically you could assume it has, but when we're already talking about accuracies of 12, 13, 14 m, it starts to become a little bit harder to determine how accurate this data is. So at this point in time, it could be anywhere within this circle, and the movement of the center point could just be the result of refinement of the device or environmental conditions that suddenly change. If the weather changes, it could cause the device to slightly miscalculate, or to calculate differently.

MR. WHIFFIN: It definitely has the potential to. Yes.

MR. WHIFFIN: That could also affect it. Yes.

MR. WHIFFIN: That could affect it.

MR. WHIFFIN: It could.

MR. WHIFFIN: At 38 minutes and 20 seconds, again refining information more — we've got an 8 m accurate radius, still focusing primarily on the front yard towards the left side. And then accuracy of 7 m at 38 minutes and 21 seconds, again showing that same general area. Between 40 minutes and 22 seconds and 59 minutes and 29 seconds, accuracy drops off again and we see some fairly wild records that don't cover the area at all. But we also see some more accurate records showing, again, where the red arrow points at Fairview Road. Those records are highlighted here — just between 40 minutes and 22 seconds and 59 minutes and 29 seconds — only showing records of 25 meter accuracy or better. And again, it kind of focuses on that flag pole area. Between 1:00 a.m.

MR. WHIFFIN: and 2:00 a.m., only looking at location information which is 25 m accurate or better — again, it kind of focuses around the front yard area. Although some of these accuracies are still rather large and could put the device inside 34, on the opposite side of the street, or towards 32. Between 2 a.m. and 3:00 a.m., fairly similar story — most of these points are centered around that same location at the front yard. Similarly between 3:00 and 4:00 a.m., between 4 and 5, between 5 and 6. And in fact, if I take all of the location data between 25 minutes after midnight until 6:00 a.m., only looking at the records that report 10 m accuracy or better, then typically they all focus around that same location at the front of the yard, nearish to where the flag pole can be found.

MR. WHIFFIN: Yes.

MR. WHIFFIN: Yes. So each of those center dots is the center of a 10 m accurate or better location record. I chose to not show the accuracy radius circle on this image just purely because it makes it hard to see when you've got all these intersecting lines. But ultimately, if you were to draw a 10 meter radius around all of these points, they would all fall within the large red circle that's shown.

MR. WHIFFIN: Correct.

MR. WHIFFIN: No. This circle only includes 10 meter accuracy or better.

MR. WHIFFIN: It could indicate movement. It could indicate refinement.

MR. WHIFFIN: It's impossible to tell at this level of detail.

MR. WHIFFIN: I believe it is. Yes.

MR. WHIFFIN: There is.

MR. WHIFFIN: It's Apple Health data. Yes.

MR. WHIFFIN: No. It's the same Apple Health data recording on the phone or the watch. The only difference is the sensors being used to do that monitoring. So if you're just using the phone, obviously you're only using the sensors in the phone. It's limited to steps walked and to altitude climbed. If you're wearing a watch, it can also do those things, but it can also add things like blood pressure monitoring and things like that.

MR. WHIFFIN: It doesn't. No.

MR. WHIFFIN: It is.

MR. WHIFFIN: Correct.

MR. WHIFFIN: Yes. Unless you actively turn the feature off, it will by default try to track movement.

MR. WHIFFIN: No. There's an application for Apple Health and then the settings are quite obvious in the settings screen.

MR. WHIFFIN: Correct.

MR. WHIFFIN: Yeah, I started again at around midnight and looked at the health data up until 6:30 a.m. on the 29th.

MR. WHIFFIN: It can be. Yes.

MR. WHIFFIN: It can determine whether it's working properly. It can determine an average kind of walking speed, for example, of a person, the average gait that the person may walk with.

MR. WHIFFIN: It would. The phone itself doesn't care who's carrying it. It just looks for movement.

MR. WHIFFIN: Correct.

MR. WHIFFIN: It doesn't. No.

MR. WHIFFIN: Yes, please. So the two sources that I got the Apple Health data from were a database called healthdb_secure.sqlite. As I said earlier, this is the typical database that's used to store long-term information about the health activity that's been recorded. So this database can have years worth of steps taken, flights climbed, and any other kind of health data that's been recorded. The downside to that is that the information is aggregated. So you see chunks of time and multiple activities can happen within those chunks of time. The cache encrypted C .SQLite database is much more temporary but is much more granular.

MR. WHIFFIN: So we can see exact times that flights were climbed, for example, or at least you can see the exact time that the flight climb was recorded to the device, and then that information is aggregated into the larger chunk of time. So again we might see within the cache encrypted C individual flight climb events that occurred, for example, 30 seconds apart. But by the time that information is written to the healthdb_secure, you're now looking at a 10-minute time period with three flight climb events as opposed to three individual flight climb events with individual timestamps. Typically that source is not used because the data is not stored there for very long. The information I found on John's phone was essentially these five records.

MR. WHIFFIN: So between 12:11:09 and 12:21:05, there were 170 steps recorded by the device.

MR. WHIFFIN: The location data that I showed to begin with on Washington Street was around 12 minutes after midnight. So the presumption is that's where the location was at that time, and then at 12:21:05 the device had already started using Waze. It was already driving along [unintelligible] or had turned onto [unintelligible].

MR. WHIFFIN: It was approximately 12:19:30.

MR. WHIFFIN: Again we see at 12:21:10 until 12:24:22 there are 80 steps recorded. And again if you compare this to the location data, we know that the device was in a vehicle at this time. Between 12:22:14 and 12:24:37, we have three flight climb events that are aggregated into that time period. And again the location data shows that the device was traveling in a vehicle at that time.

MR. WHIFFIN: Correct.

MR. WHIFFIN: Yes, the location data shows it was in the car at the time. And my next few slides will demonstrate why we're still recording a flight climb event while it was in a vehicle.

MR. WHIFFIN: Yes.

MR. WHIFFIN: Essentially, yeah. It takes the timestamps from the cache encrypted C, looks at when the first step occurred, looks at when the last step occurred, and aggregates the times based on that. So 12:32:16 would be the last steps taken for that cell phone.

MR. WHIFFIN: It can't. No. It's just purely registered what it thinks are 36 steps.

MR. WHIFFIN: It could have been a straight line.

MR. WHIFFIN: It could have been.

MR. WHIFFIN: Yes. Jumping, if they were jumping forward.

MR. WHIFFIN: There were no more steps or flight climb or any other health activity recorded during that time.

MR. WHIFFIN: I presume that the device was moving at that time, but I don't know the details of who.

MR. WHIFFIN: Regarding the flight climb events, looking at the cache encrypted C database, I was able to find more granular, accurate timestamps for these records. And I showed those timestamps on this map at the position that the device was according to the location data at the time.

MR. WHIFFIN: Correct.

MR. WHIFFIN: Correct.

MR. WHIFFIN: So we have the first record at 12:22:17 — a flight climb event was recorded. I've highlighted that with a red line, and that equates to the red line that shows underneath the timestamp where the device was at that time. The second record is 12:22:32, shown with a green line which shows over here. And then finally 12:24:37 after midnight shows with an orange line down here outside 34 Fairview. I'd like to point out that health activity events are recorded upon the event completion. The device doesn't know that you're about to walk up some stairs. It doesn't know that you're halfway up some stairs. It has to wait until you've reached the top in order to detect that an altitude change has occurred. So that change only gets written to the database once the flight climb has ended.

MR. WHIFFIN: I tested approximately eight different phones, different models, different versions of iOS, and found that on average there was a time difference between 15 and 50 seconds between when I physically stopped walking up a flight of stairs and when the record was made. So it's just based on the time that the device takes to pull the altitude, detect that an altitude difference has occurred, and then write the data to the database. So then I took that average data between 15 and 50 seconds and plotted it onto this graph, which also plots the altitude of the device over time. So the red line here shows the time according to the cache encrypted C database where the first flight climb event was recorded at 12:22:17.

MR. WHIFFIN: Working back 15 seconds from that to say that, with the gap that I know exists between the flight climb ending and when the record is recorded, the flight climb event is presumed to have occurred within this red gradient area. The altitude information on the device shows that between those times the altitude increase from around 41 m to around 45 m. You may recall earlier I said that it's a 3 m incline that Apple considers a flight climb event. Therefore the incline that occurred within this red gradient is sufficient to trip a flight climb event. When we look at the second record at 22 minutes and 32 seconds, this is shown on this chart as a green line. And again working back 15 seconds and beyond to allow for the tolerance we see the green gradient area.

MR. WHIFFIN: This shows an altitude change of around 45 m to 48 m. Again, that would be sufficient for a flight climb event to be recorded because we have 3 m incline change. We then don't see an incline change for a while. All we see is the device going downhill until we get the record right at the end there at 24 minutes and 37 seconds. And again working back around 15 seconds to the orange gradient we see an increase from around 25 to 28-29 meters. Again, that would be sufficient to cause a flight climb event to be recorded.

MR. WHIFFIN: Okay. I then compared that information to a topography website from the area according to topography website data and plotted that out. Here we see the red circle now is related to the first flight climb, the green circle to the second flight climb, and the orange circle to the third flight climb. The gradients that we see here are the same gradients that were shown on the previous graph. So the presumption is that within this red gradient is where the flight climb event occurred. Within the green gradient here is where the second flight climb event occurred. And within the orange gradient here is where the third flight climb event occurred. The white circles show the altitude of that particular location according to the topography website.

MR. WHIFFIN: So again we see that for the red gradient there's an increase from 43 to 47 m. Between the green gradient and the green number two, again we're going from around 47 to 50 m. And then with the orange gradient at the bottom, we've gone from around 26 to 28 m. So, fairly consistent with the data that was recorded on the device in terms of altitude information, and I would suggest is the reason that these flight climb events occurred.

MR. WHIFFIN: It was.

MR. WHIFFIN: Appeared to be still traveling in a car at 12:22.

MR. WHIFFIN: It was. Yes.

MR. WHIFFIN: It does.

MR. WHIFFIN: Correct.

MR. WHIFFIN: If I remember correctly, Waze had closed about 5 or 10 seconds earlier.

MR. WHIFFIN: Based on the location data, the health data and the research that I did and the testing, I believe it is more likely that the device was in a vehicle traveling on a road going up an incline versus the location data being incorrect and the person walking up physical stairs.

MR. WHIFFIN: Okay. So I'll address the idea of three clocks, which I believe was brought up previously.

MR. WHIFFIN: That is kind of covered in the next slide anyway.

MR. WHIFFIN: Yes. Essentially there is one clock on an iPhone. It's the clock that you see — it's shown in the top corner and all activity is related to that particular time. So when you receive a text message, the time that's shown in the database is related to the time that you can see on the phone. When you do health activity it's related to the time that you see in the top corner of the phone. Everything is related to that time. The difference is within the current power log databases — it's a subset of files stored on iOS devices. They use what's called a monotonic clock, but it's not a clock that can actually be trusted to see when events occurred. It's the way that the device records time. It's essentially a counter that's just counting seconds since the device was reset, basically.

MR. WHIFFIN: And I'm sure most people can recall a time where you would set a clock on a digital device, come back to it 3 or 4 months later and the clock's now not quite as accurate as it was when you left it. Time starts to drift. It might drift forward and be faster. It might drift slower and be further behind. That essentially happens with the monotonic clock as well. So you have to take the values that the monotonic clock provides and add or subtract different values which are essentially offsets in order to get the accurate time. And that's what I'll be displaying in this slide here. The confusion with the idea of three clocks I believe comes from the way that Magnet AXIOM displays power log data.

MR. WHIFFIN: They show a monotonic date and time, a baseband date and time and a display date and time within the power log records. As an examiner, it's really good to see this data and understand how the tool is determining these values. As an examiner, it would be really bad to look at these values and think that they are accurate timestamps at face value because they aren't. And I'll start to talk through how this information works. So the other thing that Axiom shows as well as the monotonic, baseband and display times is they show the location where this information came from. In this case we have two tables. One is called PL springboard agent event forward sblock and that is what this table is here. And you can see we've got an ID number, a timestamp, and a value of locked.

MR. WHIFFIN: We also show a second table that's involved called PL storage operator event forward time offset. And that's this table at the bottom here. So again, we see there's an ID, a timestamp, baseband, kernel, and system values. These values all need to be read together in order to make sense of the data. So for example, if I take the timestamp that's shown here, the 1643 33687 number, if you treat that as number of seconds since the 1st of January 1970, it's what we call a Unix epoch. That will get you the timestamp of 29th of January 2022 at midnight, 21 minutes and 27 seconds, once you account for the UTC minus 5 offset. And you'll see that that is the same timestamp that Axiom shows here as the monotonic time, 12:21:27.

MR. WHIFFIN: What we need to then do is take that monotonic time and add it to the baseband value that we see in the time offset table. So now we have a value of 1643 36 87.14954 and we add minus 183 — whatever this number is here — to get this value. If we treat this value as number of seconds since the 1st of January 1970, then we get a time of 18 minutes and 23 seconds past midnight on January 29th, which is also the time that we show here as the baseband time. Finally, we can take the monotonic time and add the minus 181 seconds shown in the system to get this value which equates to 18 minutes and 25 seconds past midnight on the 29th of January which is the same as the display time up here.

MR. WHIFFIN: So all this is essentially doing is saying that the counter that is built into the iPhone is registered at the time that we see in the top — the monotonic time. This is not necessarily the time that the event happened. You have to offset it with this value here in order to get the actual time that this happened. My own personal phone when I was doing this testing, the time difference between the monotonic time and when something actually happened was over two weeks. There was a massive difference because my phone has been drifting so far since I originally bought and set up that phone. And again, when I was testing this, I can turn the flashlight on, turn the flashlight off. Both of those activities are recorded in the power log database.

MR. WHIFFIN: If I just look at the monotonic time, it's off by over two weeks. If I do this process to calculate the correct offset, it shows exactly when I turned that flashlight on and when I turned that flashlight off. The calculation is imperative. Without the calculation, these timestamps are irrelevant. And all Axiom is doing here is they're showing you the values that they use in order to calculate the final value. It doesn't mean that you can take the monotonic timestamp and read anything into it. It's completely irrelevant on its own.

MR. WHIFFIN: It would be if we were discussing power log data. Power log data only really encompasses things like battery level, the time and date that it's plugged in, button presses, camera usage, things like that. It doesn't account for location data. It doesn't account for Apple health data. They both work on the system time and they both work on the same system time. So they're always going to be aligned.

MR. WHIFFIN: They'd be consistent with each other. So to summarize, there's only really one clock that's in use on an iPhone for recording. The only difference is the monotonic time which is how power logs record information. But you need to offset the times to figure out when that activity actually happened. And that you only have to offset those times for power log data. Not for health, not for location, not for messages or photographs or any other activity like that. Purely power log data.

MR. WHIFFIN: Yes, the next one is battery temperature.

MR. WHIFFIN: So again, we have a temperature sensor built in within the phone monitoring for if the battery temperature increases too high and becomes a danger or if the temperature gets too low and becomes an issue. So it constantly monitors the temperature of the battery and records that information in the knowledgeC database.

MR. WHIFFIN: I did. Yes. Throughout the evening of the 28th of January and then the morning of the 29th.

MR. WHIFFIN: Apparently not like that. There we go.

MR. WHIFFIN: So on the evening of the 28th, see an average temperature of around mid-80 degree Fahrenheit. I've got no understanding of where the device was at this time — whether it was in a pocket, on a surface, whether it was in use or not. But I just wanted to get an average idea of temperatures of the device. By 13 minutes after midnight, we're still at 82 Fahrenheit. At 22 minutes after midnight, we know from the location data that the device was currently in a car. And we see the temperature has dropped to 77 Fahrenheit. By 37 minutes after midnight, we now know the device is already at Fairview. It's been at Fairview for approximately 12 minutes. And the temperature has continued to drop. It's now 72 Fahrenheit.

MR. WHIFFIN: That's after.

MR. WHIFFIN: 45 minutes past, the temperature has dropped to 66 Fahrenheit. At 53 minutes past, it's dropped to 61 Fahrenheit. At 7 minutes after 1, it's dropped to 55 Fahrenheit. At 1:36, it's dropped to 50. And then we have a large gap in the data, with the next record being made at 6 minutes after 6:00 a.m. when the temperature is 43 Fahrenheit.

MR. WHIFFIN: I don't know accurately, no.

MR. WHIFFIN: Yeah, correct. This is the coldest temperature recorded.

MR. WHIFFIN: I don't know.

MR. WHIFFIN: And then as of that point in time, from 6:35, we start to see an increase in temperature to 43 Fahrenheit. At 6:40 it's up to 50 Fahrenheit. At 6:48, up to 55 Fahrenheit. And at 6:56, up to 61 Fahrenheit. And then also plotted this out onto a graph just for visualization. Again, we can see on the evening of the 28th the temperature is relatively consistent. It starts to drop as we know the phone is traveling in a car, and by the time it arrives at Fairview we only see it drop until 1:36 a.m. We see a relatively modest drop over the next few hours but no records recorded.

MR. WHIFFIN: We see the final drop at 6:14 and then we see an increase, but there are no increases that occur prior to 6:14 that would suggest that the phone went from a cold environment to a warm environment or had extensive usage between 1:36 a.m. and 6:06 a.m.

MR. WHIFFIN: No, there's no records related to battery temperature at all for that time.

MR. WHIFFIN: Yes, I was looking at device usage.

MR. WHIFFIN: Information about when the user unlocks the phone, what applications they're using, what they're using the device for, and when they lock the phone again.

MR. WHIFFIN: Everything that I was looking at was related to physical interaction and manipulation of the device by a user.

MR. WHIFFIN: So the three sources of data that I used for this were the knowledgeC database I mentioned earlier, that logs lots of different activity including device unlocks, device locks, applications that are on screen. The current power log which I mentioned, which can track button presses — so specifically when the lock button is pressed, and the times that I display have been offset appropriately. And unified logs, which is essentially a list of almost everything that's happening on that phone for a short amount of time. But it would be used, for example, if you had a problem with your device and took it back to Apple because it was crashing all the time — they could look at the unified logs and figure out what's causing these crashes to occur. So, really granular.

MR. WHIFFIN: We see that at 12 minutes and 52 seconds after midnight, the device is unlocked using biometric Face ID. The SMS application is on screen for about 5 seconds before it's closed, and then the user presses the lock button at the side of the device to lock the phone. At 13 minutes and 54 seconds, biometric Face ID is used again and the SMS application is opened. And at 14 minutes and 29 seconds, the lock button is pressed again, causing the device to lock. 15 minutes and 46 seconds, the device is unlocked using Face ID. The SMS application is already on screen because that's the application that was on screen when the device was locked. And the device is locked again at 16:03. At 17 minutes and 59 seconds, the device is unlocked again using Face ID.

MR. WHIFFIN: The SMS application is still on screen from before, and at 18 minutes and 12 seconds the lock button is pressed causing the device to lock. At 18 minutes and 25 seconds the device is unlocked using Face ID. The SMS application is already on screen from the previous usage, and at 18:31 the SMS application is closed. At 18:34, the phone application is opened by the user actively pressing on the phone icon on the home screen. At 18:36, they're now in a call and this causes a different screen on the phone. And at 19:23, that phone call ends. At 19:29, the Waze application is opened by the user pressing on the icon on the home screen. And that's open for approximately 5 minutes, closing at 24 minutes and 26 seconds.

MR. WHIFFIN: 2 seconds later, at 24 minutes and 28 seconds, the device is locked by the user pressing the lock button on the side of the phone. At 24 minutes and 59 seconds, the device is unlocked using Face ID. The SMS application is opened using the icon on the home screen. And at 25 minutes and 9 seconds, the lock button is pressed by the user to lock the device. At 27 minutes and 45 seconds, the device is unlocked using Face ID. The SMS application is already on screen. And at 27 minutes and 50 seconds, the device is locked using the lock button. 29 minutes and 52 seconds, device is unlocked using Face ID. SMS application is already on screen from the previous usage, and at 29 minutes and 53 seconds the lock button is pressed to lock the device.

MR. WHIFFIN: 32 minutes and 4 seconds, the device is unlocked using Face ID. SMS application is already on screen from the previous use, and at 32 minutes and 9 seconds the lock button is pressed by the user. And that is the final interaction with the device. It's the final unlock of the device using Face ID, and it's the final logged button press on the device as well to lock the device. So, the final