DREA: My name is Drea, this is Kyle, we'll leave it at that, we're going toe talk about
self‑destructing messaging applications. And I'm sure you all know, you have heard
about SnapChat, Wickr, Facebook, they all have different security measures which are
in place. Self‑destructing messaging apps allow a user to send a text, picture, video
to another user and do it in a way which the message then is deleted or burned after reading.
The point of this presentation is to show you whether or not that's accurate and if
there are any other supporting artifacts left behind. We're going to talk about Smart Phone
forensics, we are forensic investigators and will breakdown the artifacts based on the
operating systems, ios and Android. The three we are going to focus on are SnapChat, Facebook
Poke and Wickr, they are just a few but we had to focus on just a few. So our testing
protocol, we wanted to look at the process from cradle to grave. So we're going to look
at network traffic analysis, application program interface, API review, device analysis, sorry
about that, guys, and that is an empty slide! Okay. So for testing we looked at iPhone 4s,
on ios 5 and 6 and Samsungs, using Jelly Bean and a few others. These are a few of the forensic
applications available for doing mobile forensics. And we will talk about a few of those in a
minute. The questions that we want to ask, what are
the app stored data, we will talk about the P list on an iPhone is data cached in multiple
places, we are going to talk about meta data on an Android, is the data encrypted and differences
between apps like Wickr and SnapChat and why they exist. Are the messages recoverable,
we're going to show you in some cases yes, they are and is there supporting evidence
presence and we will talk about empty files that show there was evidence there at one
point and the evidence we can tie back to meta data and show the conversations happened,
kind of what happened. Mobile forensics has come a very long way.
It started out where investigators basically just had the phone itself, they took picture
of whatever they saw on the screen and that was the evidence that they could communicate.
We are now at a point where mobile forensics has gotten so intricate that we can recover
memory and full images with hardware and software‑based tool. These are a few of those tools. Cellebrite
Lantern, and others. Like I said earlier, we're focusing on the Cellebrite Analyzer
and MPE plus. So in the next few slides we're going to go through preservation on ios devices.
There are a lot of similarity with Android but we will discuss the differences between
them. So iPhone 4S and newer, there are chips that prevent extract, it's not am os, it is
the chip system not the operating system that prevent you from getting a physical preservation
but the earlier phones we were able to get a full capture of the device. That includes
a full copy of flash memory. It does require jail‑breaking the phone and there is a possibility
of the file system being encrypted so you may be able to get all this awesome information
and not be able to read it. As I said, iPhone, iPhone 3G and iPhone 4. So we are able to
get a full copy of the file system, this is what it would look like in end case, for example.
It requires jail‑breaking for acquisition. It's an unencrypted copy of the file system
because it's more logical than fiscal and these are the devices that you can pull that
kind of preservation from. If we're forced to or unable to get a logical
or physical acquisition we will do basically an iPhone back‑up, we will use iTunes and
get whatever iTunes can collect. Here is some of those items, photos, contact, SMS and app
data. And that's available on all ios devices. And Android preservation we can do physical
preservation, somewhat like jail‑breaking into an ios devices. Logical extraction will
give you the file system, application data, email, multi media. So SnapChat is the first
app that we're going to talk about. While SnapChat positions its as afemoral, it's not
hard to imagine that the ‑‑ some of that could be abused. This is just a few articles
that we have done a simple Google search on showing how SnapChat has been used to do less
than NSA‑type activity. SnapChat has a reputation for being a "sex app" but with so many messages
it's hard to believe that it's all sex, right? (Laughter.)
But it's not a trivial portion there is going to be a good handful and this explains in
the last year how the growth of SnapChat has exploited, how many messages have been sent
since 5‑12 up through 14. This is from the law enforcement guide. What we want to focus
on here is law enforcement acknowledges that there is the ability to recover the image
files from an image of a phone and they say well as long as you don't open them first
we can recover them. We kind of say the same thing, I think there is going to be supporting
evidence like we mentioned before but the key is if you're an investigator and you get
a phone and you see the SnapChat application is installed, obviously we don't want to be
opening those images. All right so went through several rounds of
using SnapChat and exchanging messages between ios devices and I started trying to determine if I could
find the content that backed up this information that you see on the screen, right, this is
an image of what SnapChat exchange would look like on a phone. So basically what he did
after taking that image is a ran a key word search for my user names and I found this.
For those of you who are familiar with P list files they are used to store ios information and this file was
unencrypted, it showed that on the file there were extractions and accessible by iTunes
back‑up which is interesting if you're able to get a back‑up off the image of a computer,
for example, you maybe able to get the information without having the phone itself. So we opened
up the file and this is what it looks like. There were things that were immediately interesting.
We saw user names, Unix time stamps and what ASP to be message IDs. So we have this meta
data but it's not clear how these things are associated yet, which users received what
messages when and with what IDs. So we looked into the P list format and we found that it
was an NS key archiver object which is data structure that Apple provides to developers
to allow them to store objects and values in a P list file. Parsing that P list with
the cool tool from CCL Forensics, it's a Python module and it showed that the P list contained
lots of information contained in the slide here and there are other objects that were
null or not decoded. They included module verification and snap privacy, image caption,
we just didn't recover those in our testing. Okay. So the snap object itself contains a
list of the snap objects on the device. Each of which contains meta data for the SnapChat
message received by the user and it receives it's the back‑end storage of the list of
messages shown to the user in the message list each contains the following elements
as you can see and we had some elements that were null or not decrypted. They were displays,
screen chats and time stamps and I'm assuming the screen shots field would be if somebody
took a screen shot of a file you sent and you get that message back like a user took
a convenient shot of the image. So with the knowledge of the P list you can decode it
and it looks like this. This meta data has power for us as forensic investigators, so
if you have an supervisor talking to an employee you might have an HR issue, an accountant
exchanging snaps before filing you might have a problem, a student sending messages to a
teacher, you might have a problem. Even without the contents of the image this has investigative
value to us. That being said, the question that everybody is asking , I'm sure is if
the snaps themselves are recoverable. Specific to an ios device it looks like the files cannot
be recovered from the jail broken devices. Based on the conversations we have had SnapChat
is keeping those images in memory. We haven't Donnie carving of unallocated space because
we recently were able to reverse the encryption so maybe next year. But with respect to video,
unopened and received videos can be recovered from the device and it's actually stored on
the device. So ‑‑ I'll do this one. So on Android it's different. Meta data is stored
on the device and snaps themselves are more complicated. So Decipher Forensics out of
‑‑ based out of Utah they found the file were on the system even if they were unencrypted
and we found that files are deleted only after the last message is received if you get six
message and you look at 5 of the six they are recoverable.
KYLE: How many people out here have a rooted Android device they use? Right? So I got a
Samsung Galaxy and I sent snap chats to myself. I sent myself two snaps, you go in that directory
and you can see there are two picture files that exist. So that says all right now they're
sitting on the phone themselves. I went ahead and looked at one and you can see that the
files actual still exist. I went back out, reviewed the last one and now they're gone.
Stepping back though, what I thought about the last couple of days and it's simplistic,
when you think about it. You have a rooted device so CP is it out to your SD card, the
files are on the phone and the user that sent them will never know that you have a copy
of the file if you want to do that screen capture you have to do it on your ‑‑
I'm not familiar with the Android device's screen capture but that alerts the user that
you took the screen capture and this way they have no idea that you kept them. You can save
them off and keep them. So looking at the network analysis for this we set up a proxy
and sent messages back and forth to each other and you have to force a certificate on to
the phone and it gives the perspective of what the messages look like underneath. We
sent back and forth and were able to download it and it kind of gives you an idea of the
response and the request sent so you kinda see this response here is actually very similar
to what's actually found in the user P list file and this is talking to the iPhone devices.
What's interesting about this, this is sent from the SnapChat servers every time a message
is sent so this is content similar to what you will find in the P list file. This is
the message ID in this one. It's what you want to Thai back to that communication that
goes back and forth between the two individuals. Here what's interesting, this is a picture
that was sent, right, so you're looking at it here and you go, how do you know it was
a picture that was sent and we all know the magic number in the picture file is in the
raw data but here it's not. So this alludes to the fact that there is encryption underneath
SSL that SnapChat is using. So you say this is good, though, but working
with a couple of reverses out there, these individuals had done reverses on the APX file
and were able to determine that in reality the encryption is simple they're using ADS
electronic code book mode and the key is a fixed key and that fixed key is for every
single message sent! (Laughter.) So it's simple, these two guys wrote their
own PHP module and Ruby module and before I came across this I was like, now that I
know the key based on the blog here which took me second to fine that he posted I wrote
my Python script to the decode it and I was like, oh, that was simple! So I got to looking
at the SnapChat. Now we're going to look at Facebook Poke. We did it for the ios devices,
after the message is sent it's deleted from the app, the user has a timer set and the
message self‑destructs or disappear once it's done. Is that really the case? And here
is the devices we used to do that and, again, we captured the traffic and we'll talk about
that. Looking at the device, keep in mind these change per install so these are specific
to my device that I had but when you looked in these directories on the ‑‑ under
the iPhone you see these directories so it had this one file or one directory which contained
a cached ‑‑ so it basically cached the photos and then another directory below that
had the pictures so now you have the users that you communicate with and a thumbnail
of the pictures that you communicate with but what really was the "be all" for a digital
friend approach is in the stored SQL database, this database probably had about ‑‑ I
don't remember counting but at least 50 tables in it but this one table of interest is the
Z poke message table so we were able to find recipients in a counter. You had the sender,
time limit, creation time, the media type that was sent and any text that was sent.
So we all know that you can send a text to the person, a photo to the person but you
can also send a photo with a text to the person so all this is stored in the database and
here is a picture of it showing you the one that highlighted ‑‑ you can see the message
field itself is null but text was sent so this stored everything that was sent. And
then the other table underneath that is the Z poke messages edge and you can do a join
on that table, you can see when they viewed it, what time, whether they did a screen capture
so putting all this together you can draw the picture to what's going o maybe you don't
have the photos but you can see that the communications exist and you can build a spreadsheet and
you can be like yes you talked to Jane at 7 p.m. on Sunday and you sent this message
to her and this is a text that might have been included. In this whole table itself
or in this database itself there is a table that is ZAvitar table and it included your
face book ID, so you can ‑‑ based on this one database you can build the structure
of this one person's device. So this is another ‑‑ the snapshot is
a transition directory on ios devices it takes a snapshot of the message you're in and the
home screen was actually saved inside this directory so you have what is to be like a
communication so the user can clear this tracking of the communication they're having but if
not and you exit the app it takes a screen shot and in Facebook's Poke case they left
that function on in the program so you can see messages that were sent and when they
were sent to individuals. In one of these other directories you have P list files, I
redacted them, I don't know why I did, doesn't matter because these are my Facebook IDs that
I used for this and it basically stores that information so you can take that ID number
and go to the ‑‑ I think I have it on the next slide, Developer, Explorer, you can
see the user name tied to that ID that's Open Source it's all out there and you have user
agent, log‑in ID, the last time they registered in Facebook and you have this big picture,
who they were talking to, what they were talking to them, using this app. So then we look at
the network analysis side of the stuff. We see these posts that's like when you send
a message it looks like this, when you receive the message it doesn't get done in the post
request as well but what's interesting and different from snap shat is Facebook encodes
it. So what's nice about this is it's setoff and there is no under lying encryption under
SSL using Facebook Poke, unlike SnapChat they use a 16‑byte key these guys don't do that.
So you can capture traffic that way and you can then ‑‑ it also keeps fields of what
techs was sent, if a picture was sent and if a picture was sent with techs so this is
all in the payload of the traffic itself and this is the link I was talking about take
that user ID back here that I redacted for no reason and then send it to this link and
it will say my name was tied to that user ID. So if you have the P list files you can
take the number and find out the name they have registered with Facebook.
This is taking a look from the perspective of what the traffic look like itself. This
is a payload of the picture and you can see in the blue it recognized it, trips that off
and the underlying payload itself it's the JPEG payload and here is a picture with message
and text it says "basketball hoop" you can draw this big picture if you're able to capture
the traffic and the biggest thing we're trying to draw here is SnapChat uses encryption,
Wickr uses encryption but Facebook doesn't use any encryption.
We looked at Wickr and did the same approach and they claim to leave no trace and their
device is 140‑2, HIPAA and Suite B compliant and had he use AS56 encryption so we did it
two fun apps and we look at the corporate level, this is targeted forward business folks.
In doing the analysis and doing the physical extraction of the device, ios device you have
these directories, based on the grids but in containing all of them I was not finding
anything of interest, contained no content, files were all gone, and they had P list information
but nothing with regard to the directory interest so nothing that you didn't already know that
was stored in the P list files. Then looking at the network traffic side I thought maybe
there was something in the network traffic itself and the PHP file was sent, all of them
looked like that downloaded. The only thing I was able to do ‑‑ after that it was
still encrypted, you can take a baseline ‑‑ when I sent a text versus sending a picture
versus video, the payload itself was larger, which you would expect but if you have no
baseline you can't say whether a picture was sent or just text or just a video was sent.
Then the only thing I found that stood out immediately is that the first 5 bytes were
virtually the same and you can argue that you can grab that phone, the picture might
be in memory and if you did a memory extract you will be able to get that picture, well,
no, it's encrypted and each of the keys are encrypted for each user each time so this
is what it looks like, the payload in the proxy so you can see it's nothing, it's scrambled.
I didn't do crazy encrypted analysis on it, not like I used to do but I didn't want to
spend time doing that so it's to highlight they're doing what they say they're doing,
they're encrypting the payload and you can't get anything out of it and this is a sample
of a received message. So you can see between the two, the first 5 bytes are similar but
that's about it. Kinda to summarize it all, on the ios devices
what's of interest? The P list file, on the Android you have the XML file, they contain
the same amount of meta data, times the messages were sent, who the users were, was it viewed,
when was it sent? Then specific to Android devices you have the cache images and if you
have a rooted device you can copy those out anytime someone send you a SnapChat even before
looking at it. You can see who sent it to you if you don't open it up you can send it
to a directory and copy those out and they will never know that you did that. So string
searching, why didn't we do that? We spent time doing network analysis and what else
we could find in the open files themselves. The big thing I was trying to do before I
came here was to do the memory extraction of the Android devices using Lime, since I
have that Samsung Galaxy 3 phone, I knew it was going to be in there but they didn't have
it because encryption was set for ‑‑ they configure the kernels differently. That's
really it. Here are the tools and sources we used, thanking those people as well and
we have some time, I guess there is not a Q and A room anymore so we have apparently
time left here if you have any questions you want to ask. We have 15 minutes. Anybody have
any questions? (Applause.) If you want to contact us, let us know, reach
out to us. AUDIENCE MEMBER: (Away from microphone.)
KYLE: The question was we talked about received messages, did we have anything about
the "sent" messages? Nothing that I came across when I was doing did I find any ‑‑ sent
messages I sent. DREA: On the Android sometime it will be
in the cache database, the received messages and the sent messages will be there, also.
AUDIENCE MEMBER: (Away from microphone.) KYLE: The question was, did we ever try
to trick the app into making it think that one more pending image so we could see ‑‑
I didn't do that at all in my testing. Possibly could be done and it would take a little more
reverse ‑‑ I didn't personally reverse the APX on the Android devices, we used Open
Source research and that would be something we could think about using.
So we work with another colleague that created an API to work third‑party API to work with
SnapChat and he caught wind of SnapChat getting finicky about that and he removed that from
GitHub and we were going to talk to that and explain the research but there was rumors
that SnapChat didn't like that so he pulled down his API. There is a mic in the center
if you want to walk up and ask questions. Go ahead.
AUDIENCE MEMBER: (Away from microphone.) KYLE: The question was is there any work
on iMessage? No, we didn't do any of that, we looked at the specific apps. There are
a few others like Silent Circle has self‑destructing and they have a paid service and we could
have done that and paid it but we didn't go that route.
AUDIENCE MEMBER: (Away from microphone.) DREA: Tiger Text?
KYLE: Tiger Text. DREA: We did do that and we were able to
recover pictures but no communication information. AUDIENCE MEMBER: (Away from microphone.)
DREA: For our purposes as forensic investigators, and I'm sorry I can't repeat that whole question
but I can say this. We're always trying to deal with what comes into us so it's hard
to do preventative work and exploit the devices as way shape and form we're doing evidence
so that research is interesting but not stuff we have looked into.
KYLE: Thanks for coming and appreciate it. Definitely more people than I expected.
(Applause.)