Jessica Hyde — Direct/Cross

MS. HYDE: Thank you.

MS. HYDE: Good morning.

MS. HYDE: Jessica Hyde, H-Y-D-E.

MS. HYDE: I'm a digital forensics examiner. I own a digital forensics firm that does training, services, and research.

MS. HYDE: Hexordia, H-E-X-O-R-D-I-A.

MS. HYDE: Three years.

MS. HYDE: My undergraduate degree is a bachelor of science is electronics engineering technologies. I was on active duty in the Marine Corps at the time, so I went to several schools. My final graduation was from ECPI.

MS. HYDE: Oh, so sorry, ma'am. Sorry, Your Honor. A So my final graduation was From ECPI College of Technology. However, I attended several universities because I was on active duty at the time.

MS. HYDE: From there, I went and completed my tour on active duty. I went into work in the field and eventually then did my master's in computer forensics from George Mason University.

MS. HYDE: I received my master's, I believe, 2014.

MS. HYDE: Correct. I started working in digital forensics in 2010.

MS. HYDE: I was a contractor for a company called American Systems working at the terrorist explosive device analytical center called TDAC.

MS. HYDE: Sure.

MS. HYDE: From -- from there. I can go from there. From there, I went and became the director of forensics for Magnet Forensics, which is a company that develops tools for digital forensics. So there I was in a position where I did a large amount of research into new artifacts, unsupported access to devices, et cetera. I was there for five years before starting my own firm.

MS. HYDE: That is an excellent question. I've actually been an adjunct professor at George Mason University since 2016. I've taught 20 terms in their graduate program. I teach the mobile forensic analysis course in their digital forensics master's program.

MS. HYDE: Actually several. I am a member of the Organizational Scientific Area Committee on Digital Evidence, which is a part of NIST, the National Institute of Science Technology. I am a member of the Scientific Working Group on Digital Evidence, also called SWIGD-E. I am the chair of a project called DFIR Review. That does peer review of academic work that's done by practitioners in the form of blogs. I've been chairing that project since 2018 when it started with our first publications in 2019. I am the first VP at the international executive committee level of the High Tech Crime Investigation Association, also called HTCIA, which I've been a member of since 2012, and I will ascend to -- I've been elected. I'll ascend to president next September. I am also -- see, I do a lot of volunteer work. I also am an associate member of the American Academy of Forensic Sciences, AAFS. And I just recently finished my term as an associate editor for Forensic Science International Digital Investigation, which is a peer reviewed journal in the academic space of digital forensics, and I'm still a reviewer, but I stepped down from my duties as an associate editor.

MS. HYDE: That's a great question. I've published a paper on the standardization of data recovery. I worked on that with Dr. Owen Casey and Dr. Nelson. That was published in "Forensic Science International digital Investigations Journal." I also was the second author on a paper related to the use of AI in digital forensics, artificial intelligence. And I published numerous articles, blogs, white papers. I probably have published about 20 of those, but just speaking to the peer review work, too.

MS. HYDE: Absolutely. So a peer reviewed work is when you have a novel piece of research that you then submit that novel, never been presented work to a journal. It then gets reviewed by numerous academic peers. It goes through cycles of revision where they ask more questions. On the Standardization of File Recovery paper, that process took about 14 months for it to be peer reviewed by experts in the field, and then it is published in a journal.

MS. HYDE: Correct. I perform the in addition to the publications I've done, I reviewed at least 20 to 30 articles, both in a combination of support for "Forensic Science International Digital Investigations Journal" and DFIR review.

MS. HYDE: I would describe digital forensics as the analysis of data from any storage medium that can control data, be that a mobile phone, computer or cloud, for the intention of that data intentionally being used for court.

MS. HYDE: We are headquartered in New York State in Bridgeport, New York which is outside of Syracuse. We also have an office location in the DC metro area in Tyson's Corner. But we have -- we have employees in six states.

MS. HYDE: Great question. So I do perform digital forensic analysis on cases. I currently work on two US government contracts supporting one digital forensic analysis and two novel research and exploitation of mobile devices. So I'm named personnel on two contracts, and then I manage another three. I also developed training for mobile forensics. My courses have been taken by people all over the country, and Hexordia also delivers that training. I also do research and presentations for journals, conferences, et cetera. So a combination of casework, education, and research.

