Investigating Sexual Crimes in the Tinder Age

Presenters: Jad Saliba and Jamie McQuaid, Magnet Forensics

Join the forum discussion here.
View the webinar on YouTube here.
Read a full transcript of the webinar here.


Michael Petrelli: Good morning, everyone, and good afternoon, depending on where you’re located. We’d like to welcome everyone to our webinar today, entitled ‘Investigating Sexual Crimes in the Tinder Age’. My name is Michael Petrelli, with Magnet Forensics, and I’ll be your moderator today.

Get The Latest DFIR News

Join the Forensic Focus newsletter for the best DFIR articles in your inbox every month.

Unsubscribe any time. We respect your privacy - read our privacy policy.

In this webinar, we’ll take you through a real-world case study involving… in the investigation of location-based mobile dating applications like Tinder, and we’ll explore what you need to know about finding and analyzing evidence from this new class of application. We’ll also host a live Q&A session after the presentation, so at that time, feel free to submit your questions into the Q&A box in the WebEx client during or after the presentation, and we’ll answer them in order. This presentation is being recorded, and will be available for viewing at shortly after our session today.

I’d like to introduce our presenters today. First, we have Jad Saliba. Jad is the founder and CTO of Magnet Forensics. Jad had worked with the Waterloo Regional Police Force for seven years, and then decided to found Magnet Forensics in 2009.

Our next presenter will be Jamie McQuaid, who’s our Forensics Consultant here at Magnet Forensics. Jamie had joined Magnet back in 2013, but previously worked for BlackBerry as a forensic investigator.

With that, we’re going to turn the presentation over to Jamie and Jad to get it started.

Jad Saliba: Okay, great. Thanks very much, Mike, for that intro, and thanks, everyone, for joining us today. We really appreciate your time, and I think you’ll find this to be a valuable and useful webinar. Just a quick overview of what we’re going to cover today. We’re going to walk you through a scenario that we put together – so a fictional case study, and then we’ll go through some of the artifacts, and base that on the scenario to make it a little more real. So we’ll be talking about Tinder, we’ll go into some depth there. We’ll just do a quick highlight on Grindr and Growlr, which are similar apps to Tinder. Then we’ll dive into Facebook, Snapchat, and into some quick stuff on pictures and videos, and Google Maps and geo-location, and then, like Mike said, we’ll jump into questions at that point.

Okay, so we’ll just get right into it here.

So a few headlines first, just highlighting the issue that is coming up with some of these geo-location-based apps like Grindr and Tinder. There’s a few different articles there that have made headlines recently. The first couple are about someone in Philadelphia that met someone on Grindr, after meeting, and interacting with that person, he was blackmailed, robbed, and beaten, and I think they’re still looking for the suspects in that case. The sexual assault assault on a 12-year-old there, again meeting over Tinder, using Snapchat, some of those apps, and lured a 12-year-old and assaulted her.

And then the last article centers around some of the frauds and scams that are happening on these apps. And I’m a little upset that they stole our tagline there, ‘Hook, Line, and Tinder’ – that’s what we were going to call the webinar, but it was already taken. But this is about some of the automated bots that you will find on the apps, where you’ll have people that are just trying to get you to go to either malware sites or other websites where they get paid to drive traffic towards, or even some of the more traditional online scams, where they’re meeting people, getting them into a relationship under a false identity, and then just trying to extort money, or just get money from them. Those are just some of the things that you may already be facing in your investigations, or may see down the road.

Jamie McQuaid: Now, we’re going to jump into the scenario, the case study that we’re going to look at. It’s in the next slide. First up, we have a report to the police. Wendy Cooper, who is our victim in this story, she’s 22 years old. She filed a report with her local police department that she was assaulted by our suspect, Reggie Dunlop. Cooper’s mobile device is collected and imaged for evidence. She voluntarily provided this, and then the police bring in Dunlop for questioning. And he is… [indecipherable] charged with assault. Upon arrest, his mobile device is seized and sent for examination. He pleads not guilty, and the case is awaiting trial.

Now, just to go over a bit of the incident. This wouldn’t be known to the police going into it, but we want to provide it to you guys here, just so you guys get an idea of how the incident actually occurred, or the series of events, and this kind of helps you understand the artifacts that we’re looking at here today.

So how it actually occurred was Wendy Cooper and Reggie Dunlop met over Tinder, they proceeded to use various chat programs, such as Tinder, Facebook, they emailed back and forth over a short period of time, they shared photos and videos using Snapchat, so we’ll get into some of that, and then, after some time, they actually decide to meet in person. This is where the assault occurs, and Cooper reports this assault to the police soon thereafter.

