Sunday, 15 September 2019

Setting up an Android for Fun and Profit (Testing)

A question I recently got asked by a colleague of mine was basically "what phones do you use for Android testing?" The truth is "anything I can get my hands on" but it made me think about the process I use for generating new test data.

Rule 1: Always use your own data when you can.
What? Why?! Because you know what should be there! One of my favorite things is to pull my own data from my devices because I know what I did with that device.

Rule 2: Make your life easy.
Pick a device that you can control. Get one that's easily rootable, or one that you can easily grab data from. I like to pick Android devices that have an easy root method like Magisk Manager or one I can use TWRP to grab a full image. Be aware of FBE (File Based Encryption) phones because it may change the way you need to grab data.

Rule 3: Make it last.
I like to pick devices that I know are going the distance when it comes to updates. Nothing makes me more aggravated then dropping a bunch of money on a phone to only be able to use it for a year.

So what have I recently picked?

Anyone who know me knows that I'm a massive iOS fanboy. I've used an iPhone since the iPhone 4 and iPads since the original first generation came out. But I'm a google user too. This makes doing a lot of Android data easy to generate by simply signing into a phone with my Google account. Recently, I got my hands on a Pixel 3a and made it my main Android test phone. Here's why:


  • Not super expensive
  • It's a pixel, so I've got a few years of use
  • Easily rootable (Magisk)
  • Bootloader Unlocking (and easy OEM images when I inevitably break it)

The only downside is that I'm not going to get a lot of vendor data from things like Samsung and their annoying apps they like to pre-install. I set up a Pixel 3a recently using the following method.

Download the latest OEM image. 
Google allows users to download the latest OEM images with security patches from their website here: https://developers.google.com/android/images

Unlock the Bootloader
Even to install the stock OEM images, you're going to need to unlock the bootloader. In order to do this, you have to at least turn on the phone once. You can skip all of the setup questions and jump straight into the OS. Once there, head over to developer options (Settings --> About phone --> Tab build number 7 times // if you set up a password or PIN, you'll need to enter it with Android 8 and above). That enables developer options but you'll need to go to Settings --> System --> Advanced --> Developer options to actually turn on the two options needed. 
In the above screenshot, you can see the two options (flagged on in my screenshot) you'll need to enable. OEM unlocking and USB debugging. A note I discovered: if you've never brought the phone online, you may have to at least once to turn on OEM unlocking. 

Once the options are enabled, you'll need a copy of adb you can download from: https://developer.android.com/studio/releases/platform-tools.html

The directions from here will differ from phone to phone, but on the Pixel phones it super straightforward. 

Root It!
Depending on your phone, you might be able to easily root it using something like Magisk Manager. https://forum.xda-developers.com/apps/magisk/official-magisk-v7-universal-systemless-t3473445 That's what I use and I love it! Your millage my vary depending on the phone you choose. 

What about Data?
Another reason I went with a Pixel is because of Google Fi. It's a really nice plan through Google that allows me to gen data from about 20 bucks a month (USD) plus 10 per gig I use. I like it because I can set up an account (and if you do it often, reference codes are great) and then suspend it when I'm not using it for no cost. Really I only use this when I'm traveling and need to gen "real" data otherwise I just tether it to my existing phone. 

What about you guys? I'd love to hear back from people on the phones they're using for Android testing. I'm not really experimenting with security exploits at this point as I'm focusing on OS updates and 3rd party apps. If you see some data coming from Android in my posts, it's likely coming from this guy!

Sunday, 1 September 2019

iOS - Tracking Traces of Deleted Applications