MS. HYDE: Yes, on May 4, I was contacted by Detective Kelly via our website about this case.

MS. HYDE: Yes. A contract was executed on May 9, and work began on May 10th of 2023.

MS. HYDE: The --

MS. HYDE: I was asked to look at two specific Google search terms that took place on January 29.

MS. HYDE: I was asked to look at the timelines and time stamps related to those Google searches.

MS. HYDE: I received two reports. I received the affidavit from Richard Green, and I received the report from Trooper -- I don't want to butcher his name, but something along the lines of Nicholas Guarino.

MS. HYDE: Oh, good.

MS. HYDE: Yes, I was aware of that.

MS. HYDE: On May 10, I received via US postal mail a copy of the drive with data from a phone that was identified to me as belonging to Jennifer McCabe. It was a full file system extraction from a GrayKey.

MS. HYDE: The first thing I did with that data set after having been retained was I made a forensic copy. I use an ArcPoint ATRIO to copy the data from that original disk, which was then placed in our safe to a working copy drive.

MS. HYDE: It's a forensics tool that does extraction and duplication.

MS. HYDE: I immediately verified the hash value of my new image to make sure that it matched the hash value of the original image.

MS. HYDE: A hash value is an algorithmic numerical representation of the data. So when you have a hash value, that value is unique to a certain set of data. So when you have that same hash value matching, you're ensuring that your copy that you made was correct and not in any way damaged or corrupt.

MS. HYDE: Yes, the hash values of both the copy I made to work from and the original match. They also match the document that came along with the drive stating the original hash value.

MS. HYDE: From there, I processed the image in several forensics tools. I used Cellebrite Physical Analyzer. I used Magnet Axiom. I used a tool called Artex, A-R-T-E-X. I utilized a tool called iLeap, and I later used a tool called Sanderson Forensics SQLite, but I did not use that tool at this point.

MS. HYDE: Yes, they are commonly used digital forensics tools that are very standard for other forensics examiners to use on mobile exploitation.

MS. HYDE: Correct.

MS. HYDE: So different forensics tools have different capabilities and look at data a little bit differently. Phones have thousands of applications. If you look at the Apple Store or the Google Play store, you can download a total of six million apps between the two. Commercial forensics tools, they can only support so many applications, so they each work and support different bits of data. So it's important to use multiple tools so you can see the results from different table -- different data sets and be able to compare those results and enhance those with manual analysis.

MS. HYDE: Yeah, that's very, very typical for me to process with multiple tools to ensure that I'm getting the most complete interpretations from forensics tools. Of course, you go beyond that with your analysis, but it's absolutely pertinent to do that. I would run some of those tools before others, because of speed and so I can begin analysis while other tools are running.

MS. HYDE: Yes.

MS. HYDE: The Sanderson Tool is meant to look at a specific type of data structure called the SQLite database. SQLite databases are very nuanced, and this particular tool allows you to take that database and explore it at a deeper level than the other forensics tools allow.

MS. HYDE: It is capital S-Q-L lowercase I-T-E. and SQLite is also commonly pronounced as SQLite, so both pronunciations are acceptable.

MS. HYDE: So in looking at that analysis, I was focused specifically on the data that took place on January 29. So the first thing I did was I limited my search within those tools to that period, and I looked at the artifacts that they were parsing pertaining to Safari history, as Safari was the browser that had been used at that time.

MS. HYDE: I'm sorry, I could not hear you.

MS. HYDE: I didn't hear the last word. With respect to?

MS. HYDE: Deletion, I apologize. Thank you.

MS. HYDE: Yeah. So one of the things that was asked was -- one of the things that was actually in the affidavit from Richard Green was that it was stated that there was belief that one of the search terms had been deleted. So I was specifically looking at that search term to see if what the reason was for the suspicion of deletion. There is -- the tools denote things based on how they are running as an automatic process. So tools are designed to parse through large amounts of data to make it easier. So the tools will often flag certain data as recovered, and sometimes there is confusion between what recovery and deletion means. That actually was the subject of the paper I referenced earlier that I co-authored. And the tools are sometimes misinterpreted that that statement of recovery means deletion. So I was exploring that.

MS. HYDE: That is correct?

MS. HYDE: I had the information from the two reports that had been written in terms of what they found and the two search terms, one was hos, H-O-S, long tit to die in cold. And the other one was, how long ti die in clkd.

