Ian Whiffin — Direct

MR. WHIFFIN: Good afternoon.

MR. WHIFFIN: Thank you.

MR. WHIFFIN: Yes. It's Ian Whiffin. So I-A-N, W-H-I-F-F-I-N.

MR. WHIFFIN: I'm currently the coding product manager at Cellebrite.

MR. WHIFFIN: Cellebrite is one of the world leaders in mobile forensics software.

MR. WHIFFIN: Yes. So forensic software is used to gain access to people's devices, cell phones, primarily to extract that data and to allow examiners to pass and decode that data to make sense of it in a more user-friendly way so that a report can be created for investigators.

MR. WHIFFIN: Okay. I didn't get a degree. I'm originally from the UK, where I did qualifications in computing, the Higher National Certificate in computing, and then joined the police in 2004.

MR. WHIFFIN: That was response work. So South Yorkshire Police as a response officer.

MR. WHIFFIN: In 2009, I immigrated to Canada, where I was able to continue policing with the Calgary Police Service, where I spent approximately four, five years, again, working patrol before moving to the digital forensics team of Calgary Police.

MR. WHIFFIN: So once I had made it into the digital forensics, I was sent to Ottawa for three weeks to do a foundational computer forensics course covering all manner of digital forensics to begin with. Throughout my eight years with Calgary Police, I did constant courses each year to keep information updated, including a two-week course again at the Canadian Police College in Ottawa, specifically about cell phone forensics. And then also during that time, additional courses for extracting data, for interpreting Internet artifacts or any other kind of information found on a phone or computer.

MR. WHIFFIN: In 2020, I left Calgary Police Service and began working at Cellebrite as the senior digital intelligence expert, where I would use my knowledge of the forensic community to assist the developers with creating and maintaining a program that examiners would want to use. And finally, about two years ago, I moved to the decoding product manager position.

MR. WHIFFIN: Yep. So right now, in the position I'm in, again, I use my knowledge of the digital forensics landscape in the community. I talk with users about their daily challenges, what applications are causing them problems, what they need to get access to, what they need to understand, and I take that information, create a priority list, and then determine, with our developers, what we will tackle, how we will tackle it, and how it will appear to the end user.

MR. WHIFFIN: No specific certifications. I've done the Cellebrite coursework since joining Cellebrite, but other than the -- the two, sorry, the three-week course in Ottawa and then again, the two-week course in Ottawa. I don't have the SANS training, or any of that kind of training certifications.

MR. WHIFFIN: Sorry. Could you rephrase that?

MR. WHIFFIN: Yes. So since working as an examiner, I identified that there were times that I needed to pass artifacts from applications that the main vendors didn't support. In response to that, I would do my own research. That research turned into a selection of digital forensics tools, and I created a website for myself to share that research, to share those tools with the community. And directly related to that, I have published articles related to accessing data on phones, related to SQL databases, related to various other artifacts, primarily locations.

MR. WHIFFIN: Yes, related to digital forensics, I've testified approximately 20 times mainly in Canada, but also once in Michigan, once in Australia, once in the UK.

MR. WHIFFIN: So the product is used globally. There are a slight number of countries that we don't tech support to, but generally, if a police service is interested in digital forensics, then they're using at least some of our tools. We operate a -- an email address which is open to any user called "stump us", and the idea is that users, if they come across an artifact that they can't explain, they can email to myself and some of my colleagues, and we can research that artifact, and we can try and give them an answer as to say why the artifact is there and how it should be interpreted.

MR. WHIFFIN: Yeah, so I would refer to an artifact as essentially any piece of data which I've recovered from the phone which is of interest. It could be a web history visit. It could be a text message. It could be a photograph, any piece of information.

MR. WHIFFIN: Eventually, yes. Initially, I was contacted by a member of Cellebrite.

MR. WHIFFIN: My understanding was there was an artifact found on a device, and people were looking for an explanation as to how this particular time stamp was relevant to the case.

MR. WHIFFIN: So the original question is just basically how can we explain this 227 time stamp. I spoke to my colleague and requested if he could contact the investigators and any information that they could share about where this particular time stamp was found so that I could investigate it. I was advised at that time that the case had already been uploaded to our own support network, so the full extraction of the device in question was already in Cellebrite's possession, and I was able to access it from there and start to examine what the issue was that was causing confusion.