In July of 2019 I had the great honor and pleasure to present at the annual SANS DFIR Summit with the always awesome Alexis Brignoni (https://abrignoni.blogspot.com/). We decided to tackle the issue of "Once a user deletes an app, what's left?" Turns out, while the container that holds the data is gone, there are lots of traces that remain of that application. Since Alexis has already covered the Android artifacts in his blog, I'll use this post to explain some of the iOS research I did on that side.

Let's start with talking about if your app is actually deleted or just "Offloaded." Offloading apps is a feature of iOS 11 that allows a user to remove an app from their device but keep all of the documents and data relating to the application. When a user installs an app on iOS, the data is delivered to two separate "containers" which are just folders.

In this example, by checking the ApplicationState.db which is found in an iOS device at \private\var\mobile\Library\FrontBoard\applicationstate.db or in an iTunes-style backup at HomeDomain-Library\FrontBoard\applicationstate.db you can see that the Twitter app (com.atebits.tweetie2) was installed at /private/var/containers/Bundle/Application/15FFD685-5154-4C07-B332-95F3F7521A48/Twitter.app while the data for the Twitter app was installed at /private/var/mobile/Containers/Data/Application/1562A7BD-D4FA-4838-88FC-3F48C009EBD0. If the Twitter app would be "Offloaded" by the user or by the OS because a setting was enabled to remove apps that are not frequently used, the entire folder that Twitter.app is in would be deleted but the other folder (1562A7BD-D4FA-4838-88FC-3F48C009EBD0) would still be there. Once the app is offloaded, the entry in ApplicationState.db is removed. 

So how do we figure out if there are offloaded apps? The easiest way is to check the IconState.plist properly list file (or just look at the phone itself). 
In the above screenshot you can see that 3 apps (GarageBand, Keynote, and Numbers are offloaded apps while Lime is fully installed). If the user tried to open any of the offloaded apps, they would see the app start to download from the App Store. 

By using the IconState.plist, users should compare Bundle IDs for apps that are listed in IconState.plist that don't appear in applicationstate.db. 

Okay! Back to the topic at hand: those traces and tracking them. Once confirmed that an app is deleted, we start with its Bundle ID. That is the absolute key to finding data about an app. A quick search in your favorite forensic tool of choice will show where the data appears and was used to track a lot of the artifacts mentioned below.

UninstalledApplications.plist
This one is an obvious stop. Only available in a full file-system style image, it lives in private\var\installd\Library\MobileInstallation\. This file will show the BundleID of apps and then the date when the app was LAST deleted from the device. If the app is reinstalled, then deleted, it's only tracking the last deleted date. 




This one tracks data for a LONG time. I've found data in here at least 9 months old. It doesn't transfer from device to device and it is device-specific. I've also found that this file isn't ALWAYS here, however, once a user purchases a paid app or has a credit card tied to their AppStore then it seems to populate. 

Mobile Installation Logs
Alexis already did a phenomenal job on this one and even built a tool for it. So i'll direct you over to his blog on this one. https://abrignoni.blogspot.com/2019/01/ios-mobile-installation-logs-parser.html

Some notes about it, it seems to be record restricted versus time restricted. I've only ever found a 0.log and a 1.log file. After filling these, it seems to start to reuse the logs instead of just constantly keeping more files. This will track when containers are created or deleted but also iOS likes to move around its containers at times and it tracks those as well. 

DAAP.sqlitedb
Normally DAAP for Apple stands for Digital Audio Access Protocol and it's used for their sharing media across a local network. In this case, the DAAP.sqlite db lives in private\var\mobile\Library\Caches\com.apple.appstored\ and stores applications that were purchased by the AppleID (or potentially their family). It doesn't just include apps that were on the device, just apps that were purchased. 
It seems to have been added in iOS 12 and tracks some great info. 
In the above screenshot, us.zoom.videomeetings (Zoom) was deleted. It's the same app that you can see in the screenshot from UninstalledApplications.plist that was deleted on 7/8/19. 

AppPurchaseHistory.6.sqlitedb
This database is very similar to DAAP. One thing to note is that it's also found in older versions of iOS. It can be found at private\var\mobile\Library\Caches\com.apple.storeservices\. 

There's several other artifacts you can look at including: 
  • ScreenTime
  • PowerLog.PLSQL (don't forget archived copies)
  • KnowledgeC.db
  • DataUsage.sqlite
  • netusage.sqlite
One last thing to consider is that some apps may call into other databases using APIs. For example, if you make a call from an app, it may make an entry in the CallHistory.storedata database. More recent versions of iOS will go back and remove entries from the database when the app is deleted but it's always worth a good carve through the database to check and see if there are any mentions of the bundleID. 

For more information about the artifacts, go check out the presentation over on the SANS website here: https://www.sans.org/cyber-security-summit/archives/file/summit_archive_1564167956.pdf

I'll be sure to update this post when the video goes live too!

Friday, 30 August 2019

Android - Locating Location Data: The Tile App

One of the hardest pieces of data in an investigation to find (and one of the most important to use) is location data. Proving where a device has been has always been something I've tried to dig into. This is the first a series of blog posts around locating location data stored in 3rd party applications across both iOS and Android. Today I'll be starting with the Tile application on Android.

What is Tile?
The Tile app is the tracking piece for Tile bluetooth tracking devices. These devices are often found attached to keys, in bags, and even now have been built into devices such as wallets. What they can do is provide someone who is prone to losing their keys (like I am) a way to locate your keys when you've misplaced them. Handy!

With recent updates to the Tile app, they work by not being an "always connected" device to our phones. When you open the Tile app on a device, it will display your tiles associated with your account as well as other phones tied to your account. Your mobile device will ping out when a device is located either by you (or someone else in Tile's mesh network of users) it will update its location on the map. If it's close enough to you, you can ping the device and see a ring that helps you get closer to it as well as play a sound from the device.

Interestingly enough, the app also tracks other devices that may be signed into the account as well. I have several phones tied to my tile account for testing as well as family members so we can track each other's keys when we lose them. This also allows me to see where those users are as long as they are constantly using the location services for the device (and if not, it will update when they open the app).

In this first screenshot you can see the devices that are listed and tied to my account.


If I click the center icon on the bottom I can see where my devices are on a map: 

Now, what data is the app storing? By navigating on an Android device to /data/data/com.thetileapp.tile/ I started to see some cool stuff. Starting with the /shared_prefs/com.thetileapp.tile_preferences.xml file. Didn't have anything, boo. But checking other .xml files in here I did find some cool stuff. The TilePrefs.xml file revealed how many tile devices are in my account, my current email associated with my account (helpful when asking for a search warrant WHICH you WILL want to do) and the uuid of my device. The ScanningTrackerSharedPrefs.xml file here also showed me a host of MAC Addresses I've come in contact with (probably other tile devices). 


Next I headed over to /databases/ to see what was in there. Oh look, a SQLite database, my favorite!

In the tileAndroidDb.db I found some interesting stuff. Let's start with the table: discovered_tiles_table
Only 3 devices in this list are part of my 7 devices. Phone devices uuid start with p! and there are two other tiles in here I'm currently traveling with (6dbc.. and 6b0b...). Other devices are other tile devices that I have come into contact with. The downside of this database is that it's not permanent. I did two sets of test and pulled data twice. Data I pulled earlier yesterday was not available in this database later today which means that this database is constantly in flux. To find the device's this user owns, you can check the app and open the details for each device: 

Or you could just go to the user_tile_table of that same database and get information like when the device was last seen, it's last location (latitude and longitude), if it's lost or dead, timestamps of when it was seen and disconnected, and its name and type. 



My favorite table by far is the location_history_table (and most frustrating). This one seems to constantly be in flux and doesn't store information for more than about a day or so (depends on how much data is being reported as well). 
There's lots of latitude and longitude data here, timestamps, and UUIDs for the tile devices that were discovered. This includes MY devices and OTHER devices that I just happened across during my travels.

Well the databases were helpful but I wish there was more location data. So I kept digging around and found some log files. In the /files/rotated_analytics/ folder there are a bunch of .gz files that contain log files. These log files are named with a Unix numeric (millisecond) date. Inside each .gz is a text log with JSON entries that is keeping a WHOLE lot of reporting data including date/times, device identifiers, when you connected to a tile device, and what SSID you were even broadcasting from. You also get latitude and longitude data here too! I'll be tossing these logs to my friend Alexis who I'm sure will be cooking up a tool to help us rip through them and map them out.



In this entry you can see I connected to a device "Backpack" while the application was actually in the background not actively being used and I was broadcasting from a "MicroTek" SSID.

In this entry you can see I was disconnecting from another device that I don't own, thus helping this user in the Tile mesh network hopefully track their device in the future.

Lots of location data! Since Tile works within a bluetooth range, you now can use these location points to see where my Pixel device was traveling.

Further research: These log files are storing a TON of information. Once I can get them parsed out a little cleaner I'll see what else I can rip through. I'm not done with that database yet either. I want to pin down on exactly how long or how many records I can get it to keep. And of course, iOS has a Tile app too. It's actually what made me start looking into Tile in the first place, I just had better access to share the Android side of it first. Expect a Tile post for iOS coming very soon as another one in my "Locating Location Data" series.

Oh, and if you're an AXIOM user, keep an eye out on the Artifact Exchange where I'll be uploading custom artifacts for the Tile database so we can get that nice location data plotted into World Map View very soon.

Earlier I also mentioned that you might want to get a search warrant ready. If you're doing an investigation into a device and see the user has Tile, you may want to use the user's ID (which is in those xml files and the database) and the device ID (again, database) to ask them for any stored location data. One of the devices (a phone) on my account hasn't been active on the app in months and is still showing me at least the last known location on that date and time so they're probably keeping a plethora of information. Just a thought.


Friday, 23 August 2019

Android - SMS Applications and that Syncing Feeling

When it comes to Android, one of the behaviors I have always found most interesting is that data gets duplicated all over the place. Calls, contacts, and SMS are among the prime examples that I usually find duplicated among other locations than where I would expect them to be. One of the reasons behind this is that Android allows for other applications to take control of primary functions on the device. Users can choose which app they want as their default browser, launcher, and most importantly, their SMS/messaging client! When this happens, Android needs a way to manage the data between the services.

For SMS/MMS messages the regular path for the core storage is: /data/com.android.providers.telephony/databases/mmssms.db or possibly: /user_de/0/com.android.providers.telephony/databases/mmssms.db in version 7 and higher of Android. This sis where we actually usually expect to find the data. However, you may very well find this data duplicated in multiple other locations depending upon what application has been used as the default messaging app.

This will likely turn into a series of posts exploring different messaging clients into Android. There were some apps that I used in this post I hadn’t seen before and I didn’t see a lot of support for so I thought it would be interesting to figure out how to parse them. In this post, I set out to install several applications on an Android version 9 device and see which ones asked to take over the default SMS functionality, what they report back to the main mmssms.db and if any would continue to receive messages even when they were NOT set as the default messaging application. My testing was to launch an app, see if it presented the option to be used as the new “Default SMS Application” and/or if it asked for permissions for the Android’s SMS, send a message with the app, receive a message with the app, repeat with the next app. If it didn’t ask to be the messaging client, see if it at least could send an SMS on behalf of the app to invite users to the service.

When opening up the mmssms.db database, the SMS data we usually care about is in the table “sms” which makes total sense. There is a column in this table called “creator” which will reveal the application BundleID or package name of the application that was responsible for feeding this data into the database. In many cases, unless the manufacturer is putting their own application on there for messaging (I’m looking at YOU Samsung), the recommended default application I’ve seen is Android Messages or com.android.apps.messaging.  This application can send and receive RCS messages in addition to the standard SMS/MMS messages.




The behavior you would expect to happen is that when an application is switched to being the default, it will carry over all of the messages from the app(s) used before it. In my testing, I switched to the "Verizon Messages" app next. When this app is launched, it immediately asks to become the default SMS application.

To find those messages, we'll use the BundleID mentioned in the creator column "com.verizon.messaging.vzmsgs" to find the path /data/com.verizon.messaging.vzmsgs/databases/messages.db where all of the SMS and other messages are stored. A quick query will reveal the messages for us to examine.

Sample query: SELECT message.time, message.thread_id, message.outbound, message.from_addr, message.to_addr, message.seen, message.read, text_content.c1body FROM message JOIN text_content ON message._id = text_content.docid



The interesting thing is that Verizon Messages was the second app I tested. Which means only the SMS transferred to the device before it becoming the default, and messages sent while it is the default should be listed here. Comparing this to the Android Messages app that was used prior, the last two records in the database are from the messages sent with the Android Messages app and none of the apps after it.


After the Verizon Messages app, I moved through several others. A lot of these will be covered more in depth in later posts, but I wanted to give the highlights about whether they did or didn't end up in the mmssms.db and if they stored data outside of their use. 

Android Messages - Allows SMS - Set as default on my Pixel 3a - Only synced messages when it was the default. 
Verizon Messages - Allows SMS - Continued to sync ALL SMS even when not default app. 
Facebook Messenger - Allows SMS - Couldn't locate where SMS are being stored currently. More testing required.
Facebook Messenger Lite - Didn't allow SMS
WhatsApp - Didn't allow SMS
Viber - Didn't allow SMS
Pulse SMS - Allows SMS - Continued to sync SMS after not being default app
Textra - Allows SMS - Continued to sync SMS
Mood Messenger - Allows SMS - Synced SOME messages but not ALL messages of apps used after
imo HD - Didn't allow SMS
goSMS - Allows SMS - Seems to not track SMS when it's not the default app. More testing required. No messages were able to be recovered even ones sent with this app.
Handcent Next SMS - Allows SMS - Synced SOME of the messages of apps coming after but not all.
Chomp SMS - Allows SMS - Seems to not track SMS when it's not the default app. More testing required. No messages were able to be recovered even ones sent with this app.
WeChat - Didn't allow SMS
Telegram - Didn't allow SMS
Signal - Didn't prompt to become default SMS client. SMS is capable in Signal, more testing is needed.
Kakao - Allows SMS - Could only locate partial SMS messages. More testing required.


As you can see, there's some erratic behavior from these apps. Some applications will only sync data when they're the default. Some will sync SOME data when they're not the default, others will continue to sync ALL data when they're not the default. Some apps may completely drop their records when they're not the default SMS app.

Conclusion and Roundup: 
Time to try and round up all this stuff into something that makes sense for examiners. Any time you review the data in mmssms.db and see the creator column reflecting any BundleID (and hopefully your forensic tool of choice is showing you this data), you should probably go dig into that app's data folder and see what's there. When messages are deleted from one app, it does not mean that the data will get deleted from all of the apps that have synced this data to their databases. If your user has bounced between multiple apps trying to settle on the right one for themes, stickers, or whatever other feature they were looking for, that means more data for you! Who doesn't love free data?! [Don't forget the Call Log database can do this too!]

All of the apps tested called back to the main mmssms.db. This is great news as this is probably the main place you go to look for messages, but I'm not sure that all apps will do this. Especially ones more focused on security like Signal. I was really surprised to find Kakao in here!

Another point to mention is that in some of my testing I saw where apps that can't actually send SMS got SMS messages with their bundleID as the creator column. An example of this was GroupMe. Even when GroupMe didn't have SMS functionality turned on, it still was able to send an SMS when an invite code was generated for another user. If the app has permission to read and write the SMS database, it may still send messages on its behalf even if the user isn't sending full SMS messages through it.

Further testing will include going back to take a look at several of the apps that didn't seem to keep their data around (Mood, Handcent, goSMS, and Kakao), apps that don't prompt to be used as the default (GroupMe and Signal), and some other apps I didn't get around to as well (like Samsung's default messenger). I'll continue to update this post series and hopefully come back with new links to the other parts. I'll also take a deeper dive into some of the apps to provide DB queries and other analysis info in case it's ever needed by someone.

Wednesday, 21 August 2019

iOS 12 - Delivered Notifications and a new way to parse them

In iOS 12, Apple went with a different way of storing a user's notifications than I was previously used to. In the past, it wasn't that difficult to track a user's notifications that were still hanging around on the device. It's not impossible right now, but boy is it painful. At least until a friend helped to make it easier for us.

Location: 
First off, you'll need a full file-system style image of an iOS device to dive into these. You'll find the notifications under the path: 
\private\var\mobile\Library\UserNotifications\

Inside this folder, each application that generates notification is then listed by its BundleID as seen here: 

Inside each folder, there may or may not be several property list files listed out by different categories. The files that tend to contain the most relevant data in my experience are the DeliveredNotifications.plist file, the AttachmentList.plist file and the Attachments folder. 



Okay. Time for the bad news. These property list files are NSKeyedArchiver style plist files. Yuck. If you've never dealt with these plist files before I recommend checking out Sarah Edward's blog about them here: https://www.mac4n6.com/blog/2016/1/1/manual-analysis-of-nskeyedarchiver-formatted-plist-files-a-review-of-the-new-os-x-1011-recent-items?rq=nskeyed. I'll wait.

Super annoying, right?! Anyway, I'm going to slightly cheat here. The awesome developers over at Magnet Forensics cooked up a tool that allows me to flatten these property list files into something a little bit more manageable. They're still pretty terrible to deal with though so I'll try to keep this at a several thousand foot view instead of getting deep into the weeds.

I'm going to start with the Delivered Notifications file. In this case, I'll be looking at the one for the Skype for Business app because it's chat data that I had laying around in my phone. To start, each DeliveredNotifications.plist contains a set of keys that will talk about the notification can do on the device. This will include information such as if the the notification should ignore DnD, if it should play a sound, if it should ignore the ringer switch, display on CarPlay, and some date/time information including when the notification was generated.


I'm going to focus on two keys listed about. Keys [3] and [19] which reference the AppNotificationMessage and the AppNotificationCreationDate. Once you can map out each notification within the file, we can start to find the data about the notification. 


In the screenshot above, you can see some information such as key [263] which is the actual message display text. In this case, it's a message from someone who wants me to call them. The key [272] references a time which after some manual validation showed that this is when the notification was delivered to the phone. 


Each notification is going to look at little different potentially but follow the same pattern that is laid out in the plist. 

Moving to a different app, let's look at AttachmentList.plist and the Attachments folder. In this example from my Amazon app on my phone, you can see some attachments that are listed out for the notifications. I'm starting with the DeliveredNotifications.plist again for this app. 


In the upper screenshot you can see the delivered notification text and a timestamp. Below you'll get a listing to the attachment that's part of the notification.


The AttachmentList.plist also lists out all of the attachments you can find in the Attachments folder. Not entirely sure why they're listed again, but they're there. 

Inside the attachment folder, we can use that file:/// path to find the actual file involved. 


After showing some of this to Alexis Brignoni (https://abrignoni.blogspot.com) he was able to come up with a great parser that can pull out some really relevant information from these data points into a great Triage report. I'll let him cover the ins and outs of how its used but I'll show some of the info we were able to pull out here. 

In the two examples attached we have the Instagram app's notifications and some Gmail notification data. 


Here you can see a user tagged me in a post. Instagram is letting me know that I've been mentioned. This notification includes the person who tagged me, lets me know it was a "mentioned_comment," has time/date values, and even the linked path to the attachment of the photo that was posted to the service online and locally on my device. 

Next for Gmail: 

In this one, a user "badmanbarrow1080@gmail.com" received an email about other Google Maps features they shouldn't be missing out on. Thanks for the info Google!

Alexis' tool allows us to strip out a lot of the data from these Plist files quickly and even hide some of the extra rows. You can check out his blog post on it here: https://abrignoni.blogspot.com/2019/08/ios-12-notifications-triage-parser.html and go grab the tool from his Github here: https://github.com/abrignoni/iOS-Notifications-Parser

Future Research: 
The more I did into this the more I find there's some data that we're missing here. Not all services seem to be populating into this area. For example, I had a notification from an iMessage sitting on the screen which doesn't show up anywhere. There are also some PendingNotification.plist files that I haven't found much on yet but I'm hoping can lead us to some other notifications. 

Hopefully this info is helpful to someone out there, and a big thanks to Alexis for running with this and being way more programmatically inclined than I am to work us all up a tool to use!

Friday, 16 August 2019

Rolling in soon! d20 Forensics!

Hello there! I'm Christopher Vance and you've somehow managed to stumble onto my blog that doesn't have any content yet. Welcome to d20 Forensics, my new blog that I'm going to use to post information from the random research projects that I find myself digging into from time to time. What kind of stuff will you find here? Probably mostly posts about mobile forensics, but also cloud forensics, macOS forensics, and when I have nothing better to do with my time and want to punish myself, Windows forensics.

A little background on me, I worked for several years as a forensic specialist for a law enforcement agency working cases that had about every nexus from distracted driving to domestic terrorism. I left that world and went into more of a training role where I've been the last several years. But honestly, what I love the most is research. I mostly focus on mobile forensics around iOS and Android, specifically 3rd-party application analysis. But don't expect to just find that here.

So why d20 forensics? Mostly because I'm a giant nerd. I love board games when I'm outside of the forensic space and love dice games the most. I've also always loved the icosahedron shape (so much so that it's tattooed on my body) and I feel like my brain just as multi-faceted when it comes to forensics.

I'm targeting September 1st for the first run of posts. I can't guarantee any consistency with posting schedule, but when something random comes into my brain and I need a space to put it, it will go here. My hope is that something I do will help the community in the future, but we'll see!