A little bit about the evidence we actually collected: I mentioned we’ve got two mobile devices here – we’ve got the victim’s mobile device, from Wendy. This is an Apple iPhone 5. It was voluntarily provided to us for examination. This was done… it’s an iPhone 5, so we weren’t able to get a physical extraction, but we were able to do a file system extraction on it. Then we were able to get the suspect’s mobile device. This was seized upon his arrest. This is an HTC One Android device. So we’ve got an iOS and an Android device here to look at. And this was a physical extraction done. So these are going to be the sources of our evidence that we’re going to look at, and let’s move on to our actual artifacts.

First up is obviously the big one – Tinder. This is a very popular dating app designed to meet random people nearby. I think a lot of people know, have heard about Tinder, or know about it, but they’ve probably never used it. So the first couple of slides here, I want to go into how Tinder works, and just in case you might come across it in your investigation, it’s good to understand how these applications actually work in the real world.

Now, Tinder uses photos and geo-location to make matches in your local area. The exact geo-location details are not shared with the users, but the relative proximity is. So that means if Jad and I here were on Tinder and we met over Tinder, I could set my relative proximity to look for anybody within a five-mile or thirty-mile radius, and it would show me matches in that area. And then I can pick and choose – the user chooses to either accept or deny those matches, based on their Facebook profile photos. Those photos are pulled directly from the user’s Facebook account, and you can swipe left or right and decide whether you want to match with that person or not.

Once the match is made – so once both users agree that they want to chat or meet, the match is made, they can begin chatting over Tinder. So let’s just go to the settings here. This is what the settings look like here on Tinder. Obviously, you’ve got some basic details, such as the search distance – we’ve got it set for 11 miles here, but you can range that anywhere from one mile to up to 50 miles. You can add quite a few distances there. You can show only certain age groups. So obviously, if you’re looking for a specific age group, you can narrow that down or expand that. And then you can also choose to show men or women.

So lots of options there. We’re going to focus mainly on the distances, just because the proximity settings, which again are set by the user, determine which Tinder users are presented to you in the application. Like I said, those actual coordinates… it does use your GPS, but those actual coordinates are not stored on the device. It’s stored on the Tinder servers, and those are not accessible to the actual users. So you will get some relative distances – so you will know that they are within a certain proximity, but you will not get the exact GPS coordinates.

Now, the distance is calculated when the potential match is recommended. So when you’re looking for matches, that’s when the distance is utilized. Once those matches occur, it does not matter how far apart you guys are. You are forever a match until you remove it, and the distance doesn’t matter [if it moves outside] that range. So [lots to take in for that], for the distance settings.

But now what happens if you actually come across it in your investigation? So obviously, Jad mentioned a few scenarios, that there are risks involved with meeting people online, especially when there’s very close proximity there. Several investigations around the world, Jad pointed out a few, and I know from going to trade shows and that, a lot of customers in law enforcement have definitely brought up Tinder as something they’ve looked at for an investigation. So that’s why we wanted to bring it up here.

So it’s essential to know what to look for with this. Like a lot of mobile artifacts, Tinder is actually stored in an SQLite database. Very similar to other artifacts that we see on mobile devices. You can see, I’ve got the paths there, for both iOS and Android, to tinder.db and Tinder2.sqlite. They’re both SQLite databases. You can see along the right side of the screen there – that’s the tinder.db, and these are the number of tables that you have available to you. If you look through it, obviously, there are some pretty obvious ones that might be of value – matches, messages, photos, users – we’ll get into quite a few of those in just a few slides here. But I wanted to show you what was available as an overview first.

Let’s take a look at some of the specific ones here. First up, we have users. So obviously, users – it’s going to be about the local user of Tinder on that device. You get the user ID, you get the bio, birth date, distance, which we already mentioned there, gender, first name, and last activity date.

For matches, you get a match ID, which is different from the user ID. I will get into that in a couple of slides here. You get the user name, you get the gender, the creation date/time for the account, the last activity timestamp, any message count – so if you’ve had messages back and forth with that person, that will show on the matches – and whether you’ve viewed the profile or not, as well as any draft messages that haven’t actually been sent.

Then, obviously, the most important spot is going to be the messages themselves. You can get the user ID, the match ID, timestamps of when it was sent, as well as the actual message obviously.

Finally, we’ve got the photos. You can also pull up photos for Tinder artifacts. You’ll get the user ID, the user name, and the URL. Now, if you see below, at my screenshot here, we do have the picture there. This is not stored on the local device. It is only the URL – just slightly above there, you can see there’s a URL that takes you to, slash, a giant URL. Those are stored on the cloud on the Tinder servers. You can pull those out, if you know the URL, you can pull those pictures out without any encryption or authentication or anything like that. They’re not stored on the device though – just the URL is stored in that database. So something to be aware of.

So let’s take a look at Reggie’s phone here, and see the results that we received for it. Obviously, we’ve got account details for both the suspect and victim that were found on each phone, and which confirmed their meeting. We’ve got Reggie’s Tinder ID, which is his user ID, that’s a unique identifier there, as well as a screenshot that indicates some details about the user. We’ve got Wendy’s user ID, which is a different number or value that also provides some additional details. And we’ve got the match ID.