MR. WHIFFIN: Yeah. So the issue as I was led to believe, is there was a time stamp for a web history artifact of 2:27 and 40 seconds a.m. local time, which would be UTC five, and it didn't make sense to the investigators. And the question was, is there any other interpretation for what this time stamp could mean.

MR. WHIFFIN: Correct.

MR. WHIFFIN: Yeah, several weeks later, so probably around December time last year, I was contacted by a police investigator in Austria with a very similar question, but related to obviously a different Internet search. And about a week later, the defense expert in the same case also contacted me, asking the same question. The defense expert in that case was able to provide the database, and I was able to provide the answer.

MR. WHIFFIN: So I did work with the full extraction, but my interest was focused on just the web history artifacts.

MR. WHIFFIN: So the 2:27:40 time stamp was correct insofar as that is the time that is shown within the database. It was indeed a deleted record, but the interesting thing was why the time stamp said 2:27:40. And I did some testing on this and discovered the reason why 2:27:40 was actually listed in the database, even though that's not the time, in my opinion, that the search was conducted.

MR. WHIFFIN: There's plenty of other evidence on that extraction that shows what activity was occurring at 2:27:40, and there's plenty of evidence later on in the day that shows that that particular search was conducted at 6:23 I believe 51 seconds, and then at a similar search at 6:24 and 18 seconds, I believe.

MR. WHIFFIN: Yes.

MR. WHIFFIN: I do, yes.

MR. WHIFFIN: This was the Internet history, the history.db database table, showing activity from the morning of the 29th of January, 2022.

MR. WHIFFIN: I do, yes.

MR. WHIFFIN: Okay, of course. So this was a table I created based on the data from the phone. The first column shows the local time of the record that was written to the history database. This is a database which is tracking all web pages which are loaded as you use them. The second column starts with the URL, so the Uniform Resource Locator, so what you would type in, or how the browser knows which website you want to visit. The title is part of the website which is loaded. One of the top attributes of the website will load the title. Visit count relates to an internal counter within Safari, which just tracks how many times a particular website is visited in order to make suggestions to you down the road. And then finally, the last column shows the source of this information. So history.db is the name of the database. History underscore visits is the name of the table, and then the number is the unique identifier which is assigned to that particular record in consecutive order. So every time you add a new record, that number will increase by one.

MR. WHIFFIN: That's my understanding, yes.

MR. WHIFFIN: Correct.

MR. WHIFFIN: An extraction in this case, all of the files and folders have been extracted from the device, saved on a computer in a zip file container. So essentially, in a way that is as close to the original from the device as possible.

MR. WHIFFIN: It's decoding product manager at the moment.

MR. WHIFFIN: So once the extractions been extracted, and we have the zip file, then Physical Analyzer is the tool that Cellebrite creates to allow examiners to look at that extracted data in a meaningful way. And my role is somewhat shaping how examiners will see that data when they open up Physical Analyzer and look at the extracted data.

MR. WHIFFIN: Again, so after being an examiner for ten or eleven years, I've got that kind of understanding of how examiners work, being someone who also writes my own software and does my own research, then I can kind of cross that void that usually exists between developers and examiners and help both parties try to come to a meaningful conclusion.

MR. WHIFFIN: Yes, so the lower two records which are highlighted in green, are two records which occurred at 2:27 and 42 seconds local time, so two seconds after the Google search had allegedly been made. And then the second record is five seconds after that at 2:27:47 seconds. Both those URLs relate to a website of hockomocksports.com.

MR. WHIFFIN: So every SQLite database will -- will assign a unique, contiguous identifier number. So again, the very first record created will be given a record ID of one, second record will be two, and so on and so forth. Those numbers are never reused. So if I was to delete record three, that record number will never be reused, and I can see that there's a gap and deleted data in that database.

MR. WHIFFIN: Yeah, a SQLite database essentially, it's a series of tables. It's a way for data to be stored, again, in a meaningful, organized fashion that can be queried, can be examined, can be filtered, searched, et cetera. It can be useful for anybody who wants to get data from an organized file.

MR. WHIFFIN: I'm sorry. Can you rephrase that?