MS. HYDE: Absolutely. So when I first looked at it, some of the tools surfaced the data from a specific storage called the -- let me just make sure I get the entire path for you com.apple.mobile.Safariplist. It is very common in mobile devices for it to look like a reverse domain name. Like you normally would go to a site like cnn.com. Typically, those names are like the opposite. So com.apple is going to be representative of a native Apple application. So this particular P list was related to that. A P list is -- or called a property list -- is a data structure that's unique to Apple devices, and there is data pertaining to Google search -- not Google -- well, not just Google searches -- search history that's stored there. There's also, I found evidence of the search terms in knowledge CDB. The knowledge C database is an Apple database that is meant to store information about users so it can determine future functionality, what you're looking for, et cetera. So that's the knowledge CDB.

It's more of a system level artifact. And then there was also -- and these were the observed search terms, and most of the tools picked up both of those search terms in there. They're not all tools did pick up the one that was from the wall which was the instance of "Hos long to die in cold." That's how I'm pronouncing the H-O-S. If you would like me to clarify it a different way, that's fine. That particular search term was recovered from a SQLite database, the one I later explored. And Cellebrite, specifically demonstrated and showed that particular search term as a suspended state tab. And that's a really intricate artifact, whenever we're ready to explore that. That is the one that was marked as recovered. So those were my initial findings just looking at what the automated tools parsed. However, Cellebrite was the tool that found that particular search term.

MS. HYDE: That is correct.

MS. HYDE: Absolutely. This is a really interesting data structure the way it works. So the way SQLite databases work is the data before being committed to the database, which is almost like an Excel spreadsheet if you think about that. Each table is like a page on an Excel spreadsheet. The data before going there goes kind of to almost like a text file, like, if you were to have a DOC of writing all the changes that need to happen to that Excel spreadsheet. And they're not made to that spreadsheet until it closes. So what happens is as you're doing things - either adding a website by searching for it or closing a tab or deleting a text message in a SQLite database in general, those things you add are written to that text document or things you delete. So they all hang out there together. So it's any changes that are going to be made since you started using that application until it's closed, then they change there, and then it reopens.

So to make an analogy, if you're in a restaurant and you order some food, the food being the data, and you at the table being the table that the data is going to, when you request that data and you say, I'm adding it, it goes to the area where the waiter or waitress, the server is going to grab it from, right, that warming station. That is almost like a write ahead log. And so different tables are ordering food, and food is constantly being put there. If somebody, maybe their steak came out rare and it needs to be cooked more, when they send it back, it'll also go to that warming area. So you can see there that you've got things waiting to go out to the tables and things being sent back to the kitchen. So simultaneously, that storage area contains both the newest stuff waiting to go out and the stuff coming back.

And that's really what a WAL file winds up containing - your newest Google searches, your newest text messages, et cetera, as well as anything that you've been deleted, that you've said was deleted because the reference in there is going to be delete this entry. And so then all of those don't happen until the application is closed and reopened. If the application's been closed, when we do the extraction, we actually don't get the WAL file. We only get the WAL file if at the time of extraction, that database had not been closed. So that just means that Safari, in this instance, was still running when the extraction was done. Most of you when you use your phones, you leave the applications up. So because of that, we have a WAL file, and so that WAL file is going to contain both the data that's been requested to be deleted and new data. Now when I say deleted in this instance, I don't mean like you as a user saying delete the full text message. What I mean when I say deleted in this issue -- this instance is removed from the database. So when we're talking about something like a Safari tab, deletion from the database can occur because you close the tab. We all open tabs when we use our browsers on our phone, and we all close them. And so closing in that instance would be a deletion in the database. But what that's doing is not a user requesting deletion. So I just want to be clear on that term.

MS. HYDE: Correct. And I think that's a common misconception, yes.

MS. HYDE: That's correct.

MS. HYDE: An artifact is any trace that's left behind by any action on a digital piece of data.

MS. HYDE: Absolutely. So an artifact of you sending a text message would be that we would find the database where text messages are stored, and inside that database, we would see the time and date that you sent it, who it received and who it was sent to. It might not be their name. It might be a numerical representation that we have to tie to another database. Then we would have the message itself. It may be in plain text, or it may be encrypted or encoded. And then we may have something called a blob, and that would be a reference to data that's too large to store in the database, so it would be elsewhere. So that would be if your text message included, let's say, a picture or a video.

