Learning Android Forensics

Analyze Android devices with the latest forensic tools and techniques, 2nd Edition

Oleg Skulkin, Donnie Tindall, Rohit Tamma

• Editorial: Packt Publishing
• Año: 2018
• ISBN:
  9781789137491
• Edición: 2
• Categoría: Computer Science
• Categoría: Cyber Security

A comprehensive guide to Android forensics, from setting up the workstation to analyzing key artifacts

Key Features

• Get up and running with modern mobile forensic strategies and techniques
• Analyze the most popular Android applications using free and open source forensic tools
• Learn malware detection and analysis techniques to investigate mobile cybersecurity incidents

Book Description

Many forensic examiners rely on commercial, push-button tools to retrieve and analyze data, even though there is no tool that does either of these jobs perfectly.

Learning Android Forensics will introduce you to the most up-to-date Android platform and its architecture, and provide a high-level overview of what Android forensics entails. You will understand how data is stored on Android devices and how to set up a digital forensic examination environment. As you make your way through the chapters, you will work through various physical and logical techniques to extract data from devices in order to obtain forensic evidence. You will also learn how to recover deleted data and forensically analyze application data with the help of various open source and commercial tools. In the concluding chapters, you will explore malware analysis so that you'll be able to investigate cybersecurity incidents involving Android malware.

By the end of this book, you will have a complete understanding of the Android forensic process, you will have explored open source and commercial forensic tools, and will have basic skills of Android malware identification and analysis.

What you will learn

• Understand Android OS and architecture
• Set up a forensics environment for Android analysis
• Perform logical and physical data extractions
• Learn to recover deleted data
• Explore how to analyze application data
• Identify malware on Android devices
• Analyze Android malware

Who this book is for

If you are a forensic analyst or an information security professional wanting to develop your knowledge of Android forensics, then this is the book for you. Some basic knowledge of the Android mobile platform is expected.

Forensic Analysis of Android Applications

This chapter will cover application analysis. This chapter will focus on analyzing the data that would be recovered using any of the logical or physical techniques detailed in Chapter 4, Extracting Data Logically from Android Devices, and Chapter 5, Extracting Data Physically from Android Devices. It will also rely heavily on the storage methods discussed in Chapter 2, Setting Up the Android Forensic Environment; we will see numerous SQLite databases, XML files, and other file types from various locations within the file hierarchy described in that chapter. By the end of this chapter, the reader should be familiar with the following:

• Application analysis overview
• Why do app analysis?
• Third-party applications and various methods used by popular applications to store and obfuscate data

Application analysis overview

Forensically analyzing an application is as much of an art as it is a science. There are myriad ways an application can store, or obfuscate, its data. Different versions of the same application may even store the same data differently. Developers are really only limited by their imagination (and Android platform restrictions) when it comes to choosing how to store their data. Because of these factors, application analysis is a moving target; methods an examiner uses one day may be completely irrelevant the next.

The end goal of forensically analyzing an application is consistently the same: to understand what the app was used for, and to find user data.

In this chapter, we will look at the current version of many common applications. Because apps can, and do, change how they store data through updates, nothing in this chapter is a definitive guide for how to analyze that application. Instead, we will look at a broad range of applications to show a variety of different methods used by applications to store their data. For the most part, we will be looking at very common applications (millions of downloads from Google Play), except for cases where looking at an obscure app can reveal interesting new ways of storing data.

Why do app analysis?

For starters, even standard phone functions such as contacts, calls, and SMS are done through applications on Android devices, so even acquiring basic data requires analyzing an application. Secondly, a person's app usage can tell you a lot about them: where they've been (and when they were there), who they've communicated with, and even what they may be planning in the future.

Many phones come with more than 20 pre-installed applications. An examiner has no real way of knowing which of these apps could contain information useful for an investigation, and therefore they must all be analyzed. An examiner may be tempted to skip over certain apps that would appear to have little useful data, such as games. This would be a bad idea, though; many popular games have a built-in chat feature, which could yield useful information. Our analysis will focus heavily on messaging applications, as our experience shows that these tend to be the most valuable in a forensic analysis.

Layout of this chapter

For each application we examine, we will provide a package name and files of interest. All apps store their data in the /data/data or /data/user_de/0 (newer devices) directory by default; apps can also use the SD card if they ask for this permission when the app is installed. The package name is the name of the directory for the application in one of these directories. The paths in the Files of interest section are from the root of the package name. Paths to data on the SD card are shown beginning with /sdcard. Do not expect to find data paths beginning with /sdcard in the /data/data or /data/user_de/0 directory of the application!

We will begin by looking at some of Google's applications, because these are pre-installed on the majority of devices (though they do not have to be). Then we will look at third-party applications that can be found on Google Play.

Determining which apps are installed

To see what applications are on the device, an examiner could navigate to /data/data and run the ls command. But that doesn't provide well-formatted data that will look good in a forensic report. We suggest pulling the /data/system/packages.list file; this file lists the package name for every app on the device and path to its data (if this file does not exist on the device, the adb shell pm list packages –f command is a good alternative). For example, here is an entry for Google Chrome (the full file on our test device contained 120 entries):

This is data storage method 1: plaintext. Often we will see apps store data in plaintext, even including data you wouldn't expect (such as passwords).

Perhaps of greater interest is the /data/system/package-usage.list file, which shows the last time that package (or application) was used. It's not perfect; the times shown in the file did not correlate exactly with the last time we used the app. It appears that the app updating or receiving notifications (even if the user does not view them) may affect the time, however it is good for a general indication of the last apps the user accessed:

If you're wondering where to find the time in that line, it's in a format known as Unix epoch time.

Understanding Unix epoch time

Unix epoch time, also known as Unix time or Posix time, is stored as the number of seconds (or milliseconds) since midnight on January 1st, 1970 UTC. A 10-digit value indicates it is in seconds, while a 13-digit value is indicative of a millisecond value (at least for times likely to be found on a smartphone, as 9-digit second and 12-digit millisecond values haven't occurred since 2001). In our example, the value is 1422206858650; Google Chrome was last used 1 billion, 422 million, 206 thousand, 858 seconds, and 650 milliseconds since midnight on January 1st, 1970! Don't worry, we don't know what date/time that is either. There are many scripts and tools available for download that can convert this into a human-readable format; we like DCode, a free tool that can be found here: http://www.digital-detective.net/digital-forensic-software/free-tools/.

In DCode, simply select Unix: Millisecond Value from the dropdown list, type in the value in the Value to Decode field, and click Decode:

The Add B...