The introduction of the Android operating system in mobile devices is growing at a overwhelming speed. Latest data point shows that 1.3 million Android devices are activated every day (Spanish). If Android maintains this pace, in just 4 years there will be more Google systems in operation than Windows systems. Therefore, the study of the security of Android is necessary and in security, an interesting and important area is the forensic study.
A forensic analyst must be able to extract the maximum available information from the device. Depending on the purpose of the research, s/he will focus on extracting different types of data. For example, a researcher who analyzes a possible malware-infected smartphone need processes in memory, active connections, the inbound and outbound traffic, while in the analysis of a mobile phone whose owner is suspected of a crime, it will look for data that could help the investigation to provide evidence, such as calls, emails, GPS position, photos, chat history, etc.
There area several methods to extract information from an android device: RAM memory dump, NAND memory image, external memory SD-card data and hot extraction data. Today’s post focuses on recovering data by using the Android system’s own commands, and more specifically, the logs generated by the system.
However, should take into account that the analysis of the logs generated by a machine live has two main risks:
- Data provided by commands can not be considered 100% reliable, since the device can be deliberately compromised and generate false data. Only when the executed commands come from a reliable source the extracted data can be trusted.
- The execution of a system’s own commands to extract information alters the original state of the device, so it may break the forensic chain of custody.
Not only that, but the forensic analysis of a mobile device is more difficult than of a classical computer. You can’t easily remove the system’s internal storage memory (i.e., remove the hard drive), and make an image. In mobile devices you have to extract the memory making use of chip-off techniques what tends to be quite complicated and expensive. In addition, turning off the device can prevent subsequent access to the system if it uses encryption or locking by password. We must therefore assess whether it is worth dealing with the two previous risks to extract information from the device in hot that with other methods would not be possible to recover.
As a comment, in the future probably these problems will be solved thanks to the recovery of the information through the analysis of the RAM memory dump. Until then you can get enough information dumping the RAM with LiME and analyzing it with volatility. The next version of the latter promises greater support for Android. This method will be explained in more detail in an upcoming entry.
Having said that, let’s see some useful examples. The first one is logcat. This tool dumps events generated by the system. Android currently has four buffers that collect events: main, system, events, and radio. These are found at /dev/log. You can display each of them with the parameter -b:
$ logcat -b radio D/GSM ( 641): [GsmDCT] onReceive: action=android.net.wifi.WIFI_STATE_CHANGED D/GSM ( 641): [GsmDCT] onReceive: action=android.intent.action.SCREEN_OFF D/GSM ( 641): [GsmDCT] stopNetStatPoll D/GSM ( 641): [GsmDCT] overall state is IDLE D/GSM ( 641): [GsmDCT] onReceive: action=android.intent.action.SCREEN_ON [..]
By default it does not insert the timestamps, but they can be included with the parameter -v time:
$ logcat -b events -v time 10-30 12:24:31.476 I/am_kill ( 351): [2908,com.google.android.calendar,15,too many background] 10-30 12:24:31.486 I/am_proc_died( 351): [2908,com.google.android.calendar] 10-30 12:24:31.486 I/am_proc_bound( 351): [10397,com.google.android.apps.docs] 10-30 12:24:31.946 I/am_kill ( 351): [573,com.google.android.gm,15,too many background] [...]
Normally these logs tend to be very verbose and we may want to show entries from level warning:
$ logcat -b system -v time *:W
10-30 06:35:42.286 W/ThrottleService( 351): unable to find stats for iface rmnet0
10-30 06:39:42.676 W/AlarmManager( 351): setInexactRepeating ignored because interval 0 is invalid
10-30 06:39:43.376 E/NetdConnector( 351): NDC Command {737 resolver flushif wlan0} took too long
(60002ms)
10-30 06:45:43.316 W/ThrottleService( 351): unable to find stats for iface rmnet0
[...]
The rest of parameters can be found on the website of Android development help.
There are two other tools that dump lots of information about the status of the device: dumpsys and dumpstate. Dumpsys displays a lot of information about the system services, while dumpstate collects information through /proc (in addition to dump a dumpsys also). As the size of the displayed log is often several MB, with dumpsys it is possible to display information for a specific service:
$ dumpsys cpuinfo Load: 0.0 / 0.03 / 0.27 CPU usage from 17672ms to 958ms ago: 24% 351/system_server: 22% user + 2.5% kernel / faults: 4232 minor 0% 30188/com.levelup.touiteur: 0% user + 0% kernel / faults: 662 minor 1% 142/adbd: 0.2% user + 0.7% kernel 0.5% 692/com.google.process.gapps: 0.5% user + 0% kernel / faults: 250 minor [....]
It is possible to enumerate the services available for display with the following command:
$ dumpsys | grep DUMP DUMP OF SERVICE SurfaceFlinger: DUMP OF SERVICE accessibility: DUMP OF SERVICE account: DUMP OF SERVICE activity: DUMP OF SERVICE alarm: [...]
Finally, the bugreport command is the mother of all logging commands, since it dumps the output of dmesg, logcat, dumpsys, and dumpstate.
To make it more comfortable for the investigator, there is an application called chkbugreport that processes the bugreport output and shows it in a user-friendly format, as a report in html.
