1
00:00:00,110 -->  00:00:04,670
   DREA: My name is Drea, this is Kyle, we'll
leave it at that, we're going toe talk about

2
00:00:04,670 -->  00:00:11,670
self‑destructing messaging applications.
And I'm sure you all know, you have heard

3
00:00:14,829 -->  00:00:21,829
about SnapChat, Wickr, Facebook, they all
have different security measures which are

4
00:00:22,090 -->  00:00:29,090
in place. Self‑destructing messaging apps
allow a user to send a text, picture, video

5
00:00:30,050 -->  00:00:37,050
to another user and do it in a way which the
message then is deleted or burned after reading.

6
00:00:39,070 -->  00:00:45,100
The point of this presentation is to show
you whether or not that's accurate and if

7
00:00:45,100 -->  00:00:49,899
there are any other supporting artifacts left
behind. We're going to talk about Smart Phone

8
00:00:49,899 -->  00:00:56,220
forensics, we are forensic investigators and
will breakdown the artifacts based on the

9
00:00:56,220 -->  00:01:03,220
operating systems, ios and Android. The three
we are going to focus on are SnapChat, Facebook

10
00:01:05,390 -->  00:01:12,390
Poke and Wickr, they are just a few but we
had to focus on just a few. So our testing

11
00:01:17,270 -->  00:01:23,960
protocol, we wanted to look at the process
from cradle to grave. So we're going to look

12
00:01:23,960 -->  00:01:30,960
at network traffic analysis, application program
interface, API review, device analysis, sorry

13
00:01:34,150 -->  00:01:41,150
about that, guys, and that is an empty slide!
Okay. So for testing we looked at iPhone 4s,

14
00:01:45,470 -->  00:01:52,470
on ios 5 and 6 and Samsungs, using Jelly Bean
and a few others. These are a few of the forensic

15
00:01:59,810 -->  00:02:06,810
applications available for doing mobile forensics.
And we will talk about a few of those in a

16
00:02:09,450 -->  00:02:12,180
minute.
The questions that we want to ask, what are

17
00:02:12,180 -->  00:02:17,930
the app stored data, we will talk about the
P list on an iPhone is data cached in multiple

18
00:02:17,930 -->  00:02:24,930
places, we are going to talk about meta data
on an Android, is the data encrypted and differences

19
00:02:25,120 -->  00:02:32,120
between apps like Wickr and SnapChat and why
they exist. Are the messages recoverable,

20
00:02:32,590 -->  00:02:37,069
we're going to show you in some cases yes,
they are and is there supporting evidence

21
00:02:37,069 -->  00:02:42,800
presence and we will talk about empty files
that show there was evidence there at one

22
00:02:42,800 -->  00:02:49,340
point and the evidence we can tie back to
meta data and show the conversations happened,

23
00:02:49,340 -->  00:02:56,340
kind of what happened.
Mobile forensics has come a very long way.

24
00:02:59,660 -->  00:03:06,660
It started out where investigators basically
just had the phone itself, they took picture

25
00:03:06,989 -->  00:03:10,180
of whatever they saw on the screen and that
was the evidence that they could communicate.

26
00:03:10,180 -->  00:03:16,080
We are now at a point where mobile forensics
has gotten so intricate that we can recover

27
00:03:16,080 -->  00:03:23,080
memory and full images with hardware and software‑based
tool. These are a few of those tools. Cellebrite

28
00:03:29,110 -->  00:03:36,110
Lantern, and others. Like I said earlier,
we're focusing on the Cellebrite Analyzer

29
00:03:43,060 -->  00:03:50,060
and MPE plus. So in the next few slides we're
going to go through preservation on ios devices.

30
00:03:53,650 -->  00:03:58,209
There are a lot of similarity with Android
but we will discuss the differences between

31
00:03:58,209 -->  00:04:05,209
them. So iPhone 4S and newer, there are chips
that prevent extract, it's not am os, it is

