Presenter: Tayfun Uzun, Product Manager, Magnet Forensics
Join the forum discussion here.
View the webinar on YouTube here.
Read a full transcript of the webinar here.
Transcript
Good morning everyone, thank you for joining us. My name is Melissa, with Magnet Forensics, and I’d like to thank you all for joining us for our webinar today entitled Mobile Chat and Social App Forensics.
We’re joined today by Tayfun Uzun, our product manager, who’s going to lead us in our discussion today. In this webinar we’ll take a look at the new hyper-connected world of mobile chat and social apps and talk about how these apps are impacting the field of smartphone forensics as they introduce new rich sources of evidence for examiners.
Tayfun will also answer your questions in a live Q&A after the presentation. Please submit your questions into the Q&A box in the WebEx client during or after the presentation, and we’ll do our best to get through as many questions as possible. If you’re experiencing audio issues, try reconnecting or using the dial-in number, as it tends to solve most of the issues that people experience. This presentation is also being recorded today and will be available for viewing at magnetforensics.com shortly after our session today. I’ll turn it over to Tayfun to begin our discussion.
Tayfun Uzun: Thanks Melissa. Good morning everyone. I’m going to take you through some of the challenges we deal with as a company, and you deal with as examiners, in mobile chat and social apps.
We’ve got a short agenda here: we’ll go through some introductions, I’ll talk about some of the mobile application growth. There’s a lot of mobile apps coming out and the growth has been phenomenal. We’re also going to talk about how Magnet delivers artefact updates to ensure that you’re getting the results you’re looking for from these applications. Then we’re going to take you through the anatomy of a mobile app, and this will go through various levels of where the data’s stored, encryption, data formats, and really break down how mobile apps are storing their data in their applications. Then we’ll have some closing remarks from Melissa and then we’ll go through some questions.
So who am I? I’m Tayfun, I joined Magnet Forensics almost four years ago now. Originally I started off as a developer in the company with the goal of evolving the flagship product. I’ve worked on a lot of artefacts that you see in Internet Evidence Finder. Currently now I’m responsible for product management and coming up with products and talking to customers about how we can help you in your investigations.
So diving right in, these stats here show time spent on the internet by device, so this splits up mobile and desktop computing. This is in the US, and this is from 2013 to January 2014. The most interesting thing here that you can see is that mobile apps usage and mobile browser usage has actually surpassed browser usage in the US. This trend is continuing this year. And more people are spending more time on the internet through mobile apps and mobile browsers. Now this creates more difficulty in investigations because you’re dealing with different devices, especially in mobile.
I found this pretty interesting: WhatsApp messaging user growth. So in 2012 WhatsApp had approximately 100 million monthly active users. Now the way social networks measure how much they’re growing is this monthly active user metric, and this basically shows users that visit sites regularly every month. They used to measure user base based on how many users have accounts, but this actually gives a better presentation of actually who’s using the services.
So you can see in 2012 they had 100 million monthly active users. 2013 they jumped up to 400 million and in 2015 you can see this Facebook post by the founder of WhatsApp – they hit 700 million monthly active users, sending 30 billion messages a day. This is incredible.
Similarly, Facebook has posted some stats in their quarterly annual report showing that their active user base is growing as well – this is probably no huge surprise to anyone here. But what’s most interesting about this is that the mobile and mobile plus desktop user base is growing the most, and the desktop user base is shrinking. So more people are actually using their mobile phones to use Facebook than the desktop computer. And this has driven Facebook to focus more on their mobile apps and their mobile experience more than their desktop browser experience.
So one thing that we focus on here at Magnet is understanding what applications are being used most out there, and similarly what applications you see in a forensic investigation. And this slide shows, in the US, for the top 50 apps in social networking, and this was over five years from 2011 to 2015, this shows how many times an app showed up in that top 50 list over those four years.
You can see in the first bar there 77 apps showed up in the top 50 list only once. So in the five years, there have been 77 apps that were in this top 50 list and have left. In contrast on the other end over the 5 years there were 12 applications that actually maintained their status in the top 50 list. So you can see the churn that’s happening in the top 50 list, this is specifically social networking. You can see that applications go into the top 50 list and then die off after a year or two years, three years, and there’s only twelve that have really lasted five years and these are most likely your Facebook and Twitter that you’re seeing.
Another thing that’s very important to understand is that not only are these applications going into the top 50 list and exiting the top 50 list at a high rate, the ones that are actually staying in the top 50 list are updating constantly. You can see Facebook there is updating every 21 days. This is the mobile application and that’s [indecipherable] fix bugs and add features to these applications. WhatsApp is the longest one between updates but it’s still only 49 days so you can imagine… these apps are basically updating every month and they could be changing how they’re storing data on the phones, they could be changing features like voice calling, video chat.
So what Magnet tries to focus on is getting you the most relevant and current evidence. And what we try and do for you guys is provide regular artefact updates so IEF can keep pace with these rapidly changing apps. When new apps are jumping in popularity, into the top 50, and apps are updating every month, we try and stay on top of that and provide updates for you frequently. We focus on customer requests, so if you have applications that you’re seeing frequently, we like to see that feedback so we can add to the application.
So we’ll dive into the anatomy of a mobile app. The best way we like to describe this actually comes from a movie. If you’ve seen Shrek, you might remember the scene where he’s trying to explain to Donkey that ogres are complicated, and they have layers like an onion. And we like to look at mobile apps the same way: they have layers, and you’ve got to peel back each layer to get to the data. We call these ‘layers of complexity’. Each mobile app has these layers. Some may have encryption, some may not, but in order to get to the data you need to go through these layers. And to go through them here: Storage Location layer; Encryption; File Structure; Data Format; and then you can actually get to the User Data.
Starting with the Storage Location, there’s various locations where an app can store its user data. In general on iOS and Android there are three major locations. The first one is the application sandbox and you’ve most likely seen this on iOS and Android devices. This is a standard location where apps will store their data. And whether it’s a SQLite database or a flat file, this is where most of the data will end up. Another place is external storage, and this is mainly Android; iOS doesn’t allow you to have external storage. And Android’s applications will actually store files here that they want [to be] accessible to other applications. So a good example is the Download application on Android. When you download a PDF it goes to the Downloads location and it’s actually stored on external storage, and this external storage allows other applications to access that data. The issue with the application sandbox, which I’ll take you through in a second, is that if you have data in the sandbox application, no other application can access that data. So in external storage applications like to put things like pictures, documents, music, on external storage so other applications can utilise it. Or if you want to transfer that stuff to the PC, external storage will be available to your PC when you connect the phone.
Third place and the most complex of all is the cloud and internet. We’re seeing this a lot more with apps like Snapchat – they’re going to store user information on their own servers, and when you launch the app they actually download the data and store it in memory, and it doesn’t actually save to the device. This saves a few things: it saves them from having to use up space on the device, but also allows them to provide more security, so the data doesn’t stay on the device, it’s only ever in the cloud. And some of these applications, you can’t use them unless you’re connected to the internet.
So this diagram came from the Apple developer nodes and this actually shows how the application sandbox works on iOS. You can see here the blue circle has the user data for this application. So if you imagine that this application here is WhatsApp, this would be the user’s chat messages in the database. And you can see the red box around this means other applications can’t access that database.
This was designed by Apple to ensure application security. They learned from the past on Windows that applications were accessible by other programs and then you end up with something like malware, this was to protect against malware on iOS where you have an application, you can’t access data from other applications from your application.
These are examples of sandboxes on different platforms. On Android you’ve probably seen these folders: the /data/data/ directory is where all the application sandboxes are stored. This example here is Skype. And you can see that under the com.skype.raider folder, that’s where all the Skype files would be saved. On iOS in comparison here, they’ve got /private/var/mobile/Applications, and each application gets this unique identifier and this actually represents Skype in this example. These are what the files use – what you’ve probably commonly seen on an iOS device. These are pretty standard across most mobile apps. And just to show in comparison here PC Skype: Windows is moving to an app sandbox type of architecture as well where they’re encouraging developers to store their data under these /app/data/ folders, whereas in the past applications used to store their stuff in program files. Windows is trying to reserve that now just for application binaries, and trying to get users to store their actual application data in the /app/data/ folder.
Encryption is something that comes up a lot, and we deal with a lot of it at Magnet. Chat app developers specifically, we see a lot of them are getting demand from their user base that they want better privacy in their communications, and there’s many reasons for this, and they really want their users to feel safe when they’re using their chat apps. This is leading them to introduce different types of encryption to their apps. And there’s different levels for this as well. File encryption is around data at rest, and when I say data at rest, this ensures that any data that is being stored to the device is encrypted. And you see this in applications such as WhatsApp that have Crypt 1, 2, 3, 4, 5, 6, 7, 8 now, different types of encrypted databases. And this is mainly done to stop people from being able to access your messages.
The next level of encryption, which is also an example of data at rest encryption, is field encryption. This is encrypting specific fields within a file. So the previous one was encrypting the entire file storage, whereas this one is just field. And we see applications that do this: Kakaotalk I believe is one of them. They have actually an open SQLite database, but the data within it is actually encrypted. So you can open it and see the tables, and see rows, but the data in the rows is encrypted.
The third type here – and this is actually data over the wire encryption, data in transit encryption – end-to-end encryption is becoming more popular now. This covers encryption of data over the wire, so anything being sent over the internet, this is to ensure that the data’s encrypted, and prevents things like the man in the middle type attack, where someone is snooping on the wire and reading messages coming through; this end-to-end encryption will prevent that.
I say it doesn’t directly affect smartphone forensics because end-to-end encryption doesn’t mean that the data being stored on the device is encrypted, it just ensures that if it’s being transferred over the network, over the internet, then it’s encrypted.
So if you take an image of a mobile phone, if a certain application is using end-to-end encryption – I’ll talk about WhatsApp, it’s one of the biggest ones – the actual data won’t be encrypted because of the end-to-end encryption.
This is just an example of WhatsApp, how they do their file encryption. So you can see in the diagram, the WhatsApp database is the grey part here, and it’s got a layer of encryption. And if you grab one of these files and look at it in the hex editor, you see this, you can’t see any plain text messages in here, it’s totally encrypted. By removing the encryption, it enables you to access just the SQLite database. And when you look at the SQLite database in the SQL viewer, you can actually see the data. So the data within the database is not encrypted; the entire file is encrypted.
WhatsApp was one of the first chat applications to implement end-to-end encryption. End-to-end encryption is a communication paradigm of uninterrupted protection of data. So when you’re transferring data between two communicating parties, and it’s intercepted, end-to-end encryption ensures that it can’t be read. WhatsApp is actually the largest deployment of end-to-end encryption ever, in any industry, because of their massive monthly active user base, which as I said is about 700 million at the beginning of this year.
This just shows how WhatsApp is doing their encryption: Android to Android is encrypted, Android to iOS is not yet, and iOS to iOS is not, but these are something that they’re working towards getting to as fast as possible.
So the third layer of complexity here is file structure and you’ve probably seen this in many different apps, but there’s various structures that an app may use to store its data. Some of them are easily understood with specifications in the public domain, things you can Google, things you can find on the internet, some are not. Some are complex and proprietary.
The first one we’ve got here is database storage and this is becoming the most popular form for app developers to store their data, because it’s simple, and iOS and Android both have development libraries that allow you to easily create SQLite databases and use them. So Apple and Google are providing easy ways for developers to use that mechanism, so developers are using it. Microsoft has created their own type of database called ESEDB. And these are popular in things like Windows phone and Internet Explorer 10, 11, 12, and their new browser Edge. And this is a proprietary database storage that’s similar to SQLite but not understood. SQLite is open source so you can find information about it online, but Microsoft hasn’t really released any information about the ESEDB format.
The next type of storage is flat file storage. You see a lot of log file storage that has these, it’s a line by line storage of what’s going on and text-based storage and CSV storage. This isn’t as common as database but you still find it especially for log files or transactional data.
The third one here: structured storage, there’s two types here, JSON and XML. Usually JSON is used when you’re trying to represent an object in a string format, same with XML. And I’ll dive into these a bit deeper in a few slides.
Finally, complex structured storage, as we like to call it – the plist format, which is Apple’s proprietary list file format, comes in two variations, binary and XML, and other proprietary formats which I’ll come on to in a few slides, talking about other companies that are creating their own types of structures.
So in general databases have tables of data with columns to represent different properties of the data points. And like I mentioned before, SQLite is open source and it’s the most common storage for mobile apps. It’s also multi-platform, so developers can write one data storage mechanism and have it work on multiple platforms. A SQLite database is queried using Structured Query Language, and this is SQL. You’ve probably written some of this for your investigations – it can get quite complex if you’re trying to join multiple tables or pull different types of data and format it.
ESEDB is the Windows proprietary format, and like I said it started with Windows 10, it’s been around for a long time, Windows XP actually had traces of it in there, but it really didn’t get used a lot until IE 10 came out. And like I said it’s in IE 11, IE 12, as well as Edge, which is their new browser. As well they started using it in Windows phone, and they’ve actually combined SMS, contacts, call logs and emails into one ESEDB on the Windows phone.
This is just an example of an Android image, and this is the calendar database and you can see here for SQLite you’ve got Tables and Information. I like to think of SQLite as almost like a spreadsheet: so these would be the different worksheets you have and you can see here I’ve selected the events table which on this side lists all the events which are in the events table. You can see Canada Day here, row number five. And you can go through the data like this.
Looking at more complex data structures, structured storage such as JSON. JSON stands for Javascript Object Notation and it’s useful for representing objects in string form. ‘Objects’ is a very generic word, but it really represents something that has properties. And for example you can see that Foursquare on the right-hand side here, this is Foursquare for iOS, and they use JSON to store its venue data. Foursquare, you can go to any venue, any restaurant, and check in, and you can say “Hey, I’m at this restaurant”. You can also query a bunch of restaurants and see what’s around you. And this query that users can do is based on their geolocation. So here’s a cut-out of a JSON structures format where it shows someone who did a search for restaurants around them, and you can see all sorts of data here about what the restaurant’s called, Beer Town Public House, and the location it’s on, the longitude and latitude, and this would contain all the search results for all the restaurants around you.
Similarly XML stands for eXtensible Markup Language, and it’s also used in the same way, it’s used to represent objects again, which is just something that has one or more properties. So a restaurant has an address, has a location, a name, and these other properties that this object has.
Skype uses XML on iOS, Android and PC to store account information about a user. So you can see in this example we’ve got account information here and the default account is jad.soft, and that’s how they’ve decided to store that data. In contrast their message data is actually stored in the SQLite database. So you can see that developers will actually use multiple storage formats for different things within the same application.
This here is the same JSON Foursquare data that I pulled from a mobile phone in the previous slide but this I what we call beautified. So it actually took it and formulated it in a way that’s easier to read, so now you can see this object has multiple properties: it has an ID, it has a name, and all the details about the location.
So diving into complex structures, well JSON is what we consider a simple structure, although sometimes it can be complicated as well, but this complex structure refers to things like the plist structure. The plist structure is very common on iOS apps where Apple has created their own format to store information, and you can store a lot of types of information in this format. You can see on the Twitter example here, this is a binary plist, and you can see there’s a tweet here that says “Hello, world!”. And you can see how complicated this structure is, looking at it in a hex editor. This represents actually a Twitter feed, so if I were to scroll down in the text you would see multiple Twitter messages from someone’s Twitter feed. Carving out this data can be very complex because of the uniqueness of the file and the lack of detail there is online about this format; this is a proprietary Apple format and they haven’t published the spec. Developers create their own complex storage mechanisms for a few reasons. They know they have access to SQLite and text files and CSVs and other formats; JSON, XML; but they create their own for different reasons, and sometimes it’s to increase read/write performance. Depending on the type of data they’re trying to store, different formats can provide better read/write performance for them, and what I’ve found is the biggest thing, is that engineers like to create things. And you see this a lot in software where they don’t consider us looking at their data as forensic examiners, they’re not considering how hard it is for us to carve this data, they create something that works the best for what they’re trying to do, and engineers like to build things, so you see a lot of these complex structures come from big companies where they encourage innovation with their developers to create different formats.
A good example here is actually the Skype chat sync. This is actually a database and the structure is not published online, again it’s proprietary, and you can see they’ve got a file header at the top that says sc.db, which stands for Skype Chat DB. You can see key information in here, you can see this is the chat thread, this is the chat between JB and JackSpratty that’s actually the identifier of a chat, and you can see a username here, JackSpratty, and the actual message, “Hi”. This can be very complex to carve and information again is not available online so you have to really dig into this data and try to understand how they’re storing the data.
This is the Skype Android mobile app. You can see here it would be great if they used one type of format. You can see here they’ve got a ton of databases, and some structured storage, and in that top chat sync folder they’ve got their chat sync proprietary complex databases in there. So not only are you examining a ton of apps on a phone that can have different layers of encryption, they can have different storage locations, different file formats, they could actually be using multiple files just for that application in different structures. So now we need to understand how each app has their proprietary structures that you need to know, as well as JSON, XML structures storage, and SQLite storage. This is just for one application.
Once you’ve got past the file type and the file structure that they are stored in, there’s also the data formats. The data within the application can be stored in various different ways and you’ve probably seen a lot of these in different applications. The easiest one of them all is just plain text: this makes it easiest for us as examiners. It makes it easy for you to find the message you’re looking for, you can easily scan through a SQLite database or a text file and read through this data, even hex if you’re looking at a complex storage such as chat sync, you can dive through this and see plain text messages here and there, and usernames.
The next is dates. As examiners, dealing with dates is probably the most challenging thing, especially when you’re dealing with local timestamps, Unix timestamps, timezones, non-UTC. These formats can be in various ways: there’s an example here showing the date, this is a common Unix timestamp which is milliseconds from January 1st 1970. But you’ve got Apple timestamps, which are milliseconds from January 1st, 2001. And you can have local timestamps; for example Internet Explorer 5-9 stored some of their internet history in the local time of the computer and some of it in UTC time. So understanding timestamps can be very important in an investigation and there’s various formats.
The next format that you may see is Base 64. Base 64 is a type of encoding. Base 64 is mainly used to store binary data in a structured file. You may see this with pictures: pictures may be stored in a SQLite database in Base 64. It’s really common in applications that may be sending this data over the internet, and this data may be sent over the internet in Base 64 and they’re storing it in Base 64 to make it easy.
Along with encodings you also have language encodings, like UTF8, you have ASCII, UTF16, there’s tons of these encodings that define byte orders to show different languages. You have to deal with these sometimes too in apps like Weibo, which is a Chinese app, you have to understand what encoding that data is in, to be able to properly parse it.
And finally structured data formats within files. Geolocation coordinates, so latitude and longitude. Very important data; to be able to plot it on the map, it’s good to have this data. But even latitude and longitude can be stored in various ways. We’ve seen this with various apps where sometimes they store it in one column and you have to figure out which is the lat and which is the long, or sometimes they’re split and sometimes the north reference is in a different column, so putting this data together can be complex. And again JSON and XML again is mainly using it to store objects so you may see things like, a good example is there’s some SQLite databases that store contact information, and you may have contacts such as you know, you have your name and they have five email addresses, sometimes the data’s stored as JSON in one SQLite column just to make it easy for developers to keep it in one place.
And finally GEOJSON is seen when you’re trying to store geolocation data and Google Maps uses GEOJSON, and many apps do, but basically it’s a JSON format that is designed around geological locations. It’s a published standard online that various app developers use so that you can take GEOJSON data and move it to different applications and it can still handle it.
So at Magnet we have a team dedicated to researching and developing products to automate the recovery of mobile applications. This includes peeling back layers of the onion, so every time a new app comes out, we have to go through that onion and look at the file storage, we have to look at encryption, data format, file structure, just to get to the user data. And even if an app updates, so it’s an app like Facebook which we’ve supported for years, every month that app updates and we need to look at that app again: did they change any encryption, did they change how they’re storing files, or are their data formats different, are the dates in a different format now? These are all things that we need to look at every day.
And the goal of this is to enable examiners to use IEF to find mobile artefacts. We support various image types from various tools that you may already use. So we support physical images, which are raw binary file dumps, entire block memory of a mobile phone, you can load that into IEF, it will recognise the file system, it’ll go through all the files and folders, deleted space, unallocated file slack. We also support logical images. And this can be a full file system, so from the root of the phone or it could be a partial file system, so if you just have a couple of app sandboxes, or you have a bunch of files off a phone you can run those through IEF and we’ll look for artefacts in there.
Two things that we’re working on that are coming very soon are iTunes backups and Android AB backups. These two things are proprietary formats by Google and Apple, and IEF will be able to support them, including encrypted iTunes backups and encrypted Android backups, as long as you know the password we’ll be able to decrypt that data and be able to search through that. If you’re using Cellebrite UFED, Cellebrite Advanced Logical Method One outputs an iTunes backup. So that iTunes backup will soon be supported for Cellebrite Method One.
JTAG binary data dumps. These last two actually come up a lot. A lot of customers I talk to are surprised that we support these. If you have a JTAG binary data dump or a chip-off binary data dump, you can actually load that into IEF as an image and if it’s an entire memory dump we can parse the file system. If it’s a fragment we’ll parse through everything. So if you come across those, those are fairly popular especially for Windows phone because there’s no way to get a physical or a logical image dump of a Windows phone, so chip-off and JTAG are very popular options for that.
And here are some of the most popular chat and social artefacts that we support today. This is not all the artefacts, this is just a subset, but you can see some of the most popular ones there: BBM, Google Hangouts, Facebook, Twitter, and we go through all the types of files in these applications and parse out data and make it easy for you to look at the data and analyse the data.
Some other categories we have, it’s not just in social and chat, but we’ve got cloud, web, documents, email, peer-to-peer, media, and native application information. So things like Bluetooth devices, Wifi profiles on the device.
Once you’ve loaded those images and run through the artefacts, it’s easy to review the evidence in our IEF report viewer. So in this example you can bookmark relevant evidence, and not only do we recover the data – as you can see in this bottom one we’re showing internet history – we actually look at the data and determine what that user was doing on some of these Facebook urls. So you can see that on the first couple of phases he’s on the Facebook homepage, and then looking at the profile, and the profile ID that they were looking at. And this gives the internet history some insight into what the user was doing.
Also in IEF 6.6 which is a release that has just been released a couple of months ago, we’ve added features that allow forensic examiners to dive deeper into the evidence and look at the hex data of that evidence. So you can see here, it’s actually an example that I had previously in my slides, the Skype chat sync proprietary database, that message there, “Hi”, you can see that IEF recovered the message, made it easy, showed the timestamps and put it in the right format, but you can also dive deeper by clicking the ‘hex’ tab and seeing the actual hex data, and seeing where IEF has parsed that data from.
The hex editor also shows – at the bottom of the hex editor – it shows you the source of where the data came from, as well as what offset you’re at and how much you’ve selected.
Some of the most powerful things that you see in IEF report viewer: after IEF has recovered the data, it’s showing you the data in a way that’s natural, that users can easily understand, and make it easier to look at certain things like geolocation data. The best way to look at geolocation data is on a map, and you can see here this is actually geolocation data of a chat conversation on the right-hand side, and Facebook for example actually stores your location for every single message that you send. And in this conversation this person was actually sending messages while they were travelling and you can see the different messages in the different areas on the map. The chat threading right here, this is actually how it’s displayed in report viewer for you to view, just like you’re viewing it in Facebook chat. This can be very useful if you’re sharing this with non-technical users, they can see this and recognise, “Yeah, this looks like Facebook, I understand,” rather than looking at data in a SQLite viewer which is just a bunch of rows, or a spreadsheet.
One thing that we’ve added about a year ago and has proven to be very useful as we hear from our customers is Dynamic App Finder. And Dynamic App Finder was designed to enable examiners to find chat messages from potentially thousands of chat apps. There’s thousands of chat apps out there and IEF supports the most most popular and the ones requested by our customers, ones we’re seeing in their investigations, but there’s thousands out there that may only have a couple of thousand users. But you may see these in your investigation. So Dynamic App Finder has the ability to detect obscure or custom chat applications. And with the frequency of application updates, Dynamic App Finder might catch a change in an app and display the data for you.
So Dynamic App Finder works in this way: it looks for SQLite databases in the mobile image, and it runs heuristics to determine if the database it’s looking at is a chat database. And if it determines that yes, this looks like a chat database, it will try and parse these four fields: the sender, the receiver, the actual chat message, and the date/time. And this has been proven to work in a few cases I’ve heard from customers, where IEF didn’t support the chat application but they actually found important chat data about the exploitation of a child and it proved to be very useful in their court case.
One thing we can do here is remap fields, so when Dynamic App Finder finds a database that it thinks is a chat message, you can see here we’ve got BlackBerry Messenger groups. So when BlackBerry Messenger added group messaging, a new database showed up called ‘bbgroups’. And they added unsent messages, so before they had group messaging but they weren’t storing any messages that were unsent, so if you typed a message and didn’t send it, when you went back to the BlackBerry application after closing it, that message was gone. But they started showing that data, to make it easier on their users, and in this example we’ve identified a message column, which is message, the sent time of the message, and a timestamp showing when the message was sent. Dynamic App Finder strives to get the best data here, but you can actually change these. If you find that there’s another timestamp that you feel fits better with that column, then you can actually switch this.
Another valuable piece here is once you’ve found an artefact: Twitter here, for an example – Twitter added message drafts. So when you’re typing a tweet, you’re storing a draft and that was a new feature. And IEF picked up on this with Dynamic App Finder saying hey, there’s a new database here, and it looks like it’s storing some sort of chat message. And it picked up these tweets that were in draft form, but the date/time was in a Unix timestamp. With Dynamic App Finder you can actually remap this and say hey, yes, this is the Unix timestamp, and format it in a way that’s human-readable. This allows you to sort and filter based on timestamp.
I’m going to hand back to Melissa to go over a few closing remarks, thanks everyone for listening, I hope I provided some insight into mobile apps and how they store their data, and back to Melissa.
Thanks Tayfun for sharing that presentation with us today. So Magnet Forensics has a research and development team committed to staying on top of the latest apps and providing frequent artefact updates for our customers. If you haven’t already tried IEF, we’d like to offer you a free 30-day trial, which will include our mobile artefacts module. To download the trial, just visit our website at magnetforensics.com/trial. Existing IEF users can also request a trial of our mobile artefacts module by visiting our customer portal.
We’ll start our Q&A session now, so if you do have questions that you want us to answer, submit them into the Q&A box in the WebEx client and we’ll do our best to answer as many as we can.
The first question I’m going to touch here today is: How does Magnet stay current with the latest apps in use?
So that’s a good question, we analyse the top applications that are in the app stores today, we look at what’s popular, what’s growing, what the trends look like, and we have a team dedicated to looking at that data, collecting that data, but that being said, a lot of what we find valuable is when customers tell us what they’re seeing in their investigation, and we strive to talk to as many customers as we can to understand what they’re seeing. Because just because an app is popular in the mobile app store, like the Apple app store, doesn’t necessarily mean that suspects or criminals are using it. They may be using obscure apps, hence why we look on the Dynamic App Finder. So customer feedback drives a lot of our decisions around what new apps are conning out. Now the updates, focusing on application updates, we’ve built a team and a system in place to monitor for app updates and analyse those app updates to see what’s changed.
Great. So the next question is: What if someone has deleted WhatsApp from their phone, can IEF find a .db file and try to extract the chats from the file?
Yup, so, if someone had deleted WhatsApp from the phone, IEF will carve for messages from that database, and it will extract the chats from that file. There’s two ways of doing this. So if you have a physical image, and someone has actually factory reset the phone, that data goes into deleted space and if you have a physical image, IEF will carve through that and find that data. But in general, the way SQLite databases work is if you’re using an application and you’re not uninstalling it, even if you’re deleting messages within the application, some of that deleted data still stays in SQLite databases as what they call a free list, where if you’re looking at a SQLite database in a SQL viewer you may not see this data, but IEF can actually carve it out of the free space of the SQLite file. SQLite is very similar to a file system in a way, where it maintains knowledge of what data in the file is actually not deleted, and in viewers it’ll show you that, but the actual deleted data’s still in there. That can be very valuable. Even if you don’t have a physical image, you can actually get deleted WhatsApp data just from the database.
Can I ask [for] help in extracting the key for decryption of WhatsApp?
Yes. IEF does extract the key for decryption. IEF doesn’t actually proved you the key afterwards, but when it encounters WhatsApp on a mobile image it will actually find the encryption key, decrypt the data and show you the unencrypted data. But it doesn’t provide the key to you, but it will give you the decrypted data. You don’t really need to worry about the key once IEF has recovered that data for you and stored it.
With the Android and iTunes backup, will I need the passcode or the encryption password to decrypt and acquire the data?
I’ll answer these separately. For iTunes backups: to acquire the data using Magnet Acquire or any of your mobile acquisition tools, you don’t need the password but you will end up with an encrypted iTunes backup. So if you do have an encrypted iTunes backup, for IEF, you will need to provide the password. IEF doesn’t do any password cracking at this time, so you will need to know the password.
For Android as well. Android backups are only force encrypted on certain phones, so for most acquisition tools when it does an Android backup, if you don’t put in a password you won’t end up with an encrypted image, but if you do end up with one from another means, then yes you will need a password to decrypt it.
On the map view of geolocations, what does the number on the points represent?
This is what we call a cluster of points, so if I had zoomed in on that map you’d see that that cluster with the numbers on it would actually expand into a bunch of different pins. And when you’re zoomed out it’s hard to show… like in one of those there were over 100 pins in that one little location, it’s just hard to show that on a map, so we cluster them and show you how many pins are in that location using that number.
Are you developing anything to scan device images for malware?
We don’t have anything… we will search device images for malware URLs. Internet history where they may have visited a site that may have malware indications, but we don’t actually search anything for malware at this time.
What we will do though, we have an artefact that we’ve recently added that, on Android, will identify apps that are potentially unwanted, so these could be spyware, these could be malware, based on the nature of the applications it will identify saying ‘hey, this may be an app that’s potentially unwanted.’
Can we apply this tool with a backup of an Android or iOS stored in a PC?
Yup! So IEF currently, if you have the mobile module… today, if you have an iOS backup on a PC, like if you’ve acquired someone’s computer and they have an iPhone and they were backing up to the PC, as IEF encounters that backup on that PC it will search it for mobile artefacts.
For Android specifically that’s something that we’re working on for the near future, and that will be the same way: as long as you’re searching a PC image, and there’s a backup somewhere on it, we’ll pick it up.
I have a case where the Viber app was uninstalled. Can your tool still recover the messages from this device? Also how does the evidence acquisition process occur? Via Encase, or does your app handle everything: acquisition to analysis?
In general, on a phone, depending on the type of phone, whether it’s iOS or Android. iOS started encrypting their deleted space, so as you probably know, getting a physical image off of an iOS device is very difficult, almost impossible now for the newer ones. So if this case was on an iOS device, and Viber app was deleted, that data’s actually stored encrypted when it’s deleted, so recovering that data may be difficult.
If it was an Android device, that data could go into deleted space, and IEF will carve for Viber messages and recover that data if you can get a physical of the phone. The challenge is when an app is uninstalled, its database and app sandbox is destroyed, so the only data available would be in deleted space, so as long as you can acquire that deleted space, IEF will carve it.
Now IEF today doesn’t acquire phones, we’ve recently released into beta Magnet Acquire, which is an acquisition tool that allows you to acquire iOS and Android smartphones and quickly gets you the data you need, and Magnet Acquire will be available to the public very soon, it’s currently in beta, and if you’re a customer of IEF you can sign up for that beta and get access to it. If you’re not a customer of IEF, the community beta will be available very soon.
Does the Dynamic App Finder only search for SQLite database, or other types of storage as well?
Today it only searches for SQLite databases. Our goal is to expand it to support other types as well, you saw there’s various types there and we definitely see the value in Dynamic App Finder so we’re hoping to expand it, but today it’s SQLite.
How do you extract mobile contacts from an Android mobile phone?
The easiest way to do this is.. you need to acquire the data using some method, if you have Cellebrite UFED, if you have EnCase, or MPE+, or Magnet Acquire, you need to acquire the data. For contacts, most forensic tools with their logical imaging – you don’t need a physical to get contacts – so most logical images, or if you’re using Magnet Acquire, a quick image, will get you Android contacts. It’ll get the app sandbox which contains the contacts2.db. And searching that image, IEF will pull up contacts for you.
Are you able to decrypt the messagestore.crypt8 database? I heard that the Crypt8 database has a cypher in the header in the new format.
We don’t have support for this just but we’re actually working on Crypt8 and we have some pretty promising results, so expect to see that fairly soon.
Are you able to discover deleted Kik Messengers from iOS with IEF?
iOS, like I said, if the phone’s in factory reset, iOS does a really good job of encrypting deleted space, and getting a physical image from iOS again is very difficult now, so getting a logical image or a Magnet Acquire quick image… as long as the application hasn’t been uninstalled, we can recover deleted Kik messages from the SQLite database for Kik.
Proprietary apps are either included as base functionality with IEF or Dynamic App Finder is capable of finding/returning those logs, correct? Also traditional social health update apps, like Runner, Runkeeper or FitBitSharing?
Proprietary manufacturer apps: I’m assuming you’re talking about stuff like Bluetooth, contacts, SMS. Those are included if you have IEF with the mobile module, so if you have that, IEF will recover those. Dynamic App Finder today only focuses around chat applications. We hope to expand this to other types of applications, but today it only focuses on chat. And in terms of the health apps, that’s something that we’re actively looking at as well. FitBits are becoming very popular, and the FitBit can track incredible information about when you were sleeping, when you were moving, and whether you were walking or running and stuff like that, with timestamps. So that’s something we’re actively looking at, but we don’t support any health applications at this moment.
This is a bit of a long question, so bear with me. Is there evidence that can be recovered from a smartphone and/or social media site like Facebook that can enable the investigator to attribute social media activity to the phone user? I’m thinking of a situation where a person denies posting something on social media and using the social media site messaging system, and claims someone gained unauthorised access to their account, or some other defence?
I’ll jump in on that one, it’s more of an investigator question, this is Jamie McQuaid. Basically this is really a challenge, if you’ve got to determine from an investigative standpoint who’s actually sending messages or using the tool in question. It’s always been a challenge no matter what type of device you’re using: PC, mobile. Typically your best case is if there’s a password on the phone, this usually tells you that it’s the actual authorised user to use it that goes with the computer. Or if they’re logging into those social networking accounts like Facebook and that, there’s more likelihood. There’s never a guarantee that that user’s going to be sending it, but with factors like that, that they were logging into their Facebook account, and there was a password on their phone or scenarios like that, that usually helps in those types of scenarios where you have to prove that the user actually sent the message. Hope that answers the question.
I think we have time for one more. You mentioned supporting UFED backups, do you support Oxygen backup files?
We don’t officially support these at this time, but it’s something we’re looking at. If you’re able to get an iTunes backup out of Oxygen, IEF will support that very soon, or again if you can get a raw binary dump or even a file dump, if you can get just the files and folders out of that, we will support it.
Great. Thanks everyone for attending and participating in our discussion today. As I mentioned, the session was recorded and will be available for viewing at magnetforensics.com as well as Forensic Focus. This concludes our presentation today. Thank you everyone.
End of Transcript