Now, the match ID is something that’s unique. This is a unique number that’s created when they actually, when both users match up. Now, this is used and stored in every message conversation, so that you can tie it back to a specific match. It’s important to know that this is a unique number, different from the actual user IDs for both people.

Next up we have the Tinder conversations. So Reggie and Wendy were matched, and they begin to talk. So we can see a part of the conversation below, we can see some of the details, they chat just to get to know each other. But if you see at the bottom, they decide to add each other as Facebook friends and continue the conversation over Facebook. So that’s where this investigation’s going to lead us to. We’re going to go look at some additional artifacts after that.

One thing to note – I want to mention – we’re going to mention Grindr and Growlr here. Our case study does not apply to Grindr and Growlr. We don’t have any evidence for Reggie and Wendy using Gridnr and Growlr, but these are similar dating apps that use geo-location details and photos to make matches and that. It’s geared towards gay or bisexual men. I know women use it as well, but that’s what it was typically created for. You can pull out chat, contacts, and notes from both these applications. Again, it’s an SQLite database – you can see the locations below for Grindr and Growlr for iOS and Android there. One thing to note is for Growlr Android databases I’ve got a *.db at the bottom. The database name is unique – it’s different based on the user. But as long as you go to that actual path and find any database, that’s going to be the Grindr or the Growlr database that you need. It’s still obvious, and it’s still easy to read once you do find it, it is in that path, but the name is slightly different.

Next up I’m going to pass it to Jad – he’s going to talk about Facebook.

Jad: Okay, so we’re going to look briefly at artifacts on PCs and mobile devices. Obviously, beyond chat there’s things like wall posts and statuses that you can recover as well. We’ll just be focusing on the chat and geo-location data in this webinar. On the Android side, if you look under the com.facebook.katana, you’ll find a number of databases and other files that could be interesting, depending on your case. The file that we’re going to look at is the threads_db2. And on the iOS side, the database is named orca2.db. They’re both SQLite databases.

On the PC side, Facebook chat used to be great a few years ago – you could find lots of chat on the hard drive, either in live files or unallocated space, pagefile. And then they changed the backend system for their chat, and now very little chat actually goes on the hard drive. You’ll find some stuff in the pagefile and hibernation file, and you’ll still find a lot in live RAM captures, which is why those are becoming more and more important, but you won’t find a ton of stuff in unallocated or the browser cache. And there’s been multiple formats over the years. So we’ll show you a couple of examples. But the way that the artifacts look, once they hit the hard drive or are just found in RAM, has changed over the years. They’ve also consolidated chat and the messaging system. Used to be you had emails and live chat, and now they’re essentially one and the same.

So here’s just an example of a really basic Facebook chat artifact. You can see the text there. It’s fairly easy to go through this [indecipherable] fragment here. We’ve got a message, we’ve got a From ID, a To ID or the recipient ID, and then a timestamp, and you probably recognize that as being a UNIX timestamp.

So not a ton of data here – no names, and just the bare bones details. So if we go to the next example though, there’s a fair bit more data here. I think we… [we highlight] through here… so we’ve got the author ID, the person that sent the message. You’ve got the names, we’ve got a display name for that person, we’ve got a thread name for the conversation, and then a snippet of the actual message, so just kind of a preview, and then the actual, full message. Now, the timestamp here is just a relative timestamp, because it’s coming from what would be displayed in the UI to the user. So other times you get a full time… date and time. Because of the timing of when this was left behind, either on the hard on RAM, it was recently sent, so you’re seeing the words “Just now”, which is what would be displayed to the user. But other times you’d get a full timestamp there.

So looking on the Android side, we’re under that folder that I mentioned earlier, and then under that the sub-folder databases, and we’ve got the threads_db2 file, and as you can see, there’s a number of other SQLite databases that could have some useful information in them as well, so they’re worth taking a look at when you’re looking at Facebook data.

So if you open up that database, go to the messages table, we can see a number of messages here from our scenario, under the… we’ve got a message ID, and then a sender. So under the sender column, you can see an email address, Facebook, the Facebook ID, and then the display name for the user. And then the next column is the text, so that’s just the message itself.

And then if we scroll over further, what you can find sometimes is the actual coordinates, latitude, longitude, where the user was when they sent that message. And sometimes you can even find things like the heading, and altitude, and even their speed can be stored under this column. So here we have some geo-location, and that’ll be able to show us later where they were when they sent these messages.

Also on the Facebook [side], looking at photo URLs – so if you’re looking at browser history, either on a mobile device or on the PC side, you may see URLs like this. And this is indicating that a photo was viewed. So if we step through the URL, we can point out what some of these different numbers represent. We’ve got the photo ID, and that’s just representing that specific photo on Facebook. Next we have the album ID. This is the ID of the album that contains that photo. And then, near the end there, we’ve got the actual user ID that that photo belongs to. That’s the person that posted the photo on Facebook.