32
00:04:11,209 -->  00:04:15,730
the chip system not the operating system that
prevent you from getting a physical preservation

33
00:04:15,730 -->  00:04:22,730
but the earlier phones we were able to get
a full capture of the device. That includes

34
00:04:23,869 -->  00:04:30,869
a full copy of flash memory. It does require
jail‑breaking the phone and there is a possibility

35
00:04:32,610 -->  00:04:36,650
of the file system being encrypted so you
may be able to get all this awesome information

36
00:04:36,650 -->  00:04:43,650
and not be able to read it. As I said, iPhone,
iPhone 3G and iPhone 4. So we are able to

37
00:04:46,270 -->  00:04:53,270
get a full copy of the file system, this is
what it would look like in end case, for example.

38
00:04:56,270 -->  00:05:02,649
It requires jail‑breaking for acquisition.
It's an unencrypted copy of the file system

39
00:05:02,649 -->  00:05:08,110
because it's more logical than fiscal and
these are the devices that you can pull that

40
00:05:08,110 -->  00:05:15,020
kind of preservation from.
If we're forced to or unable to get a logical

41
00:05:15,020 -->  00:05:21,719
or physical acquisition we will do basically
an iPhone back‑up, we will use iTunes and

42
00:05:21,719 -->  00:05:28,719
get whatever iTunes can collect. Here is some
of those items, photos, contact, SMS and app

43
00:05:29,779 -->  00:05:36,419
data. And that's available on all ios devices.
And Android preservation we can do physical

44
00:05:36,419 -->  00:05:43,419
preservation, somewhat like jail‑breaking
into an ios devices. Logical extraction will

45
00:05:48,009 -->  00:05:55,009
give you the file system, application data,
email, multi media. So SnapChat is the first

46
00:05:55,580 -->  00:06:02,580
app that we're going to talk about. While
SnapChat positions its as afemoral, it's not

47
00:06:08,020 -->  00:06:15,020
hard to imagine that the ‑‑ some of that
could be abused. This is just a few articles

48
00:06:16,330 -->  00:06:20,710
that we have done a simple Google search on
showing how SnapChat has been used to do less

49
00:06:20,710 -->  00:06:27,710
than NSA‑type activity. SnapChat has a reputation
for being a "sex app" but with so many messages

50
00:06:28,899 -->  00:06:32,929
it's hard to believe that it's all sex, right?
(Laughter.)

51
00:06:32,929 -->  00:06:39,929
But it's not a trivial portion there is going
to be a good handful and this explains in

52
00:06:50,399 -->  00:06:57,399
the last year how the growth of SnapChat has
exploited, how many messages have been sent

53
00:06:57,939 -->  00:07:04,939
since 5‑12 up through 14. This is from the
law enforcement guide. What we want to focus

54
00:07:08,520 -->  00:07:15,520
on here is law enforcement acknowledges that
there is the ability to recover the image

55
00:07:16,279 -->  00:07:21,709
files from an image of a phone and they say
well as long as you don't open them first

56
00:07:21,709 -->  00:07:25,869
we can recover them. We kind of say the same
thing, I think there is going to be supporting

57
00:07:25,869 -->  00:07:29,789
evidence like we mentioned before but the
key is if you're an investigator and you get

58
00:07:29,789 -->  00:07:35,349
a phone and you see the SnapChat application
is installed, obviously we don't want to be

59
00:07:35,349 -->  00:07:42,159
opening those images.
All right so went through several rounds of

60
00:07:42,159 -->  00:07:49,159
using SnapChat and exchanging messages between
ios devices 
and I started trying to determine if I could

61
00:07:55,529 -->  00:08:00,830
find the content that backed up this information
that you see on the screen, right, this is

62
00:08:00,830 -->  00:08:06,429
an image of what SnapChat exchange would look
like on a phone. So basically what he did