MR. WHIFFIN: Okay. So within the history.db file, there were no missing numbers from the beginning of January, essentially until early February. That told me as the examiner that no records have been deleted during that time.

MR. WHIFFIN: I do, yes.

MR. WHIFFIN: This is the browser state record which identified a search at 2:27:40 a.m.

MR. WHIFFIN: It is, yes.

MR. WHIFFIN: Okay. So this is a searched item exhibit. It's technically a derivative of a different exhibit. that we find on the device. So we found what we consider a web history record. So a web history record would just mean we have a URL that was visited and potentially a time stamp and a title. Searched items looks at all of the web history items that we found and tries to identify were these actually searches that were conducted. So, for example, if you were to do a search on Google, you'd see that the website that you're taken to is Google.com, query, then it contains the query string that you've typed in. We extract that information, we extract that query, and provide it to the user as a searched item. In this case, I can see that it came from the browser state dot DB WAL file. The search query itself was "Hos long to die in cold," and it shows as a deleted record.

MR. WHIFFIN: Don't recall saying the word C, but I can explain what most C is in this case.

MR. WHIFFIN: Yes, the knowledge C database is at the heart of iOS. It stores lots of information about the activity on the device at any given time, things like when the backlights turned on, when the device is unlocked, what application is in focus at the time, and how long it's in focus for. And important to this case, which websites on screen at any given time as well.

MR. WHIFFIN: So in terms of iOS itself, when it's in focus, it would be the primary item that's visible on screen. So with iOS, you can have applications in the background that you aren't using, but the one that you are currently using is considered in focus, taking up the entire screen.

MR. WHIFFIN: Correct.

MR. WHIFFIN: Browser state DB is just the name of the database, the name that Apple gave it. It's gone through some changes over the last few years. For example, in iOS 14, it did store the state of the tabs that were open within a browser. In iOS 15, there was a significant change, and the only time that records were written to the database is when the tab was closed. So a significant difference in that it doesn't show you what's currently open, it only shows you what's previously been closed.

MR. WHIFFIN: This record is not mentioned at all within the history DB database.

MR. WHIFFIN: There were no missing records in the history.db database. Within this time frame, within the browser state database, there were three deleted records.

MR. WHIFFIN: These are records that have been deleted, not necessarily by the user, potentially by the system, but they are considered deleted records that we're able to recover.

MR. WHIFFIN: The phone, right. Our tool is designed as a forensic tool. It's not going to edit, delete, or affect the data in any way - just present what is in the extraction. But there are multiple times on an iOS device or an Android device where cleanup essentially happens, and we start to lose data after a certain amount of time.

MR. WHIFFIN: Yes. So Cellebrite Physical Analyzer has been available for approximately 12, 13 years in various versions.

MR. WHIFFIN: Obviously, in the digital forensics landscape, whenever a provider creates a new feature, we have to change our code to adapt to what they've now introduced. There can be research that's been done, so we now learn new things, and we add support all the time. So something can be supported in this new version of Physical Analyzer that may not have been supported or even existed in a previous version.

MR. WHIFFIN: Aside from Physical Analyzer?

MR. WHIFFIN: Okay. So I have my own tool called Artex, which I've been working on for around five years, since -- since being an examiner myself and struggling to pass any particular application that I needed. So I started to write my own tools, and that's the one that is -- one that I still maintain on the side of my own time, partly for my own knowledge, but partly because I think it still introduces some fantastic features which aren't available in any other tool for research purposes. So, yeah, I continue to write this tool to this day.

MR. WHIFFIN: Artex. A-R-T-E-X.

MR. WHIFFIN: Sorry. Is it deleted?

MR. WHIFFIN: The record itself has been deleted. As I said, the reason why it's deleted through my testing, I've only found two ways that that kind of record can be deleted by the user, and I don't believe either of those ways was actually utilized on this device.

MR. WHIFFIN: The user has the option to selectively delete history items. So you can delete either one at a time or the entire day's content, or the last two days' content, or you can delete all content altogether. If all content had been deleted, we wouldn't have found any information on this phone at all related to web history. So I was able to discount that one quite quickly.

MR. WHIFFIN: Thank you.

MR. WHIFFIN: I do, yes.