What we can do with this is use the Facebook Graph API to learn more about that user. So if all we have is the user ID and we want to learn more, we can use the Graph API to do that. So if you just open a browser, and type in “,” slash, the user ID, or if you have a user name you can put that in as well. You can just open that up and get some information on the user.

And I’m getting this without having to be logged into Facebook, without having to have any access to that person’s profile, and they could have their profile locked down, and this information is still publicly available. So you can see there we’ve got a name now, linked to their Facebook profile, and some other information, like their locale and gender.

Looking at some of the Facebook chat results for our case, we can see here by reviewing and pulling out all that data from the Facebook databases, we can see the messages, and we can this all nicely formatted, to see their coordinates when they were sending stuff, dates and times, and some of the other metadata. And another way to view this is in a conversation view. This can be a lot easier for juries or judges, or even just investigators that you’re handing the case over to, to review the messages and see it more in the original format, similar to what you would see using a Facebook app or logging into Facebook.

So this is something we can do in IEF now for Facebook, Kik, WhatsApp, and Skype. So just some of the… just another way to view messages versus the traditional spreadsheet format.

Jamie: Okay, so now we’re going to look at Snapchat. Again, this is one of those apps that is extremely popular on… again, another photo messaging app, you have chat, you do photos, videos, text, drawings, you can add filters, which is basically text, to your pictures and video. These are known as snaps. They’re sent to specific people. You can set a time limit on how long those recipients can view the snaps, anywhere from one to ten seconds, and then it’s deleted after the time expires. And again, this is one of those things that is very popular with people these days. But we’re seeing a lot more investigations around it.

Now, some data can still be recovered, but it does depend on the version of the app. So we’ll get into a bit of that as well. Snapchat tends to change their application and how they store the data quite frequently, so it’s certainly a challenge to keep up with. But depending on what version you’re seeing, what operating system [you use, you can] definitely still get some data back from it. So let’s take a look.

First up, this is for Android – you can see the path there. It’s an SQLite database, the tcspahn.db is an SQLite database. You can see along the right there, the number of tables that are available for it. There’s quite a few, and there’s a lot of really good data in it. You might also be able to recover the pictures and video. Again, this depends on the version you’re examining. But typically, you’re going to want to look in the phone cache and the SD card for these types of photos.

Now, what Snapchat does – and again, depending on the version – what they do is they’ll rename the photo or the video with an extension of .nomedia. So these can still be recovered. They just don’t have the typical extension. You can see an example down there below.

Now, depending if you’re on iOS or Android, this can be easier or harder. We’ve found that recovering this stuff on Android is far easier than it was on iOS, which we’ll see in a little bit here.

I want to call out specifically the AnalyticsEvents table that was found in that SQLite database. This is basically a transaction log of a lot of the logs and events that have occurred with snapchat. So this will show you whether a camera button was pressed, the chat session, pages, or any sort of requests back and forth, story posts, all of that stuff. Really useful even if you can’t get the pictures or video, you’ll still get a nice little log of what might have occurred on this artifact.

So let’s take a look at what we recovered on the suspect’s device. Again, we went into that same SQLite database, we went into the chat table, and there are still some chat conversations between Reggie and Wendy. But they are very short, but it confirms their meeting and the coffee shop, and they plan to meet, so you can get some confirmation there that we also found in Tinder and Facebook. You’ll see several pictures were sent… that we recovered were sent. It will include the filters – you can see the bear picture on the bottom right there. We use pictures of bears to represent graphic images. So you’ll see that quite a bit in this case study. This is to represent a graphic image that Reggie sent to Wendy over Snapchat, probably still a lot better than actually using graphic images.

Now, the logs – I mentioned that depending on the version and what OS you were looking at, you might or might not have some difficulties recovering some of those pictures. The logs will be there for iOS and the Android. We have a lot of difficulty recovering pictures and videos from the iOS, but we were able to get quite a bit from the Android device. So even on iOS, if you can’t get the pictures and video, you will still be able to get some logs for it as well. And again, this all depends on the operating system and version, but you should still get some pretty good results for that.

A little bit about the pictures we’ve recovered. You can see quite a few. I’ve bookmarked quite a few pictures, relevant pictures there. You’ll see some pictures from the suspect’s Facebook profile as well as some of those graphic or images that we found on his system. We’ve got a consolidated list from both the victim and from the suspect, and we also found some additional photos that weren’t sent to the victim, but were still found on the device, that probably require some additional analysis to determine if they were illicit photos or child pornography or whatnot.

Next up we have videos. Again, these were pulled from the mobile devices. What we’ve done here is we’ve displayed them, and you can see that we’ve done screenshots, and this is a nice preview of one of the videos that gives you screenshots at specific intervals, to provide that preview. You can then choose –given that preview, you might want to view it in an external viewer or export it for additional analysis. But it gives you a nice little preview there to take a quick look at.