63
00:08:06,429 -->  00:08:13,429
after taking that image is a ran a key word
search for my user names and I found this.

64
00:08:15,129 -->  00:08:22,129
For those of you who are familiar with P list
files they are used 
to store ios information and this file was

65
00:08:27,779 -->  00:08:34,779
unencrypted, it showed that on the file there
were extractions and accessible by iTunes

66
00:08:35,860 -->  00:08:40,899
back‑up which is interesting if you're able
to get a back‑up off the image of a computer,

67
00:08:40,899 -->  00:08:46,529
for example, you maybe able to get the information
without having the phone itself. So we opened

68
00:08:46,529 -->  00:08:52,930
up the file and this is what it looks like.
There were things that were immediately interesting.

69
00:08:52,930 -->  00:08:59,930
We saw user names, Unix time stamps and what
ASP to be message IDs. So we have this meta

70
00:09:01,959 -->  00:09:07,040
data but it's not clear how these things are
associated yet, which users received what

71
00:09:07,040 -->  00:09:14,040
messages when and with what IDs. So we looked
into the P list format and we found that it

72
00:09:17,240 -->  00:09:23,550
was an NS key archiver object which is data
structure that Apple provides to developers

73
00:09:23,550 -->  00:09:29,420
to allow them to store objects and values
in a P list file. Parsing that P list with

74
00:09:29,420 -->  00:09:36,420
the cool tool from CCL Forensics, it's a Python
module and it showed that the P list contained

75
00:09:40,899 -->  00:09:47,899
lots of information contained in the slide
here and there are other objects that were

76
00:09:49,389 -->  00:09:56,389
null or not decoded. They included module
verification and snap privacy, image caption,

77
00:09:57,899 -->  00:10:04,899
we just didn't recover those in our testing.
Okay. So the snap object itself contains a

78
00:10:05,180 -->  00:10:10,470
list of the snap objects on the device. Each
of which contains meta data for the SnapChat

79
00:10:10,470 -->  00:10:17,470
message received by the user and it receives
it's the back‑end storage of the list of

80
00:10:18,839 -->  00:10:23,670
messages shown to the user in the message
list each contains the following elements

81
00:10:23,670 -->  00:10:30,670
as you can see and we had some elements that
were null or not decrypted. They were displays,

82
00:10:31,430 -->  00:10:37,019
screen chats and time stamps and I'm assuming
the screen shots field would be if somebody

83
00:10:37,019 -->  00:10:42,319
took a screen shot of a file you sent and
you get that message back like a user took

84
00:10:42,319 -->  00:10:49,319
a convenient shot of the image. So with the
knowledge of the P list you can decode it

85
00:10:50,389 -->  00:10:57,389
and it looks like this. This meta data has
power for us as forensic investigators, so

86
00:10:59,939 -->  00:11:05,639
if you have an supervisor talking to an employee
you might have an HR issue, an accountant

87
00:11:05,639 -->  00:11:12,449
exchanging snaps before filing you might have
a problem, a student sending messages to a

88
00:11:12,449 -->  00:11:17,079
teacher, you might have a problem. Even without
the contents of the image this has investigative

89
00:11:17,079 -->  00:11:24,079
value to us. That being said, the question
that everybody is asking , I'm sure is if

90
00:11:24,160 -->  00:11:31,160
the snaps themselves are recoverable. Specific
to an ios device it looks like the files cannot

91
00:11:32,529 -->  00:11:39,529
be recovered from the jail broken devices.
Based on the conversations we have had SnapChat

92
00:11:41,310 -->  00:11:47,709
is keeping those images in memory. We haven't
Donnie carving of unallocated space because

93
00:11:47,709 -->  00:11:54,709
we recently were able to reverse the encryption
so maybe next year. But with respect to video,

94
00:11:55,800 -->  00:12:02,459
unopened and received videos can be recovered
from the device and it's actually stored on