MR. WHIFFIN: It's a document that highlights both the search terms that were found in mobile Safari dot P list and the method of searching.

MR. WHIFFIN: I do, yes.

MR. WHIFFIN: Correct.

MR. WHIFFIN: Yeah, so a P list or a proxy list, is Apple's way of storing serialized data. That essentially means a list of data with names and values.

MR. WHIFFIN: Yeah. So again, this is a table I created from the data within the mobile Safari dot P list. The term shown down the left is what the user would have typed in to the search bar that's -- sorry, I just blinded somebody -- the search bar in the bottom of the Safari browser window. The UTC time is the time which is actually recorded within the P list. It's recorded as a string, so just text as it's presented on the screen there. And then I converted that and subtracted five hours to bring it into local time around Canton.

MR. WHIFFIN: Yes.

MR. WHIFFIN: Yeah, so private browsing mode is a setting that you can set on iOS devices or primarily most devices, that prevents any of your browsing activity being recorded, so that it won't save the searches, it won't save the navigations. It protects everything so that it can't be found later on.

MR. WHIFFIN: If these searches had been conducted while in private browsing mode, these searches would not exist within this file.

MR. WHIFFIN: Correct.

MR. WHIFFIN: Yes.

MR. WHIFFIN: Yes. So obviously, whenever you try to visit a web page, there's a stream of information coming from the web to the device, which then renders onto the screen. At the completion of the load event, there's a function effectively which runs and that records the visit to the history database. If, for some reason, the page doesn't load and it shows up with an unable to load message, so, for example, you don't have an Internet connection at all, that unable to load will be recorded. If, however, the device stalls and it just sits kind of waiting to load, nothing gets written to the history database. And if you were to close the browsing window prior to the page completing its load event, nothing will be written to history.

MR. WHIFFIN: Technically, the only place I found would be the browser state.

MR. WHIFFIN: Primarily, it's used to save preferences. So you'd have a lot of information in there, if it's using the light mode or dark mode, or when you want tabs to auto clear, that kind of information, but it also records several days' history of searches. The actual number of days' searches, I actually don't know.

MR. WHIFFIN: In order for the search item to be saved to the mobile Safari P list, you need to actually type into this particular search bar. If you were to just visit Google.com and start typing into the Google search bar, it will not be recorded within the mobile Safari dot P list.

MR. WHIFFIN: So these particular two searches were conducted at 6:23:51 and 6:24:18, respectively. They were searched using the search bar that's built into Safari. The fact that they didn't exist within history DB, and that there were no deleted records from history.DB leads me to believe that they never successfully loaded.

MR. WHIFFIN: I do, yes.

MR. WHIFFIN: This was the additional -- the items from the history.db I believe.

MR. WHIFFIN: Yes. Sorry, it's a comparison between the search terms found in the P list, so the mobile Safari P list and the search terms found within the history.db database.

MR. WHIFFIN: Correct.

MR. WHIFFIN: Okay. So the first list, the P list term, shows the term within the mobile Safari dot P list excluding the two that we've already mentioned, which are of note. And the first time stamp column shows the time stamp according to that P list. The history item shows the search term as recorded in the history database, and then we have the time stamp as per the history database. So the purpose of this document was to show that we have a search for "Raining Men" and a history item related to the Google search for "Raining Men," and they show within a second of each other. Again, the next one down Antoinette Okoh basketball and the associated Google search. And again, the time stamps are within a second. This list was nonexhaustive. There was hundreds of examples within the history.db, but limited examples within the mobile Safari P list.db And as I mentioned, the two searches of interest, the "how long ti die in cikd," and "hos long to die in the cold," didn't exist within the history DB at all.

MR. WHIFFIN: Yep. So initially, pre and including iOS 14, the browser state database would show all tabs that you currently had opened. So as soon as I go into my browser and open a new tab, a record is created. It includes information such as the time that I opened the tab, or the time I last viewed the tab, the current URL which is being displayed within that tab. It shows information whether it's in private browsing mode or not. So in that kind of case, in iOS 14 and below, we're able to see current private browsing records and subsequently recover deleted ones. But in iOS 15, things changed. The record was no longer written as soon as the tab was opened. It was only opened when the tab was -- sorry -- the record was only created when the tab was closed. That meant that our ability to recover that kind of history was significantly lower. It means that it no longer makes use of the private browsing field because now private browsing records simply are never written to that database. So now we can only really see a list of all of the tabs that have been closed, not which are currently open.