A little bit about the pictures and video we found on the suspect’s device. I mentioned that we found those graphic images that were sent over Snapchat. Those were concerned in the assault. But we also found some illicit pictures that weren’t sent to the victim and that are certainly questionable and might require further analysis. We used [indecipherable] to identify a few of those [known] illicit images, and we were able to hit a few alerts on that as well. So again, we were using bears and bear cubs as an example of illicit images, but those are supposed to represent graphic images. Now, we’re going to pass to Jad for Google Maps.

Jad: Okay, great. So Google Maps uses the tile system to display the maps. You’ve probably seen some of these in your exams before. Each one is 256 by 256 pixels generally and the file names for the tiles can give us some information on where on the world map that tile exists. So there’s an X-Y value, and then a Z value, which is the zoom level. And you can see some examples there – different filenames that contain those X-Y and zoom level values.

So using values, we can look at a tile – here’s an example tile and the coordinates for it. Obviously it’s difficult to tell exactly where this is based on the information we have in the tile. And some tiles are even more difficult, depending on the location. But if you download the surrounding tiles, as we’ve done here, we can get much more context around what the person was looking at, where they were getting directions for, or where they physically were, based on this tile information that gets saved to the device. And it’s easy to download these by just changing the coordinates.

So we go to a browser and type in that URL, and then just put in our own X-Y and zoom level values, as we’ve done in the address bar there. You’ll just get a tile back that represents that location. And then, in March 2014, Google changed everything up so that the tile filenames are different now, and a little less pretty to look at, a little harder to pull out the values that we are interested in. The good news is that they’re still there. So if we look at some samples here, we can walk through this. The one i represents the zoom level – so it’s a field that’s designated as one i, and the ‘11’ is the zoom level. If we go to the next field here, two i’s – that’s the X value. And then we’ve got the Y value under three i’s. So same values, same information, just represented differently.

And then of course, to make things a little more complicated, this is a slightly different filename, so we’ve got a zoom level here, got an X value, and a Y value. So everything’s the same so far, but then we’ve got a four i field, with the value 128, and that represents the size of the tile. So in this case, you’d actually have to add one to that 15 zoom level to get the proper tile, since these tiles are being represented as half size.

In our case, we also found some URLs that are indicative of where someone was searching, getting directions, or just looking up locations. In this case, you can see in the maps/dir in the URL, that’s someone looking at directions. And if we break down a few of the data points in the URL, the first piece is the coordinates for the destination. So the 43.47 etc – that is the location that they want to get to, Forest Heights, Kitchener, ON is the starting point. And then the coordinates that we have after that are actually just the center of the map that’s being viewed at that time. So if you were to put this URL into the browser, you’d get the same view that we’ve got there, and then, as you zoom in or out, that third coordinate value will change, depending on where you’re zoomed in. So just something to keep in mind.

So we’ve got here a map view from our software, and this just takes all sorts of different apps and websites that have geo-location data potentially attached to the records, and plots them on a world map view, Google map view for you to review. This helps do the investigation seeing exactly where someone was when they were sending a message. As you can see at the top left here, we’re looking at a Facebook message that was sent and had geo-location data attached to it, so we can see where that person was when they sent that message. And there’s all sorts of other apps that contain that kind of information that makes it really easy for you to just quickly visualize where someone was at different times and different locations that may need to be further investigated.

Okay, I’ll just turn it over to Jamie to wrap it up.

Jamie: Okay, so just to summarize what we’ve gone over here – obviously, in the case study, we’re preparing for trial here, so we wanted to go over what the evidence was. Obviously, we found Tinder artifacts detailing how the suspect and the victim met. Then we went over some good conversation history between Reggie and Wendy for both Tinder, Facebook, as well as Snapchat, there was some conversation there. They made details around plans to meet, and location data on both devices, so that helps confirm both the suspect and the victim met at that location, it helps corroborate the victim’s story. We also found some inappropriate photos that were sent to the victim using Snapchat, and as well, we found some illicit photos and videos that were on the suspect’s mobile device that were not sent to the victim. So again, further investigation into those as well.

So a good summary of quite a few artifacts there. Hopefully that was helpful to you. Right now, I’m going to pass this back to Mike, and he can close things off for us with some Q&A.

Michael: Okay, thanks, Jad and Jamie. So we’ve noticed how Jad and Jamie showed us some things to look for when investigating cases involving these applications using a [mail] process, but you may have also known that they use the latest version of Internet Evidence Finder to expedite the recovery and analysis in an automated fashion. Thousands of forensic professionals are currently using IEF to recover and analyze hundreds of artifacts on computers, smartphones, and tablets. And if you haven’t had a chance to try IEF yet, we’d like to offer you a free 30-day trial, and encourage you to try it on new cases or existing cases you may be working on. And if you’d like to download the trial, you can do so at

We’d like to now get into the Q&A portion, so please submit any questions into the Q&A box. We have a few that are in here already, but continue to send them through, and we’ll get to those in sequence here.