95
00:12:02,459 -->  00:12:09,459
the device. So ‑‑ I'll do this one. So
on Android it's different. Meta data is stored

96
00:12:13,990 -->  00:12:20,810
on the device and snaps themselves are more
complicated. So Decipher Forensics out of

97
00:12:20,810 -->  00:12:27,810
‑‑ based out of Utah they found the file
were on the system even if they were unencrypted

98
00:12:31,589 -->  00:12:37,279
and we found that files are deleted only after
the last message is received if you get six

99
00:12:37,279 -->  00:12:43,810
message and you look at 5 of the six they
are recoverable.

100
00:12:43,810 -->  00:12:50,810
   KYLE: How many people out here have a rooted
Android device they use? Right? So I got a

101
00:12:58,629 -->  00:13:05,629
Samsung Galaxy and I sent snap chats to myself.
I sent myself two snaps, you go in that directory

102
00:13:15,300 -->  00:13:21,129
and you can see there are two picture files
that exist. So that says all right now they're

103
00:13:21,129 -->  00:13:28,129
sitting on the phone themselves. I went ahead
and looked at one and you can see that the

104
00:13:29,220 -->  00:13:35,220
files actual still exist. I went back out,
reviewed the last one and now they're gone.

105
00:13:35,220 -->  00:13:38,759
Stepping back though, what I thought about
the last couple of days and it's simplistic,

106
00:13:38,759 -->  00:13:45,759
when you think about it. You have a rooted
device so CP is it out to your SD card, the

107
00:13:45,999 -->  00:13:51,069
files are on the phone and the user that sent
them will never know that you have a copy

108
00:13:51,069 -->  00:13:58,069
of the file if you want to do that screen
capture you have to do it on your ‑‑

109
00:13:58,389 -->  00:14:04,089
I'm not familiar with the Android device's
screen capture but that alerts the user that

110
00:14:04,089 -->  00:14:09,790
you took the screen capture and this way they
have no idea that you kept them. You can save

111
00:14:09,790 -->  00:14:16,790
them off and keep them. So looking at the
network analysis for this we set up a proxy

112
00:14:22,819 -->  00:14:28,389
and sent messages back and forth to each other
and you have to force a certificate on to

113
00:14:28,389 -->  00:14:35,220
the phone and it gives the perspective of
what the messages look like underneath. We

114
00:14:35,220 -->  00:14:39,600
sent back and forth and were able to download
it and it kind of gives you an idea of the

115
00:14:39,600 -->  00:14:46,309
response and the request sent so you kinda
see this response here is actually very similar

116
00:14:46,309 -->  00:14:53,309
to what's actually found in the user P list
file and this is talking to the iPhone devices.

117
00:14:53,379 -->  00:14:57,970
What's interesting about this, this is sent
from the SnapChat servers every time a message

118
00:14:57,970 -->  00:15:04,970
is sent so this is content similar to what
you will find in the P list file. This is

119
00:15:06,410 -->  00:15:11,389
the message ID in this one. It's what you
want to Thai back to that communication that

120
00:15:11,389 -->  00:15:18,389
goes back and forth between the two individuals.
Here what's interesting, this is a picture

121
00:15:20,990 -->  00:15:23,990
that was sent, right, so you're looking at
it here and you go, how do you know it was

122
00:15:23,990 -->  00:15:30,290
a picture that was sent and we all know the
magic number in the picture file is in the

123
00:15:30,290 -->  00:15:35,019
raw data but here it's not. So this alludes
to the fact that there is encryption underneath

124
00:15:35,019 -->  00:15:42,019
SSL that SnapChat is using.
So you say this is good, though, but working

125
00:15:43,769 -->  00:15:48,470
with a couple of reverses out there, these
individuals had done reverses on the APX file

126
00:15:48,470 -->  00:15:55,470
and were able to determine that in reality
the encryption is simple they're using ADS

