Latest / Parsing the Truth: One Byte at a Time / Karen Read 1-2: Jessica Hyde Testimony Part 1

Transcript

Karen Read 1-2: Jessica Hyde Testimony Part 1 · 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. Welcome back to Parsing the
0:53
Truth One Bite at a Time. I'm Stacey Eldridge and with me,
0:57
as always, is my Co host, Becky Passmore.
1:00
We are the podcast that focuses on digital forensics in today's
1:04
modern crimes. So yes, we're talking about true
1:07
crimes, but our unique focus is the facts and artifacts from the
1:12
digital evidence in these cases. What are the digital forensic
1:16
examiner's doing in saying that's our focus, Becky, what
1:20
are we doing tonight? Well, today.
1:22
We are continuing our coverage of the first Karen Reed trial.
1:26
In tonight's episode, we're covering the testimony of
1:30
Jessica Hyde, who was called as an expert witness to discuss the
1:34
digital evidence from Jennifer McCabe's iPhone.
1:37
If you haven't listened to last week's episode, Season 1 Episode
1:42
42, you might want to go back and listen to that first because
1:46
that's when and where we discussed Richard Green's
1:50
affidavit, which ultimately led to Jessica Hyde and Ian Whippen
1:56
being called in to work on this case.
1:58
And as digital forensic examiners ourselves, we're
2:02
particularly interested in the digital evidence.
2:05
And so we're going to use Jessica Hyde's testimony as an
2:08
opportunity to learn about all the different artifacts that are
2:11
discussed and also to learn more about what goes on in the
2:15
courtroom. We're going to share our
2:17
thoughts to guide you through this awesome learning
2:20
opportunity. And we're make it very clear as
2:23
we're going through this stuff, like what were the things that
2:25
were said in the courtroom versus our own commentary.
2:29
So with that being said, Becky, let's dig in.
2:32
Let's go. So Jessica Hyde has taken the
2:35
stand. The attorney begins by going
2:38
through her background and experience to get her qualified
2:42
as an expert. There are a couple of things of
2:45
note. Hyde is prior military and is
2:48
the founder of Hextoria. In this case, Detective Brian
2:53
Tolley requested her services and she was specifically asked
2:58
to examine 2 Google search terms from January 29th and to look at
3:03
the timelines and the timestamps related to those searches.
3:08
She also received and reviewed the Richard Green affidavit and
3:12
Trooper Nicholas Gariano's written report before beginning
3:17
her analysis. So jumping back to last weeks
3:20
episode, you have to remember that the Green outlined in his
3:24
affidavit that Jennifer McCabe was searching for House Long to
3:31
die in cold at 2:27 AM before John O'Keefe was found.
3:38
To get started, Hyde received a copy of the full file system
3:42
extraction from Jennifer McCabe's phone.
3:45
She made a copy of it and then she verified the verified that
3:48
the hash values matched the original.
3:51
She explained to the court what a hash value is and why it
3:55
matters in terms of forensic integrity.
3:58
And she also listed some of the tools that she used.
4:00
So she used the Arc Point Atrio to make that copy.
4:05
And then she also used some standard industry tools,
4:07
Celebrite Physical Analyzer, Axiom Art X, ILEAP and Sanderson
4:13
Forensic Browser for SQ Lite. So when the attorney asked why
4:18
she used so many different tools, I'd explained that
4:22
different tools have different capabilities.
4:25
There are so many apps that some tools may not process everything
4:31
you compare results and enhance with manual analysis.
4:35
Her focus was specifically limited to January the 29th and
4:40
Safari. Now, before we get too far into
4:44
this testimony, we want to point out the two searches that are
4:48
going to be discussed throughout this segment.
4:52
We talked about it last week. We already mentioned one of them
4:54
once, but the first search term that came into question is the
4:58
phrase house long to die in cold.
5:02
So it's house. HOS was how it was typed.
5:06
And then the second search term that is going to be discussed is
5:10
how long T die in kick D. And so it's how long tti die in
5:18
kick DCIKD. So just listen carefully, do
5:22
your and we're going to do our best to enunciate it.
5:24
But those are the two phrases that we are talking about.
5:27
And in her written report, she stated that her task was to
5:30
understand the timeline of those two different Google searches
5:35
when they occurred on January, so specifically the how long to
5:40
die in Kikti and House Long to die in Cold.
5:44
Now, on the stand, she was asked whether she looked at anything
5:48
related to deletion. And she explained that Richard
5:52
Green had stated in his affidavit that one of the search
5:55
terms had been deleted, and so she was looking to determine the
6:00
reason for that suspicion. So Hyde went on to explain that
6:04
tools may notate certain things as recovered and there is
6:08
sometimes confusion about what the tool means by recovered
6:14
versus deleted. She actually co-authored a paper
6:18
on this topic titled Standardization of File Recovery
6:23
Classification and Authentication within Casey and
6:28
Alex Nelson, which can be found on Science Direct will link to
6:33
this document in the show notes if you want to more about it.
6:37
But the thing to know about recovered files is that in the
6:40
celebrite, the recovered artifacts have a red X symbol
6:45
next to them and. Both of the reports that she
6:48
mentioned have an artifact called com dot apple dot mobile
6:54
dot safari dot P list. First off, she explained that
6:59
this name that I just read out loud is a reverse domain.
7:03
So instead of, you know, you're used to seeing apple dot com,
7:06
this started with the opposite com dot apple.
7:09
And that's very common. You're going to see this when
7:11
you are dealing with iPhones, Androids, and that sort of
7:16
evidence. But she explained that this dot
7:19
P list also stands for property list and that it contains search
7:24
history. And we want to also point out
7:27
that there is other data in the P list in addition to the search
7:30
queries. Excuse me.
7:32
So it's not just search queries only in this P list file.
7:35
But another thing you need to know if you're looking for
7:39
search queries to show up in here in this com dot apple dot
7:43
mobile dot safari dot P list is that it's only going to show up
7:48
if you are using that search bar that appears on your iPhone
7:52
directly above the keyboard on the iPhone.
7:56
If you are on.google.com or any other search engine and you're
7:59
using the search box for that website, it's not going to show
8:03
up in the P list She. Also found evidence in knowledge
8:08
C dot DB which is a system level artifact.
8:13
It's an Apple database meant to store information about user
8:18
activities so the device can determine future functions and
8:23
suggestions. We want to point out that it
8:26
logs both system activity and user activity and contains
8:31
roughly 30 days worth of data and she.
8:34
Noted that not all of the tools picked up this search for House
8:39
Long to die in Cole. She specifically noted that
8:42
Celebrite did find it in the wall file.
8:46
So UAL the wall file record associated with the browser
8:51
state dot DB. And sometimes you'll also hear,
8:56
and this is my commentary, you'll also hear that these
8:59
artifacts from this database can be referred to as suspended
9:03
state tabs. You might hear people talk about
9:06
it that way. You might also see it notated as
9:10
that artifact type, that artifact category when you're
9:13
looking at your forensic tools. But so this search, this entry
9:19
for House long to die in cold associated with the browser
9:24
state dot DB is the artifact that was marked as recovered
9:29
based on her testimony. At this point, it sounds like
9:33
Axiom and maybe some other tools have not found this.
9:36
So we want to make a note to kind of keep track of that as we
9:39
continue to break down her testimony and the testimony of
9:43
others as we go forward and see what else is said about the
9:47
schools and what they did or did not see in terms of this search
9:51
for house long to die in the cold in the wall file for the
9:55
browser state right so. Then the attorney asked her to
9:58
define what a wall file is, and she started by explaining how a
10:04
SQLite database works. She used an analogy for the
10:08
SQLite DB database by stating it's similar to an Excel
10:13
spreadsheet where a table is like a page.
10:16
In the spreadsheet, all changes go to something like a text file
10:20
1st, and then those changes are written when the spreadsheet is
10:24
closed, whether you're adding or deleting the data, I think.
10:28
That Excel spreadsheet analogy for a database pretty standard.
10:32
I've used it, but I have not had to explain what a while what a
10:38
wall file is on the stand. So I'm interested to hear what
10:42
her analogy is for this wall file.
10:44
So let's go into that now. She actually uses a restaurant
10:48
analogy to explain it further. And she explains that if you're
10:52
in a restaurant and you order some food and you need to think
10:56
of the food as the data, and you're at a table where the
11:01
table is where it's going to when you request that data.
11:06
And so you're saying I'm adding to it and it can go to an area
11:10
where the server is going to go grab it from the warming
11:14
station, which is like the right ahead log.
11:17
So she's saying that warming station where the food goes and
11:21
sits when it's done in the kitchen and then the server's
11:24
going to bring it out to you. That is kind of like the ride
11:27
ahead log. And so different tables can be
11:30
ordering food and food is constantly being put there in
11:35
the wall file in the warming station in her analogy.
11:39
And so another example she gave was that if somebody's steak
11:42
came out too rare and it needed to be cooked more, they could
11:46
send it back. And that would also go to the
11:49
warming area. So you can see that you've got
11:52
things going to and from the tables, things are coming out of
11:56
the kitchen and things are being sent back to the kitchen
11:58
simultaneously. So that storage area, in this
12:02
case, the actual law file or this warming area and analogy
12:06
would contain both the newest stuff that just came out of the
12:10
kitchen and then the old stuff which is coming back, which is
12:13
essentially think of it as being deleted if you're sending your
12:16
food back. And so bringing it back to the
12:20
actual data part of it, she continued, She said, here's what
12:24
a wall file contains. It's going to contain things
12:26
such as your newest searches, your newest messages, as well as
12:31
anything that has been flagged for deletion.
12:34
And I personally think this is a really helpful analogy.
12:38
I, I pondered it. I don't know that I can think
12:40
of. I, I couldn't think of anything
12:42
better. I think it's good.
12:43
I think it's great. I think that it resonates with
12:48
people in the jury. You know, they can visualize an
12:51
analogy like this, and that's why I'm making your analogies
12:55
very clear and something that can be visualized by your jury
12:59
members. So yeah, I agree.
13:01
I think it's a great analogy and I.
13:03
Don't know if I did enough justice to it when I was trying
13:06
to summarize it here. So you can certainly go back and
13:09
then we'll link to her testimony and listen to that snippet.
13:12
We'll put the time stamp in the snow show notes.
13:14
So if you want to hear her explain it really well, you can
13:17
go and do that as well. So Hyde also.
13:20
Clarified in the context of the wall file that she means when
13:26
she says data is marked as deleted in a database context,
13:32
she's not talking about a user actually taking action to delete
13:36
this text message. In database terms, deletion
13:39
means removing data from the database itself.
13:43
She explained that closing a tab can trigger a deletion event in
13:48
the database, so it's worth clarifying that the user cannot
13:54
delete records from the database directly, and they cannot delete
14:00
records from the wall file either.
14:03
So remember, this wall file is going to be the temporary
14:09
folding space until the database is closed.
14:13
The database won't be closed in this case until you close the
14:17
Safari tab. Exactly.
14:19
And since we have this wall file, we know that Safari was
14:23
still open when they did the extraction from the iPhone.
14:26
And another part of her testimony, she touched on the
14:30
concept of an artifact and she defined it as any trace that's
14:35
left behind by any action on a digital piece of data.
14:39
She also mentioned BLOB files. So BLOB is BLOB.
14:45
And she explained that a BLOB is used for data that's too large
14:49
to be stored directly in the database.
14:51
It could be for attachments or even possibly used in relation
14:55
to text messages. Now to dig into this a little
14:59
bit more, A BLOB stands for a binary large object.
15:04
A BLOB stores binary data and it could store all sorts of things
15:11
and so you can see like serialized objects, encoded
15:15
metadata, compressed data, images, audio, proto buffs,
15:20
you'll see all sorts of things in there.
15:22
It just depends on the specific database and what the app that
15:27
is writing to that database it has been programmed to do.
15:31
So if you ever see something that says BLOB or you're seeing
15:35
that BLOB organization, it's important not to skip over them
15:39
because they can contain very important data.
15:43
And we talked about it on one other show.
15:45
We mentioned the tool Rabbit Hole, but that is a great tool
15:49
to deserialize a BLOB if you can't read it otherwise exactly.
15:53
So then Hyde walked us through table one from her report, and
15:58
that was titled Web History Tool Results Combined.
16:03
We'll also tag the this in our show notes, but I'm going to go
16:07
through this table and define everything that was identified.
16:13
So it starts with a 2:27 AM suspended state tab artifact
16:20
with the search term of house long to die in cold, the Google
16:26
search URL and the fact that it's from the browser state dot
16:32
DB wall file. At 6:23 AM, Safari cash record
16:37
artifact for the apple suggested the term How long does it take
16:43
to digest food? Along with thecd.smoot.apple.com
16:51
URL and the fact that it came from the cash dot DB at 623 and
16:59
51 seconds. And there was a recent web
17:03
search artifact for how long tea die in.
17:11
So how long TI die in CIKD know your all is present.
17:17
It comes from com dot apple dot mobile safari dot P list at 623
17:25
and 56 seconds and 6/23/57 seconds AM Google search app Web
17:32
usage artifact how long TI die in CIKD Google search URL is
17:41
present and the artifact is from the knowledge C dot DB at 624
17:48
and 818 seconds AM. There was a recent web search
17:53
artifact of how long to die in cold from calm dot apple dot
18:00
mobile safari dot P list. Then finally it's six 2447
18:06
seconds AM Google Google search of house long to die in cold
18:13
with the Google search URL and that it comes from knowledge C
18:19
dot DB. You don't get a great view of it
18:22
in the courtroom, and the public copy of her report could be
18:26
better quality, so you've got to examine it closely.
18:30
It begins with a 2:27 AM suspended state tab artifact
18:37
containing the search term House long to die in cold with a
18:42
Google search URL coming from the browser state dot DB wall
18:47
file. Then at 623 and 49 seconds AM,
18:52
there's a Safari cash record of the Apple suggested term.
18:57
How long does it take to digest food coming from cash dot?
19:03
Yeah, we. Should note if you go and watch
19:05
her testimony, I don't know if it's it's just her, but she's
19:08
probably 1 of just a couple of people where something happened
19:13
in the courtroom earlier that morning and somebody was shown
19:16
on camera on TV that shouldn't have been.
19:19
And then so the judge made an order that we're switching to
19:22
zoom only. And then you can see at the very
19:24
end of her testimony that she is back on regular camera.
19:28
So I think that's part of the reason why it's hard to see
19:32
because it was on the zoom they couldn't control, you know, like
19:35
tighten the window and zoom in like they had in some of the to
19:38
the other people when they testimoned or testified using
19:41
exhibits shown up in display where you could really get a
19:44
nice screenshot of what was shown up in the courtroom.
19:47
Could not happen at all with this report, unfortunately.
19:50
So we're doing our best here to relay all of that information
19:54
for you. But continuing on, So going
19:58
through this table and her discussion, she notes that at
20:01
6/20, 3:51 AM, there was a recent web search artifact.
20:06
For how long? To Die and Kiki with no URL
20:12
reported and it is coming from that com dot apple dot mobile
20:16
safari dot P list. And then at 62356 and 6/20 3:57
20:24
AM, there are some Google search app web usage artifacts for that
20:31
same how long T die and kick D search along with the Google URL
20:38
coming from the knowledge C dot DB.
20:42
And so a side note here. What this is doing is there's
20:46
two artifacts demonstrating that something happened.
20:51
So there's that cooperation that is an examiner.
20:54
You would want to see that. And so you can see that in her
20:57
table as you read through some of these artifacts.
21:01
Now back to her discussion. At 6/20, 4:18 AM, there is a
21:07
recent web search artifact for House Long to die in Cold from
21:12
the P list. And then finally at 6/20 4:47 AM
21:19
there is a Google search of House Long to die in cold with
21:24
that Google URL coming from the Knowledge C DB, right?
21:30
So then Hyde focused on explaining that at 227 AMA
21:36
timestamp from the browser state dot DB.
21:39
She explained that the browser state dot DB is an artifact that
21:44
tracks when tabs are moved. When you're using your browser
21:49
and switching, closing, or minimizing tabs, that timestamp
21:54
reflects the tab changed state. What's important to take away
21:58
from this is that this timestamp is not necessarily the time of
22:03
the search itself. So keep that in mind now.
22:06
She also explained that if a browser is opened and only one
22:11
search is made, the times could match, but if the browser has
22:16
any tab activity such as closing, minimizing, moving to
22:21
the background, then that can update that time stamp that is
22:25
logged. The search term stored there
22:28
will always be the most recent search term that was in that
22:31
tab, meaning that the last item open in that tab was house long
22:37
to die in cold. However, you noted you cannot
22:41
determine from this artifact alone what time that search
22:45
actually occurred. And another thing we want to
22:48
clarify here is you know she's talking about Google searches,
22:53
but this does not mean that the browser state dot DB only tracks
22:57
searches and search terms. She is speaking specifically to
23:02
this evidence and the but overall this database is
23:06
tracking the last page or the last website that is open in
23:10
that tab. And so the key take away here is
23:14
that this artifact is tracking what is happening in the tab.
23:19
It's not tracking the time of the search.
23:23
And certainly there is website information in there, There is
23:26
that URL data in there. But the purpose of this database
23:31
is to track the tab state hide. Continues.
23:35
That means the last item that was open in the tab was House
23:40
Long to Die in Cold and that we cannot tell by this particular
23:45
artifact what time that search occurred.
23:47
There is a high likelihood that this tab was opened at this time
23:52
because there was another search that occurred at 2:27 AM for
23:58
Hockomock Sports and there were more searches done immediately
24:03
after that and. You can see this is our
24:06
commentary here, but you can see this Internet history for the
24:08
Hockomock sports from the history dot DB and Exhibit 614.
24:14
So we'll link to that as well if you want to look more into the
24:17
Internet history, but that's Exhibit 614.
24:20
Now high continues that this search term is always going to
24:25
be the most recent search term in that tab.
24:28
And again, just to reiterate it, it is.
24:31
This does not mean that the browser state dot DB only tracks
24:35
search terms. She's against talking
24:37
specifically to this evidence. It's tracking the last page, the
24:42
last website open in that tab, whatever it may be.
24:45
That's right. So Hyde shared that the purpose
24:48
of the browser State dot DB is actually to a allow you to open
24:54
Safari on your iPhone, then pick up the same tabs on your iPad or
25:00
Mac. It's what enables that seamless
25:03
experience across all Apple devices.
25:05
And so this is important to keep in mind with these types of
25:09
artifacts. Apple doesn't build them to
25:11
solve crimes. They're built for a specific
25:15
user experience purpose. Browser State dot DB exists so
25:21
you can leave your laptop on your desk and pick right back up
25:25
on your iPhone, say, on the subway.
25:28
So most of these features are also enabled by default because
25:32
it makes it easier for people, Yeah.
25:34
I think that's a great point that you made there, Becky,
25:36
about it's just tracking what's happening so you can go and then
25:41
pick up where you left off on another device, right?
25:44
So jumping back to table one and the 2:49 AM entry that is coming
25:51
from the cash dot DB, Heid explained that this is an Apple
25:55
suggested term. And so as the user is typing,
25:59
Apple is trying to anticipate the search and be helpful and
26:03
suggest something. So in this case, the user is
26:06
typing how long to die and kick the and along the way Apple is
26:13
suggesting how long does it take to digest food.
26:17
The CDN 2 dot smoot URL in the results indicates that it was an
26:23
Apple suggestion, not something the user typed or is what she
26:27
said. Now a couple of things we want
26:29
to point out about this part of the testimony.
26:32
If you're listening, it kind of sounds like she says smooth for
26:36
part of the URL, but we checked the exhibits.
26:38
It is for sure C CDN as in the number dot smoot with AT at the
26:44
end. So it's not smooth.
26:46
But anyways, let's talk about what a CDN is, in case you don't
26:50
know. So a CDN is a geographically
26:54
distributed network of servers that delivers Internet content
26:58
quickly and it's going to be based on your user's location.
27:02
And so when Apple is suggesting something, it's reaching back to
27:06
its servers and then the CDN is going to connect you to the
27:10
closest one to you for speed. Because it's not going to be
27:14
very helpful if there's like 1 server and you're on the other
27:17
side of the planet. And it's got to go back and
27:19
forth to make that suggestion for you, right?
27:22
And another thing to call out here is that this search is also
27:28
shown in the knowledge C dot, which you would expect to see
27:31
because the iPhone is tracking this Safari activity at the app
27:37
level and at the system level. So that's why it's showing up
27:40
twice, yeah. That's right.
27:41
So then Hide explained what the timeline would look like if you
27:47
lined up the activity rather than just the timestamps.
27:52
It starts with the user beginning to type a search.
27:55
Apple makes a suggestion of how long to digest food.
27:59
The user doesn't take that suggestion.
28:02
The user then inputs how long TTID, then a search is made for
28:10
house long to die in cold, which ends up being the last search in
28:16
that tab these. Typos are horrible for trying to
28:19
say healthy search terms over and over again.
28:22
I just rather, I just rather spell them.
28:24
But anyways, it continues. The attorney asked her, and this
28:27
is prosecution still asked her why the table showed 2:27 AM if
28:34
the search didn't happen until later that morning.
28:38
And Hyde clarified that that table is not showing the time of
28:42
the search. It's showing the last time that
28:45
tab was touched or moved to the foreground or the background,
28:50
which was 2:27 AM AM. And she says that some action
28:55
was taken with that tab at 2:27 AM when that Hockomock Sports
29:00
website visit occurred. And then later at 6:24 AM, the
29:06
house Long to die in cold search becomes the final update, the
29:11
final web page for that tab. She says that what exactly
29:15
triggered that 2:27 AM timestamp is undetermined, but it is not
29:21
indicative of when that search was made.
29:24
And again, to reinforce the point, the time stamp is related
29:29
to the tab state not searching, not visiting websites.
29:35
This database is not tracking your Internet surfing, is not
29:39
tracking your Internet history. That happens in a different
29:42
database where that's its primary focus.
29:45
But so you know, it's possible and this is, you know, us
29:48
surmising that that tab came into focus at 2:27 AM and
29:53
somehow stayed in focus until 6:24 AM.
29:57
We don't know all the different things that happened on the
30:00
phone. We don't have the evidence.
30:02
We only have some of the exhibits Heights testimony at
30:05
the end of the day is she doesn't know exactly what
30:08
triggered that 2:27 AM time stamp.
30:11
But it's not house long to die in coal being searched at 2:27
30:17
AM. Yep.
30:18
So the attorney asked whether there was any evidence of that
30:22
tab being in use between 2:27 AM and 6:23 AM.
30:28
Hyde replied that since there is a search at 6:24 AM, that means
30:33
the tab was used after 2:27 AM. So a note here is that there is
30:39
other searches and browser activity that occurs, but it's
30:42
not seen in Table one because Table 1 is focusing on the
30:48
searches that were that were typed only.
30:52
Next, the attorney asks her to explain the intricate artifact
30:56
that she mentioned earlier. Here's where she discusses the
31:00
wall file in more detail. Hyde noted that Celebrate
31:05
displayed it where other tools did not, and that you cannot
31:10
always tell from a wall file what is waiting to be committed
31:15
versus what's waiting to be removed.
31:17
And so in order to sort that out, she reconstructed the data
31:21
using Sanderson's forensic tool for the SQLite Browser.
31:25
And during her reconstruction, she found 16 instances of that
31:31
artifact entry. But all of these entries had the
31:34
same unique identifier, which means that it was one search
31:40
stored multiple times in that wall file, and it even had
31:44
multiple offsets. So it was clear from the
31:48
examination of those 16 instances that it was not 16
31:53
separate searches. And I think at this point, we're
31:57
about halfway through her testimony.
32:00
She was only on the stand if you cut out all the sidebars and
32:03
stuff for about an hour. So I think we'll we'll stop here
32:09
and then we'll continue on with her testimony next week.
32:13
But as we kind of wrap up this episode, Becky, do you have any
32:17
like final thoughts, things you want to, you know, point out to
32:21
people from what we've heard so far as we're digging into the
32:25
actual testimony, I think providing.
32:28
Analogies, defining terms, being able to set the stage of what
32:35
the examiner is talking about, posed by the questions that the
32:38
attorney is asking, really helps the examiners give a very good
32:45
description of the terms, how they are used and what is
32:51
actually happening at the time. So I think being able to explain
32:56
to our listeners about expert testimony and the use of
33:00
definitions and analogies is very effective.
33:04
Yeah, and. I think, you know, there was
33:05
certainly we're summarizing it obviously, but there was
33:10
technical testimony in there, especially when she's talking
33:12
about like how a wall file works and, and she'll get more into
33:16
that. But it's, it's definitely some
33:17
technical stuff going on. And there are definitely times
33:22
where the attorney kind of loops back around after that.
33:26
And it's like, so and basically asking, So what does all of this
33:29
mean? And so she can kind of give that
33:32
answer summarizing all this technical mumbo jumbo that she
33:36
just said and explained to the jury in ways that they can
33:40
understand. What is the significance of all
33:43
this stuff I've just said? What is the significance of all
33:46
this data I've just been talking about?
33:49
And, you know, in order to do that, your attorney and you have
33:53
to sort of prep together and be like, you know, you need to know
33:56
what he wants to know and get out of you.
33:58
But he also needs to know the right questions to ask you
34:03
because there's got to be that transition.
34:06
Because it's not just like a scripted monologue when you get
34:10
on the stand and you're like, OK, I'm, I'm just going to sit
34:13
up here and talk for an hour. There's got to be those
34:16
questions back and forth. I mean, I would love to just get
34:19
up there and do a PowerPoint presentation about everything I
34:23
think is important, important needs to be said.
34:26
But it doesn't work that way. Does not.
34:28
Does not work that way. That is not part of the justice
34:31
system. Well, all right, everyone, thank
34:33
you so much. Join us every week on Thursday
34:36
as we continue to dive into Karen Reed's first trial.
34:39
So if you've enjoyed this episode, we're asking a favor.
34:42
Can you share this with your network?
34:44
So until next time, stay safe, stay sharp, and as always, keep
34:48
parsing the truth one bite at a time.
34:52
If you enjoyed this episode, make sure to follow us to get
34:56
notified the next time a new episode drops.
34:59
If you can do more, head on over to parsingthetruth.com and
35:03
donate by clicking on the donate button.
35:06
Parsing the Truth is a nonprofit organization and we are raising
35:09
money to send a new digital forensic examiner to I Asus
35:12
training next year in Orlando. Thanks.
35:20
Yeah, yeah, yeah, yeah. Yeah, yeah, yeah, yeah, yeah.