Latest / Parsing the Truth: One Byte at a Time / Karen Read 1-5; Ian Whiffin Testimony P2

Transcript

Karen Read 1-5; Ian Whiffin Testimony P2 · Parsing the Truth: One Byte at a Time

0:01
Join former FBI Senior Forensic Examiners Becky Passmore and
0:05
Stacey Eldridge as they dig into the world of digital forensics
0:08
one bite at a time. Now leading their own consulting
0:11
firms and educating the next generation of cyber sleuths,
0:14
these badass babes of digital forensics bring sharp insight,
0:18
real world case experience, and a dose of humor to the bits and
0:21
bites that filled today's investigations.
0:23
From deep dives into business e-mail compromise and ransomware
0:26
attacks, Becky's specialty to cracking the complexities of
0:29
iPhone forensics, Stacy's obsession, this podcast delivers
0:33
insider knowledge for professionals, students, and
0:36
true crime techies alike. If you've ever wondered what
0:39
really happens when the digital trail is all that's left, TuneIn
0:42
and start parsing the truth. Parsing the Truth One Bite at a
0:53
Time is proud to welcome our first sponsor, ACE Forensics.
0:57
They are based near Chicago and they've been building systems
1:01
since 1983. ACE Forensics delivers high
1:05
performance digital forensics workstations, laptops and
1:08
servers to justice agencies across the United States and
1:12
around the world. They offer unmatched value and
1:15
the industry's only five year digital forensics warranty.
1:20
ACE Forensics build the systems digital forensics software
1:23
deserves. If you're procuring digital
1:26
forensics equipment, reach out to them for competitive quote.
1:29
Now on to our episode. Welcome back to Parsing the
1:33
truth one bite at a time. I'm Stacey Eldridge and with me,
1:37
as always, is my Co host, Becky Passmore.
1:39
We are the podcast that focuses on digital forensics in today's
1:44
modern crimes. And it's true crime, but with a
1:47
techie twist. Becky, what are we doing today?
1:50
Well, today we are continuing our coverage of the first Karen
1:54
Reed trial and we're going to continue to dive into Ian
1:59
Wiffen's testimony, who is who's the prosecution's second digital
2:05
forensic expert. And we are a little more than
2:07
halfway through his testimony and there's still a lot of good
2:12
stuff to dig into. Yeah, Part 2 of his testimony.
2:16
So if you missed the first part of Ian's testimony, it's in
2:20
Season 1, Episode 45. You'll definitely want to take a
2:23
listen before jumping into this episode.
2:26
And if it's been a minute, we'll give you a quick refresher of
2:30
what we covered in the last episode.
2:32
So basically, Ian Whiffin was brought in to explain that
2:36
controversial 2:27 AM time stamp associated with that web history
2:42
search on Jennifer McCabe's iPhone.
2:46
During his testimony, he has walked the jury in the court
2:49
through several key databases, the history dot DB, the browser
2:54
state dot DB, the mobile safari dot P list, and the knowledge C
2:59
dot B. He's explained how they work,
3:02
what they record. So based on his testimony so
3:06
far, you can conclude that his findings are that this 2:27 AM
3:12
time stamp does not reflect when the searches were conducted.
3:16
And he's getting given information that the actual
3:19
searches were conducted at 6:23 and 6:24 AM And he also has
3:25
established that those two searches have never successfully
3:29
loaded or they didn't successfully load and that and
3:32
he explained that's why they didn't show up in that history
3:34
DB with the Internet history. And he also explained that that
3:40
deleted browser state record, this record for the house long
3:44
to die in the cold was not user deleted, but was instead
3:47
orphaned and cleaned up by the system.
3:51
Like we said, we're halfway through.
3:53
Sounds like he's done of a lot of explaining, but there's more
3:56
explaining to be done. That's right.
3:58
Now we get into that knowledge. C dot DB.
4:01
He describes it as deeply embedded in iOS 15 logs.
4:07
Essential. It logs essentially everything
4:11
happening on the device at a system level.
4:14
When the screen backlight turns on.
4:18
When the device is unlocked, of course, what application is in a
4:22
foreground and for how long, which websites are visible on
4:25
the screen at any given moment. He explains that in focus means
4:30
the primary item visible to the user.
4:33
You can have apps running in the background, but the one you're
4:37
actively using is the one in focus.
4:41
So this leads us to Exhibit 621 again.
4:45
We'll have that link to all the exhibits in the show notes, so
4:49
you can go and look at them. But Exhibit 621 is a document
4:53
that he put together from the web usage logs that he
4:58
discovered and analyzed that were in the knowledge C dot DB.
5:02
So something to note here that within this database, the
5:05
knowledge C dot DB web usage data is going to be stored in a
5:10
table called Z object. And then the artifact type that
5:14
you're looking for in there is slash app slash web web uses.
5:19
So that's for our digital forensic examiners trying to
5:21
keep track of what they should look for.
5:23
So take note of that. Now he also notes that the
5:26
knowledge C organizes all the data in streams and that like
5:30
information is grouped together in the exhibit.
5:34
He has some sections that are highlighted in green and those
5:37
green highlightings, they correspond to the entries from
5:41
the time around 2:27 AM. And again, that that time is
5:47
associated with that House Long to Die in the cold search.
5:51
Now, I think everybody agrees that that search was typed in.
5:55
From everything we've heard, that's not in dispute.
5:58
But in his testimony, Ian states that these records highlighted
6:02
in green are what the Knowledge Seed DB actually recorded as
6:06
being visible on the screen at 2:00 AM.
6:10
And these URL's that are displayed in the exhibit are
6:12
related to Ozone basketball and Hockomock's sports.
6:17
And there's nothing displayed there that says anything about
6:20
House Long to Die in Cold. Yep, he's asked directly what
6:24
were you able to determine about the timing of those searches
6:28
based on your full analysis, and his answer is specific.
6:33
At 2:27 AM, the only websites visible on screen were Hockomock
6:39
Sports an Ozone Basketball. The search How Long to Die in
6:45
Tiki first appeared on screen at 6:23 AM and House Long to Die in
6:52
Cold. The second search appeared on
6:55
screen at 10:33 AM. He also confirms that neither
6:59
search appeared on screen at any point before 6:23 AM.
7:05
OK, so whatever was happening at 2:27 AM, it was not someone
7:09
searching for information about House Long to Die in cold.
7:13
Whoa, Did you guys catch that? There's been a new timestamp
7:18
introduced? Ian Whiffen said 10:33 AM, and
7:23
he's talking about local time because everything else that
7:25
he's been talking about has been local time.
7:28
So this is new information being introduced and it's new
7:33
information regarding these searches, and it's specific to
7:36
when they appeared on the screen.
7:38
I went back and checked, you know, well the episodes about
7:42
Jessica Hyde's testimony and she didn't really discuss anything
7:46
from her testimony about the knowledge see artifacts
7:51
regarding the times that different web pages were present
7:54
on the screen. Now she did mention that there
7:58
was the 3:00 AM recent web search artifact for How long to
8:03
die in Kikti with no URL present and that search was coming from
8:09
the com dot apples mobile safari dot P list.
8:13
And then she mentioned two other time stamps from 6:23 at 56
8:19
seconds and 57 seconds. And that there was the Google
8:24
search app web usage artifacts again for that same how long to
8:30
die or how long to D and kick the these search terms.
8:35
But anyways, and that was coming from that Google URL.
8:38
And that was also documented in the knowledge seed database.
8:42
And then she talked about at 6:24, there were some recent web
8:47
search artifacts for the house long to die in cold from the
8:51
Mobile Safari P list. And again, coming from the
8:54
Google search of house long to die in cold with that Google URL
9:00
being pointed out or documented in the knowledge C dot DB.
9:04
So she never mentioned anything about a time stamp of 1033, but
9:10
she also didn't talk about anything and what time it was
9:13
displayed on the screen to her to the user.
9:16
I think that was maybe out of her scope based on her
9:19
testimony. And so and remember everything
9:22
that we talked about South far. If you want to know what's on
9:24
the screen, you have to look for that artifact related to in
9:28
Focus and specifically in the knowledge CD.
9:30
Maybe you are looking for slash app slash in focus.
9:34
I went through the exhibits. I didn't see a specific exhibit
9:38
about in focus. So now we're we're kind of
9:41
making this assumption that basically all of those web usage
9:44
artifacts and the in focus artifacts of line that are
9:49
relevant to this case. I'm wondering if there was much
9:54
commentary about this 10:33 AM time stamp in other podcasts.
9:59
Yeah. Was everyone so intent on
10:02
figuring out what the heck was happening with that that the
10:06
browser state dot DB and it's just sort of zipped?
10:10
By Yeah, yeah, I don't know. I mean, there's been a lot about
10:13
the time stamps in the news, right?
10:16
People kind of tend to be on one side or the other.
10:18
They think it means this or they think it means that.
10:21
I've not really seen or heard anything about people harping on
10:24
10:33 AM. Right.
10:27
So we've got more testimony to go through.
10:29
Of course, Cliffin agreed with the prosecution that neither
10:33
search ever appeared on the screen before 6:23 AM.
10:38
He was also asked what he concluded regarding the time
10:43
stamp, and he said it's important to ignore that time
10:48
stamp in the browser state DB because it's not a reliable time
10:52
stamp to show when a URL is visited.
10:56
And he also indicated that there are the mobile Safari dot P list
11:01
records that show 6624 coupled with other very similar time
11:05
stamps for some of the same search searches that were logged
11:10
in the knowledge C dot DB. Now, he does mention that that
11:14
10:33 AM time stamp for house long to die in cold being on the
11:18
screen at, you know, 10:33 AM took a lot more explaining.
11:23
So that sounds like it's more complicated than just, you know,
11:27
a simple time stamp being logged.
11:28
And maybe we'll hear more about it during the trial, who knows?
11:31
Now comes one of the more technical sections of his
11:34
testimony, the ride ahead or wall file.
11:38
And so we want to spend a little time on this because it's the
11:42
house long to die in cold search record, which was recovered from
11:48
the browser state dot DB and try to understand it is important
11:55
because, well, it can be tricky. Yeah.
11:58
He explains that the sequel Lite database stores its data in
12:02
pages. It's not something that the user
12:05
ever sees. It's part of the structure of
12:07
the SQLite databases. Just as chapters in a book can
12:11
span multiple pages, data in a database can also span multiple
12:16
pages, and it's not necessarily in the expected order.
12:21
It's up to the database application to find those pages
12:25
and order them correctly in order to display the data to the
12:29
user. The wall file is a temporary
12:33
holding area for changes to those pages, and it's organized
12:38
into frames. Each frame contains a version of
12:41
a page, plus some identifying information at the top.
12:45
And we've got more. So every time a record is added,
12:50
edited, or deleted, a new frame is written to the wall file.
12:56
So over time you can end up accumulating multiple frames
13:01
that all contain different versions of the same page.
13:05
Now, a normal database application reads only the most
13:09
recent version of each page, so you only see what the app
13:15
intends for you to see. And that makes sense.
13:17
However, with forensic tools, we as examiners can dig deeper and
13:23
take a look at some of those older versions of those frames,
13:27
the pages, things of that nature.
13:29
And because we can do that, this is how some deleted records can
13:33
be recovered. And Ian Wiffen gives a clear
13:36
example. He says if you have records 1-2
13:41
and three, and then you go back and delete record 2, the most
13:46
recent page version will only show one and three.
13:49
And if you use your forensic software, you can dig in and go
13:53
back to an earlier frame that still contained record 2.
13:58
And so this is ultimately how that deleted browser state
14:02
record was found. It existed in an older version
14:06
of a page that was able to be recovered from the wall file.
14:11
So ask what is the relevance of only certain data only existing
14:16
in the wall file? And his answer is if I create a
14:19
record that's in the wall file and delete it before it's
14:23
committed, which means when it gets merged into the main
14:26
database, then it exists only in the wall file.
14:30
It could be that it's a brand new record that just hasn't been
14:35
written yet, or it could be one that was deleted from the
14:39
database prior to the commitment occurring.
14:43
He was asked to explain what a commit is in database terms, and
14:48
this is because it comes up in the context of how records can
14:53
exist only in the wall. A commit is when the database
14:58
takes all the most recent page versions from the wall, copies
15:04
them into the main database file, and then deletes the wall
15:07
file. So if you're feeling confused
15:10
about committing the commits, I think we got you covered here.
15:13
So basically what it boils down to is any transaction for the
15:19
database is going to be committed to the wall file.
15:24
You can be adding a new record, you can be deleting an existing
15:29
record, and then once that transaction is completed, then
15:35
it's committed to the wall file. But then to weapons point,
15:40
that's how we have so many versions of the same record in
15:44
the wall. The data in the wall is not
15:48
going to be entered into the actual database until the
15:53
checkpoint is reached. And so the checkpoint happens at
15:58
a couple different occasions. It's either going to be because
16:01
you hit a size limit or the app or the database is closed.
16:06
And then when that checkpoint happens, the wall is cleared
16:11
whether it reaches a size limit or if it's closed either way.
16:14
And then once all that data is cleared out, that wall file is
16:18
deleted. OK, so once a checkpoint occurs,
16:22
the wall file is gone and any deleted records that existed
16:27
only in the wall frames are gone with it.
16:30
If a record is created and deleted before that checkpoint
16:34
happens, it might only ever exist in the wall file, never in
16:38
the main. Database and so think about how
16:41
you use your iPhone right? Many of us just leave it on for
16:45
days and days and days. So we're not shutting it down.
16:49
And so these checkpoints are only going to happen if we're
16:53
closing our apps and sometimes we don't even do that very
16:56
often. So we're kind of a lot of
16:58
instances we're waiting for that file size limit to hit before
17:02
these commits occur. So hopefully thinking about it
17:05
like that, you can see how something may have only ever
17:08
existed in the wall and never actually have shown up in the
17:12
database. Hopefully this makes it maybe
17:16
just murky water now instead of muddy water.
17:20
Starting to clear out. Yeah, Now back to his testimony
17:24
when he was asked about deleting data from the peeling.
17:28
He's clear that deleted data cannot be recovered from it.
17:32
If a record is present in the P list, it hasn't been deleted.
17:36
Now regarding the history dot DV, he reiterates what he said
17:40
earlier that the record IDs are are unbroken.
17:44
There is no evidence of any deletion between January and
17:48
February 2nd. And then regarding the knowledge
17:50
C, he explains that the data is constantly being added and
17:55
deleted by the system itself. None of that stuff happening in
17:59
the Knowledge C is at the users discretion and we can't say for
18:04
sure what was deleted from the Knowledge C, but you can see
18:08
that during the times that Safari was being used, records
18:12
exist within the Knowledge C and they seem to indicate that
18:18
nothing was deleted. So regarding deletions in the
18:21
browser state DB, he says it contained numerous deleted
18:26
records. 3 records were recovered from the wall file,
18:30
all with the timestamps very close to 227 and 40 seconds.
18:35
AM. When asked about the options for
18:38
deleting data from the browser, state Database Within explained
18:42
that the first and most prominent option is is to delete
18:46
absolutely everything from the device or delete all history
18:52
from the device, which as he mentioned, they knew didn't
18:56
happen because other records still existed.
19:00
So the only other real option is to delete selectively, which
19:05
could mean deleting one at a time, or deleting either the
19:08
full day in the last two days or in the last hour.
19:11
But in all of those cases, the record must exist in history dot
19:16
DB in order to be deleted. Since the searches don't exist
19:20
in the history dot DB, the user doesn't have the option to
19:24
selectively delete it. And that makes sense.
19:27
If it's not there, you can't do anything with it.
19:29
That's right. Next, another exhibit.
19:32
This one is 6/22, and these are some browser state dot DB
19:37
records. And there are some red lines
19:40
documenting where one or more records have been deleted.
19:45
Now deleted in this case means that the application would not
19:50
see the wreck. So like the application doesn't
19:53
know it existed. That's what that means.
19:55
And he goes through and explains the columns and he notes some of
19:59
the different missing record ID's and asked, you know,
20:03
overall what he could determine from the dates and times of
20:07
records, umm, 4024 and 4025. And if you look up the exhibit,
20:12
it'll make a little more sense. But he stated that.
20:14
They matched when a tab was shown to the user.
20:18
Next he was asked what he can determine about records 4026 and
20:23
4027 and he said there was actually about 5 records within
20:28
the browser state dot DB with all within about 9 seconds
20:33
around that 2:27 AM time stamp with all sorts of sites being
20:37
visited, going from PayPal to YouTube and I think there was
20:42
even some banking stuff. But anyways, he was next asked
20:45
about spontaneous deletions and he said that's not a term he'd
20:50
use, but essentially it's a cleanup operation for records
20:55
that aren't required anymore. He said that with his testing,
20:59
he was not able to replicate any spontaneous deletions, but he
21:03
was able to replicate orphaned records.
21:08
I don't know, Becky, did we cover?
21:09
Like, what means do you want to do that?
21:11
OK, so basically it's kind of like, you know, in the in the
21:14
parent child relationship, if you think about people, once you
21:17
no longer have a parent as a person, you're an orphan.
21:21
And so the same things, if you are a piece of and whatever your
21:25
parent was, whatever you belong to, if that's gone now you're
21:29
orphaned. And so, and we see it a lot in
21:32
folders, folders get orphaned, folders get deleted, but then
21:35
you can still like recover parts of the files.
21:37
And so they're orphaned files. And in this case, we've got
21:40
records and parts of records that are being recovered from
21:43
the database that are orphaned. And so files and database files
21:47
and folders, files and file system can end up being orphaned
21:52
when they're deleted. There's no connection to any
21:55
path. So more exhibits related to
21:58
Exhibit 622 or up next, exhibit 623, Hockomock sports entry in
22:05
history dot DB related to that record 40264026 from the browser
22:12
state dot DB that within just indicated was a deleted record.
22:17
These are two history records from the evening of 127 to the
22:23
Hockomock Sports website. Exhibit 624 shows visits to
22:28
YouTube in the history dot DB related to the browser.
22:32
State dot DB recovered through deleted record E 27.
22:39
These were visited in the afternoon of 127 and related to
22:43
the It's rain, It's raining men on YouTube.
22:46
Exhibit 625 is entries from history dot DB for record 4029
22:53
from the browser State dot DB and it shows URL's related to
22:58
Canton High School visited on the afternoon of 128.
23:02
Exhibit 626 is entries from history dot DB for record 4030
23:08
from browser state dot DB. It shows Ozone Basketball was
23:13
visited on 1/25 at 11:26 AM. So to kind of summarize what all
23:19
that means is we have to remember that browser state dot
23:22
DB is keeping track of tabs. And so those records are keeping
23:28
track of tabs. He's kind of backwards figured
23:30
out what all that sort some of that session information was.
23:34
And when he tries goes and correlates it to the history,
23:37
you see a variety of websites. But I think the important thing
23:41
to take away from these different websites that were
23:44
being visited overtime is that all of these dates were from
23:49
before January 29th. And so I think that's the key
23:54
take away there in my opinion. Now he was next asked about the
23:58
totality of his analysis and what conclusions he came to in
24:03
terms of the timing of the two searches in the question or
24:07
excuse me, in question within stated and I'm quoting.
24:10
In conclusion, I determined that the tab that was used was
24:14
focused at two 2740 seconds AM, so the tab was opened at that
24:22
time, at which point it was being used to show Ozone
24:25
basketball and Hockomock sports websites.
24:29
The 6:23 AM timestamp is when the search was first conducted.
24:35
It never loaded the page, otherwise there'd be a record
24:38
for it in the history database. And while that page was still
24:42
loading, a secondary search was conducted for House Long to Die
24:47
in Cold again. That page never loaded either,
24:51
although both did show up in the Knowledge Seed database to show
24:55
that the browser was trying to display these pages.
24:59
Safari was closed prior to House Long to Die in Cold was recorded
25:04
being shown to the screen at all.
25:06
But when it was reopened at 10:33 AM, in regard to what
25:13
other, whatever other Safari activity was being conducted, it
25:17
appeared on the screen. So basically what he was saying
25:21
there is you have this 10:33 AM record where House Long to Die
25:26
in Cold was finally shown on the screen, even though the page
25:31
never successfully loaded. So, so we heard a little bit
25:34
more about 10:33. Right, absolutely.
25:37
So when asked whether any of the data marked as deleted was
25:40
actually user deleted, or whether a user actively went
25:44
through the process of deleting it, within stated, We know that
25:49
she didn't. We know that nobody deleted the
25:52
entire history, so that leaves the only option to be
25:57
selectively deleting records. The fact that there are no
26:01
missing records in the history shows that it's impossible that
26:05
the user could have deleted that record.
26:08
It could have just been orphaned and in the database, and I
26:12
believe would have deleted itself at some stage whenever a
26:17
particular cleanup function ran. Although as I said earlier, I
26:22
haven't been able to replicate that and that's and that's
26:26
within speaking. And those orphan records he's
26:28
talking about again, are from that browser state dot DB.
26:32
And he's talking about that cleanup function running in or
26:37
four or two, however you want to say it to that browser state dot
26:41
DB. And when he's done in that last
26:44
statement, if you look at, he's looked at what's happening
26:48
between the two different databases.
26:49
And really his testimony has been building this whole time
26:53
regarding what was happening regarding those searches by
26:57
using multiple artifacts along the way to explain what was
27:03
going on. Right, right.
27:04
When asked if he reviewed the affidavit of Richard Screen over
27:10
the course of his analysis and testing within confirmed he had
27:15
and stated that he had issues with the several of the
27:19
statements being made as part of the affidavit.
27:22
When asked what those issues were, he stated namely it
27:25
specified that the Celebrite report identified that the
27:29
search was conducted at two 2740 seconds AM.
27:33
And as I've explained, as within his talking, I believe the tab
27:36
took focus at 22749 when the search occurred.
27:41
The report mentioned that this Albright report identified it
27:44
was deleted by the user. We don't do that.
27:47
We'll tell you the record is deleted, but we don't specify
27:52
how the record was deleted. That's something for the
27:54
examiner to determine. And then there was a mention of
27:58
the purpose of the browser state database.
28:02
The explanation given was correct for iOS 14 and below,
28:07
but not for iOS 15 and above, which is relevant in this case.
28:14
And then he mentions something which I think is really
28:16
significant. He's asked about what Celebrate
28:21
has done about this time stamp. He said that Celebrate itself
28:25
has recognized that the browser state dot DB time stamp, the one
28:29
that we've been talking about for like almost 4 episodes now.
28:33
Well and then five if you count the affidavit, right.
28:36
So a lot of time he says that they, they being celebrate,
28:40
think the time stamp could be misleading and they have made a
28:44
decision to remove it from their output altogether.
28:48
So the software now shows that a page has been visited, but it
28:52
does not always attribute or it does, it simply does not
28:56
attribute a time to it anymore specifically because in his
29:00
words, that time stamp could be wildly inaccurate.
29:05
He said wildly. Those are his words.
29:07
And so you have to look at this, this company makes a wild or a
29:12
widely used digital forensic tool.
29:14
A lot of people in law enforcement and celebrate looked
29:17
at this time stamp and they decide it was too unreliable to
29:21
display. So it's not a minor footnote,
29:25
not something to breeze over really.
29:27
But as examiners, you still have to remember that this time stamp
29:31
still exists. And so if you or the opposing
29:35
examiner is manually digging into the data and reviewing the
29:39
raw contents of the database, they will see it so we don't
29:43
just get to forget all about this artifact.
29:46
Exactly. So Next up, Next up is a live
29:50
demonstration. Before the demonstration begins,
29:53
the judge addresses the jury directly.
29:55
She instructs them that what they're about to see is simply a
29:59
demonstration to help them understand the evidence in this
30:03
case. It is not itself evidence, and
30:06
they must decide the case based on the evidence presented to
30:09
them. The lawyer then asks Within
30:12
whether he was able to prepare a demonstration related to what
30:16
he's been discussing throughout his testimony, and he says yes.
30:20
The lawyer then walks through a couple of clarifying points with
30:23
him before they start. He confirms that the
30:25
demonstration doesn't specifically reflect the
30:28
searches or the extraction report from this case, and
30:32
Within agrees with that. The lawyer then asks whether the
30:35
demonstration does address the overall issue he's been
30:38
discussing throughout his testimony, and Within confirms
30:41
that it does so. The jury hopefully understands
30:45
going into this that it is not a recreation of what happened on
30:50
the phone in question, it's an illustration of how the
30:54
technology behaves. So Whiffin then shows his iPhone
30:58
screen live in the courtroom. It's being projected on the big
31:01
screen so the jury can see it, the courtroom can see it, and on
31:05
the other half of the screen, he's got his Art X tool.
31:08
And he takes a moment to explain that what Art X is doing, it
31:12
basically has a feature that allows you to see the files from
31:15
a connected device in near real time.
31:18
So it basically maps or syncs or copies whatever word you want to
31:22
use those folders and files to your computer.
31:26
And then he explains that this is useful because it increases
31:30
the speed. So instead of having to conduct
31:33
a full extraction every time you want to check something, you can
31:36
simply refresh and then pull the most current version of the
31:39
files down directly from the phone directly to your computer.
31:44
So now he is navigating to the copy of the phone files that are
31:48
present on his computer. He navigates straight to the
31:52
browser state dot DB and opens it and shows the jury that at
31:57
this moment there are no records in it.
32:00
He then provides the context for what they're about to see.
32:04
He explains that he has Safari open on his phone from the night
32:10
before. At 8:10 the previous evening, he
32:15
opened a brand new tab in Safari and performed a search.
32:19
That tab is still open on his phone right now in the
32:22
courtroom. He chose his search terms
32:25
deliberately. He searched for the date and
32:28
time, which makes it easy to track and document rather than
32:32
using something generic like Test one or test 2.
32:35
Time and date are essentially built right into the search
32:39
results so that you can follow along clearly.
32:42
And then he performs a live search for the current time, so
32:45
he's in Safari, and he searches for 1442 so the jury can see a
32:50
real search being conducted in real time.
32:53
So after that search is done, he goes back into Art X and hits
32:57
the reload button. And then with that Press of the
33:00
button, Art X deletes the copy of the database that's on his
33:03
computer, and it pulls the most recent copy down from the phone
33:07
and puts it on his computer. He opens it up again.
33:10
He shows the jury the result. It still shows no records in the
33:15
browser state DB still empty. Nothing has changed.
33:19
And here he explains why. He explains that this is
33:22
expected behavior because he has not closed this tab yet.
33:28
The search was conducted, but the tab is still open.
33:32
And then he draws the direct comparison.
33:35
So he says if it was iOS 14 then there'd already be a record in
33:40
the browser state dot DB showing that this tab is open.
33:43
But iOS 15 doesn't work that way and records only get written
33:49
when a tab is. Closed.
33:52
So to make sure the jury sees the entire process, he goes back
33:57
to Safari and closes the window. Then he goes back into RX and
34:01
hits reload again, and this time records appear in the browser
34:05
State dot TV. He pulls up the newly presented
34:09
record and walks the jury through what it shows.
34:12
The title of the record reflects the 1442 search Google search,
34:17
the one he just conducted moments ago in the courtroom.
34:21
He points out that the Google search record is right there,
34:26
but then he draws their attention to the last viewed
34:29
time field and it still shows 8:10 PM from the night before.
34:34
Not 1442. Not the time of the search he
34:37
just did. 8:10 PM, the time he originally opened that tab this
34:44
the previous evening because that is when the tab first took
34:49
focus. The time stamp reflects when the
34:51
tab was focused, not when any search within that tab was and.
34:57
With that, that concludes his direct examination.
35:00
And I mean, wow, like a live demonstration in court.
35:04
Becky live. You and I both know live demos
35:07
are always risky, no matter when or where, no matter how much you
35:11
prep. But to do this in in open court?
35:14
Yeah, That's that's, that's brave.
35:17
Yes, very brave. I am curious as to whose idea it
35:21
was to do this demo. Based on the instructions, I bet
35:26
there was a little bit of heated debate behind the scenes.
35:29
But to reiterate, what was the purpose of this demo?
35:33
It was to show when that time stamp gets updated.
35:37
Even as an examiner, I thought this demo like really, it was a
35:41
nice walkthrough to see it happening real time.
35:43
So if you're a visual person, it kind of put makes it more tan.
35:48
Some stuff you can see on the screen.
35:49
He was using an iPhone 6S running iOS 15 dot 8.2.
35:55
So that's a little bit newer version than McCabe's phone.
35:58
The file names are kind of hard to read on the screen, but you
36:01
can see he's in the folder that contains the browser state DB,
36:05
so you can make the assumptions. The other files present are the
36:08
wall and the dot. Now we move into cross
36:11
examination the Fed. The defense starts by getting
36:16
into how Wiffin became involved in the case.
36:19
And it was because this the timestamps didn't make sense to
36:23
investigators. And he agrees with that, that
36:26
characterization. The defense then asks whether
36:30
Trooper Proctor was one of the investigators on the case, and
36:34
Within says he doesn't recall any names specifically because
36:38
the case came to him through another celebrite examiner
36:42
rather than directly from law enforcement.
36:44
The defense shifts then to the demonstration itself and starts
36:48
pressing on the question of whether or not it was truly a
36:52
fair comparison. They ask within whether when
36:55
conducting A demonstration you would want it to be as as close
36:59
as possible to the real conditions, essentially an
37:03
apples to apples comparison. And within agrees with that
37:06
principle. Then the defense gets specific
37:09
about the iOS versions. He asked within what versions he
37:12
tested and he said he tested versions 12 through 17 and even
37:18
a beta version of 18. And then as I just mentioned,
37:21
this demo was actually conducted on a device running 15 dot 8.2.
37:26
And then the defense points out that the phone, in this case
37:30
from Jennifer, Jennifer McCabe's phone was running 15 dot 2.2,
37:35
and he agrees that he's aware of that.
37:37
And then the defense asked whether the way an artifact is
37:42
stored on an iPhone can depend on a specific iOS version.
37:47
Whiffen agrees that it can, and he also agrees that he didn't
37:50
use the same version, though he mentioned it was the closest
37:55
version he could get his hands on.
37:57
The defense then moves to the deleted browser.
38:00
State record asks Within directly.
38:03
Was the 2:27 AM record deleted? Within says yes.
38:08
The defense then asked whether he was able to recover the data
38:12
contained in that record. Within confirms that he was.
38:15
He recovered the 2:27 AM time stamp and the Google search URL
38:21
for House Long to die in cold. The defense then asks
38:25
specifically about the session history, and Whiffen agrees that
38:30
he was not able to recover that, so the record itself was
38:34
recovered, but the session history associated with it was
38:38
not. The defense asks whether Whiffen
38:40
conducted his demonstration using a different operating
38:43
system than the 1 running on the phone.
38:45
In this case, Riffen agrees that he did.
38:48
He was then asked about whether his own testing produced a
38:52
situation where a wall file contained a deleted record and
38:57
the session history. Not recoverable, He says yes.
39:01
He explains that in the instance, the session was so
39:04
large that some of the pages had been overwritten, which is why
39:08
the session history couldn't be recovered.
39:11
He's then asked whether he was able to recreate the other
39:15
deletions. The other records that appeared
39:18
as deleted in his exhibit, not just the one tied to the house
39:22
Long to die in Cold search. Wiffen stated that in his
39:25
testing when he selectively deleted items from.
39:28
History. Those items were also removed
39:31
from the browser state dot DB, so he was able to replicate that
39:36
behavior OK Wiffin continues that there are five possible
39:41
methods for deletion and he ruled out four of them during
39:44
his testimony today. That leaves 2 user deletion and
39:48
another method that isn't fully understand and that Wiffin
39:52
himself has said he can't replicate.
39:54
The defense states if 4 methods are ruled out and one can't be
39:58
located or explained, then the only method left is user
40:03
deletion. Wiffen's response is equally
40:06
plain that that is not the case. That is not in this case.
40:11
The defense follows up by asking Wiffen to agree that selective
40:15
deletion means the user selects what they want to delete, and he
40:19
agrees, and then he's asked to describe who the user is, and
40:24
Whiffen says it's whoever's using the iPhone itself.
40:27
The defense asks another pointed question.
40:29
Would Whiffen agree that someone who had access to the data
40:34
before the extractions were made, could they have performed
40:37
selective deletions of that data?
40:41
There's an objection, the judge allows it, and then what
40:45
Whiffen's answer is. No.
40:47
The defense then asks whether Whiffen is familiar with an
40:51
application called My Sequel. He says he is.
40:55
The defense then asked whether someone with access to that
40:58
application could use it to make selective deletions.
41:02
Wiffin explains that if someone had the extraction, they could
41:05
technically remove a file, alter it, and then replace it.
41:09
But he notes that the hash values would document that a
41:12
change had been made. In other words, it would have
41:15
wouldn't be invisible. There would be a detectable
41:18
record of the alteration. Next, he's asked whether someone
41:22
could read numbers, the data in the history dot DB and the
41:25
knowledge C to cover their tracks.
41:27
Wiffin says it could theoretically be done, but that
41:31
it would require a significant level of knowledge and skill to
41:34
do it in a way that wasn't detectable.
41:37
And we are nearly at the end. It's time for the redirect.
41:40
The prosecution comes back and asks about the iOS version
41:44
discrepancy, specifically whether the difference between
41:48
the version of the demonstration device and the version of on
41:51
McCabe's phone has any impact on what Wiffin showed the jury.
41:56
He answers that in every iOS version 12 and 18 that he
42:03
tested, the last few time was consistently been recorded as
42:08
the time the tab took focus. That behavior has not changed
42:13
across versions, so the version difference does not affect the
42:17
conclusion he drew from his demonstration.
42:20
Regarding the question of selective deletion, he
42:22
reiterates his position. There is no evidence of
42:26
selective deletion in this case, and he points back to the same
42:30
foundational facts that he established earlier.
42:32
The row IDs in the history DB are unbroken.
42:36
There's no missing records. If a selective deletion had
42:39
occurred, there would be gaps and there are none.
42:43
On the hash values, the defense raised the possibility that
42:46
someone could have tampered with the data.
42:48
The prosecution asks within about that directly.
42:51
He says he did not have access to the values in this case.
42:55
He did not see anything in the data that would indicate
42:58
tampering had occurred. He acknowledges that it could be
43:01
possible, but he is unclear that it would require a considerable
43:06
level of skill and expertise to carry out without leaving a
43:10
detectable trace. And then the prosecution asked
43:13
him perhaps one of the most important questions of his
43:16
testimony, what is his opinion as to when those Google searches
43:22
were actually conducted? He says he has no doubt that
43:26
they were conducted at 6:23 and 6:24 AM on the morning of
43:30
January 29th. And that is the conclusion of
43:34
Anne Wiffen's testimony. So we've covered a lot of ground
43:37
across these two episodes, dates and times regarding the house
43:41
long to die in the cold and how long to die in, to the basics of
43:48
how SQL I databases work, to wall files and deleted records,
43:54
and even a live demonstration conducted in open court.
43:58
Stacy, what do you want to go back and discuss?
44:01
Well, I think I want to talk more about the lawyers a little
44:05
bit here at the end and they're questioning because, you know, I
44:10
think a lot of the first half of his testimony is just in within
44:15
is getting the facts and he's talking about all the things.
44:18
And then kind of towards the last half, there's a little bit
44:21
of new information coming in. But now the lawyer is asking him
44:26
for his opinions and his conclusions.
44:29
So he's reiterating those facts again, but in a much shorter
44:33
form. So he could share basically the
44:35
key takeaways. So he's like, you know, it's
44:38
kind of like, hey, jury, I've been talking for a long time,
44:41
probably a couple hours at this point.
44:43
And so he's the lawyer is getting him to be like, what
44:46
does this all mean? He's sharing that.
44:48
So like, you know, especially that very last question at the
44:51
end, basically, when were those Google searches conducted?
44:54
He says 623 and 624. He's got a lot of the The lawyer
44:59
did a lot of good job of asking what great questions to clarify
45:03
what does all of this gobbledygook.
45:07
Mean. Yeah.
45:08
And I think that the slow, methodical way of handling this
45:14
technical testimony is the right way to do it because with a
45:19
repeat of questions, with a repeat of steps, with a
45:25
methodology put together and then doing a live demonstration,
45:29
wow. And being successful, you're
45:32
seeing what he's doing to come to these conclusions.
45:36
Yeah, yeah. And he never once said, well in
45:40
terms of like he wasn't ever quoting like well Celebrite said
45:43
or Axiom said or this other tool said.
45:46
He was explaining what he found, what his analysis said, what his
45:51
testing said all along the way. And in terms of time, the
45:58
defense and their cross examination wasn't really too
46:02
long at all. They tended to ask a lot of
46:05
their questions of wouldn't you agree with me?
46:09
I think that was kind of a lot of their questions.
46:11
They want you to agree with them.
46:13
Yeah. And they're, they're of course
46:17
trying to demonstrate what they believe happened and get you to
46:23
say that like, I don't know, they're trying to get you to be
46:26
like, everything I just said is wrong, right?
46:27
Sure. It's kind of what they want to
46:29
say if your position is not supporting their position.
46:33
But they didn't cut him off right away.
46:36
They they let him explain like, oh, I, I deleted more than than
46:40
just, you know, or I tested more than just, you know, the one
46:44
version that didn't match. I went backwards in time and I
46:48
went forwards in time of what's been released and they all had
46:51
the same behavior. So I think that was very good
46:54
for him to get in again with the defense.
46:57
I'm asking those questions. But then again, also, you know,
47:00
when he said, well, wouldn't you like to have the apples to
47:03
apples? He agrees.
47:04
He also agreed that it wasn't the exact same version.
47:08
So and he didn't like, you know, he wasn't unprofessional, He
47:12
wasn't snippy about it. He's just like, like these are
47:15
the facts. And that's always the approach
47:19
that we have to take to they take with these things, because
47:22
there are times where this is our conclusion.
47:25
And just like what Jessica said with like about the whatever the
47:27
panda comment was, sure, there's this slim chance.
47:31
Sure, sure it could happen, you know, and that's, that's just
47:34
how some of it goes. That's.
47:35
Right. That's right.
47:37
Well, join us every week on Thursday as we continue to dive
47:40
into Karen Reed's first trial. Yeah, if you've enjoyed this
47:44
episode, we're just asking you to do us a favor and share this
47:48
with your network work. Leave us a review wherever you
47:51
listen. It helps new listeners to find
47:54
us. So until next time, stay safe,
47:57
stay sharp, and as always, keep parsing the truth one bite at a
48:01
time. If you enjoyed this episode,
48:05
make sure to follow us to get notified the next time a new
48:09
episode drops. If you can do more, head on over
48:12
to parsingthetruth.com and donate by clicking on the donate
48:16
button. Parsing the Truth is a nonprofit
48:18
organization and we are raising money to send a new digital
48:22
forensic examiner to I Asus training next year in Orlando.
48:26
Thanks. OK, so what's going on?