127
00:15:55,920 -->  00:16:00,709
electronic code book mode and the key is a
fixed key and that fixed key is for every

128
00:16:00,709 -->  00:16:07,709
single message sent! (Laughter.)
So it's simple, these two guys wrote their

129
00:16:09,079 -->  00:16:14,759
own PHP module and Ruby module and before
I came across this I was like, now that I

130
00:16:14,759 -->  00:16:21,029
know the key based on the blog here which
took me second to fine that he posted I wrote

131
00:16:21,029 -->  00:16:27,910
my Python script to the decode it and I was
like, oh, that was simple! So I got to looking

132
00:16:27,910 -->  00:16:34,910
at the SnapChat. Now we're going to look at
Facebook Poke. We did it for the ios devices,

133
00:16:35,360 -->  00:16:42,360
after the message is sent it's deleted from
the app, the user has a timer set and the

134
00:16:44,749 -->  00:16:50,779
message self‑destructs or disappear once
it's done. Is that really the case? And here

135
00:16:50,779 -->  00:16:55,709
is the devices we used to do that and, again,
we captured the traffic and we'll talk about

136
00:16:55,709 -->  00:17:02,709
that. Looking at the device, keep in mind
these change per install so these are specific

137
00:17:04,079 -->  00:17:09,789
to my device that I had but when you looked
in these directories on the ‑‑ under

138
00:17:09,789 -->  00:17:16,699
the iPhone you see these directories so it
had this one file or one directory which contained

139
00:17:16,699 -->  00:17:23,699
a cached ‑‑ so it basically cached the
photos and then another directory below that

140
00:17:25,809 -->  00:17:31,000
had the pictures so now you have the users
that you communicate with and a thumbnail

141
00:17:31,000 -->  00:17:35,899
of the pictures that you communicate with
but what really was the "be all" for a digital

142
00:17:35,899 -->  00:17:42,899
friend approach is in the stored SQL database,
this database probably had about ‑‑ I

143
00:17:44,500 -->  00:17:49,880
don't remember counting but at least 50 tables
in it but this one table of interest is the

144
00:17:49,880 -->  00:17:56,250
Z poke message table so we were able to find
recipients in a counter. You had the sender,

145
00:17:56,250 -->  00:18:01,890
time limit, creation time, the media type
that was sent and any text that was sent.

146
00:18:01,890 -->  00:18:06,690
So we all know that you can send a text to
the person, a photo to the person but you

147
00:18:06,690 -->  00:18:12,149
can also send a photo with a text to the person
so all this is stored in the database and

148
00:18:12,149 -->  00:18:16,080
here is a picture of it showing you the one
that highlighted ‑‑ you can see the message

149
00:18:16,080 -->  00:18:22,049
field itself is null but text was sent so
this stored everything that was sent. And

150
00:18:22,049 -->  00:18:25,659
then the other table underneath that is the
Z poke messages edge and you can do a join

151
00:18:25,659 -->  00:18:32,659
on that table, you can see when they viewed
it, what time, whether they did a screen capture

152
00:18:33,370 -->  00:18:38,039
so putting all this together you can draw
the picture to what's going o maybe you don't

153
00:18:38,039 -->  00:18:43,909
have the photos but you can see that the communications
exist and you can build a spreadsheet and

154
00:18:43,909 -->  00:18:48,289
you can be like yes you talked to Jane at
7 p.m. on Sunday and you sent this message

155
00:18:48,289 -->  00:18:54,289
to her and this is a text that might have
been included. In this whole table itself

156
00:18:54,289 -->  00:18:58,529
or in this database itself there is a table
that is ZAvitar table and it included your

157
00:18:58,529 -->  00:19:04,380
face book ID, so you can ‑‑ based on
this one database you can build the structure

158
00:19:04,380 -->  00:19:11,380
of this one person's device.
So this is another ‑‑ the snapshot is

