Presenter: Jad Saliba, Founder and CTO, Magnet Forensics
Join the forum discussion here.
View the webinar on YouTube here.
Read a full transcript of the webinar here.
Melanie: Hi, and welcome to today’s webinar: Using Geolocation Artefacts and Timeline Analysis to Solve the Case – a Digital Forensics Case Study. My name is Melanie, and I will be your moderator for today.
In this webinar we will take you through a fictional case study involving child luring that leads to murder. You will discover how digital forensics, geolocation artefacts, and timeline analysis in particular can be critical in solving cases like these, and where you can look to find the artefacts. The data analysed will include a PC image and a mobile device image, showing how both sources of evidence can provide valuable insight into what happened, where to start a search for a missing person, and the corroborating evidence to support criminal charges.
We will have a Q&A at the end of the webinar, so please write your questions into the space available on the side panel, or send them to [email protected] and we will answer them at the end of the presentation. Our presenter today is Jad Saliba, Founder & CTO of Magnet Forensics. Jad is a former digital forensics investigator who left policing to devote all of his time to developing software solutions that dramatically improve the process of recovering and analysing internet evidence left behind. He has since developed Internet Evidence Finder into a thorough, easy to use software solution that recovers internet related artefacts from computers, smartphones and tablets. As Magnet Forensics’ CTO, Jad is focused on researching new methods of recovering and analysing all types of evidence for digital forensics investigations. Now I’d like to hand it over to Jad so he can begin.
Jad: Thanks Melanie, and thanks everyone for joining us today. We tried to do this webinar at a time that would suit our friends across the pond and be at a better time during the day, so any of our friends that are in North America are on and are wondering why it’s that early, that’s kind of the reason behind it. So we will be recording this webinar and posting it later on, so if any of you need to go back to sleep right now and catch it later you can definitely do that. I really appreciate everyone that’s on with us today, and for making the time to be with us.
So I’m going to jump into this here and give you a background story on this fictional case study.
So, pre-incident: a sixteen-year-old female and 29-year-old male meet on Facebook. The male is pretending to be eighteen and using a fake name. He uses grooming techniques to establish a bond with the female and convinces her to meet him in person. Using Yahoo! webmail, an email is sent from the male to the female, who has a Gmail account, with the map of the meeting location attached. The female uses Google maps on her computer to get directions to the meeting location, and then leaves the house to meet the male.
The male arrives at the meeting location and uses Facebook on his Android phone to message the female telling her “I’m here”. The female arrives shortly after, and after an altercation ensues the male murders the female. The male panics and sends a friend messages using Kik messenger asking for help and advice on what to do. He attempts to hide the body and leaves the scene. Later on he runs Google searches on his phone for information on how to cover up a murder and common murder sentences.
The female’s family files a missing person report and police start their investigation. Information is found on the female’s computer showing her chatting with the male on Facebook, the email received on Gmail, and Google maps artefacts. Based on the Google maps artefacts, the police attend the meeting location and find the body. They obtain an IP address for the male by logging in to the female’s Gmail account and viewing the full headers of the Yahoo! email that was sent by the male. They obtain his home address from his internet provider and execute a search warrant on his house, seizing an Android phone during the arrest. GPS coordinates are found on the phone in the Facebook app data, placing him at the scene of the crime. Incriminating Kik messages and Google searches are also found and used during the investigation, where the male confesses to the murder.
So that’s the background story that we made up to include a few different aspects of investigation, a few different artefacts that you probably have already run into or will run into in investigations. And what we’re going to do is go through the artefacts first, kind of look at them from the crime scene’s perspective and parsing them manually, and we’ll also go into how timeline analysis can help you get to some conclusions quickly and how geolocation data can help you, in your investigations, quickly find out where to start looking for evidence or to prove that someone was in a certain location.
So as I was going through that you probably picked up a few different artefacts that are involved here. So on the PC side, which was for this purpose going to be just the female victim’s side of the incident, is Facebook chat, Gmail artefacts and Google maps artefacts on the PC. On the mobile side for the suspect we’re going to be looking at some Android artefacts; again Facebook chat; we’ll see geolocation data, Kik messenger chat and then some web browser history and searches on the mobile device.
So let’s jump into the PC artefacts .
So just a quick background on Facebook chat: it used to be left behind on the hard drive, as many of you know, in temporary text files, and there were only a few formats at the beginning. Because it was left behind in text files in the ‘temporary internet files’ folders, there’s quite a bit of chat to be found in those cache folders, in unallocated space and other places of the hard drive. Facebook made a few changes a couple of years ago and now they’re mainly found in live RAM captures, which is a good reason to start doing those, if you’re going on scene and computers are on and you’re not already doing the RAM captures. Other places they can be found is the page file and the hibernation file, and because those are two files that are closely linked to live RAM that’s why you’ll find artefacts there as well. And today there’s multiple formats, so Facebook is constantly changing from a user perspective, which means the back end also changes and the way the artefacts look is constantly a moving target, and there’s also more ways of communicating on Facebook now so things like the emails that you can send within Facebook has kind of blended with the chat messages, and the artefacts start to blend that way.
So we’ll look at a couple of examples from our scenario here. So this is a Facebook chat message, it’s from this case study, and it’s an example of what you might see on a hard drive. I’m just going to highlight a few things here. So we’ve got the actual message here that was sent, so “we should meet up sometime”, then we have a message ID and then a timestamp. We’ve got a timestamp here, this is in Unix millisecond time, so it can be converted easily and it’s in UTC time. The key thing about this field is that the time is coming from the Facebook servers. So even if the local users change their local system clock so they’re changing time zones, or they’re on different time zones, this field will not be affected by those changes, it’s coming from Facebook.
Now the next field here, the client time. This is another Unix timestamp but it’s set by the client, by the user, so potentially there could be some different data here than what you’re seeing on the time value. And if someone’s using a third party Facebook chat application that doesn’t set this properly, you might see some very different data here. So less reliable than the time value, but it’s something that you can look at as well. We have another message ID for whatever reason and it actually has the timestamp in it again, so just something to notice there. Then we start having some user data, so we have the user ID that the message was sent from here, and then the user ID that the message was sent to. Then we start having some names in this artefact, so we’ve got the from name, John Smith and the first name, and then we’ve got the recipient’s name which is Jane Doe, first name there as well. We’ve got some information, some metadata: if the sender was offline when they tried to send this message, and some other metadata about if it was a message or an email or other information like that.
So that’s one example of Facebook chat. We’re going to go to another example here.
So this is another Facebook chat artefact and as you can see there’s a fair bit less data here. So if we jump in again, we’ve got a ‘from’ ID for the sender of the message, we’ve got the recipient ID, the Facebook ID, we’ve got a timestamp, this is the one we saw in the last artefact. You don’t have that client time in this artefact, we also don’t have ‘from’ or ‘to’ names, so we don’t have the actual full names of the users. We’ve got another message ID and then the actual text of the message here.
So slightly different as you can see, and there’s more formats than this, but these are just a couple of examples of some Facebook artefacts you might see and again, if you’re doing live RAM captures you’re generally going to have the page file and information file if you’re dealing with the Windows system, these are artefacts you can definitely find in those areas.
Moving on to Gmail.
So when people are using Gmail, sending and receiving messages, there are traces of data that are left behind from that inbox view that we can recover. So generally what you’re going to find is the data that you would see when viewing a folder on Gmail. So you can see email addresses and names, subject line, a snippet of the actual content of the email, and then a couple dates and times. Sometimes you can find full messages as well, but that’s a little bit more rare because of how Gmail handles their web content and trying to keep it from hitting the hard drive for numerous reasons. So again, live RAM is our friend here, you are going to find a lot of this data in live RAM, because of that, the page file and the hibernation file. But you also find it sometimes in some unallocated space, temporary internet files, so it does… there are times when this data will get saved to the hard drive and then deleted, sometimes it’ll go into the temporary internet files and it’s quickly deleted, within a second or two, and then in that case you’ll find it in unallocated space. So it’s definitely something you’ll see in investigations. And let’s take a look at an example from this scenario here.
So again this is a fragment of Gmail data that you might see, so we’ll just start going through it here. This flag here indicates if the message was read or not, so ‘yP’ indicates a read message. If you were seeing a ‘zF’, that would indicate that the message was not read. So we’ve got the flag there, then we have an email address here and this is the recipient, and then we’ve got the sender’s address here.
Now these email addresses are basically the addresses that were in the conversation of the email, so it’s not necessarily… in this case you can see the email address is not necessarily the sender, it’s just one of the addresses that was involved in this conversation, and in this case our suspect has been good enough to make it very clear who he is by his email address. You may not have that luxury, but you’ll likely understand the mail address of your victims versus your suspects and be able to make this determination in your cases.
So moving on from there, we’ve got a subject here for the email, obviously there’s some metadata around, some characters for things like HTML tags and so on, so we’re just going to move around those, and then we’ve got a snippet of the actual content of the message here. And this “\u0026” is just the hex character for ampersand, and then the “hellip” is three dots, so in HTML it ends up just looking like three dots here at the end, which is what you would see looking at the inbox view of your Gmail account. So sometimes you’ll also find attachments, in this case an attachment was sent, you can see the file name of the attachment here, “map.jpg”. You obviously in this fragment are not going to actually find the file itself, but you’ll have some ideas there, a clue that there’s an attachment and perhaps there would be a file on the hard drive to look for by that name.
After that we’ve got a date and it’s just in plain text in a format that… there’s a quick date here, just August 10th, and then a full date in plain text that Gmail formats and saves in that format, so there’s nothing you have to convert here, and this is local time, so it’s 8.28pm local time. And this format may vary depending on the locale the user. After that we have a Unix time in microseconds. And this time is something that we’ve done some research on. It appears to reflect either the last time that the message was viewed, or the last time it was modified in some way. So if you add a star to the message to kind of bookmark it in Gmail, this time would get updated; if you view the message it would be updated, and if you haven’t touched the message it’ll essentially reflect the time that’s just prior to that, it’s August 10th at 8.28. So this time can give you some different clues about the user’s activity, they can give you an idea of the time zone that the computer was set to and can be pretty useful to have. So that’s a Gmail fragment there and it’s kind of part of our scenario where the suspect sends a map to the victim, he’s sending it from Yahoo!. Yahoo! does store the sender’s IP address in the headers, so later on in the investigation, investigators are going to be able to log in to the victim’s Gmail account, view this email, look at the full headers and get the IP address of the suspect.
So we’ll move on to Google maps now.
So depending on the browser that is used, when someone’s going onto Google maps and researching addresses or getting directions, you may or may not see URLs that include all the information about what they were looking for. So it just depends on what browser they’re using. But data is left behind regardless, containing URLs and other metadata that will give you some information about where the person was trying to find directions to, or addresses they were searching, including some geolocation information. So these can be found again, live RAM page file, hibernation file, but they can also end up in the temporary internet files and then therefore unallocated spaces as things get cleared out of those folders. And this can be really useful in a lot of types of cases, so in this case, a homicide, but in child luring cases if a child is trying to meet up with someone they’ve met online, and if they’re trying to get directions obviously they’re going to go to Google maps, they’re not going to use a traditional map or ask someone how to get there, they’re going to find it online. And if a child’s gone missing and you have their computer, this is a good thing to be looking at. Terrorism cases can also involve mapping, and all sorts of other cases.
So we’ll take a look at the example from our scenario and kind of go through some of this data. So this is a fragment of data that’s left behind after the victim got directions to the meeting location. So going through here, we’ve got this field here, this is the starting address or source address, and this is her… we’re going to see this is her home address here, and then we’ve got the destination address. And this is the meetup location that was given to her by the suspect. We’ve got some other metadata after that, we’ve got an original query here, so this is the text that was typed in by the user, and sometimes you’ll have this in a couple places. So in this case, original query, sometimes you’ll just have a “q=” with the search query. So if we go further along here, we’ve got another field here, “sll=” and then we have a longitude/latitude coordinate there which is really great. So the “sll” field, if you do some research on it, it’s what’s considered a business location, so when you’re searching for something Google’s going to assign this GPS coordinate for use when you’re trying to find nearby businesses. So it may not always be exactly the location of this address here that we’ve seen just prior, but it’ll be very close by, it’ll be used for those business searches.
So going a little further we’ve got a direction flag and in this case it’s “d”, so these are… we’re getting driving directions here, but you can see the other flags that would indicate public transit as a method of travel or walking or other things like that. And if they were using public transit, this “ttype” field, which in this case equals now, so we’re getting directions for right now, but you could… with public transit say that you’re travelling tomorrow at 5pm and you’re looking for routes that apply to that time, so you might see some more information in that field indicating when they’re actually going to make their trip. So just something to keep in mind if you’re looking at this kind of data.
In this case we have some text that gives us some obvious information, get driving directions and then the starting address and the destination address here. So that’s a fragment that you might see on a PC that indicates that someone’s looking at directions on Google maps to a specific location.
OK, so we’re going to move on to the suspect’s side and look at some Android artefacts.
So Facebook… Facebook app stores a lot of different things, we’re going to focus on chat in this scenario and the geolocation data that’s stored. So if your suspect or victim is using Facebook on their Android phone, you’re going to find data in the com.facebook.katana folder on the data partition, and there’s also another app just for Facebook messaging, and if they’re using that you’d see com.facebook.orca. And these are just kind of code words or project names that Facebook uses for their different apps. The file we’re interested in is called “threads_db2”, but as you’ll see in the next few screens there’s quite a few different files with a lot of great information in them. This file is a SQLite database and as you’ll start to see as we go through some of this Android data, there’s a lot of SQLite going on here. Let’s take a look at the data from the case.
So this is the main folder, that com.facebook.katana, and you can see there’s lots of great stuff in here, there’s a cache folder, files and share preferences. Going to just jump over to a folder view and we’ll look at some of those before we go any further.
So we’ll go into the com.facebook.katana folder. Under the cache folder you’ve got some chromium cache files, you’ve got some images, you can see some images here that are stored from either files that were sent or profile pictures of users, we’ve got a victim or our suspect here. Going back under ‘files’, we’ve got some more files here, no extensions but these are .png files so I’m just going to open them up in a viewer. And you can see kind of an icon there, it’s either from an app that was being used or again a user thumbnail that was set. So you can go through a lot of these files, there’s some XML files in the preferences folder that contains metadata like the last time that the app was used and last location and stuff like that, so lots of great stuff to be found in here. So going back into Outlook, this is the databases folder which we didn’t look at but you can see it here, so there’s a few different databases as you can see, quite a bit of data, the “fb.db” file is actually the main database, hence the name, and you can find a lot of different data about what the user was doing on Facebook or friend information in that file.
So again we’re going to be focusing on the threads, or “threads_db2” folder, and take look at it here. So you can see I’ve got the file open in a SQLite browser, on the left side we’ve got a few different tables, we’re looking at the main.messages table, and we’ve got a few different columns here, so we’ve got some message IDs, a thread ID, and then the text of the message and the sender information. There’s a bit of JSON data in that column indicating the email address, which was a Facebook email address, the user ID, and then the actual name of the user. We’ve got a timestamp in milliseconds, that’s Unix time again, so easily converted, and it’s going to be in UTC time.
If we scroll over a bit we’ve got our coordinates. So this is the message that was sent by the suspect when he arrived to the meeting location and told the victim that he was there. And we’ve got a latitude and longitude, with some other information like altitude and speed. So he was stopped at the time, we’ve got a 0.0 for the speed, but if he was driving while he sent this message then we’d have some information about the speed of the car as well.
So you can see the message there, where he’s saying “I’m here”, and then a reply from the victim saying that she’s almost there. So that’s some of the data that you’ll find in the “threads_db2”, there’s other tables obviously with more information that’s useful to look at if you’re investigating a case and you want the full picture, so lots of great data to look at for Facebook, for the Facebook app on Android.
Moving on to Kik messenger, so this is the app that this suspect used after killing the female to get some advice from a friend. And so again there’s lots of great data to be found in the Kik app folder, but we’re going to focus on chat for this webinar.
So the folder, or the package folder, that Kik messenger uses is a bit different than Facebook, it’s just “kik.android”, and the file that we’ll be looking at is the “kikdatabase.db” file. Another SQLite database, I’m sure you’re surprised as quite a bit of data on Android and IOS devices is on SQLite. So we’ll jump in and take a look at the data here.
So some similar folder structures, lots of great information, we can jump over and take a look for Kik. So we’ll jump into the “kik.android” folder, we’ve got some thumbnails here, got some… you could have some pictures in the large folder as well. And then again you’ve got some preference files, some XML files that have different user preferences, and other metadata that may give you some information on the usage of the user. Jumping back in here we’re going to look at the databases folder, so a couple databases, not as many as the Facebook app, but still we’ve got the main “kikdatabase.db” file and then a Kik Android file database which stores information on file transfers that are sent using Kik messenger.
So opening the kikdatabase file again there’s a few different tables, contacts and other metadata. We’re going to look at the “main.messages” table, and you can see the body of the message in this column here. We’ve got the default message that you receive from Kik when you sign up, and then some of the user messages further below. You’ve got the partner ID, I’m not sure what the ‘J’ stands for, but this is essentially the Kik messenger ID. So it’s got the username, “jeanclaude” and then an underscore “rbs”. And again I’m not 100% sure what the ‘rbs’ stands for but again it’s just something that Kik uses, so it’s @talk.kik.com. And then a flag that indicates if it was the user of the phone that sent the message. So a ‘1’ indicates that it was the local user, a ‘0’ indicates it was from the remote user. Then you have a read state, so in this case we’ve got a bunch of 500s and these indicate if the message was successfully delivered, or it was delivered and read, or just sent to the user. So these 500s indicate that the message was delivered and read, the 400 indicates that it was just delivered. We’ve got a timestamp here, again Unix timestamp, fairly common, and that’ll be in UTC time. That’s all we have for Kik, and we’ll jump over to the Android browser now.
So we’ll just do a quick overview again: there’s a lot of data for all these apps that can be found and we’ll be focusing on a few areas today. So the default browser on Android can be found at com.android.browser in the data partition, again the file that we’re looking at is called “browser2.db”, and again SQLite database, so again makes things easy for us, and a standardised format. So we’ll take a look at some data here as well. So that’s the main folder, there’s a bunch of app folders there, so if you have a different kind of plugins for Chrome, extensions, you’ll see some information there for those different apps, the database folder and then some shared preferences.
So under the databases folder we’ve got a few databases again, funny enough, and the browser2 files will contain most of the information that we’re interested in. But you can find some cookie information, some of the other files that are there, and then some auto fill information that’s saved by Chrome.
So once we’ve opened the file you can see a few different tables on the left side, some bookmarks, images, searches, and so on, settings and the “main.history” is going to contain the history records that we’re interested in. So fairly easy to go through just like the others, the other SQLite databases, we’ve got a web page title which gives us a fair bit of information. Since it’s a Google search and then we’ve got the URL, and something to notice in the URL, this flag here, the “qsubts=”, this is a Unix timestamp and gives you some information about when the search was performed. Obviously you’re going to have a timestamp in this database from Chrome, but this timestamp’s slightly prior to the time that the browser saves in the database and could be used to just verify that the times are consistent. I’m not sure exactly what this field name stands for, obviously the ‘ts’ is timestamp and the ‘q’ is the query, so I’m not sure where ‘sub’ fits into that, but just something to keep in mind.
If we scroll over a little further, just look up the URL in view there, you can see the query in the URL, ‘how to hide a dead body’, and these are the searches that the suspect did shortly after the murder, and then a few, the last couple he did a bit later on, after having some time to think about it. So we’ve got the dates there, timestamps in Unix time. You can see they’re slightly different than what’s in the URL, but they’re fairly close, within a second or two.
Then you’ve got a visit count and a flag indicating if the user entered the URL themselves. So while the user did type in the searches here they didn’t actually type out this entire URL themselves, so they didn’t go in and type “Google.ca/search?hl” et cetera, they did a search and the browser generated the visit to Google which created the URL. So you can obviously tell if the user typed in the search, but if they actually typed in the full URL you’d have a 1 instead of a 0 under the ‘user entered’ column.
And that’s kind of it for the browser, like I said, there’s more to be found in some of the other tables and files, and it’s something to keep in mind if you’re trying to find more information on browser history when looking at an Android phone.
So that kind of wraps up the behind the scenes look, we’ve taken a look kind of manually at all the data, where to find it and what it looks like, what some of the different fields mean, so we’ll take a quick look at some timeline visualisation and geolocation data to show how that can be helpful in getting us to this data faster.
OK, so we’ve just got our internet explorer, our Internet Evidence Finder report viewer open here, and this is again some results from a search that we did using some of the test data that was generated for this case study. And what we’re simulating here is taking a live RAM capture from the victim’s PC and then also just grabbing the app folders from the Android device and searching them all in one search so we have all the data together. If you had a full image of the Android device you could still do the same thing, or if you had a full image of the PC, of the hard drive obviously you could search both together and have all the results together like this, just to view the data inline.
So we’ve got our Kik messenger artefacts here, we’ve got some contacts, we’ve got the suspect’s friend ‘jeanclaude’, this was pulled out of their kikcontacts table here as you can see from the Kik database. We’re got the messages here that were sent, including the message status and the message partner information, if the message was sent and received, and then the timestamps. If we go further down we’ve got our Gmail that was sent, sent from our suspect to the victim with the map, you can see all the different artefacts that we looked at in the raw data and we’ve got that last modified or viewed timestamp.
Looking at the Facebook messages these are the ones sent and received on Android, so we’ve got the “I’m here” message from the suspect, we’ve got that latitude and longitude information here which we’ll look at on a world map in a second. We’ve got all the other messages that were sent and received and you can see some of the different information that we looked at in the raw messages again. So those, we had some artefacts that had the full information including the sender names and receiver names, these artefacts at the top here just had the more scaled down version of the artefact with less information: just the message, the sender ID and receiver ID, and the timestamp, so just an example of what you might see, a mix of information, some records having more data than others.
We’ve got our Chrome history from the Android device, so the web page title, the URL, the last access date/time, visits and so on. And then we’ve got our Google maps artefact from the PC side. And again you’ll recognise this information from the raw data that we looked at, so we’ve got our source and destination address and then the latitude/longitude information.
So if we take a look at this case and we want to see any geolocation information from these artefacts we have the world map. And we see here in this case we’ve got a couple artefacts that have geolocation information. Obviously with a real case that has a lot more data you might see quite a few hits here and you can zoom in to see the different information. These apps on the side are a list of all the different artefacts that IEF recovers that have some sort of geolocation information. So I’m going to click on these two points here, we can see that this one came from the Google maps information, from the search that the victim did to find directions to this location, and then if we look at this marker here it’s the message on Android Facebook that was sent by the suspect saying that he was at the meeting location. And as we saw when we looked at the database and in IEF, there was the geolocation data stored there, so we can plot that right on the map showing where he was and showing that the victim searched for this location as well. So on the investigation side, before they had any information about the suspect, just knowing from looking at the victim’s computer – knowing this information here that the victim was looking at this address – gives the police some quick clues on where to look for further evidence. And then once they have the suspect’s information and Android device it’s able to put them at the crime scene through the geolocation information that’s in the message that he sent. So that’s kind of a really quick look at how this geolocation data can help you get some information on where to further the investigation as well as corroborating information to help prove some charges.
So we’ll jump into a timeline view now and take a look at the data on the case. So we’ve got all our timeline data plotted here, we’re going to zoom in to the time of the incident. It kind of falls in August, between August 10 and 12 here, keep zooming in and take a look at some of the data. So if we click here we can see some of the Android messages that were sent from the suspect to the victim, zoom out a little bit we can see the Kik messenger messages that were sent by the suspect, we can see the Chrome searches that were done after those messages, and then here we can see a few more Chrome records from searches that the suspect performed. So we can kind of quickly see here if we grab the Facebook chat here how things progressed, so the messages that were sent on Facebook first as the suspect and victim first met each other and how things progressed there, then we’ve got the Gmail that was sent by the suspect, and then things progressed to the actual meeting time and the aftermath of the event. So if we were investigating this case and didn’t have any of this prior knowledge but knew that the victim was reported missing around the 10th or the 11th we could quickly do this timeline view, zoom in to the dates of the incident or the dates in question and then kind of get a quick idea, without knowing anything else, of what might have happened and the sequence of events.
What we can also do instead of having to zoom in, can do a quick filter here, so I’m going to run a global daytime filter, put a start date in of August 1st and then an end date of August 14th, going to run this filter and we get a subset of data that just falls within those dates. So now I can do a timeline view of that, and again I get right to the data that I’m looking for and I can look at it that way. So if I’ve got a much larger case where there’s a lot of different artefacts and I want to filter down just to the ones that apply to the time of the incident that I’m investigating, that’s a quick way to filter everything and then pull out around a timeline view to again take a look at the sequence of events and quickly have an idea of what’s going on in my case. Anything that I want to dig deeper into, either in IEF or another tool, and get some more information and go from there.
So that’s kind of a quick overview in IEF of how geolocation data and Facebook or timeline data can help further your investigation, answer some questions, give you some clues on next steps and quickly help you get to the bottom of things.
I’m going to turn things over back to Melanie here and really appreciate everyone tuning in today and for your time, hopefully this was of interest, hopefully you learned a few things and that this can help you in your investigations going forward.
Melanie: OK thanks everyone, thanks Jad, we’re actually going to start the Q&A portion, we have some questions queued up. So the first one was:
Are there possible login credentials for Facebook in Android app files?
Jad: I haven’t seen login credentials, including passwords or anything like that, but you will see the email address information for the local user in the Android app files. So you’ll be able to determine who the registered user on the app is; you won’t have their password stored in any plain text in the files, but it’s a starting point.
Melanie: OK, and Mike from Merseyside police said:
We have used the dynamic app finder on an app called WeChat. The user data and the messages were on different tables. Is there some way of linking the tables in your tool to display the user and the messages? Thanks, really enjoying the mobile functionality.
Jad: Thanks Mike, that’s really great to hear, that’s exactly what we had hoped that the dynamic app finder would provide for you and we know that’s a very popular app. We’re working on a way to try to add some sort of linkage ability in the dynamic app finder, it may be a bit tricky just because of the complexity there, but I can tell you that we’re adding full support natively to IEF for WeChat in our next release so we’ll be doing all that linking and joining of tables and so on for you, but we’re trying to find a way to help you do that for other apps that we don’t support yet using the dynamic app finder as well, so that’s really great to hear and thanks.
Melanie: OK and we had a question:
How do you know who he is talking to in kikdatabase, or in Kik messenger?
Jad: OK I’ll… let me just jump back to a slide further back and we can quickly see that here. So if you can see that slide, so we can see the partner ID right here, so like I said the username is the part up until the underscore, so ‘jeanclaude’, and then I believe there’s more information not in this table. So that’s the username and then in the contacts table you’ll see the actual name of the user and some other metadata which I showed briefly in IEF. But just from that one column there you can see the user he’s talking to, ‘jeanclaude’. The ‘was_me’ column indicates if it was a sent or received message, so the ones that are 0 are messages from the remote user and the ones that are flagged with a 1 are from the local user. So hopefully that answers your question.
Melanie: OK and someone had a question as to what SQL viewer you are using.
Jad: I’m using one called SQLite Expert and it’s a really great application for viewing SQLite, handles most files fairly well and the different formats, different field formats and I believe there’s a free, or community version available on the site as well so you can try it out for free.
Melanie: OK, and with Google now using https for all search results, will this change the data stored in browser2.db?
Jad: No, that’s a good question, but the records are still saved as they are with the queries, so as long as they’re not… as long as they don’t start encrypting or encoding the actual query in the URL, the fact that they’re using a secure connection for the content of the data that’s transferred in the session doesn’t change the records that are saved in the browser history. So you’ll still be able to see in the history the queries and the search terms, as well as the web page title, as we saw, indicates the search terms as well. So again, as long as they don’t change those things on top of the SSL we’ll still be able to see all these search queries.
Melanie: OK, and is it possible to plot all GPS records that are found in a case at one time onto the map?
Jad: Yeah absolutely, in this case we only had a couple records that had geolocation data so that was the reason we only saw two there just with it being test data, sample data for this case, but in every, any other case that has more, everything gets plotted all on the map all at once, so anything that was listed in those apps on the right side of that screen, if there are records from those artefacts and they have geolocation, they’ll get plotted on the map all at the same time so you can see it all in one view.
Melanie: OK, and Avis from Pakistan wanted to know that when a false Facebook page is created and later removed, how the person who made it can be determined.
Jad: Yeah, so if you have some artefacts indicating a Facebook user ID from prior to the account being removed, or the Facebook page if there’s a group ID or a page ID, you can potentially go to Facebook, work with their law enforcement department and try to get some previous records from them on the user or the page information. So if you’re able to get that information, some sort of ID number that you can provide to them, you can likely request that if they have the data still. I’m not sure what their retention policies are for things like that, there’s probably… there’s a law enforcement guide out there that probably has some more information on retention times, and like I said they’ll provide it to you with a proper request if they have the data.
Melanie: OK, our next question was will this information be available offline?
So I can answer that one, it will be available afterwards, it’ll be available on forensicfocus.com, it’ll also be available on magnetforensics.com, but if there is a specific need that you have, you can always send an email to [email protected]
OK, our next question is which tools you use from acquiring the RAM dump and the data from the Android handy to work with IEF.
Jad: Yeah, so we have a triage product called IEF Triage which has its own live RAM capture tool built in and it works on 32-bit, 64-bit systems. Really easy to use, you just browse to where you want to save the RAM dump, give it a name and hit ‘start’ and so that’s what I used for this scenario and that’s an option out there. There’s other free command line tools that you can use and a lot of different options out there. So for the mobile data, again there’s a number of different devices you can use, Cellebrite, XRY, Oxygen and so on, that can either pull a full image for you or a logical image. For the examples I showed today all you need is the logical data, so as long as you can get those folders from the data partition on a phone, you’ll be able to look at the same data as we looked at today for those apps.
Melanie: Is there a way to ensure that collected messages were not spoofed? My understanding is that with a routed phone one could hypothetically plant any data in the database.
Jad: Yeah but the routed phone… the user would have access to these folders, these application package folders, so they theoretically could go into the SQLite database, change some of the messages and make it look like something else was sent, or you know, change some of the metadata, so there’s no way to really detect that other than maybe looking at some timestamps of the files to see when they were last modified versus the timestamps that are in the records within the file. The other way that you could verify that is if you were able to get at both sides of the conversation. So if you were able to get data from the recipient as well as the sender obviously while they can spoof the messages or modify them in their local database, the messages that are received by the other user, unless that user’s doing something like that as well, you’d be able to… they won’t be able to change the messages that are on the remote phone, so you’d be able to kind of cross reference things, validate things by looking at both the data from both phones.
Melanie: OK, so we appear to have quite a few more questions, we are getting to the end of our hour so I’ll ask Jad one more question and then for the rest of the questions we’ll actually send email responses to your questions.
So last question is: is there a guide for law enforcement that defines the codes used for the various fields in SQLite?
Jad: If you mean codes used in SQLite in general, I don’t believe there’s anything that would apply to that, all these apps use different codes, they’re all kind of specific to the app. So you may be able to do research on the specific apps to see if there’s anything published out there and we can certainly help with anything that we’ve done research on, if you have any questions as you’re going through cases. Even if you’re not an IEF user, happy to try to help out where we can and then IEF obviously will translate those codes into their meanings for the ones that we’ve been able to research and determine ourselves.
Melanie: OK, so we’d like to thank everyone for their time today, we hope you’ve found this webinar informative and useful, and we wish you luck in your investigations involving these technologies. If you haven’t tried IEF we encourage you to try the fully functional 30-day free trial on your own cases, please go to www.magnetforensics.com/trial to download the trial. If you have any follow up questions you would like to ask, and then as well for the ones that we weren’t able to ask within the time, we will send you emails, but if you have any further questions that you would like to ask please feel free to email them to [email protected] or to Jad directly at [email protected] Thanks again and have a good day.
End of Transcript