MS. HYDE: That is correct.

MS. HYDE: That is correct.

MS. HYDE: I do.

MS. HYDE: Thank you.

MS. HYDE: I do. Let me -- oh, yes.

MS. HYDE: Absolutely. So this table here has a couple of different elements that I'm showing in terms of what searches were searched, where, when, and what source of data they came from. So if we look at this first search, I have them in the time stamp order that is associated with the artifact. I want to clarify that we need to discuss the meanings of these time stamps as we go. So this first one that you're going to see is - and I'm just going to reference my paper because of the size - is 2:27, 02:27 and 40 a.m. So that's two o'clock in the morning, twenty-seven minutes and forty seconds. And it is a search for the term: "-H-O-S long to die in cold," and that is time stamped, in this instance, is from the browser state DB, which is right here. The browser state DB is an artifact that speaks to when tabs are moved. So when you're using your browser and you open different tabs, you may have a search that this time pertains to the time that that tab moved. It could be lots of things.

It could be you switch tabs. It could be you close the tab. It could be you minimize the application, depending on the version of iOS, what can be that browser state of the tab that changes the time stamp differs. But what's very special to know about this time stamp is that that is not the time necessarily of this search. If a browser is opened and a single search is made, those will match. However, as long as that browser hasn't been closed, moved to the background, et cetera, if that browser has had any activity that happens to that tab in terms of application, closing, minimizing, this can update. That is what that time stamp is for. This search term is always going to be the most recent search term in that tab. That means the last item that was opened in that tab was H-O-S long T-I in cold. We cannot tell by this particular artifact what time that search occurred. It is a high likelihood that that tab was opened at this time because there was another search that occurred at 2:27 in the morning. It was a sports site. I cannot pronounce it. It began with an H. Honk -- hock --

MS. HYDE: Hockomock. Okay. Thank you very much for the pronunciation. Hockomock Sports. There were a couple of searches pertaining to that done immediately after, but it appears that that's when this tab was opened and the first search done there. So this search, we know was done by this, and we know that it was the last search in the tab because it comes from this source, the browser state DB, and that means that particular time stamp and search pertains to what has happened with the tab. And that's what allows you to open your Safari browser on your iPhone and then open it on your iPad or your Mac and have the same tab. That's the function there. This search here. This is really interesting. So at 6:22:49 a.m., we have an entry in cache DB that is specifically if we dig into this URL, this is an Apple suggested term. So when you use a browser and you start to type a search you've never typed before, the browser tries to help you and say, "Are you searching for this?" So as the user began to type the phrase in the immediate search after which is, "How long T-I to die in C-K-L-D," this particular suggestion came up, indicating, in all likeliness, that the search term being typed had not previously been searched because Apple suggested, instead of a previous search, it suggested, how long does it take to digest food. After how long to digest food had been suggested, the user then has a search at that -- at that time 6:23:51 for, "How long T-I die in cold," and that is coming from the mobile Safari P list, com.apple.mobileSafari P list I mentioned earlier, and the search is also shown in the knowledge CDB. That's commonly what we would expect. We would expect that search to be in both of those -- both that P list and that database. Then the --

MS. HYDE: Yeah, absolutely.

MS. HYDE: That is because the search is not being tracked, not only by the P list for Safari, but also by the system itself to be able to do that predictive coding. So in the future, when you start to type how long it gives you what you searched last time.

MS. HYDE: Correct. The source of that, if you look at the first in line where it says CDN2smooth.apple.com(ph), that's what indicates that this is an Apple suggested term, not a user input term.

MS. HYDE: Absolutely. The next search that was done immediately after the search at 6:23, the next search was "how long T-I die in C-L-K-D," Again, we see that search both in the knowledge CDB and the mobile Safari P list. And then we have, yeah, so we see it in both databases. Then -- so that's how long to die in cold. Sorry, I moved onto the next line. Then at 6:24, we get the next search, which is, "-H-O-S long to die in cold." And we have that search again both in the knowledge CDB and the P list. If I were time lining this based on activity, as opposed to time stamps associated, what I see here is the beginning of a user typing a search, Apple making a suggestion of how long to digest food. The user does not take that suggestion and rather inputs "how long T-I die in C-K-L-D." They then make a second search of "hos long to die in cold." that search winds up being the last search in the tab, and that is why we see it in the -- this particular browser state DB. It should be noted that this is in one of those WAL files and not the raw file.