We have a few questions to start with here, for Jad and Jamie, so either of you can jump in and answer these as they come through. One of the first few questions on this was around what tool you guys were using to view the SQLite databases, and what you might recommend for viewing these databases.

Jamie: Okay, so the database views – we used a few tools. Obviously, we used IEF for a few of those views, but for the raw pictures and that, we used… I believe it’s called SQLite Expert. [indecipherable] Yeah, I believe it’s called SQLite Expert. There’s a free version and a paid version. I believe that was just the free version that you can download off the internet. And again, there’s nothing special about these databases, so they can be viewed with any viewer, but that’s the one we use, just for our [test] data and that.

Michael: Okay, good, thanks. A question on Snapchat here – can you explain what happens to the pictures and videos after the timer expires? Are they set to delete? Is that why they’re harder to recover from iOS than Android?

Jad: Yeah, so that’s a great question. [indecipherable] it comes down to, depending on the version of Snapchat that they’re using, in some of the testing that we’ve done, even after the timer expired, the photo was still available to be found, just with that .nomedia extension attached to the filename. In other cases, they are actually deleted. So on the Android side, since most of the time you can carve unallocated space for deleted data, you can actually still recover those pictures, while on the iOS side, if the pictures are actually deleted, most of the time they’re encrypted, and it’s not possible to carve them. So that’s kind of the situation with Snapchat. Yeah.

Michael: Okay, good. So we have a couple of questions around the tool used to analyze the data in your case study here. As we mentioned, IEF was the tool that was being primarily used. Does the existing version of IEF support these… the analysis that we’ve been running with Tinder and Growlr or is [upcharges] required, additional add-ons required?

Jad: This is part of our mobile module – we released this module back in, I think, 2013, and this has all of our mobile functionalities, the ability to carve through, to recover deleted data on mobile devices, mobile images for all these different apps, and also within the databases themselves being able to recover deleted data. So it’s part of that module, and all of these new artifacts we’re adding to the module. If you do have it, you get them for free, there’s no additional charge to get the functionality that we displayed today. So you just get all of that data.

Michael: Okay. Another question here – we heard, and it may be rumored, that the deleted chats of WhatsApp can be recovered from the subject’s phone or getting logs from the WhatsApp server – do you know if this is possible?

Jad: We are able to recover deleted chats from WhatsApp. We’ve been able to do that for a while now, and we can also again… within the database, there’s times where you’ll find deleted messages that just haven’t been cleared out of the database, so we can recover those as well. So there’s lots to be recovered there, but it is also possible that you can go to WhatsApp with a search warrant or subpoena, depending on what you need, and get information from them. I don’t know how long they keep the messages for, so if you do have a case that you want to get some information from them, it’s good to contact them as soon as possible to get them to preserve that data for you.

Michael: Okay. So we have another question on geo-location here. Are geo-location messages… they’re being sent. Are they saved on the phone as evidence? One of the cases where the woman was assaulted, prior to the assault, there were messages to find each other’s location. So is there evidence on the phone that shows their geo-location as they get closer to each other?

Jad: I think on the Tinder side, like Jamie had mentioned, the location data is saved at the time of seeing that match. Some of the evidence that we were showing, of Facebook messages or other apps that store geo-location could show you their locations as they got closer for the meeting or they were at the location that they were going to meet at, and sent a message that had some geo-location attached to it. But Jamie, maybe there’s some other stuff you saw on Tinder?

Jamie: Yeah. Tinder, you’re not going to get a whole lot, because again, there’s no specific geo-location data stored on the user’s local device. So you’re not going to get a whole lot there. The Facebook messages, obviously, if you’re coming across… if they’re sending messages back and forth as they go to their meeting, you will see that, but it’s not something that it’s just going to pop up if they don’t send any messages or do any activity on the phone. For our case study here, we had a lot when they were prepping for it. Both users looked up the actual address on their phone using Maps and that. So that’s how we were able to corroborate that. But if they… yeah, you can get the gradual geo-location data if they continue to send messages. Quite often, they’ll have their phone with them, and they’ll say, “Hey, I’m here! Where are you?” sort of thing. If the geo-location’s enabled there, you can certainly get that, and that’ll also confirm that.

I know there’s another question about location services being disabled. Obviously, location services need to be turned on to the device in order to recover those geo-location details from Facebook messenger. Obviously, if they look up the map, you’re still going to be able to get those mapping artifacts from the browser, but location services do need to be turned on to recover geo-location data from Facebook Messenger.

Michael: Okay. Thanks, guys. Another question around Facebook – is there any way to identify the suspect’s Facebook ID who has sent [indecipherable] messages or chat to the victim, and then deactivated his Facebook account?

Jad: Yeah, that’s a great question. If you have some information on the user, the Facebook ID that they were using at the time, or their user name, you can still look up some information. As you indicated there, when people delete their accounts, they’re actually only deactivating it. So the account data is still there. And certainly, if you go to Facebook with a request, they can give you all the information about the account that you require. But there’ll be a lot of times where you can still, on a deactivated account, still recover a lot of information about that user. And certainly, if there’s any artifacts that are found on the victim’s phone, let’s say from that user, that’s also stored, it doesn’t get deleted from the victim’s device when the suspect deactivates their account.

