My name is Dre.
This is Kyle.
We'll leave it at that.
Today we're going to talk about self-destructing messaging applications.
And so I'm sure you all know, you've heard about Snapchat, Facebook, Tiger Text, they
all kind of have their own purposes and different security measures which are in place.
Self-destructing messaging apps basically allow a user to send a text, picture, video
to another user and do it in a way which the message should then be deleted or burnt after
reading.
The point of this presentation is basically to show you whether or not that's accurate
and if there are any other supporting artifacts left behind.
We're also going to talk about smartphone forensics.
We are forensic investigators.
And then we'll break down some of the artifacts based on operating system, iOS, Android, and
then we're going to look at some network traffic.
The three apps that we're going to focus on, Snapchat, Facebook Poke, and Wicker, they
are a very small subset of the whole, as I'm sure you know, but obviously we had to
focus on just a few.
So our testing protocol.
We wanted to look at the process from Crayola.
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.
So for testing, we looked at iPhone 4 is running iOS 5 and 6, Samsung Galaxy S3 is running
Jelly Bean and S3 Mini.
We used Cellebrite Physical Analyzer and AccessData and PE Plus.
These are just a few of the forensic applications available for doing mobile forensics.
And we'll talk about a few of those in a minute.
So the questions that we want to ask, where do the apps store data?
We'll talk about the user P list on an iPhone.
Is data cached in multiple places?
We're going to talk about metadata and then the data itself on an Android.
data encrypted? And we're going to talk about the differences between apps like Wicker and
Snapchat and their intentions, you know, why they exist. Are the messages recoverable?
We're going to show you that in some cases, yes, they are. And is there supporting evidence
present? So we'll talk about empty files that show that there was an image present at one
point in time and the evidence we can use from those files to tie back to metadata and show
the conversations happened, when they happened and kind of what happened.
So mobile forensics has come a very, very long way. It started out where investigators
basically just had the phone itself. They took pictures of whatever they saw on the
screen and that was the evidence that they could kind of communicate. We are now at a
point where mobile forensics has gotten so intricate that we can actually recover memory
off of a phone.
And full forensic images, physical images from devices with tools, hardware and software
based tools. These are a few of those tools. We've got the Celebrite, Lantern, MPE Plus,
like I discussed before, even NK7 claims to have some pretty good forensic capabilities.
Like I said earlier, we're focusing on the Celebrite physical analyzer and MPE Plus.
So in the next few slides we're going to go through preservation on iOS devices. Generally
speaking there are a lot of similarities with Android but we'll discuss a little bit
of the differences between them.
So iPhone 4S and newer, they're chipset requirements that prevent extraction. It's not OS related.
That is kind of something that is misconstrued in the community. It is a chipset. It's not
the operating system that prevents you from getting a physical preservation. But the 4 and older,
we were actually able to get a full physical capture of the device.
That includes a full copy of flash memory. It does require jailbreaking 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 really be able to read it. And as I said, iPhone,
iPhone 3 G, iPhone 3GS and iPhone 4. So a file system preservation. We're able to get
a full copy of the file system, you're not going to get that unallocated space. This
is kind of what the file system would look like in case, for example. It also requires
jail breaking for acquisition. It's an unencrypted copy of the file system because it's more
illogical than physical. 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 just basically an iPhone backup, we'll use iTunes, and we'll
get whatever iTunes can collect. Here's some of those items, photos, contacts, SMS, and
app data. And that's available on all iOS devices.
Android preservation, we can do physical preservation, which will temporary root the phone, similar
to jail breaking in iOS device. And in some cases we use it as a boot loader for Samsung
and Nokia phones. Logical extraction, again, will give you the file system, application
data, SMS, e‑mail, multimedia. So Snapchat is the first app that we're going to talk
about. While Snapchat positions itself as an ephemeral messaging application that's
supposed to be used for lighthearted exchanges with friends, it's not hard to imagine that
some of that could be abused. This is just an example of what Snapchat can do. It's
just a few articles that we did a simple Google search on showing how Snapchat has
been used to do, you know, less than innocent type of activity. Snapchat generally has had
a reputation for being a sexting app, but with 150 million messages sent a day, it's
hard to believe that those are all sexts, right? But it's also ‑‑
That would be really ‑‑ well, yeah. But it's also likely ‑‑ it's not a trivial
portion, right? It's, you know ‑‑
There's going to be a good handful. And this is just going to ‑‑ it kind of explains
just in the last year how the growth of Snapchat has exploded, how many messages have been
sent since 5‑12 up through 4‑13. This is a snippet from the law enforcement guide.
Kind of what we want to focus on here is law enforcement even acknowledges that there
is an ability to ‑‑
Yeah.
‑‑ 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. And we kind of say the same thing. I
think that there's always going to be supporting evidence like we mentioned before, but the
key is if you're an investigator, you get one of these phones and you see that the Snapchat
application is installed, obviously we don't want to be opening those images.
All right. So I went through several rounds of using Snapchat to exchange messages between
five and six devices. And then we use Celebrite Physical Analyzer to gain full physical and
file system extractions on each unit. So I started trying to determine if I could
find the content that backed up this information that you see on the screen. This is just an
image of what Snapchat exchange would look like on a phone. So basically what I did after
taking that image is I ran a keyword search for my user names and then I found this. This
is a user.plist file.
For those of you who are familiar with P list files, they are used by OSX and IOS to store
configuration information and other settings.
They have two formats, binary and XML.
This file was unencrypted and the test that we ran showed that it existed not only on
the file system extractions but it was also accessible by iTunes backup, which is interesting.
If you're able to get a backup off of the image of a computer, for example, you might
be able to get this information without having the phone itself.
So we opened up the user.p list file in Xcode and this is what it looks like.
There were some things that were immediately interesting.
We saw usernames, UNIX time stamps and what appears to be message IDs.
So we have this metadata, but it's not clear how these things are associated yet.
Which users received which messages when and with what message IDs.
So we looked at this.
We looked at the P list format a little more and found that the user at P list was actually
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 ‑‑ it's a cool, really very cool tool from CCL forensics,
it's CDBPS Python module, and it shows that the P list contained a number of objects,
those related to ‑‑
So this interchange of information are displayed in the slide here.
There are a bunch of other objects that we were either null or not decoded.
They include device token, module verification, snap privacy, image caption.
We just didn't recover any of those in our testing.
Okay.
So the snaps object itself.
It contains a list of the snap objects on the device, each of which contains metadata
for the message.
Okay.
And it appears that the snap object is the back end storage of the list of messages shown
to the user in the message list.
Each snap object contains the following elements, as you can see, and then again, we had some
elements that were either null or not decrypted, and they were displays, screenshots, and view
time stamps.
I'm assuming that screenshots field would be if somebody took a screenshot of a snap that
you sent, and then you get that kind of message back.
Like, hey, the user took a screenshot of this image.
So with the knowledge of the P list file and its structures, you can decode it and then
prepare a table that looks kind of like this.
This metadata has power for us as forensic investigators.
We can say who's talking to whom and when.
So for example, if you have a supervisor talking to an employee, you might have an HR issue.
If you have an accountant exchanging snaps right before a filing, you might have a problem.
If you have a student sending messages, you might have a problem.
So even without the contents of the image, this information still 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 on this screen, it looks like the photos cannot be readily
recovered from unjailbroken devices.
Based on the behavior of the app and some conversations we've had with reversers, it
looks like Snapchat is actually keeping those images in memory.
We haven't done any carving of unallocated space because we just 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.
Okay.
So on Android, it's a little bit different.
It is actually stored on the device.
And snaps themselves are more complicated.
So decipher forensics is a forensic firm, I think they're based out of Utah.
They found that images are stored unencrypted as unencrypted files on the file system even
after they were opened.
Others including us have done a little bit more research and found that snapshots are
deleted but only after the last message was received.
So if you get five or six and you read five of the six, they're still recoverable.
And this is where I'm going to hand it over to Kyle.
So again, I'm Kyle.
So this is kind of taking a perspective of like a rooted Android device.
So how many people out here have a rooted Android device that they use?
So what I did is I got a Samsung Galaxy S3 mini.
I rooted it and then I sent snapshots back and forth to myself.
So you can see initially on the right ‑‑ I think on the left‑hand side, the directory,
where that cached image is stored.
The image is empty.
You send ‑‑ I sent myself two snaps.
You go in that directory and you can see now there's two of these picture files that exist.
So that kind of says, all right, now they're sitting on the phone themselves.
You go ‑‑ I went ahead and looked at one, went back to that directory, and you
can see that the files actually still exist.
Now I went back out, viewed the last one, and went back, and now they're gone.
So kind of stepping back, though, this is what I thought about the last couple days,
and this is really simplistic when you think about it.
These files exist.
You have your device on here.
You have your device.
So just CP it out to your SD card.
Those files will still be on the phone, and then you can take them off, but the user that
sent them to you will never know that you actually have a copy of the files now.
Because you all know if you use a Snapchat and you want to do that screen capture, you
have to, like, you know, quickly do a screen capture on your iPhone device or I'm not too
familiar with an Android device to do the screen capture, but you can do the same thing.
But that alerts the user that you took that screen capture of the photo.
This way they would have no idea that you have the factually photos, so then you can
save them off.
You can save them as long as you want.
So kind of we're stepping through.
So we're looking at the network forensics ‑‑ sorry, the network analysis from this.
So we kind of set up a manual proxy, and then we set the messages back and forth to
each other.
So it's kind of a hypothetical situation.
You have to force a cert onto the phone, but yada, yada, yada.
But it still gives a perspective of what the messages look like underneath.
So we sent them back and forth, and we're able to download it, and it kind of gives
you an idea of, like, what's the response and what's the ‑‑
So you kind of see this response here is actually very similar to what's actually found in the
user P list file, and this is kind of talking on the iPhone devices.
So when you look at ‑‑ what's interesting about this, this is sent from the Snapchat
servers every single time a message is sent.
So this is the content that's similar into ‑‑ you know, that you'll find in the user P
list file.
And here is kind of what the note is, the message ID in this one, so the message ID
is what you want to tie back to.
communication that goes back and forth between the two individuals.
And then here what's interesting, this is a picture that was sent, right? So you're
looking at it here and you're like, well, how do you know it's a picture that was sent?
We all know that the magic number in a picture file is in the beginning of the raw data.
But here it's not that. So this kind of alludes to the fact that there is some kind of encryption
underneath, you know, SSL that Snapchat is using. So, you know, this is good, though.
But working with a couple of reverses out there, these individuals had done some reversing
on the APX file and were able to then determine that in reality encryption is very simple.
They're using AES electronic code book mode and the key is a fixed key and that fixed
key is for every single message that's sent.
So it's very simplistically, these two guys wrote their own, you know, PHP module and
Ruby module. Before I even came across this, I was like, oh, well, now that I know the
key based on this guy's blog here, which took me seconds to find that he posted, thankfully,
I just wrote my own little Python script to then decode it. And I was like, oh, that
was really simple.
So I got to kind of looking at the Snapchat. So now we're going to look at Facebook Poke.
So Facebook Poke is kind of like, you know, like, you know, like, you know, like, you know,
Facebook Poke app is just, when we did it, it was only for the iOS devices. You know,
their whole thing is after the message is sent, it's deleted from the app. It kind of
has the same idea as Snapchat. You know, the user has a timer set and that message
will then self-destruct or, you know, disappear once it's done. Well, is that really the case?
And here's what kind of the devices we use to do that. And, you know, again, we decapitated
traffic and we'll talk about that as we step through. So looking at the device, keep in
mind these GUIDs change. They change every single time. They change every single time.
They change per install. So these are just kind of specific to my device that I had.
But when you looked in these directories on the ‑‑ under the iPhone, you know, you
see these directories. So it had this one file which ‑‑ or one directory that contained
a cached SQLite. So it basically cached the photos of your Facebook profile pictures and
that's ‑‑ it stored it in there. And then it had another directory, the one right
below that, that actually had the pictures.
So now you kind of have the users that you communicated with and a thumbnail of the pictures
you communicated with.
But what really was, you know, the all be all for at least a digital forensics approach
is in the store.sql database. This database probably had about ‑‑ I didn't remember
counting, but at least 50 tables in it. But this one table of interest is a Zpoke messages
table. So in here we're able to find recipients in a counter. You had the sender. You had
a time limit. You had a creation time. You had the media type that was sent. And then
you had any text that was sent.
So we all know that you can send ‑‑ you can either send a text to the person, you
can send a photo to the person, but then you can send a photo with text to the person.
So all this is stored in this database. And here's just a kind of picture of it and showing
you. Kind of the one that highlighted, you can see that the message field itself is null,
but still text was sent. So this stored everything that was sent. And then the other table underneath
that is a Zpoke messages edge. So you can do a join on that table. And then you can
see the viewer state itself. You can see when they viewed it, what time they viewed it.
Whether they did a screen capture of it or not. So putting all this together, you can
really draw the picture to what's going on. Maybe you don't have the photos, but again,
like we did earlier, you can see that these communications exist. 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 type
of message to her. And this is the text that might have been included.
And then just in this whole table itself ‑‑ or in this database itself, there's another
table that is the avatar table. And this included, like, your Facebook ID. So you can add ‑‑ you
can, based on this whole one database alone, you can build a whole structure of this communication
of the one person's device. So this is another of the snapshots. It's
kind of a transition directory on iOS devices. When you kind of hit the home screen, it takes
a snapshot of the app you're in. So this is a snapshot of the message home screen was
actually saved inside this directory. So you have what is to be like a communication. So
the user can clear this ‑‑ this kind of ‑‑ this kind of ‑‑ this kind of, you know,
tracking of the communication they're having. But if not, and, you know, you exit the app,
it takes a screenshot of it. And Facebook's post case, when they programmed it, they left
that function on. So then you can see now messages that were sent and when they were
sent to individuals. And then in one of these other directories, you have P list files.
So I redact them. I don't know why I did, because it doesn't really matter. Because
these are my Facebook IDs that I use for this. And basically it stores that information.
So you know you can take that Facebook ID number and you
can go to the ‑‑ I think I have it on the next slide. Like a developer, explorer
from Facebook, you can put that ID in and you can see the actual user name that's tied
to that ID. That's open source. So that's all out there.
So then you have these other user agent. You have the log in ID. You have the last time
they registered Facebook. So you have this big ‑‑ you can build this big picture
of when this user was communicating, using this app, who they were talking to, when they
were talking to them. So then we can look at the network analysis side of the stuff.
You know, we see these posts. That's like when you send a message, they all look like
this kind of post. When you receive the message, it does a get request and a post request as
well. But what's interesting and different from Snapchat is Facebook just does a GZIPS
encodes it. So what's nice about man to mail proxy, it strips that off. So actually there's
really no underlying encryption under SSL using Facebook poke. You know, unlike Snapchat
that uses a 16‑byte key, these guys don't do that. So you're able to then, you know,
easily save that information. And then you have the other side of the network analysis.
You can save out pictures that were sent. So if you're able to, you know, capture their
traffic that way. You can then ‑‑ it also keeps fields of what text was sent, if a picture
was sent, and if a picture was sent with text. So this is all caught and this is all
in the payload of the traffic itself. And this is that link I was talking about. You
can take that user ID back here that I redacted for no reason and then send it to this link
and it can say ‑‑ it will say my name was tied to that user ID. So if you have those
P list files that ‑‑
You can take that and figure out who actually ‑‑ you know, the name they have registered
with Facebook. So this is kind of taking a look from the perspective of what the traffic
looks like itself. This is a payload of the picture. So you can see in the blue text
it recognizes it was GZIP encoded. It strips that off for you. So the underlying payload
itself is the JPEG payload. And here you can see there's a picture message that's text
and it actually stores in a message field. It says basketball hoop. So now you can really
draw this big picture if you're able to capture traffic.
And the biggest thing we're trying to draw here is that Snapchat uses the encryption.
Wicker uses encryption. But Facebook really doesn't use any encryption.
So last we took a look at Wicker and we kind of did the same kind of approach. They
claim to leave no trace. Their device ‑‑ their app is FIPS 140-2 HIPAA NSA Suite B compliant.
And they use AES 256 encryption. So the idea here was to kind of show ‑‑ we did two
fun apps, you know, Snapchat and Facebook. But we kind of look at the corporate level,
one that's more targeted towards the business folks.
So in doing the analysis and doing the physical extraction of the device, the iOS device,
you know, you still have these directories, you know, based on the GUIDs. But contained
in all of them, I wasn't finding anything of interest. Either they were empty, files
were all nulled out, contained no content. And it had some P list files, but all of them
had all the information that regarded to the directory of interest. So, I mean, nothing
that you didn't already know that was stored in these P list files.
And then looking at the network traffic side, I'm like, well, maybe there's something in
network traffic itself and then I can pull out there. You know, all the messages that
were sent looked like that PHP file was sent. All of them looked like that downloaded. The
only thing I was able to really do, because after that it was still encrypted, you can
take a baseline.
When I sent a text versus sending a picture versus sending a video, the payload itself
was obviously larger, which is what we expect. But if you have no baseline, you still can't
say whether a picture was sent or just text was sent or just, you know, a video was sent.
And then the only thing I found that just stood out immediately is that the first five
bytes of each of the payloads were the same. And then you can argue that, you know, well,
you can still grab that phone, that picture might still be in memory. And then, you know,
if you did a memory extraction, you'll be able to then get that picture. Well, no, it's
still cryptographically protected. Each of the keys are initiated for each user each time.
So this is kind of like what it looks like under ‑‑ this is the payload in Man-in-the-Mill
proxy. So you can see it's nothing. I mean, it's all scrambled. I didn't do crazy cryptanalysis
on it, not like I used to do. But I didn't want to spend time doing that. So it was just
kind of a highlight that they use ‑‑ they're doing what they say they're doing. They're
encrypting the payload. You can't find the payload. You can't find the payload. You can't
get anything out of it. And this is a sample of a received message that was sent. So, I
mean, you can see between the two, the first five bytes are similar, but that's about it.
So kind of to summarize it all, on the iOS devices, what's of interest? Well, you have
the user.plist file. On the Android devices, you have that XML file. They kind of link
up to each other about the same. They can contain the same amount of metadata, times
of messages that were sent, whether it was a picture message, who the user was texting,
how long the users were, how long the ‑‑ you know, was it viewed, when was it sent.
And then what's specific to Android devices, you have those cached images. As I said earlier,
if you have a rooted device, you can copy those pictures out any time someone sends
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 CD to that directory and copy those out, and they'll never know that
you did that. So some future research that we're kind of
looking at doing is doing unallocated string searching. Why didn't we do that? Well, we
spent a lot of time doing that. We spent a lot of time doing that. We spent a lot of
time trying to do network traffic analysis and looking at the actual physical, like what
else can we find, and just open files themselves. And 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
had that rooted Samsung Galaxy S3 phone, I was like, I know these pictures are going
to be in memory, but unfortunately the kernels I was using, they didn't have a configuration
set that specifically used for Lime, but I'm going to figure that out, because you
can do it on different devices. I think it was just these Samsung devices, they configure
the kernels differently.
So that's really it. Here are some of the tools and sources we used, you know, thanking
those people as well. And we have some time. I guess there's not a Q&A room anymore, apparently,
so we have some time left here. If you guys have any questions you want to ask, we have
15 minutes. So if anybody has any questions. This is Dre and I. If you want to contact
us, let us know, reach out to us.
You talk a lot about .
So we did, in some cases ‑‑ sorry. The question was we talked about received messages.
messages. So did we have anything about the sent messages? So nothing that I came across
when I was doing did I ever find any, like, of the sent messages I sent.
I had some on the Android. Sometimes on the Android you'll have it in the same cache
database. I'm sorry. Sometimes on the Android phone and the same cache database of the received
messages, the sent messages will be there also. I don't know.
So the question was did we ever try to trick the app into making it think that one more
pending image so that we can see if they all ‑‑ I didn't do that at all in my testing
at all.
Possibly could be done and it would take a little more of reversing. I didn't personally
reverse APX on the Android devices. We used a lot of previous open‑source research that
did that. That might be something to think about and look at a little further and how
can we trick it.
You should mention Snapchat coming after API.
Oh, yeah. So there was ‑‑ we worked with another colleague that actually created an
API to work, you know, a third‑party API to work with Snapchat and he caught wind of
Snapchat getting a little finicky about that. So he actually pulled that out.
And removed that from GitHub. So we were going to talk to that and explain his little research
that he did. But there was that ‑‑ you know, there was rumors that Snapchat didn't
like that. So he pulled down his API.
Okay.
There's a mic in the center if you want to walk up and ask questions. But go ahead.
The question was is there any work on iMessage? No, we actually didn't do any of that.
Okay.
Okay.
We're just kind of looking at these specific apps. There's a few others like Silent Circle
has a similar kind of set up of self‑destructing. But they have a paid service. And, yeah, we
could have done that and paid it and our company might have paid for that. But we just didn't
go that route.
How about Redbub?
Tiger text?
Yeah.
Tiger text?
Oh, no. We did do some research with Tiger text, though, which is a secure, like, email
address. And we were able to recover pictures but no communication information.
Thank you.
So 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 dealing with, like, what comes first. We're always dealing
with what goes into us. So it's very hard for us to do preventative work or, you know,
exploit the device in any way, shape or form. We're kind of getting it as evidence. So a
lot of that research is very interesting. It's just really not been stuff that we've
looked into.
Well, I want to thank everybody for coming. And I appreciate it. There's definitely more
people than I expected.
Thank you.