159
00:19:13,299 -->  00:19:20,299
a transition directory on ios devices it takes
a snapshot of the message you're in and the

160
00:19:21,559 -->  00:19:28,120
home screen was actually saved inside this
directory so you have what is to be like a

161
00:19:28,120 -->  00:19:32,990
communication so the user can clear this tracking
of the communication they're having but if

162
00:19:32,990 -->  00:19:38,380
not and you exit the app it takes a screen
shot and in Facebook's Poke case they left

163
00:19:38,380 -->  00:19:43,580
that function on in the program so you can
see messages that were sent and when they

164
00:19:43,580 -->  00:19:49,279
were sent to individuals. In one of these
other directories you have P list files, I

165
00:19:49,279 -->  00:19:54,130
redacted them, I don't know why I did, doesn't
matter because these are my Facebook IDs that

166
00:19:54,130 -->  00:20:00,610
I used for this and it basically stores that
information so you can take that ID number

167
00:20:00,610 -->  00:20:07,610
and go to the ‑‑ I think I have it on
the next slide, Developer, Explorer, you can

168
00:20:07,799 -->  00:20:14,279
see the user name tied to that ID that's Open
Source it's all out there and you have user

169
00:20:14,279 -->  00:20:21,279
agent, log‑in ID, the last time they registered
in Facebook and you have this big picture,

170
00:20:22,269 -->  00:20:28,080
who they were talking to, what they were talking
to them, using this app. So then we look at

171
00:20:28,080 -->  00:20:32,799
the network analysis side of the stuff. We
see these posts that's like when you send

172
00:20:32,799 -->  00:20:36,769
a message it looks like this, when you receive
the message it doesn't get done in the post

173
00:20:36,769 -->  00:20:43,769
request as well but what's interesting and
different from snap shat is Facebook encodes

174
00:20:43,809 -->  00:20:50,000
it. So what's nice about this is it's setoff
and there is no under lying encryption under

175
00:20:50,000 -->  00:20:57,000
SSL using Facebook Poke, unlike SnapChat they
use a 16‑byte key these guys don't do that.

176
00:20:58,549 -->  00:21:05,549
So you can capture traffic that way and you
can then ‑‑ it also keeps fields of what

177
00:21:09,460 -->  00:21:13,600
techs was sent, if a picture was sent and
if a picture was sent with techs so this is

178
00:21:13,600 -->  00:21:18,890
all in the payload of the traffic itself and
this is the link I was talking about take

179
00:21:18,890 -->  00:21:25,890
that user ID back here that I redacted for
no reason and then send it to this link and

180
00:21:26,080 -->  00:21:31,260
it will say my name was tied to that user
ID. So if you have the P list files you can

181
00:21:31,260 -->  00:21:38,260
take the number and find out the name they
have registered with Facebook.

182
00:21:38,450 -->  00:21:42,330
This is taking a look from the perspective
of what the traffic look like itself. This

183
00:21:42,330 -->  00:21:48,070
is a payload of the picture and you can see
in the blue it recognized it, trips that off

184
00:21:48,070 -->  00:21:54,649
and the underlying payload itself it's the
JPEG payload and here is a picture with message

185
00:21:54,649 -->  00:22:00,070
and text it says "basketball hoop" you can
draw this big picture if you're able to capture

186
00:22:00,070 -->  00:22:05,390
the traffic and the biggest thing we're trying
to draw here is SnapChat uses encryption,

187
00:22:05,390 -->  00:22:10,289
Wickr uses encryption but Facebook doesn't
use any encryption.

188
00:22:10,289 -->  00:22:17,289
We looked at Wickr and did the same approach
and they claim to leave no trace and their

189
00:22:18,289 -->  00:22:25,289
device is 140‑2, HIPAA and Suite B compliant
and had he use AS56 encryption so we did it

190
00:22:31,029 -->  00:22:38,029
two fun apps and we look at the corporate
level, this is targeted forward business folks.