MR. WHIFFIN: There is, yes. That's one of the fields within the database.

MR. WHIFFIN: Yeah, so from my research based on this, that time stamp relates to the time that the tab took focus. So that's either when the user creates the brand new tab, when they switch between tabs and bring a tab back into focus, when they close a tab, which automatically brings one of the background tabs into focus, or if Safari has been completely closed and reopened, that essentially acts like almost a new tab and the time stamp gets updated at that point.

MR. WHIFFIN: I think I find --

MR. WHIFFIN: I think I followed that. Okay. So if, for example, at 12:00 p.m., I create a new tab, I can do a search for whatever I want, and at that point, if I close the tab, then the record that gets created will show that I opened the tab at 12:00 p.m., and I did a search. Excuse me. However, if I open the same tab at 12:00 p.m., do a search, close it, like completely closed down Safari and reopen Safari, that would actually -- that would also update the same time stamp to show that I'd opened it up again. What I meant to say at that point, is that if I create a 12 o'clock tab, minimize Safari, I can leave it for several hours, for several days, for several weeks. The time difference is not really important. When I come back to it and open up Safari again from a background state, the time stamp is not updated, so it will still show 12:00 p.m. today, and it will show whatever my most recent navigational event is. So I can search for something in three weeks' time using the same tab I opened today, and the time stamp will show today's time.

MR. WHIFFIN: Thank you.

MR. WHIFFIN: I do, yes.

MR. WHIFFIN: This is the entire Google URL that was found on the browser state at record. So broken down into each of its important sections.

MR. WHIFFIN: It is, yes.

MR. WHIFFIN: Okay. So the right -- sorry -- the left side of the table is the entire URL that was recovered from the browser state record. What I've done is broken it down into each of its individual components and explained what each of those components means. So the very first row is Google.com/search. That just tells the browser that we're going to the Google website and that we want to run a search. The second part, the Q equals, is telling the browser what the query term is. So the query term here is, "Hos long to die in cold." The little plus symbols in between is in place of a space because spaces can't be part of a URL. Next, we have the input encoding and the output encoding. Just explains what kind of characters to use and what language to use when you're accepting the search query and giving it back to the user. And finally, the important part is the and client equals Safari. This is something that just tells Google that this query is being done using the Safari client. Again, if I was to use Safari and just visit the Google web page and type that in, that type of searching, that part of the string wouldn't be there. That's only there because I used the Safari search bar as part of the Safari application to do that search.

MR. WHIFFIN: Again, that confirms that this search was conducted via the Safari bar search feature that's part of the Safari browser application. The same one that caused the records to be recorded in the P list.

MR. WHIFFIN: I do, yes.

MR. WHIFFIN: This is the live records from the browser state.db database.

MR. WHIFFIN: I do, yes.

MR. WHIFFIN: Yes. So this time stamp is the last viewed time according to the database itself. It's already been offset so that it's in local time. This particular table, we can see there are records missing between records 4025 and 4031. We have -- sorry -- 4025 and 4031, we have 4026, 27, 28, 29, and 30 missing. And typically, the time stamps that we do have here, some of them are separated by as little as a second or two.

MR. WHIFFIN: That's correct.

MR. WHIFFIN: So first of all, the task was to try to recover the deleted messages -- oh, sorry -- the deleted history records from browser state. So first of all, it was reading the deleted pages, essentially, to find the records that had been deleted from this current version of the page.

MR. WHIFFIN: Yes.

MR. WHIFFIN: I do, yes.

MR. WHIFFIN: This is the same data source, so it's still browser state dot DB, but now looking at it with the unique recovered records.

MR. WHIFFIN: So typically there can be lots of different versions of a page within a WAL file. So you may have several page ones, several page twos, and so on. Why I looked at is doing is recovering the data whether records that I recover are different from each other. So if I recover the same record multiple times, I can ignore it, but if I recover the same record with a slight change, then I would show it in this view.