MS. HYDE: Because that table isn't showing the time of that search. It's showing the state of the database. So it's saying that the last time that tab was touched, moved to the background or foreground, was 2:27 a.m. The website, as you search more websites in the tab, that gets updated. So the current state that this is showing is that it was -- the tab was moved to the background or opened or some action for the tab at 2:27 a.m. when the Hockomock Sports -- I got it right. Hockomock Sports website was visited, and then once the Hockomock Sports website was visited, that tab was in continual use. There were other searches J|and activities that happens. We don't see that happens. Eventually, this search gets made at 6:23 a.m., this search at 6:24 a.m. That winds up being the last search in the tab, and because it's the last search in the tab, that's what the final update is and the final status.

MS. HYDE: I'm sorry. I don't understand the question.

MS. HYDE: Two twenty-seven isn't necessarily one time when the tab was closed. That's -- in my report, I say that it's undetermined because there's a lot of things that can cause that time stamp to be there, including tab being moved, tab being minimized. I don't know exactly what caused the tab to get that particular entry, but it is not -- that time stamp is not indicative of the time of the search or any URL that's visited there. That time is indicative of movement of the tab and the search is the most recent search. So they update at different times.

MS. HYDE: So the fact that the time -- that that time stamp exists at 2:27 combined with the fact that the only existence of this search is at 6:24 means that, yes, that time that -- that particular tab was used after 2:27 when the Hockomock Sports was searched. I apologize for not being familiar with that name.

MS. HYDE: Mm-hmm.

MS. HYDE: So the artifact that needed a little bit more explanation and digging was this browser state tab, and that's because if you look at the end of a file name, you'll see it's a DB dash WAL. That means it wasn't in the regular database. It was in the write ahead log. And to Cellebrite's credit, they -- that tool actually parsed the write ahead log and displayed it where the other tools did not. If you remember before we talked about write ahead logs, and we talked about the fact that they can contain data that is both removed from a database and data that's not yet to be committed. And this database, we cannot -- we do not know which that is. But what I did was I manually went through, and that's in the figure, I manually went through and reconstructed the WAL files using the Sanderson SQLite tool. And in reconstructing the WAL files, I found many -- I'll tell you exactly how many if I can refer to my notes --

MS. HYDE: Can I refer to my notes? A Approximately 16 instances of that existing in the WAL file. Now, what's interesting in that figure is that the -- each entry of something in a write ahead log gets a unique identifier. So it gets a -- it gets a number, right, that makes it unique. Just like each one of us has a phone number that's unique to us, each entry in the database that starts in the write ahead log gets its own unique identifier. And that unique identifier in this instance in all 16 entries in the WAL file is the same, which shows that it's truly only one search, not multiple searches for that search term in terms of what exists in the WAL file. So that's -- that's the first piece of nuance there that it only truly was searched one. And you would -- you would have to really dig into that WAL file to expose that, but I think it was pertinent to know how many times this was searched.

MS. HYDE: Yes, please.

MS. HYDE: Oh, wonderful.

MS. HYDE: May I look at table two?

MS. HYDE: Thank you, Your Honor.

MS. HYDE: I do. That is table two of my report on page four.

MS. HYDE: So table two here is designed to share with us what each of the locations that can potentially have Safari data, what kind of data they hold. And one of the things that many of us are interested in sometimes is do these things hold our private searches, like, if we're in Incognito mode in Google or private searching here. So this table denotes if we're seeing private or nonprivate searches, if it includes tabs that are open or closed, so that we know which artifacts are giving us what kind of information, as well as what some of the associated time stamps mean. So this was designed as a guide to really understand table one more in depth. So this first one here. This refers to the history DB WAL file, and that file has nonprivate searches. It includes closed tabs and the visit time there is the time that a user reopened the tab. We don't always have the artifacts we want, and in this instance, we did not have that particular one. Then we have the Safari tab CB.

