Device Agnostic Mobile Acquisition – Who Needs Model Numbers?
There is a current misconception by many in the mobile forensics field that every acquisition method conducted on a mobile phone is specific to that model. Quite often, I will get requests from examiners asking for a list of mobile devices our tools support. I will often reply with a list of the models we do physical recovery images on and then say we’ll support a logical acquisition of any iOS or Android device. The responses to this last part range from confusion to flat-out disbelief.
In reality, the majority of methods, specifically around logical or file system acquisitions are not specific to any model of phone but work on a majority of devices. Model-specific profiles and images only start to come into play when you’re acquiring physical images via recovery image or bootloader and even then, not all physical extractions are model-specific as well. There are many exploits dealing with entire chipsets that might be limited to that chipset, but works across any device that contains the same chipset hardware (see Qualcomm EDL methods).[i]
Examples of Android Acquisition
Let’s take a look at some Android examples to see what I mean.
Most logical or file system acquisitions done through Android devices will either use ADB or attempt to install an agent to pull provider data (or both.) These methods work for most Android devices since Android 2 (when ADB was added) and while there are some minor quirks between software versions, there’s nothing in the device hardware limiting these methods. Occasionally, you’ll come across a device that does not have ADB installed and the only method available is via an agent or installing an application to pull data from the device (some phones in Asia remove ADB from their packages preventing the ability for your forensics tool to do an ADB backup on the device). However, as long as your tool attempts both of these methods, you should still get something from the device.
In many mobile forensics tools, a list of supported devices is provided to identify devices that the tool has built a profile for and included support for in their product. This acts as a great resource for examiners to look up the current device they’re examining and to see what type of support they’ll expect to get. Another great benefit of the device agnostic approach is that if a new device comes to market, it can still work with your forensics tools right away without requiring a profile to be built for that specific model. This can also help with less popular models or devices that are slow to be supported due to its lack of popularity.
Even when a device is listed as supported, not all supported methods are created equally. Obviously getting a physical image either via software methods (recovery/bootloader) or hardware (JTAG/ISP/Chip off) is best, but not always available. Many physical extractions allow bypassing of passcodes and lock screens but don’t often help with encryption. Full disk encryption often prevents or hinders many physical methods leaving only logical methods available to many newer devices that ship with encryption on by default and this trend will continue to grow as encryption by default becomes standard for device manufacturers. Even logical methods vary in what they can recover as they’re often limited to what the API gives you access to. App developers choose to be included in a backup or not and they can even choose what files get backed up or not.
Other logical methods such as Android OTG, won’t work on every device but the limitation is in the software more so than the hardware or specific model. The OTG method was patched in late 2016[ii], so depending on the software version of your device, this method may or may not be available, it has nothing to do with the model of device. For example, if you’re investigating a Samsung Galaxy S7, these devices originally shipped with Android 6 (Marshmallow) and OTG was an available method. Many of these devices have been updated since (often depends on the telco carrier to choose when updates get approved and pushed out) to various versions of Android 7 or 7.1 (Nougat). So, if you’re running the latest version of Android on your device, that method won’t be available regardless if that model was previously supported.
Don’t Rely Solely on a List of Supported Models
I recently saw on Twitter that someone is building a consolidated list of models supported by various forensics tools and hardware boxes (https://www.digitalforensiccompass.com/) which looks to be the start of a good resource. As with anything in DFIR, your investigation will dictate your needs. Sometimes you’ll need model specific images or exploits to get physical access to a device or bypass a passcode, other times, a device agnostic logical image with ADB is the only option available to you. There’s nothing wrong with having a list of supported models attached to a given tool as it can be a helpful resource, however don’t solely rely on those lists as the basis of whether a tool is going to be successful in getting you the information you need in your investigation. It’s not as black and white.
There are many acquisition methods that work across models and operating systems, understanding how those methods work will help you better understand the type of data you will get in return. We are taught as examiners to investigate and understand how our tools work and how we use them in our investigations because we may need to testify to the methods to our stakeholders or in court. An understanding of the tool acquisition methodology can also help you better understand how to approach mobile device acquisitions in the future. This helps you find the best method(s) and tool(s) for the device you are examining.
Feel free to reach out if you have any questions or comments.
Jamie.mcquaid@magnetforensics.com