191
00:22:40,330 -->  00:22:47,059
In doing the analysis and doing the physical
extraction of the device, ios device you have

192
00:22:47,059 -->  00:22:51,919
these directories, based on the grids but
in containing all of them I was not finding

193
00:22:51,919 -->  00:22:58,919
anything of interest, contained no content,
files were all gone, and they had P list information

194
00:23:01,830 -->  00:23:06,789
but nothing with regard to the directory interest
so nothing that you didn't already know that

195
00:23:06,789 -->  00:23:12,500
was stored in the P list files. Then looking
at the network traffic side I thought maybe

196
00:23:12,500 -->  00:23:19,500
there was something in the network traffic
itself and the PHP file was sent, all of them

197
00:23:21,690 -->  00:23:26,750
looked like that downloaded. The only thing
I was able to do ‑‑ after that it was

198
00:23:26,750 -->  00:23:32,669
still encrypted, you can take a baseline ‑‑
when I sent a text versus sending a picture

199
00:23:32,669 -->  00:23:36,730
versus video, the payload itself was larger,
which you would expect but if you have no

200
00:23:36,730 -->  00:23:43,730
baseline you can't say whether a picture was
sent or just text or just a video was sent.

201
00:23:45,450 -->  00:23:49,669
Then the only thing I found that stood out
immediately is that the first 5 bytes were

202
00:23:49,669 -->  00:23:56,669
virtually the same and you can argue that
you can grab that phone, the picture might

203
00:23:57,760 -->  00:24:03,049
be in memory and if you did a memory extract
you will be able to get that picture, well,

204
00:24:03,049 -->  00:24:10,049
no, it's encrypted and each of the keys are
encrypted for each user each time so this

205
00:24:10,950 -->  00:24:16,960
is what it looks like, the payload in the
proxy so you can see it's nothing, it's scrambled.

206
00:24:16,960 -->  00:24:22,760
I didn't do crazy encrypted analysis on it,
not like I used to do but I didn't want to

207
00:24:22,760 -->  00:24:27,419
spend time doing that so it's to highlight
they're doing what they say they're doing,

208
00:24:27,419 -->  00:24:32,210
they're encrypting the payload and you can't
get anything out of it and this is a sample

209
00:24:32,210 -->  00:24:36,679
of a received message. So you can see between
the two, the first 5 bytes are similar but

210
00:24:36,679 -->  00:24:43,679
that's about it.
Kinda to summarize it all, on the ios devices

211
00:24:45,450 -->  00:24:52,450
what's of interest? The P list file, on the
Android you have the XML file, they contain

212
00:24:55,220 -->  00:25:02,220
the same amount of meta data, times the messages
were sent, who the users were, was it viewed,

213
00:25:02,990 -->  00:25:09,990
when was it sent? Then specific to Android
devices you have the cache images and if you

214
00:25:10,519 -->  00:25:14,710
have a rooted device you can copy those out
anytime someone send you a SnapChat even before

215
00:25:14,710 -->  00:25:19,200
looking at it. You can see who sent it to
you if you don't open it up you can send it

216
00:25:19,200 -->  00:25:26,169
to a directory and copy those out and they
will never know that you did that. So string

217
00:25:26,169 -->  00:25:33,120
searching, why didn't we do that? We spent
time doing network analysis and what else

218
00:25:33,120 -->  00:25:38,200
we could find in the open files themselves.
The big thing I was trying to do before I

219
00:25:38,200 -->  00:25:43,340
came here was to do the memory extraction
of the Android devices using Lime, since I

220
00:25:43,340 -->  00:25:50,340
have that Samsung Galaxy 3 phone, I knew it
was going to be in there but they didn't have

221
00:25:50,500 -->  00:25:57,500
it because encryption was set for ‑‑
they configure the kernels differently. That's

222
00:26:00,590 -->  00:26:07,590
really it. Here are the tools and sources
we used, thanking those people as well and