This has private tabs and nonprivate tabs and it only -- it shows only tabs that have not been closed. So this is an active tabs database. The next one we have is the browser state DB and its WAL file. And this is the one we were referencing where that -- that we keep talking about where that 2:27 a.m. number is coming from. So this one is going to be nonprivate searches. It includes closed tabs, which is important, and the last viewed time, so when an item went to the background. So it's about the tab, not about the search. That's probably the most important demarcation. And one of the issues here is when the tools parse the data, they call the columns what the columns are called raw in the data. Those don't necessarily tell us what they mean. We have to verify and validate what they actually mean. So when I'm saying last underscore view time, that's what the database name is, not necessarily the actual function or not what we would presume it to mean. The next one, the last one here, is the mobile Safari P list, and this one actually tells us the date here, gives us the time that something was queried, reliably.

MS. HYDE: So SQLite databases work and function as a storage for anything that the phone may need to reference later that you're doing. They're stored for a variety of things. Most of your third-party apps use SQLite databases and multiple applications do. So SQLite gets information in and it allows for that information to be updated, added to, or removed from. So data that's in that situation, that it's sitting in the database, that is what we refer to as live data. Then data that is waiting to be put into the database, that is sitting in the WAL or has been requested to be removed, that is what's in the write ahead log, and we call that nonlive data because it's not in the active database.

So when you're using an application and it's putting that data to that temporary storage area, that WAL, that write ahead log, what happens is, then when you request data by going into your contacts, let's say, and looking at the people who are stored in your contacts, right, your mom, your dad, your brother, your sister, all those people, when you're looking -- your best friend -- you're looking up their numbers, that data is all stored in that database. So when you add someone, it does that entry to the WAL. Now, so if I just added Sally, how do I know that Sally's in there, right? Well, what happens is the interpretation of the SQLite database goes to the wall, checks and sees if it's in the WAL, and uses the WAL to incorporate it together to present you everything as if it's in there. Then when you close the application, you close contacts, you don't just put it away, like go switch apps. You actually close it. When it closes, all of those changes get committed.

So now the items that you've requested to be deleted, that contact you don't like anymore, that X, whatever their data is no longer in there. The data that you've added is now in there, and now that's all live. Sometimes we can get more complex and recover some of those items that are left over because they are marked for deletion but still sit in the database, or they're sitting on a page that is no longer active in the database. So there's a lot of places that we can recover data from in addition to the WAL that exists in a database after something has happened. But that isn't pertinent to this particular use case.

MS. HYDE: Oh, one of the biggest complexities is the assumption that because data exists in a write ahead log, that a user took an action to delete it. When I teach at the university, when I peer review my colleagues' reports, this is one of the most common mistakes I see, and it's really because some of the forensics tools to indicate that the file has been recovered, they put a big X on it. And that was actually a big subject of that Standardization of File Recovery paper I referenced earlier, and it speaks about all kinds of files, but actually has a special section on SQLite, specifically because that nuance is often missed by examiners.

MS. HYDE: So Cellebrite and Magnet Axiom - both Cellebrite Physical Analyzer and Magnet Axiom both have file system viewers that then have SQLite database viewers. I would say that those SQLite database viewers have more of a basic function in terms of looking at data in the live database. They don't allow for deep analysis of the write ahead logs which is why in my analysis, I use the specialized Sanderson forensic browser for SQLite.

MS. HYDE: Absolutely. Anytime I see an entry marked as recovered, and I'll use the term recovered instead of deleted, by Cellebrite and the source is the write ahead log, I would go and begin reconstruction of the write ahead logs using Sanderson's forensics tool to get the meat of is this something that has been deleted, or is this something that has yet to be written to the database. You can often see remnants of that based on how many unique entries there are of it, and you -- what the other thing we do is, so I mentioned that when we have the WAL file, it hasn't been applied. So if I take the SQLite database and the WAL file out, and I make another copy of them -- so I've got one copy I'm looking at Sanderson, and I take another copy, and I actually open it, what's cool is it does the commits. So then I have a copy of the database that actually has all those changes. So I now know if the entry was deleted by Just comparing the two. So I can do that analysis by basically making the database think it was reopened by reopening it with a nonforensics tool in that instance just to see what it would look like in real life, and then I can look at the difference between the two and determine if something was marked for deletion or addition.