Michael: Okay, another question on Snapchat here. So what phone did we use and what version of Snapchat did we use to recover photos on?

Jamie: For the… where we got most of the Snapchat data, like I said, the iOS, iPhone 5 that we had, we didn’t get a lot, we just got some log file details. But for the Android device, it was an HTC One phone. I believe we had… in the middle of that I upgraded versions. So I had an older version, I don’t know the exact version number. But part of the webinar was done, or the data collection was done on an older version, and part of it was done on a newer version. So I got a bit of data from both. So again, I was able to recover the sent snaps from… that the suspect had on his system, but I was not able to recover it from the victim’s phone. But I did see logs on it. So again – I don’t have the exact, specific version, but for the most part, if you’ve got an Android device, you’re going to get at least some details. iOS you’re very limited, in terms of what type of Snapchat details you’ll get.

Michael: Okay. So back to Facebook again. We have another question around how you change the view to see the actual Facebook chat after you pull the [graphs off]

Jad: Okay. That was actually… we were actually showing the output from my… in that case… so I was just going in a browser on the screenshot to look at information on that user ID or user name, and then the results we showed after that were in IEF, pulling data out of the SQLite databases that are on the device. So that’s where you can get all the messages themselves, and then you can kind of go from there.

Michael: Another question on the SQLite databases – are they encrypted, and did you manage to decrypt them?

Jamie: Typically, most of these SQLite databases are unencrypted. They’re stored locally on the device, and you can open them up with any SQLite viewer. It’s very rare that you’re going to actually have an encrypted SQLite database for most of these applications and artifacts. WhatsApp is a good example – they have an encrypted version and an unencrypted version on the phone. We are able to decrypt the database. It usually comes in a crypt or crypt5 or a crypt7 database. You can still decrypt those databases and then view them just as normal. It just takes that extra step. But typically, all the artifacts we showed here – those SQLite databases are in plain text and easy to read with any viewer.

Michael: Okay. So back to WhatsApp – it has the same features, but I can’t find many people talking about how to deal with it during forensic testing. Does IEF support collecting WhatsApp artifacts?

Jamie: Yeah. Like I said, [indecipherable] we support pulling it out, both the unencrypted database that’s in the user partition as well… they store the encrypted version on the SD card. And again, it depends on what version of WhatsApp they’re using, but they generally encrypt the one on the SD card and keep the unencrypted one on the data partition. So if you’re able to get root on the device, you don’t need to decrypt. But if you’re only able to get the database off the SD card, you’ll have to decrypt it using whatever algorithm… depending on whether it’s crypt, crypt5, or crypt7. But those can all be cracked easily with the key that’s found on the device.

Jad: Yeah. Just to add to what Jamie was saying there. Some of the newest versions of WhatsApp are encrypting the messages on the private database as well, but our latest version of IEF can decrypt those using those algorithms and by using the key that they use to encrypt the messages. So those are available for decryption now.

Michael: Great. So as we’ve been talking about a lot of mobile app usage and [indecipherable] within these apps, a couple of questions have come up around a comparison of IEF in this space to what [Cellebrite] would do. Any comments on those two tools there?

Jad: Yeah. I mean, I look at IEF as being [Cellebrite] or other tools like [XRY] and so on. And it’s all about using multiple tools in forensics. There’s never one that can do everything perfectly every single time. So it’s throwing multiple tools at the data and seeing what gets you the best results on different cases. And we do a great job of recovering deleted data in the databases, in unallocated space, and supporting a lot of different apps and a lot of different artifacts from those apps, and really explaining to you what the different fields mean, different columns. So I think using them together is a great option.

Michael: We had a couple of kind of general questions about what IEF supports in terms of the mobile artifacts. There’s really hundreds of them, so we’re not going to go through them all here, but you can find some details on what we support there by visiting our website at, and under the Internet Evidence Finder section on Mobile, we have a quite extensive list of the artifacts that are available there. And in the same vein, some questions around… white papers, with these case studies, and we do have those available as well at You can search through those via type or category, and which talk about a lot of similar examples to what Jad and Jamie took us through here today.

Another question here around custom apps, a comment that some people use custom apps to share their geo-location with other users, which is believed to lead to some problems. So how can forensic examiners deal with such apps?

Jad: Yeah. It’s a great question, and beyond custom apps, there’s just thousands of apps out there. So trying to deal with all the different apps on multiple cases is a difficult thing. We developed a feature that we call the Dynamic App Finder a little while ago, and what that does is it goes through all the files on an image, and identifies databases. And once it identifies the database it checks certain fields and contents to see if it’s from a chat application. And what we’ve been able to do through this feature is identify chat applications that are not currently supported – could be custom applications or just not very popular yet, and allows you to pull the data into your IEF case, to still be able to not miss that data, and still bring it into your case and analyze it. And we’re going to be adding more functionality to that feature, which is patent pending… [like GPS-type apps], like Tinder and so on, and just other apps, to try to help you not miss any of these things, and add that more robust support across the board.

