Join the forum discussion here.
View the webinar on YouTube here.
Read a full transcript of the webinar here.Amy: Good afternoon, everyone. I’m Amy from the marketing team here at Magnet Forensics. Welcome to our webinar today, presented by Jessica Hyde, our Director of Forensics. Jessica will share with you how the onset of security apps is impacting investigations.
Before we get started, I have a few housekeeping notes. This is a one-way audio webinar. We have plenty of time for questions. To submit a question, you can use the Questions panel in the GoToWebinar application on the right-hand side of your screen. Also, we are recording our session today, and we’ll send it out before the end of the week. So everyone who attends will receive a recording.
With that, it’s my pleasure to introduce Jessica Hyde.
Jessica: Thank you, Amy. Hello, everyone. So let’s get started.
Just a little bit about me – my name’s Jessica Hyde, I’m the Director of Forensics here at Magnet Forensics. What that means is I actually work with the product and development teams to ensure that we’re taking the perspective of the forensics examiner into account. Prior to working for Magnet Forensics, I worked as a forensics examiner, as a contractor for Basis Technologies, working primarily [on a customer site] in US government. Before that I was a consultant doing incident response with Ernst & Young. Prior to that, I was also a contractor for American Systems, again working in the government space in the US, doing digital forensics exams, primarily on damaged mobile devices. And before that, I was in the United States Marine Corps.
Just as a note, I do have a little bit of a cold, so please ignore any clearing of my throat or inadvertent coughs.
I also have a second gig – I’m an adjunct professor at George Mason university, where I teach in the MS in Computer Forensics program, I teach a Mobile Forensics course there and I’m also an alumnus of that program.
Alright, let’s get started. Today we’re going to be talking about privacy apps. We’re going to go through some of the features of the privacy apps and we’re going to talk about a bunch of them in the marketplace that differ. And then, we’re going to do a bit of a deep dive into Cheetah Mobile and some of the things that you can recover specifically from Cheetah Mobile security applications.
Starting with the types of privacy apps that are on the market, there are several different types that have different functions. Sometimes, these can be singular apps that do one function, or sometimes, one app can have multiple functions. One of the first things we’re going to see are photo vaults – we’ll go into a little bit about what that is. Then we’re going to talk a bit about application locks, private browsing, and then there’s also additional features of privacy apps that are more in tune with normal use, such as antivirus and “find phone”.
Vault apps really provide a secondary storage for pictures and videos. A lot of people refer to this as a secret photo album, and typically, what these do is they’ll remove the picture from the gallery or downloads, and place it into a specific vault to hold pictures. I’m going to talk about several different applications that have this, and then we’ll deep dive specifically into Cheetah Mobile.
There are also some screen lock apps on the market, and what these do is they lock applications to a pattern, PIN, or fingerprint for access to the application, and many of these take intruder selfies, which we’re going to talk about, and they’re advertised from a security perspective to help hide your private chats. Then of course there’s private browsing [03:49], and a lot of these security apps include a private browser. The main functions of the private browser are clearing browsing data on exit, and saving a lot of that private data into an integrated vault. Several of these allow for downloads of mp3 video in the browser, so directly in that browser and then to a specific location.
The issue with this is that they’re not all innocent users. There’s lots of reasons for average people to use security apps, and they’re very common with young people, as far as even things like providing privacy against their parents. But they’re also used by not-so-innocent users. These apps have come up frequently in both child exploitation and terrorism cases, as a means of spreading either illicit images and videos or propaganda.
So let’s start with going into a little bit about some of these different apps that exist in the marketplace. The first one I wanted to cover is by Fotoable. As we go through each one of these, they’re going to get a little more intense in terms of what you can do with them. And then we’ll finish up with the Cheetah Mobile series of apps.
So Fotoable is for Android, and it provides with the Lock Screen as well as AppLock Security. The big thing about this app is that it allows you to customize your lock screen so you can make it look different, and you can also control what is shown when you’re on your lock screen. So if you don’t want your Twitter to actually display notifications when your screen is locked, you can prevent that app from doing this in here. It also randomizes the keyboard, so that someone who’s shoulder-surfing can’t tell what code you’re putting in, and not only does it work on the device lock screen, but you can actually assign a lock for each app, and you can determine which apps you want to lock. And that’s pretty common amongst different application locks.
The next one I’m going to talk about is LOCX. This is what [05:53] and it actually took me a while to figure out what their icon was, and then somebody informed me that that’s a chameleon. It may not be so recognizable, but this also is for Android, and this one goes beyond just having an app lock, it also has a vault. So it gives that secondary storage for images and videos that you want to put into it. It also has a fake cover for the app, so that you can’t tell what the original app was. And that’s the reason it’s really the chameleon app. So if you’re trying to hide your use of Snapchat, it would change the logo and you would have a different cover over that app. It also allows you to lock the app on exit.
So far, we’re really just dealing with these locks. And then come some of what I’ve seen a lot – this one happens to be Secret Calculator, by One Wave AB.
This one’s available on iOS, but there’s actually several calculator function apps out there, and the goal of these apps is that they look like a calculator, so that when you’re using them, or when somebody else comes across your phone, they don’t realize that that’s a vault app. These apps tend to – and this one specifically does have regular calculator functions. So you could do basic addition, subtraction, multiplication etc. However, when you enter a pre-determined code, it actually opens to a photo and video vault. This particular app allows for several vaults. So it has a password vault, a contact vault, a vault for files, it allows you to take notes directly in it, it has a vault for photo and video, it has a vault for passwords. It also has a private browser.
And then I think one of the more interesting features of this is that it actually has cloud storage that you can pay for a fee. I did not pay for the fee, so I do not know if that particular cloud storage still stores to the device or if it’s just in the cloud, but it’s something we need to be aware of, as we’re finding these vault apps on devices, if we need to also be attempting to get data from a provider if it’s going to be stored in cloud storage.
Then we have Vault-Hide SMS, Pics & Video, by NQ Mobile Security. And this one, we’re starting to definitely get into some areas where we need to be concerned as investigators. This one is available on both Android and iOS, and you can actually lock the app with just your fingerprint, which allows you to quickly close an app. With this application, you can have it so any new photos you take with the camera, instead of going to the gallery and having to move them, are directed directly to the vault. One of the interesting features on this one is as soon as you turn the phone down, and put that screen down, that vault is actually going to exit, and another app will launch, so that if then someone looks at your device, they’ll assume you were on that app.
And again, this one gets a little more nefarious, because it actually also employs a decoy password. What a decoy password allows for is for you to have a secondary vault that has normal, unassuming pictures. So for example, if I’m doing big, bad activity, and I have a vault for big, bad activity, and my password for that big, bad activity is [1111], I can also create a secondary vault, where I put a whole bunch of pictures from my vacation, and those will be under password 1234. So if somebody asks to view my gallery because they know that this is a vault that hides things, and I say, “Sure, my password is 1234,” and the officer who is maybe stopping me and has probably cause or I’m giving consent, because I’m trying to prove there’s nothing wrong here, and they go ahead and enter “1234”, they will be taken to a vault. And that vault will have the pictures of my vacation, which area completely legitimate, non-problematic images, while all my nefarious images are locked in the second vault.
So this is what we call a decoy password, and this is something that we need to be aware of as first scene responders.
There’s also private cloud space for this app, where you can store additional data. The app looks like the regular camera app, so that when you’re taking pictures with this, they are directed directly to the app, to the vault, and people may not know that they’re going there. You can pay for a vault, and that’s that private cloud space. And then there’s the concept of the intruder selfie, which is pretty scary. So let’s say that you find this phone, and you’re looking at it, and you don’t know the password or the decoy password, but you think you know the password. You think this actor uses “5555”. And you go ahead and type “5555” into it, that application will go ahead and use the front-facing camera to take a picture of whoever is actually entering the password. I will share with you that this is never a flattering picture. But it’s usually very, very close if you’re putting in the password – straight up the nose type of pictures.
But these intruder selfies are really important. The reason this is important to your investigations and to know about it is if you did inadvertently, while handling the device, put in this wrong password on the app lock – and remember, this can lock any app you can set the app lock to – and you go to enter that combo and do it wrong, your image is going to be in the data of that device. And that may be something you want to be prepared to explain on the stand – why your image …
I have definitely worked cases where first responders, who had handled and collected the evidence, which was not part of my role at the time, did wind up, because of intruder selfies, on apps, in the evidence.
Let’s talk about another one. They get a little more interesting as you go. This one’s by Legendary Software Labs, LLC, this also is available on Android and iOS. What’s interesting about this one – very similar – it has a decoy password, and it has a password-protected vault. But it, with its intruder selfie, it actually delivers a break-in report, and that break-in report, and that break-in report not only includes the actual picture from the front-facing camera, but it also includes the GPS location of where the device is. So if this device is back at your lab, and it is unknown, or you’re doing … where that lab is … it might be giving away the location, where the phone is being examined. This makes it very important that we’re using network isolation when looking at these devices.
Additionally, in addition to doing picture vaults, this also does allow email. There’s a video viewer in the app, that means that when you actually view videos with this app, they’re cached within the app, and not in a secondary cache. And those images and videos aren’t added to the “recents”.
The next two apps are both by the same company, SMSRobot Ltd, and the first one is FotoX. These two applications are for Android. They have a vault [like we’ve been talking to they do] a direct picture. What they do that’s unique is they have this fake crash. When someone who puts in the wrong password into it to access the vault, it fakes a crash. So the user or the person attempting to access the app is not aware that the app is hiding content and that they don’t know the password, they just think that the app is failing. This app again also has cloud fee service. It has a stealth mode, where it hides the icon so that you can’t see it, and it also prevents itself from being uninstalled. SMSROBOT Ltd wanted to add some additional premium features, so in addition to FotoX, they have their [Vault Hide Photos App Lock]. This one has, in addition, face recognition unlock for the vault – so it has to be your face – and that’s a paid feature. Or, I guess, your twin.
And this app also has two other locks that aren’t on the other application. So it has a time-based lock, so you can say after X amount of time, it’s going to lock. And it also has a Wi-Fi location-based lock, which means unless you are on a designated Wi-Fi, it will lock this. This means that this user could have it set up so that the application – and remember, this application can also be hidden – but that the vault will not unlock at work, and only at home, or at a designated Wi-Fi and not on others.
Now, what’s important to know about these applications is, for the most part, they actually don’t do a good job of hiding the images. Several of them just rename the images and place these images in a new folder. Some examples are Secret Pictures, Photosafe, and KeepSafe Vault. What’s common is that these applications advertise encryption, but indeed, all they are doing is renaming images and putting them in a new folder. Some of them may copy, some of them don’t delete the original images. So there’s a high likelihood that you will still find evidence in these.
But let’s go ahead and talk about Cheetah Mobile, which is really the most prolific set of apps. And you’ll see here that I have three logos on the screen. What I really want to stress here is that Cheetah Mobile makes a variety of apps, everything from Clean Sweeper, which is that icon down in the bottom, to CMSecure, to Security Master. Security Master is the most popular one right now. There’s over 24 million downloads is what I see on the site, but Cheetah Mobile is advertising that that has been downloaded over 500 million times. So this is definitely the most common app. This icon here, this is the icon for Security Master.
It does have some normal functionality. One of the reasons that this app is so popular is that it also has a virus scanner. Clean Sweeper is supposed to optimize your phone. From my brief testing, it slowed down my phone, so I don’t know how functional that is. But these are quite popular. And that’s why I really want to explore these. We’ll go into a little bit more how I wound up looking into this in the first place. But these do have an app lock. They have an intruder selfie, and when an intruder selfie is sent, it’ll send an email notification. There’s a private browser included, there’s a “find phone”, and there’s a virus scanner. And it of course depends which one of these applications you’re using, but there’s quite a few that are available, and that headline one, Security Master, that one includes all of the features of the other products.
Let’s talk a little bit about the app lock, or how you know which Cheetah Mobile application you have, because there’s quite a few. Just as a reminder, iOS isn’t really going to apply, because Cheetah Mobile isn’t available for iOS, but I did want to give you the path of where you’re going to find information as to what applications are installed – in case your tool that you’re using doesn’t tell you. However, right here, data/system/packages.list – which you’re seeing here, is going to give you a listing of every application installed. And data/system/packages.xml will give you not only the applications installed on the device but also which permissions they use. I typically use this as a starting point to find data and applications that are not parsed by the tools I’m using.
Moving right along, you’ll see here cmcm.locker – so in this instance, on this device, we had the Cheetah Mobile locker app installed. You’ll see some of the paths for the other ones as we go along. There is this app lock intruder selfie, and I’ll give a little disclaimer – that is a stock photo – I had a piece of red tape over this phone when this was tested. This actual intruder selfie actually gets stored in a folder called CMLocker/.temp/intruder, and then it has a GUID. And what I want to bring your attention to – there it goes – is this icon here. This one here that says “CM LOCKER”, this means that it was the full phone on lock that was used, and you’ll see that it says, “This one wants to unlock your device” and it gives the date and time. If this was a specific application, instead of being the CM Locker icon, it actually shows you the icon of the application that was unlocked.
And there’s actually even a great log that tells you this, and you can see the storage location of where this log is. So you’ll see in this instance, it’s in the media\0 file under the package name. And this here, for anyone who doesn’t know, this is the package name for Clean Master security. So if you’re ever on the Google Play store and you look up an application in the browser bar, the path will include this package name, and this package name is where data for the application will be stored. Note that on Android devices, it may be a media\0 and then a path to that name as well as in root data. So make sure you’re checking both locations. And if there were multiple users on the device, this number here is indicative of the user, so the first user is 0, the next user is 01, third user will be 10, the first user 11, and counting upwards by binary as such.
But what I really want to show you on this screen – and let me go ahead and zoom in a bit here – is let’s talk about what we’re seeing. So first up, we can actually see all of the apps, at the beginning of this log file, that were set to be locked with this application. So that’s great. So if anyone enters any of those applications and puts in the wrong code, they’re not going to be able to get in, and their picture will be taken, that intruder selfie, and then it’ll be sent out. But what’s even more interesting, and of great investigative value, is that once that app locking monitoring begins, this lock actually tracks what application is currently in view – with the timestamp. So this can be extraordinarily useful to your investigation, because it’s not just the applications that are designated to be locked. It literally tells you what the top app is – in other words, what is being viewed – second by second. And you can see that here, as it is changed.
Then, once an application is entered with an incorrect password, you’ll see that the intruder selfie is enabled at that time, you’ll see that it captures it, it takes the picture, and then it sends it out. It’s also viewable then once you put in the correct password, the erroneous selfie is shown from the erroneous attempt.
Okay. So let’s talk a little bit about where the pictures are actually stored. Pictures that are placed in the vault can be stored at this location, right here – data/com.cleanmaster.security – again, that’s the package name – files/.CMSVault, do not delete, exclamation point. Thank you so much for giving us a clue that this is of value. And so that CMS is going to stand for Cheetah Mobile Security. So this is – CMS is just a good search term when looking at your file system, if you suspect this app on your device.
Now, in addition, the data can also be stored on the SD card or emulated storage, so this could be an onboard EMMC chip, which – and you’ll see in that instance, it’ll be stored emulated/0/.CMSVault. That means that this can be recovered, this vault, from a logical image. So I did a quick logical image of my phone, which I was using the vault on, and you’ll see, because of my device, I did have it set to go to the SD card. You’ll see this here, the “.CMSVault (Do not delete!)”.
Now, once we’re there, let’s look at what we have. I told you we’d get into a little bit of the nitty gritty here. So in this instance, I have three files that end in a “.cms”. I can see they’re pretty big in size. And if I actually come here and look at the hex viewer, I’ll see that that .cms is definitely just a rename of the extension. This “FF D8” here, this is the header for a jpeg, and in this instance it’s a jpeg in [JFF] format, which means that, luckily, this is going to most likely include some good access data.
Here’s a quick little video … that I made, because I do not trust the live demo gods. So I’m going to go ahead and just navigate to the SD card here, and I’m going to go to that CMSVault. And so, when I go to that CMSVault, you can [live here] see those three pictures that are renamed with the .cms extension, again showing you that “FF D8”, so this is a good old jpeg. You’ll note that there is a text file that just has a name of “Do not delete folder or your photos would disappear.txt”, and you can see all three of these here are definitely my pictures, potentially – well, they are my pictures.
So I’m going to go ahead and just go and do a reverse – few related artifacts. We call this reverse source linking. And this is in Axiom, and I just want to show you I’ve got these three pictures here. So these have geolocation data. I took these pictures. And you can see here, if you look at the source in the bottom right-hand corner, that these were taken and that they’re stored currently in the CMS, and I’ve got all these great timestamps, December 9, 2017, etc.
Now, because these have geolocation, I’m going to go ahead, and I’m just going to filter down just to these three images of interest, and throw this on to a world map view. And if I’m looking at my world map view here, you’ll see that these three pictures were actually taken in distinct places – Singapore; Sydney, Australia; and Virginia. So right here, I actually took this picture – this was outside my hotel room last month, and it’s Singapore, the river walk. You can see December 12, 2017. Lots of good data, this is in the vault, CMS, and note that it’s completely parsed normally. Obviously not encrypted, as was advertised [laughs] by Cheetah Mobile.
Here’s one of the inside of an Echo Show, because I was doing a lot of work on dismantling and probing those to get data. And here’s a koala from the Taronga Zoo – I’m not sure if I’m pronouncing that right – in Sydney, where I was last month, December 9th, I went to the zoo there before heading off to Singapore. So in between forensics, I got to cuddle cute little animals.
But the point being that there’s a lot of great data there, and there’s even a log of that. So as the pictures are moved to the vault – so I had taken those pictures on my regular camera, and then I went ahead and moved them to the vault – there’s a VaultLog.txt here in that same package name folder, under media/0/Android/data. And if you come over here, you will see, from storage/emulated/0/DCIM/Camera, with the time/date 2017/12/12, 065914 – so that’s actually when I took that picture in Singapore – that I’m moving that picture to this new location. What’s great about this is you can now show that this picture, with this name that has this random number as a name, that this is the actual time and date stamp for when the image was moved from this location, originally took with the camera, to this location. This is forensic gold, when someone is using a vault.
So knowing that this log exists can help you tie that picture that exists, that you’ve carved, that ends in .cms, which is really just a jpeg, to actually seeing when that picture was moved from the regular gallery to the vault.
But what about direct downloads into the vault? Now I’m going to talk a little bit about the case study, which is how I actually started getting into this Cheetah Mobile app and looking at these different security apps.
A question came up – I got a call from a customer, who had found CP on an Android device. And that customer noted that these files that had CP on them had .cms extensions, and he was unfamiliar with it. And the reason that he had called in to Magnet was because IEF had parsed and displayed the images. So since it’s just a renaming, when we go [ahead] and carve the image, we’re still going to carve that as a picture. So the pictures were carved, they were displayed, and their source link showed that they had this .cms extension. Actually, when I first got the question – so the question came in to support, and support reached out to me, and they were like, “Have you seen this?” And I was like, “I have.”
I said, “I actually have seen that before working a case. That .cms, I bet you it’s one of these Cheetah Mobile apps, I don’t know which one. So let’s see if we can prove it.” And the suspected use case, in this instance, is that these images were downloaded, directly into the vault.
So what happened in this instance was a folder was created, the downloads were redirected. Cheetah Mobile claims that they encrypt the file at this point and delete the original. We already know that they’re not encrypting the file, that if I just rename it to a jpeg, I can open it or I can go ahead and carve it.
So I started researching this and testing, and I found this amazing database is actually formed, called “downloaded file list”, and it’s under databases, under the package name. And [laughs] this actually tells you the file path that the image is originally downloaded to, and the timestamp for it, before it moves to the vault. So this is amazing, because this is the actual time in which the image in question is downloaded.
So, I want to write a quick customer artifact for this customer. So did a quick query to parse those Cheetah Mobile downloads, and this is a custom artifact that’s available on the Artifact Exchange. Quick note about the Artifact Exchange – the artifact exchange is open to the public and it contains both Python- and XML-formatted artifacts. I believe that when I checked this morning, there were 67 up there, contributed both by people at Magnet like me, who aren’t actual developers, and some of our trainers, some of our … Jamie McQuaid, who does a lot of content for Magnet, as well as people from the community. So there are a lot of community members who write a lot of awesome scripts. Some allowed us to convert theirs, and some have continued to contribute new ones, like [30:55] and [30:57] – I think they’re the most recent people to contribute artifacts to the Exchange.
So this is a free place, and these artifacts do not need to be run in Axiom, you can use a SQLite query in any SQL browser of your choice that allows you to run queries, and [Python 27 is Python 27], so you can just pull out the Axiom headers and footers, and go ahead and run those.
This is an example of just what that query looked like. I really only cared about three names, three actual columns from the table – file path, source app name, and timestamp. So I was just selecting those from this table. And I thought I was being fancy, and told it to order by timestamp descending. But that was obviously not important. This is it – this is the whole query. The rest of this is just me naming the download, telling it that it’s going to be Android, where the filename is that I actually want to parse against carving against everything, and then just me renaming columns and categories, and making sure that my time/date stamp is actually all up here, on the time/date stamp.
So pretty easy, but just so you guys know, if you are interested in this, you can pull the query from there, and you can either run it in Axiom or run it external. You do not need to be a Magnet customer to have access to that portal.
Here’s what it looks like when I went ahead and ran that. Again, it’s that same data – you can see, here’s the file path. I called this column Source, which is the application that it came from. Here’s the timestamp, and it’s decoded, because I named it as such. And that simple. So we’re able to give that back, and then you can include that in your reporting.
Let’s talk a little bit about the concerns here. The primary thing is that I want you all to be aware of some of the concerns related to these vault apps. The first one is the intruder selfie. It’s definitely something you want to be aware of. Something I didn’t mention is that some of the intruder selfies in some of these applications not only take pictures. So I started recommending – the first time I across this on a case a couple of years ago. I started recommending to all first responders that they cover the camera, that when they’re putting in the PIN because they’re about to do an acquisition, and they’re going to enable ADB debugging, they know the password, that they need to cover the camera with a sticky or something.
But then, what we discovered is some of these are also recording audio at the time that that wrong password is recovered. So you want to ensure that you’re not having conversations about the case in question when someone’s adding this password, or that you’re in a space where sensitive information is being discussed, because it is possible that that information is being sent out.
Now, if I was a nefarious actor, it would not be my design to have these sent to me. I’m probably with my phone at the moment I’m getting [rolled up]. The reason this can also be so dangerous is if you enter that password, and I was a nefarious actor and I’m a smart enough nefarious actor to have an application on my device that has an intruder selfie, that notification email is going to someone who can destroy the evidence. So maybe they’re actually hiding evidence at another scene that’s not digital evidence, or maybe that person is about to send a remote wipe command to this device.
So you definitely want to be aware of the intruder selfie for a couple of reasons, because it could be an alert to a third party; it could be an alert to the actual regular party if they do not know that you’re accessing their phone; it potentially could record audio, which, depending on what discussions are going on at the time, it makes sense when you’re looking at a device that you might be discussing that case, so it could include some of that information; as well as just your picture being recovered potentially by opposing counsel may not be something that you want to have to explain on the stand. So it’s just important – or, if it does happen, you want to be able to explain it, right? Because if you’re putting in the passcode that they gave you, you’re not doing anything erroneous in it taking that picture – especially if they gave you a wrong password intentionally and gave you consent. So you just need to be aware of it, and know that it exists, and be able to discuss it and be prepared.
Then there’s the issue with decoy vaults. It’s important to be aware of the decoy vaults, so that you don’t believe that an actor is actually completely benign when they’re doing something nefarious because instead of going to the actual vault where the evidence was, they instead directed you to a decoy, where other data is.
The second is that there are other locations for pictures, and you need to look for them. Because the vault may have – A, you may be dealing with multiple vaults, you may be dealing with multiple applications that have vaults, and just because you don’t find a picture in a gallery or the download or the browser cache where you expected it – there may be secondary and tertiary places that you need to look, and that these locations may have pictures that are just with different file extensions. So you definitely want to run a carver that’s actually going to be looking for proper headers instead of just extensions, and you want to be able to pull those out if that’s the case. You also want to understand where things came from if you’re finding pictures in places you don’t expect, and to be able to tie it back to the original application. And again, talking about those renamed extensions.
I put the paid cloud storage on here because I think that this is going to be a further issue. And again, I didn’t pay for any cloud storage when I did my testing on these apps. But I think it’s really important that we’re aware that if an app has paid cloud storage, it’s possible that the evidence you’re looking for may not even be on the device that you have in your possession – it may be stored in the cloud. And if you’re seeing that, please let us know what applications, because maybe we can – we do do some cloud recovery, and we may not be looking at those applications at this time, but maybe we need to, to see if we can recover anything via APIs. However, the other point is maybe you need to serve that organization and request, with your proper authorities, data back from a cloud storage provider.
A lot of times, we’re looking at cloud storage providers, and we’re thinking about Drive, and Dropbox, and Onebox, and we’re not really thinking about these vaults that could exist on mobile apps, and these security applications.
So at this time, I’m going to go ahead and see if we have any questions. Let me go ahead and open up the question bar here. Give me one second, it’s a little bit difficult to see until I expand it.
I apologize, this is – the GoToWebinar is not being my friend right now and allowing me to extend the box. I can see that there are questions, let me just get them so I can actually view them.
I’m having mouse issues, guys, gals. Alright, there we go. Now I’ve got this wide. Let me bring it – there we go. Alright.
So let’s see the first thing we have. We have: Is it possible to retrieve the password which is set by the suspect? I had to deal with an iPhone Best Secret Folder. I get all the hidden photos, but I didn’t retrieve the suspect’s password.
[Artis], I haven’t looked specifically at the Secret Folder app, so I’m not sure if the password there, where it is stored or how.How will rooting affect the storage location and/or is rooting required to access the databases? [Jeff], that’s a great question. It depends on where the data is being stored. When the data is being stored on the SD card, like you have the option to with Cheetah Mobile Security apps, that data is completely recoverable in just a logical extraction. So when I was showing you guys that stuff from Cheetah Mobile off my device, with those three images that I had moved to that folder, I actually only did a logical on my phone.
So it depends on the storage location. Most of these apps, from my testing, actually don’t back up. So if they’re choosing to store it on the phone memory instead of EMMC or SD card, you may need a physical. A physical does not necessarily mean you need to root the device. There are other methods of getting physicals, such as customer recoveries, chip-off – but of course, that’s an issue if full-disk encryption is employed – and boot loader acquisitions. So there are acquisition methods that don’t involve rooting, that may allow for full physical acquisition of the mobile device, but that’s going to vary based on the device, and not just device by common name, but specific make and model which you’re going to do to actually pull the data from that device.
Oh – would you post a link to the portal after you’re finished with the presentation?
You know what, that is a great question. Actually, I have it right here. This is actually the Magnet Forensics portal right here, just so you guys can see it. And if you google “Magnet Forensics artifact exchange” you’ll be brought to it. And these are actually all of the 67 parsers that are there, and you can add those to your cases.
Brilliant. Of course, when I did that, it squeezed that thing again, so now I’ve got to [41:11]. [laughs] My apologies. This is very, very small.
Okay. The next question [41:27] so please ignore this question. So … alright … that’s rooting question.
How do you determine if the images and videos are cached within the app or on the phone itself? Great question, Andy.
The number one way I determine it is by testing. One of the most critical things, once you find an application, is to look at that package name, find out what the application is, get another device, and start testing. If you’re lucky enough to have had a full physical acquisition, my method is, from the actual image, to take the .apk file or [.ipa] file, to actually take that file that you have on there and [side-load] that, that APK, the actual application file, on to my test device. That way, I know I’m working with the exact same version of the app.
Because if I download the most current version from the Google Play store – or, it is possible these apps are coming from secondary stores – I may not be getting the exact same version that matches my evidence. Then, I want to go and research all of the different functions of the application, and test, doing both types of storage. And if I’m moving the storage, I actually want to go ahead and do an image, both ways, with the storage in both locations, both in emulated storage as well as regular storage. And by going through and using the app, and testing those features, you’ll be able to see what those settings and choices are, and how the data resides in those different locations. There’s actually another webinar that we’ve done, on parsing unsupported applications, that actually goes through the entire process of how to do that, and I would encourage you to go ahead and take a look at that webinar.
I did receive some good joke questions. So thank you for stating that you actually didn’t want me to read it. [laughs]
Okay, let’s see. [43:32] all good.
Okay. The prime requirement to view files from these apps is that their database should reside on external memory. What if residing on handset’s internal memory?
That’s a good question. It goes back to if you have a physical or a logical. So actually, one of the [sets] I was telling you about actually was from the physical memory of the device itself. So the data that was recovered from the download list, that download file list.db that I was talking about – that path is actually on the device itself. Let me go back to showing you that. Excuse my screen here being wrong.
I’m going to go back right here to show you where that was. So this here, this Direct Downloads screen capture I’m showing you right here, this is actually from a full physical of the phone. This is not from the SD card or emulated storage. So the file location for this was recovered in a full physical. So it is going to depend on to get, and the settings that were employed by the user. Of course, if you can get a full physical – we all love full physicals. But I just want you to be aware that sometimes you’re able to get that data with just a logical …
Now, I’m going to go ahead … it doesn’t look like I have many more questions coming in. I do have a question in here about if we’ve experienced apps like [Wickr] and what kind of information are we finding on devices. And there’s a whole host of “end-to-end encrypted chat applications” that are a little bit … they are also privacy applications, in terms of allowing for chat. But what we find on most of these is that on some of these applications, the encryption is only in transit, and the data is decrypted on the device. And others of these applications, the data actually is encrypted on the device.
So WhatsApp, for example, uses [cryp12], and we work to go ahead and decode that. So if you provide the proper files, you can decode that. It’s not backed up normally in a regular backup, so we use actually what’s called an app downgrade to go ahead and pull that across on a backup if you don’t have a full physical, and then we’re able to decrypt that. Or applications like Signal – if you put in the password, we can decrypt Signal.
So it varies application by application. If you have a specific encrypted application that you’re dealing with, where the data is stored encrypted, and you are not able to get the results you’re looking for, please let us know about that artifact. One of the great things we do at Magnet is we prioritize our parsing of artifacts based on customer requests. So if you’re requesting that artifact, then we know it, and then we can look at it.
So there’s a comment here that most of these apps reviewed today do not encrypt the data. Are there any apps which actually encrypt the data? And [Neville], that’s actually a really fair question. None of the ones that I looked at in this instance actually encrypted the data. [laughs] My guess is that some do, but … they advertise it, but none of them that I have looked at have. If any other examiners who were on the call have seen any that are actually encrypted, that would be great, and we need to know about that, so that we can look at figuring out how to decode that data.
William, great question. You said that I said that either the physical or logical image would grant us access to the data hidden from the app. It depends. It depends on if the data is being stored … depends on the app location as well as where the user has selected for the data to be stored. My favorite forensics answer is “It depends”. And that truly is the answer here. So, in the instance that the application is set to be backed up, it is … the app author can determine if the application is going to be backed up and what data is going to be backed up.
So if it is stored on device, that data may be chosen to be backed up or may be chosen not to be backed up. So it’ll depend by app and possibly by version. Additionally, if the data is stored on the SD card, typically, we can retrieve that via logical. Now, if the data, by choice of the user to only be stored on the physical device and not on emulated storage – now, remember, emulated storage can exist on the physical device. So an on-board EMMC chip is physical storage on the device. So for example, I’ve run into devices that had a 16-gigabit on-board EMMC storage, but had one gig of regular flash RAM, and so when you actually look at that device and pull a physical acquisition, you may only see one gig or you may see 17 gigs. If you see 16, you’re really only getting the EMMC. So it’s important to do your research on the hardware on the device, and see what’s stored on the device, and make sure that your acquisition is actually complete, but also, to know what type of data you’re getting.
In the instance if it is only stored on local storage, not emulated storage, and it’s not backed up, you’re not going to see it in a logical, and you’re going to need a physical. In the instance that you have a physical, providing that your physical [laughs] is of both local and emulated storage, you should have everything. So it’s … it depends. I hate to say that’s the answer, but unfortunately, in this instance, it is. [laughs] As in much of forensics.
So if there are no further questions, I’m going to go ahead and turn this back over to Amy.
So thank you.
Amy: Thank you, Jessica. As I mentioned, we are recording our session today, and everyone should receive a copy of the recording within 24 to 48 hours.
We did want to share with you, we have a couple of upcoming events in June. Magnet is hosting a user summit. It’ll be on May 21st in Las Vegas. So look for updates to our website, and to the email for more information about that. And then, we will plan to be at Techno Security, which is a big conference in June in Myrtle Beach. So if you’re interested in having a demo or learning more about Magnet, please let us know, and we’ll schedule some time to meet you there.
Thank you, everyone!
End of Transcript