MS. HYDE: Yeah, well, there's a couple of reasons. First, the way tabs work from a functional perspective, you can close a tab, but there's not really a user deletion function for the tab, and there was no evidence of other deletion, if that makes sense. I also -- it doesn't make sense that the term was -- I don't see evidence that the term was searched prior to that 6:24 time. So since the term wasn't searched prior to that 0624 time, the existence of the tab being closed would not mean that that search was deleted because then it would be evident in the other databases pertaining to the actual search not the databases pertaining to the state of the tab. Is there a possibility that the tab was closed? Absolutely. But that is -- that is not a deletion. Secondly, an existence in the WAL file, as we mentioned, could be that it's something new, not something that was deleted. So just it's mere existence in the WAL file doesn't mean it's deleted. I should say that that same X in the tools, you have to check the file because it could be from a free list or a free page in which case - I know we didn't go into those details nuance of SQLite databases that actually doesn't pertain to this. However, those would be truly deleted items. So there's other places where we would expect potential recovery, not necessary in this instance, and you can have something that's in a WAL file and deleted without being in those other locations just stating that its existence in WAL file itself doesn't mean deletion. But there are other SQLite things that would clearly indicate deletions that aren't applicable to this particular search.

MS. HYDE: Ma'am, may I -- thank you, Your Honor.

MS. HYDE: Yes, this is figure one. This is a direct screen capture from Sanderson's tool from the browser state DB limited to the "hos long to die in cold" search.

MS. HYDE: Absolutely. So all of the searches are the exact same term, and here we have the order index, and here we have that last viewed time. And by looking at the last view time, which is the raw title of that artifact for the time stamp we were looking at, these -- and these are identical. This -- and more importantly, there are actual UID for these are identical which is right here. Now the offsets are different. And what that means is that this is just appearing several times in the write ahead log. It has moved as the database has moved data through the write ahead log to different positions, but has in every instance the same unique identifier meaning that all of these entries are the same entry - just shown multiple times in the same database.

MS. HYDE: Well, that UID shows that in this particular instance that it existed once in the last time in the tab because this artifact does not tell us how many times something was searched by the user. This artifact is limited just to the tab. We would look at the mobile Safari P list which has one entry service time stamp or knowledge CDB, which also only has one entry for this search. Those is where -- those two locations are where we would determine how many times it had been searched as opposed to this location which could tell us that if there were multiple entries, but there is only one. But since this is laid(ph) -- limited to just the last search that's showing in a tab, it isn't a good source to say how many times was it searched, just not this particular artifact.

MS. HYDE: Absolutely. You can determine that from both mobile Safari P list and knowledge CDB.

MS. HYDE: That's really what's of significance is that it is the same entry there multiple times, and we can tell by the U -- unique identifier, that it is the exact same entry also, but -- and it's -- although it's the same search term and the same time stamp, it's only one instance of it, just it's stored in the database multiple times at multiple offsets.

MS. HYDE: Well, I guess I should really clearly for people who may not be familiar, that doesn't look like a normal time, right? That's because this is an Apple WebKit time stamp. So we actually convert it to a regular time. So when you look at this number raw, you can actually see that it's consistent throughout, even though you don't know what it is. But if we put it into a decoder, this particular time stamp is where we're getting January 29, 2022 at 0247 a.m. And to be clear, just for real clarity, when we actually translate this time stamp, it's in universal time constant, not in local time. But for the sake of conversation, I'm using the local time here as opposed to the time in the universal time constant, which is how this artifact is particularly stored.

MS. HYDE: Absolutely. So with this artifact and being able to determine what this time stamp really means, I actually did quite a bit of testing, which is fun, but that's okay. So we went ahead and did -- took a jailbroken iPhone, and the purpose of a phone being jailbroken is we're bypassing the security protocol so we can monitor the data and its storage in real time and bring the data through. We did this both -- we did this manually in terms of pulling the data out, and we also did multiple forensic images at different stages. We manipulated tabs. We did some Google searches, and then we would close tabs, move tabs, and perform several different searches that we scripted out first what we were testing, and then check to see how that time stamp was moving. We even did some really interesting things where we tried --

MS. HYDE: Yes.

MS. HYDE: It's okay.

MS. HYDE: Oh, I --

MS. HYDE: I had somebody peer review and test my testing. So they didn't -- they didn't work on the case, but as I was testing, one of my team members just validated that I would -- that I was following my test plan. That's just normal practice that we use peer review.

MS. HYDE: I conducted, correct, correct. But I had peer review by my team member on the script I had made to do my testing. So and I use the -- when I do testing, I'm following the NIST guidelines for data set generation and testing that's outlined by OSAC, which ironically, I should disclose, I'm a coauthor on.