MR. WHIFFIN: Yes. So again, the very first column on the left is the unique identifying number. You'll notice that there are some numbers here which are repeated. This is, as I said, because the records are recovered from multiple versions of the same page. There was actually 16 versions of this record across 60 -- across 23 different versions of this particular page. These three have some difference, primarily it was the -- what's called the tab order field, but that's the only difference that showed up across these three "Hos long to die in the cold," records. All the rest show the same URL, the same ID number at the beginning, or tab ID number, and the same time stamp. Worth noting, there is no title shown in this particular record. Again, that speaks to the fact that this page didn't successfully complete loading. Otherwise, there would be a title of, "Google search. Hos long to die in the cold," as you saw on some of the other examples earlier.

MR. WHIFFIN: No. In iOS 15, as I mentioned, if you are using private browsing mode, there is no records recorded in this database at all.

MR. WHIFFIN: Everything that was recorded in this database was conducted not in private browsing mode.

MR. WHIFFIN: Yes.

MR. WHIFFIN: Essentially, the life of the particular tab. So when I start a tab and I start to use navigation, I go to different websites. All of my navigation events would be considered part of the same browsing session, essentially.

MR. WHIFFIN: Yeah. So far, the bulk of what we've discussed - the history.db, the browser state DB, and mobile Safari dot P list are all particular to the Safari application on iOS. Knowledge C is much more global. It's much more ingrained within iOS. Everything is essentially recorded in there on iOS 15. So again, backlight activity, unlock activity, application state activity, and web usage activity is all recorded as part of Knowledge C.

MR. WHIFFIN: (Witness complies.) Yes.

MR. WHIFFIN: I do, yes.

MR. WHIFFIN: This is a document I created based on the Knowledge C web usage records.

MR. WHIFFIN: I do, yes.

MR. WHIFFIN: This is a particular what's called a stream within Knowledge C. A stream is basically all like information being grouped together. So in this particular case, the stream is related to Safari, and it's telling us what web page was visible on screen, what time it started, and what time it finished.

MR. WHIFFIN: Correct.

MR. WHIFFIN: I highlighted the sections in green due to their time stamp. So typically, these items last between 2:27:37 a.m., and 2:27:53 a.m., so around the time of the Google search, if you were to believe the browser state.

MR. WHIFFIN: The ones in blue are the actual Knowledge C records that show when the "Hos long to die in the cold" and the "How long ti die in the cikd," web pages were actually visible on screen.

MR. WHIFFIN: At 2:27:40, the only websites that were visible on screen were related to Ozone Basketball and Hockomock Sports, and that the, "How long ti die in the cikd," first appeared on screen at 6:23:56, and, "Hos long to die in cold," first appeared on the screen at 10:33 a.m.

MR. WHIFFIN: Correct.

MR. WHIFFIN: So essentially, ignoring the browser state time stamp is important because that is not a reliable time stamp to show when that URL was visited. We have mobile Safari dot P list record searches that show 6:23 and 6:24, and we show the same searches with very similar time stamps within half a second as showing up on screen in Knowledge C, for the "how long ti die in cikd," and the, "hos long to die in the cold," was actually several hours later, which took a little bit more explaining, looking at knowledge C and when the applications were opened up.

MR. WHIFFIN: I actually didn't look at any WiFi connection information.

MR. WHIFFIN: So according to the Knowledge C records, which were mostly also reflected within the history DB as well, it was the Hockomock Sports, YouTube, Ozone Basketball, and that's it for the main domains.

MR. WHIFFIN: Yeah, I don't remember looking at WiFi history.

MR. WHIFFIN: Thank you.

MR. WHIFFIN: (Witness complies.) Okay.

MR. WHIFFIN: (Witness complies.) Okay.

MR. WHIFFIN: I do, yes.

MR. WHIFFIN: I believe it was 0207. I didn't actually remember the time stamp just then.

MR. WHIFFIN: I can't recall.

MR. WHIFFIN: The WiFi was connected at 0212 and disconnected at 0539. There was no further WiFi activity until 11:00 a.m.

MR. WHIFFIN: I am, yes.