223
00:26:07,789 -->  00:26:13,679
we have some time, I guess there is not a
Q and A room anymore so we have apparently

224
00:26:13,679 -->  00:26:20,110
time left here if you have any questions you
want to ask. We have 15 minutes. Anybody have

225
00:26:20,110 -->  00:26:27,110
any questions? (Applause.)
If you want to contact us, let us know, reach

226
00:26:38,590 -->  00:26:45,590
out to us.
   AUDIENCE MEMBER: (Away from microphone.)

227
00:26:50,799 -->  00:26:56,549
   KYLE: The question was we talked about
received messages, did we have anything about

228
00:26:56,549 -->  00:27:03,250
the "sent" messages? Nothing that I came across
when I was doing did I find any ‑‑ sent

229
00:27:03,250 -->  00:27:09,159
messages I sent.
   DREA: On the Android sometime it will be

230
00:27:09,159 -->  00:27:16,159
in the cache database, the received messages
and the sent messages will be there, also.

231
00:27:20,210 -->  00:27:27,210
   AUDIENCE MEMBER: (Away from microphone.)
   KYLE: The question was, did we ever try

232
00:27:37,799 -->  00:27:44,799
to trick the app into making it think that
one more pending image so we could see ‑‑

233
00:27:45,559 -->  00:27:51,259
I didn't do that at all in my testing. Possibly
could be done and it would take a little more

234
00:27:51,259 -->  00:27:56,690
reverse ‑‑ I didn't personally reverse
the APX on the Android devices, we used Open

235
00:27:56,690 -->  00:28:03,039
Source research and that would be something
we could think about using.

236
00:28:03,039 -->  00:28:10,039
So we work with another colleague that created
an API to work third‑party API to work with

237
00:28:12,330 -->  00:28:19,250
SnapChat and he caught wind of SnapChat getting
finicky about that and he removed that from

238
00:28:19,250 -->  00:28:25,799
GitHub and we were going to talk to that and
explain the research but there was rumors

239
00:28:25,799 -->  00:28:32,799
that SnapChat didn't like that so he pulled
down his API. There is a mic in the center

240
00:28:35,519 -->  00:28:38,890
if you want to walk up and ask questions.
Go ahead.

241
00:28:38,890 -->  00:28:44,450
   AUDIENCE MEMBER: (Away from microphone.)
   KYLE: The question was is there any work

242
00:28:44,450 -->  00:28:50,019
on iMessage? No, we didn't do any of that,
we looked at the specific apps. There are

243
00:28:50,019 -->  00:28:56,700
a few others like Silent Circle has self‑destructing
and they have a paid service and we could

244
00:28:56,700 -->  00:29:02,499
have done that and paid it but we didn't go
that route.

245
00:29:02,499 -->  00:29:09,499
   AUDIENCE MEMBER: (Away from microphone.)
   DREA: Tiger Text?

246
00:29:15,190 -->  00:29:18,940
   KYLE: Tiger Text.
   DREA: We did do that and we were able to

247
00:29:18,940 -->  00:29:25,940
recover pictures but no communication information.
   AUDIENCE MEMBER: (Away from microphone.)

248
00:29:35,999 -->  00:29:42,999
   DREA: For our purposes as forensic investigators,
and I'm sorry I can't repeat that whole question

249
00:29:44,559 -->  00:29:48,980
but I can say this. We're always trying to
deal with what comes into us so it's hard

250
00:29:48,980 -->  00:29:55,980
to do preventative work and exploit the devices
as way shape and form we're doing evidence

251
00:29:59,039 -->  00:30:03,789
so that research is interesting but not stuff
we have looked into.

252
00:30:03,789 -->  00:30:10,789
   KYLE: Thanks for coming and appreciate
it. Definitely more people than I expected.

253
00:30:12,289 -->  00:30:12,539
(Applause.)