 My name is Drea, this is Kyle. Today we're going to talk about self-destructing messaging applications. And so I'm sure you all know, you've heard about Snapchat, Wicker, Facebook Pope, Tiger text. They all kind of have their own purposes in 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 Pope 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 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 running iOS 5 and 6, Samsung Galaxy S3 is running Jellybean and S3 mini. And then we used Celebrite Physical Analyzer and Access Data 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. Is 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 have 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, there are chipset requirements that prevent extraction. It's not OS related. That is kind of something that is misconstrued in the community. It is the chipset. It's not the operating system that prevents you from getting a physical preservation. But the four and older were actually able to get a full physical 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 really be able to read it. And as I said, iPhone, iPhone 3G, 3GS and iPhone 4. So file system preservation. We're actually able to get a full copy of the file system. You're not going to get like 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 logical 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 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. And during preservation, we can do physical preservation, which will debris the phone, similar to jail breaking in iOS device. And in some cases, we use it as a bootloader 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 a few articles that we did a simple Google search on showing how Snapchat has been used to do less than innocent type of activity. Snapchat generally has had a reputation for being as sexy as, but with 150 million messages sent a day, it's hard to believe those are all sexes, right? But it's also, that would be really, well, yeah. But it's also likely that it's not a trivial portion, right? It's, you know, there's going to be a good handful. This is just going to kind of explain, just in the last year, how the growth of Snapchat has exploited, how many messages have been sent since 512 up to 413. 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 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 iOS 5 and 6 devices. And then we used 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, right? 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 plist 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 tests that we ran show 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.plist file in Xcode. And this is what it looks like. There were some things that were immediately interesting. We saw user names, UNIX timestamps, 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 went and with what message IDs. So we looked into the plist format a little more and found that the user at plist 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 plist file. Parsing that plist with, it's a cool, really cool tool. From CCL Forensics, it's CDBPS Python module. And it shows that the plist contained a number of objects. Those related to this interchange of information are displayed in the slide here. There are a bunch of other objects that we either know 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 SNAP object itself. It contains a list of the SNAP objects on the device. Each of which contains metadata for the SNAP message that was sent or received by the user. 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 timestamps. 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 PLS 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 your employee, you might have an HR issue. If you have an account and exchanging SNAPs right before a filing, you might have a problem. If you have a student sending messages to a teacher, 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 had with reversers, it sounds like SNAP chat 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. MetaDays 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 SNAP chats 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. Thanks, Drew. 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? Right. So what I did is I got a Samsung Galaxy S3 Mini. I rooted it and then I just sent SNAP chats 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 empty. You send, I send myself two SNAPs. You go in that directory and you can see there's two of these picture files that exist. So that kind of says, all right, now they're sitting on the phone themselves. 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, reviewed the last one and went back and now they're gone. So kind of stepping back though is what I thought about the last couple of days. And this is really simplistic when you think about it. These files exist on here. You have your rooted device. So just CP it out to your SD card. Those files won't, those files will still be on the phone. And then you can take them off and then you put 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 SNAP chat and you want to do that screen capture, you have to quickly do a screen capture on your iPhone device. I'm not too familiar with the 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 have no idea that you have the factory photos. So then you can save them off and keep them as long as you want. So kind of we're stepping through, so we're looking at 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 hypothetical situation. You have to force a cert on the phone. But it still gives the 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 request sent. So you kind of see this response here is actually very similar to what's actually found in the user PLIS file. And this is kind of talking on the iPhone devices. So when you look at that, 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 to, you know, that you'll find in the user PLIS file. And here is kind of what to know is the message ID in this one. So the message ID is what you want to tie back to that 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 kind of looking at it here and you're like, well, how do you know it's a picture that was sent? And you know, we all know that the magic number in a picture file, you know, in 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, you know, but we, you know, working with a couple of reverses out there, a couple, you know, 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 app is just, when we did 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 ideas. 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 you know, here's what kind of the devices we use to do that and, you know, again, we caps the traffic and we'll talk about that as we step through. So look at the device. Keep in mind these glids 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 basically cached the photos of your Facebook profile pictures and that's stored in there. And then it had another directory, the one right below that. They 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 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 Z poke 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 with that. So we all know that you can send, you can never 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 Z poke 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 like 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 another text that might have been included. And then, you know, 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 loan, you can build a whole structure of this communication of the one person's device. So this is another, the snapshots, is it kind of a transition directory on iOS devices when you kind of hit the home screen. It takes a snapshot of the message, the app you're in. So this, 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 kind of tracking of the communication they're having. But if not, and you know, you exit the app, it takes a screenshot of it. In Facebook's post case, they left, 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 files, I redacted 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 can see 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 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 Facebook is that you can put it off. So actually there's really no underlying encryption under SSL using Facebook poke. Unlike Samchat that used the 16 byte key, these guys don't do that. So you're able to then easily save out pictures that were sent. So if you're able to 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 that's the whole 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'll say my name was tied to that user ID. So if you have those PLS files that contain that number, you can take that and you can figure out who they actually, you know, the name they have registered with Facebook. So this is kind of taking a look at it. So you can see in the blue text, it recognized it was GZIP encoded, it strips that off for you. So the underlying payload itself, you know, it's the JPEG payload. And then here you can see there's a picture message of this 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 kind of draw here is that Snapchat uses the encryption, Wicker uses that kind of approach. You know, they claim to leave no trace. Their device, or their app is, you know, FIPS 140-2 HIPAA NSA sweet 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 Pope, but we kind of look at the corporate level, one that's more targeted towards the business folks. So in doing the analysis and pulling out the extraction of the device, iOS device, you know, you still have these directories based on the GUIDs. But in containing 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 PLS files, but it had all the information that it related to the directory of interest. So, I mean, nothing that you didn't already know that was stored in these PLS files. Like, well, maybe there's something in network traffic itself, and then we 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 that when I sent a text versus sending a picture versus sending a video, the payload itself was obviously larger, which would we expect. But if you have no baseline, you still can send or just text was sent or just 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, well, you can still grab that phone, that picture might still be in memory, and then if you did memory extraction, you'll be able to then get that picture. Well, no, it's still cryptographic protected. Each of the keys are initiated for that. So this is kind of like what it looks like under, this is the payload in mandemill proxy. So you can see it's nothing. I mean, it's all scrambled. I didn't do crazy crypt analysis on it. Not like I used to do, but I didn't want to spend time doing that. So it was just kind of highlighted that they were doing what they said they're doing. They're encrypting 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 kind of summarized at 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 was sent, whether it was a picture message, who the users were, how long the, you know, was it viewed, when is it sent? And then what's specific to Android devices is the image. As I said earlier, if you have a rooted device, you can copy those pictures out anytime 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 were kind of looking at doing is doing unallocated string searching. Why didn't we do that? Well, we spent a lot of time trying to do network traffic analysis and looking at it. 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 root of Samsung Galaxy S3 phone, I was like, I know these pictures are going to be in memory, but unfortunately the kernels are used in and 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 don't, they configure the kernels differently. So that's really it. As we used, you know, thanking those people as well, and we have some time, and I guess there's not any, 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 Dray and I, if you want to contact us, let us know, reach out to us. We did, so like those are, in some cases, so sorry, the question was, we talked about received 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. Yeah, I'm sorry. I don't know, let's go here quick. 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 would take a little more of reversing, I didn't personally reverse the APX on the Android devices, so we used a lot of previous open source research that did that. I don't know, I don't know if we used 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 up with API. We worked with another colleague that actually created an API to work, 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 down and removed that from GitHub, so we were going to talk to that and explain his little research that he did, there was rumors that Snapchat didn't like that, so he pulled down his API. 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. We were just kind of looking at these specific apps. There was a few others like Silent Circle, has a similar kind of setup of self-destructing, but they have a paid service and yeah, we could have done that and paid it but we just didn't go that route. Tiger text? Tiger text? No, we did do some research with Tiger text though, which is a secure email, and we were able to recover pictures but no communication information. Right, 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 what comes in to us, so it's very hard for us to do preventative work or 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, thank everybody for coming and I appreciate it. There's definitely more people than I expected.