MR. WHIFFIN: Yes. So a write ahead log is essentially a temporary store for database pages. When I'm talking about database pages, it's not something that the user ever sees. It's part of the structure of SQLite databases. Just as chapters in a book can span multiple pages, data in a database can span multiple pages also, and it's not necessarily in the expected order. It's up to the database application to find those pages and order them correctly in order to display the data to the user. The WAL file, on the other hand, it still contains pages, but they're organized in frames, essentially. And a frame is the same as a page, but with additional information at the top that identifies what page it is. So I mentioned earlier that it's possible to have multiple versions of the same page within the WAL file. That's because every time I write a record to the database, a new frame is created and the page is updated.

So for example, if I was to have a new database, create a record, a new frame is created with page one, and it adds my record. As soon as I add a second record to that database and a new frame is created again, so I now have frame one and frame two. Both of those frames would contain a version of page one. The first frame would contain only record one. The second frame would contain records one and two and so on. Forensically, where it gets interesting is on the edit or deletion of a record, because the same process is applied. So now a new frame is created. The page number is the same as previously, so we'd still have a page one, but now only the records that I don't want to delete are copied across. So I could end up in a situation where I have four versions of page one, one has record one, one has records one and two, one has records one, two and three, but the most recent version of the page only has record one and three, for example. Now, a normal piece of database software will only look for the most recent version of the page, so you would only see records one and three. The forensic software can look at all previous versions of the page as well, and that's how we're able to recover record two in that instance. And that's essentially how we were able to recover the browser state record from WAL.

MR. WHIFFIN: So again, if I create a record that's in the WAL and delete it before it gets committed, which means when it gets merged into the main database, then it exists only in the WAL. It could be that it's a brand new record that just hasn't been written yet, or it could be one which was deleted from the database prior to the commit occurring.

MR. WHIFFIN: Commit's a process where, essentially, the database looks at all of the most recent versions of each page in the WAL file, copies them out from WAL and puts into the main database, and then deletes the WAL file altogether. So at that point, we lose the ability to recover data from WAL because the WAL doesn't exist, but we have all the most recent versions of the page.

MR. WHIFFIN: Recovering data that's been deleted from the P list is not really possible. So all we can say is if this record exists within the P list, it hasn't been deleted.

MR. WHIFFIN: There was no records of any -- so there's no evidence of any records being deleted from history.db since early January. I think it was like the 3rd of January up to February 2.

MR. WHIFFIN: Again, every record is given a unique number, and there'd be a gap in that numbering system if a file or if a record had been deleted. The fact that there was no gaps indicates that nothing had been deleted.

MR. WHIFFIN: Knowledge C contains such a large amount of different type of data that's always being added and deleted for various reasons, none at the discretion of the user. It's a completely system driven event to delete information from Knowledge C. So we can't say what was deleted from Knowledge C, but we can see that during the times of Safari usage, records exist within Knowledge C that indicate, or certainly appear to indicate, that nothing was deleted.

MR. WHIFFIN: Browser state did have numerous records that had been deleted. Some we were able to recover. Three records from browser state all had a time stamp, very similar to 22740. These were three records that had been deleted at some point.

MR. WHIFFIN: So the first most prominent option is to delete absolutely everything from the device or delete all history from the device, which, as I mentioned earlier, we know that didn't happen because we still have other records. So the only other real option is to delete selectively. That could mean delete one at a time, and it could mean delete either the full day, the last two days, or last hour, but in all of those cases, the record must exist in history.db in order to be deleted from browser state. The fact that this record, the hos long and the how long ti die in cikd, don't exist within the history database would mean that the user would never have the option to selectively delete that record.

MR. WHIFFIN: Thank you.

MR. WHIFFIN: (Witness complies.) Yes.

MR. WHIFFIN: I do, yes.

MR. WHIFFIN: So this is a list of the browser state DB records showing a red line where a record or more have been deleted.

MR. WHIFFIN: It means the record has been marked as deleted. If you were to read this database in a regular database application, you would not see it. But it doesn't necessarily mean that we can't recover it.

MR. WHIFFIN: It is, yes.

MR. WHIFFIN: So again, we can use the number down the left side, which will identify the unique identifier given to each of these records. We can see that the red line between the first two records indicates that records between three- nine-eight-six and three-nine-nine-three, have been deleted. We can see that record 4,001 is deleted. Records between 4,004 and 4,019 have been deleted. Record 4020 was deleted, and then finally, records between 4025 and 4031 had been deleted also.