MS. HYDE: Absolutely. Yes, so then populated the device and looked at all of the different data that came back from the different states while it was jailbroken and the changes that happened. What I was saying was interesting is then tied it to a Mac and saw how the browser state changed if we change the browser and the tab on a Mac and how that would affect it, and because we could see the differences. And by we, I mean that my -- I had my testing peer reviewed, because I could see the differences of what the data looked like when I was altering it both in the Mac and on the phone, I was getting differences in those time stamps and those different conditions. So in other words, I could get a time stamp that showed in the browser state DB That was earlier than the current search by a variety of means, including manipulating the tabs, closing them, opening them, switching which one was in proper view forward, as well as looking at that tab on an external device, including a Mac and an iPad on the same account.

MS. HYDE: Yes.

MS. HYDE: Correct.

MS. HYDE: I believe that my experience in research, development, and reverse engineering throughout my career pertaining to artifacts, of course, influences and my analysis processes in terms of wanting to ensure I understand how things work. I think it actually gives me a better understanding in many ways of how data moves through devices as well as how understanding why the tools parse and represent data the way they do in terms of the fact that they are using the -- they are presenting the data as they parse it using the proper algorithms to dissect that data and determine what it is based on testing and knowledge. So I think it actually influences in a positive way the depth that I go through in my analysis.

MS. HYDE: Correct.

MS. HYDE: In Mr. Green's analysis, there is a conclusion that is drawn that a search occurred at 0247 a.m. on January 29, based on the artifact recovered from browser state DB that Cellebrite parsed out. And there are two errors with that? The assumption that that is the time of the search is a misunderstanding of the browser state DB artifact because that artifact is not the time of search. It's the time of movement at the tab as well as the statement that -- that it was deleted due to the demarcation of Cellebrite as recovered.

MS. HYDE: My conclusion is that there was a search at 0247 a.m. for Hockomock Sports, that that browser was in use, and there were continual searches due through the night. The phone was, I do agree with Mr. Green's findings, that the phone was in use at that time at 0227. Later, the phone is a web search is done at 6:23 a.m. for how long. At that moment, Apple produces a suggestion for how long to digest food. The search is instead completed with "how long T-I die and C-K-L-D," at 6:23. A new search is conducted at 6:24 of "hos long to die in cold." "Hos long to die in cold?" That search is then the last search that is made in that particular tab, and that's my conclusion.

MS. HYDE: In regards to those artifacts pertaining to those search terms, I had no evidence of deletion.

MS. HYDE: Good afternoon, sir.

MS. HYDE: Essentially, except it's not 2:27 a.m. timestamp on a Google search. It's a 2:27 a.m. timestamp on a tab.

MS. HYDE: That is correct.

MS. HYDE: Yes.

MS. HYDE: Yes.

MS. HYDE: Yeah, PLIS is not a database. Just it's a structure. So just a small correction.

MS. HYDE: Yes.

MS. HYDE: Would you call them issues as that were --

MS. HYDE: Elements, fair. Fair enough, yes. Yes.

MS. HYDE: Can you rephrase, please?

MS. HYDE: Repeat it. Repeat it, please.

MS. HYDE: That timestamp is not indicative of a time of search. So the question is difficult to answer, because I can't say that that timestamp tells me anything about the time of search.

MS. HYDE: Mm-hmm.

MS. HYDE: If I'm understanding your question, there was a double negative so I just want to clarify. The question is if the timestamp could exist because of a search happening at that time?

MS. HYDE: Okay.

MS. HYDE: There is no indication of a Google search at or before 2:27 a.m.

MS. HYDE: There is a very unlikely possibility based on the fact that there is no evidence that the search occurred before that time. That's just like saying that the user searched for pandas at 2:27 a.m., could you rule that out? I can't rule out something that doesn't exist.

MS. HYDE: Mm-hmm.

MS. HYDE: Correct. I had a very limited scope in this analysis.

MS. HYDE: That scope was relayed to me by Detective Tully.

MS. HYDE: Safari's history, search history, specific to January 29, 2022, that is correct.

MS. HYDE: I looked at related artifacts such as the -- such as what was being done at that time, the phone being on, the phone being used, but not anything else outside of that, correct.

MS. HYDE: Correct.

MS. HYDE: Of course.

MS. HYDE: Thank you very much.