Michael: Okay. So a question around have we ever looked at data from Ashley Madison.

Jad: Yeah. I mean, on a professional [laughter]… professional side, we have. And we do have support in IEF for fragments that are left behind when using the Ashley Madison website. So we’ll recover the HTML fragments for you, and display that, which can show you things like messages, people viewing profiles, and so on from that site. But that’s in our product as well.

Michael: Okay, another question here – in the case of needing to have GPS data turned on, [no data of] cellular location is saved. So for example, between three signal towers, can we triangulate locations of the users?

Jamie: Yeah. So typically, those aren’t going to be saved in the specific application. So like Facebook chat and that, you’ll get the GPS coordinates using the location services and that, but if you’ve got location services turned off and you’re doing cell tower analysis, that’s not going to be stored in the chat. You might still get some stuff if you’re able to do some cell tower analysis, but it’s really beyond the scope these applications. And again, it does take some specialized skill sets to do those triangulations. It’s actually pretty difficult to do. It’s not something I’ve ever done, but… I know it is possible, but it’s definitely not stored in these applications in the same way that the location services and GPS coordinates are.

Michael: Okay. Another question on Facebook here – Facebook graph only reflects the basic information that can be viewed publicly. How else can the Facebook graphs be helpful?

Jad: Yeah. It is true, you’re only getting basic information from the Facebook graph, but that can be the starting point for you. So once you have names, maybe a link to the profile… you can take your investigation from there. So it’s all part of just building your investigation, taking one piece of data and building upon it, and going from there. And there’s other tools you can use once you have a user name, full name on Facebook, to learn more about that user.

Jamie: Just to add to that – I know Jad mentioned the, with slash, the user ID. You can also go to, slash, the user ID, and that will take you to the actual user’s profile. Now, it depends what’s locked down on that account, but you still might be able to see some additional information. I know I did a lot of open-source investigations, and obviously, you being logged into your own Facebook account also gives you some additional details about that user, even if you’re friends or not. You do have to be careful none of that data is shared with the user, but you never know. Facebook does store when you view certain profiles, so you want to be careful with that. But it does give you some additional stuff like pictures and that, that wouldn’t be available with the graph.

Michael: Okay. So what images does IEF parse from mobile devices?

Jad: IEF will parse any raw image, any [DD] file or bin file image from a mobile device. Also zip archives or tar archives. And then if it happens to be in any other forensic format that was for… like [E01s, EX01s, LO1s] and so on, we can all support those. Most tools that are doing the acquisitions put the data in a bin file, some sort of raw format. Some of them have some sort of encryption or encoding around that, so in those cases, you just need to export your image to a bin format, and then IEF can run against that.

Michael: Okay. So looks like we may have one last question here. Is IEF an acquisition tool or just an analysis tool?

Jad: Yeah. [On the… I mean, kind of] tied to that last question, on the PC side, we do some acquisition around RAM catchers, live systems imaging, and stuff like that. On the mobile side, we rely on other tools today to do that acquisition, either physical or logical, and then you can run IEF against them to do the processing, artifact recovery, and then analysis.

Michael: Okay. Let’s see what else we have here. So a question around Twitter – if we investigate a Twitter account where a user’s [illicitly] threatened the victim. What options do we have to locate the subject, and is there any further evidence we can find?

Jad: Yeah. A lot of times, people leave that GPS location turned on for their account on Twitter. So you may be able to find that yourself by looking at the tweets, and get an actual location for where that suspect is. Also, in cases like that, you’ve got an illicit thread, someone’s life’s in danger, you can contact Twitter and get some information right away about that person under exigent circumstances, without a warrant.

So I would definitely contact Twitter in those cases, if you can’t get what you need right off the site, and there’s other tools out there that help you investigate Twitter-related cases online. But Twitter can definitely help you out. I think there are some law enforcement guidelines out there for who to contact and how to get that data. But exigent circumstances like that, they’ll give you what you need right away.

Michael: Okay. Great. So I think we’re going to wrap it up there, for the sake of time, but we appreciate everyone attending and participating in the discussion today. We again thank Jad and Jamie for taking us through the material. If you have any further questions, feel free to email Jad or Jamie. Their email addresses are listed here. And as a reminder, this session was recorded, and we’ll make it available for viewing at within the next 24 hours. So thanks everyone, again. And this concludes our presentation today.

End of Transcript

Leave a Comment

Latest Videos

This error message is only visible to WordPress admins

Important: No API Key Entered.

Many features are not available without adding an API Key. Please go to the YouTube Feeds settings page to add an API key after following these instructions.

Latest Articles