Sometimes you cannot image or root a device
All blog posts to date
Introduction
This post will be a bit of a change of gears. Most of the rest of my posts involve imaging the device in question and examining the image. And of course, imaging requires three things:
Determine if the device has been compromised
A common fear with Android devices is that the device can be rooted without the user knowing. This is a legitimate concern, and it can be addressed with an adb shell to the device. Also this takes a couple little pieces of knowledge:
Shell into the device and cd to /system. Then do an ls -al. The -l part of ls will get a listing of all the files and directories at the /system directory including last modified times, and the -a will list any hidden files so you do not miss anything. Here are the results from my Nexus 5:
shell@hammerhead:/ $ cd /system
shell@hammerhead:/system $ ls -al
drwxr-xr-x root root 1970-11-15 06:44 app
drwxr-xr-x root shell 1970-11-15 06:44 bin
-rw-r--r-- root root 4065 2015-04-17 13:34 build.prop
drwxr-xr-x root root 2015-06-25 22:10 etc
drwxr-xr-x root root 2015-04-17 13:34 fonts
drwxr-xr-x root root 2015-04-17 13:34 framework
drwxr-xr-x root root 1970-11-15 06:44 lib
drwx------ root root 1969-12-31 19:00 lost+found
drwxr-xr-x root root 2015-04-17 13:34 media
drwxr-xr-x root root 2015-04-17 13:34 priv-app
-rw-r--r-- root root 89346 2015-04-17 13:34 recovery-from-boot.p
drwxr-xr-x root root 2015-04-17 13:34 usr
drwxr-xr-x root shell 2015-04-17 13:34 vendor
drwxr-xr-x root shell 2015-06-25 22:10 xbin
As the timestamps show, most directories were last altered 2015-04-17, which is when I last flashed a version of Android onto my device. Yes, I am behind the times. Intentionally. I like Android 5.1.1 and I'm sticking with it for now.
But you will also see some oddities. Namely two directories that were updated two months later on 2015-06-25. What is going on with etc and xbin? Let's find out.
So I cd to etc and do another ls -al.
shell@hammerhead:/system $ cd etc
shell@hammerhead:/system/etc $ ls -al
-rw-r--r-- root root 2 1970-11-15 06:44 .installed_su_daemon
-rw-r--r-- root root 1472 2015-04-17 13:34 DxHDCP.cfg
-rw-r--r-- root root 277097 2015-04-17 13:34 NOTICE.html.gz
(A bunch more files ....)
-rw-r--r-- root root 38 2015-06-25 22:10 resolv.conf
(A bunch more files ....)
drwxr-xr-x root root 2015-04-17 13:34 updatecmds
drwxr-xr-x root root 2015-04-17 13:34 wifi
shell@hammerhead:/system/etc $
You will see that the file resolv.conf, which can only be read and written but not executed (explanation found here), was last modified 2015-06-25. So what is in that file and should I care?
I also can see that the file is only 38 bytes. Small file. So I just cat it.
shell@hammerhead:/system/etc $ cat resolv.conf
nameserver 8.8.4.4
nameserver 8.8.8.8
shell@hammerhead:/system/etc $
The contents of the file are pretty simple. For an explanation of what "nameserver 8.8.4.4" means, quite literally consult Google.
So on the one hand, you have a file which basically just says use Google for DNS, so nothing of real significance. On the other hand, why was that file modified when it was? If you remember, at the same date and time that the resolv.conf file was modified, the /system/xbin partition was modified. Let's cd to that and get an ls -al.
shell@hammerhead:/system/etc $ cd ../xbin
shell@hammerhead:/system/xbin $ ls -al
lrwxrwxrwx root root 2015-06-25 22:10 [ -> /system/xbin/busybox
lrwxrwxrwx root root 2015-06-25 22:10 [[ -> /system/xbin/busybox
lrwxrwxrwx root root 2015-06-25 22:10 acpid -> /system/xbin/busybox
.....
-rwxr-xr-x root root 1095836 2015-06-25 22:10 busybox
.....
-rwxr-xr-x root root 75364 1970-11-15 06:44 su-rwxr-xr-x root root 75364 1970-11-15 06:44 sugote
-rwxr-xr-x root root 157412 1970-11-15 06:44 sugote-mksh
.....
lrwxrwxrwx root root 2015-06-25 22:10 zcat -> /system/xbin/busybox
lrwxrwxrwx root root 2015-06-25 22:10 zcip -> /system/xbin/busybox
shell@hammerhead:/system/xbin $
So what does this all mean? It means that on 2015-06-25 at 22:10 EST, I installed busybox on my device. Busybox installed all these logical links at /system/xbin which point to busybox, and busybox additionally changed the /system/etc/resolv.conf to point to Google.
Additionally, you can see that on November 15, 1970, I rooted my device as you can see the su binary.
Wait, what? In 1970, neither the device nor me existed. Google didn't exist, cellular connectivity didn't exist, computers used punch cards as input, and bell bottom jeans were hot fashion
No, most likely, I rooted my phone in June 2015. However, I rooted my phone via recovery mode, which does not use the Android clock, so all activity appears to take place in 1970. I hate to disappoint you all, but I am in fact not a time traveler. Additionally, this explains the file /system/etc/.installed_su_daemon as seen above, also modified in 1970.
So quick takeaways. If you are worried that your phone might be compromised, do an ls -l in /system and see if anything looks like it was modified at strange times. Additionally, see if /system/xbin/su exists.
Now some caveats:
See what apps have been installed and if there are any you do not recognize
You install apps on your phone and you know what you've installed. Or you install so many apps that you forgot what you've installed but the fact is you did personally install the app and you can account for it.
But what if somebody else gets their paws on your phone and installs something? We've all read articles about scares over spyware on phones, and we've all seen those movies where the bad guy gets the good guy's phone and installs something nasty which lets the bad guy listen on and everything the good guy is doing. The truth is the Android development environment can be exploited to allow such apps to run.
So what if you think somebody has "tapped" your phone? There is a good chance that if your phone has not been rooted and yet somebody put something on your phone, the little gift they left for you is an app. It may be hidden, but it can be found with some simple command lines.
I'll give a quick and simple method which gets a list of all user-installed apps and then another method which tells details of all apps on the device.
So the quick way first. Adb shell into your phone and type the following command:
pm list packages -3
pm is a command which stands for "package manager". It does just as you may think - it manages packages, or apps, on the device. The command above lists all third party apps, or user-installed apps. The output from my phone is as follows:
shell@hammerhead:/ $ pm list packages -3
package:stericson.busybox
package:com.redfin.android
package:com.weather.Weather
... a bunch more third party apps ...
package:com.google.android.apps.chromecast.app
package:com.lookout
package:com.fandango
package:com.hp.android.printservice
shell@hammerhead:/ $
If any of the apps listed look like something you do not recognize, perhaps you should look into it. I personally recognize all the apps installed. stericson.busybox is a shortcut way to install busybox. I care about the weather, hence a weather app. My wife and I went to go see Deadpool last week, hence the Fandango app.
Now let's say you want to look into a specific app. You can use the dumpsys command, which accesses all types of system logs. For example, let's do a look into the WatchESPN app. I may be a massive nerd, but I love my sports.
I enter the following line ...
dumpsys package air.WatchESPN
And I get the following info about the WatchESPN app
shell@hammerhead:/ $ dumpsys package air.WatchESPN
... a bunch of developer related activity at the top ... Packages:
Package [air.WatchESPN] (2f619c56):
userId=10111 gids=[3003, 1028, 1015]
pkg=Package{2ab5f4d7 air.WatchESPN}
codePath=/data/app/air.WatchESPN-2
resourcePath=/data/app/air.WatchESPN-2
legacyNativeLibraryDir=/data/app/air.WatchESPN-2/lib
primaryCpuAbi=armeabi
secondaryCpuAbi=null
versionCode=2100103 targetSdk=22
versionName=2.4.1
splits=[base]
applicationInfo=ApplicationInfo{36a34671 air.WatchESPN}
flags=[ HAS_CODE ALLOW_CLEAR_USER_DATA ALLOW_BACKUP ]
dataDir=/data/data/air.WatchESPN
supportsScreens=[small, medium, large, xlarge, resizeable, anyDensity]
timeStamp=2015-10-31 08:03:15
firstInstallTime=2015-10-10 15:09:36
lastUpdateTime=2015-10-31 08:03:16
installerPackageName=com.android.vending
signatures=PackageSignatures{155cf1c4 [2bd4d8ad]}
permissionsFixed=true haveGids=true installStatus=1
pkgFlags=[ HAS_CODE ALLOW_CLEAR_USER_DATA ALLOW_BACKUP ]
User 0: installed=true hidden=false stopped=false notLaunched=false enabled=0
grantedPermissions:
android.permission.INTERNET
android.permission.READ_EXTERNAL_STORAGE
android.permission.READ_PHONE_STATE
android.permission.ACCESS_NETWORK_STATE
android.permission.WRITE_EXTERNAL_STORAGE
android.permission.ACCESS_WIFI_STATE
shell@hammerhead:/ $
So what does all this mean? Let's break down some important highlights.
So this app is obviously legit. And if this information looks awfully familiar, it is because the same information shows up in the packages.xml file.
You can also type the following command:
dumpsys package
and you will get a similar listing for every app installed on the device. Now I would recommend catting this all out to a file. The way to do that is get out of your adb shell and cat the output to a file on your computer. It would look like the following, and note that I am shelled into my computer, not my phone:
adb shell dumpsys package > dumpsyspackage.txt
You will have a file on your computer called dumpsyspackage.txt with a full listing of every app on your device.
Now let's say I found something in the listing for the WatchESPN app that bothered me. I may want to reverse engineer the app. I can pull the app without root access. Here would be the line to pull the app onto the local computer:
adb pull /data/app/air.WatchESPN-2/base.apk
Based on the output above, the app is in the directory /data/app/air.WatchESPN-2/, and I happen to know the apks for third party apps in Android 5 get installed in that directory as the file base.apk. The above command pulls that file to your local computer.
Continuing with that nifty dumpsys command ...
Fun with dumpsys
As I said before, dumpsys is a command which accesses system logs. It can tell you a whole lot more than just what apps are installed.
Now if all you want to do is obtain an entire system log, do a similar command as the previous command to dump all package logs to a single file. Type the following command ...
adb shell dumpsys > dumpsys.txt
... and go grab a drink because it will run for a while.
The resulting file dumpsys.txt will be quite large, unorganized, and difficult to prod through. So let's get a finer view of it. ADB shell into the device and type the following:
dumpsys -l
I get the following output:
shell@hammerhead:/ $ dumpsys -l
Currently running services:
DockObserver
SurfaceFlinger
accessibility
account
activity
alarm
android.security.keystore
appops
appwidget
assetatlas
audio
backup
battery
batteryproperties
batterystats
bluetooth_manager
... a bunch more services ... voiceinteraction
wallpaper
webviewupdate
wifi
wifip2p
wifiscanner
window
shell@hammerhead:/ $
It is a list of all running services that can be dumped. So let's say I want to find out about my wifi. I can enter the following command from the computer, similar to previously dumping all app info.
adb shell dumpsys wifi > dumpsyswifi.txt
And I will get an output about what WiFi I am connected to, packet usage, etc. You can do the same for any of these running services. Want to know what your bluetooth is up to? You know what to do now.
dumpsys is a good tool to play around with and it works on live running devices. This is not something you can do to an image. An image is just a file, a dead, flat file. A device is a live, running computer that you can interact with, or in the above cases, interrogate.
Summary
This post will be a bit of a change of gears. Most of the rest of my posts involve imaging the device in question and examining the image. And of course, imaging requires three things:
- Data connection between the device and the computer
- Exploit
- Imaging command
Determine if the device has been compromised
A common fear with Android devices is that the device can be rooted without the user knowing. This is a legitimate concern, and it can be addressed with an adb shell to the device. Also this takes a couple little pieces of knowledge:
- The system partition, mounted at /system, is mounted read only
- Normal users cannot modify anything in this partition without a root exploit
- The root binary, su, is typically found in the system partition
- Which all means that if the device is compromised, there is most likely evidence of it found in /system
Shell into the device and cd to /system. Then do an ls -al. The -l part of ls will get a listing of all the files and directories at the /system directory including last modified times, and the -a will list any hidden files so you do not miss anything. Here are the results from my Nexus 5:
shell@hammerhead:/ $ cd /system
shell@hammerhead:/system $ ls -al
drwxr-xr-x root root 1970-11-15 06:44 app
drwxr-xr-x root shell 1970-11-15 06:44 bin
-rw-r--r-- root root 4065 2015-04-17 13:34 build.prop
drwxr-xr-x root root 2015-06-25 22:10 etc
drwxr-xr-x root root 2015-04-17 13:34 fonts
drwxr-xr-x root root 2015-04-17 13:34 framework
drwxr-xr-x root root 1970-11-15 06:44 lib
drwx------ root root 1969-12-31 19:00 lost+found
drwxr-xr-x root root 2015-04-17 13:34 media
drwxr-xr-x root root 2015-04-17 13:34 priv-app
-rw-r--r-- root root 89346 2015-04-17 13:34 recovery-from-boot.p
drwxr-xr-x root root 2015-04-17 13:34 usr
drwxr-xr-x root shell 2015-04-17 13:34 vendor
drwxr-xr-x root shell 2015-06-25 22:10 xbin
As the timestamps show, most directories were last altered 2015-04-17, which is when I last flashed a version of Android onto my device. Yes, I am behind the times. Intentionally. I like Android 5.1.1 and I'm sticking with it for now.
But you will also see some oddities. Namely two directories that were updated two months later on 2015-06-25. What is going on with etc and xbin? Let's find out.
So I cd to etc and do another ls -al.
shell@hammerhead:/system $ cd etc
shell@hammerhead:/system/etc $ ls -al
-rw-r--r-- root root 2 1970-11-15 06:44 .installed_su_daemon
-rw-r--r-- root root 1472 2015-04-17 13:34 DxHDCP.cfg
-rw-r--r-- root root 277097 2015-04-17 13:34 NOTICE.html.gz
(A bunch more files ....)
-rw-r--r-- root root 38 2015-06-25 22:10 resolv.conf
(A bunch more files ....)
drwxr-xr-x root root 2015-04-17 13:34 updatecmds
drwxr-xr-x root root 2015-04-17 13:34 wifi
shell@hammerhead:/system/etc $
You will see that the file resolv.conf, which can only be read and written but not executed (explanation found here), was last modified 2015-06-25. So what is in that file and should I care?
I also can see that the file is only 38 bytes. Small file. So I just cat it.
shell@hammerhead:/system/etc $ cat resolv.conf
nameserver 8.8.4.4
nameserver 8.8.8.8
shell@hammerhead:/system/etc $
The contents of the file are pretty simple. For an explanation of what "nameserver 8.8.4.4" means, quite literally consult Google.
So on the one hand, you have a file which basically just says use Google for DNS, so nothing of real significance. On the other hand, why was that file modified when it was? If you remember, at the same date and time that the resolv.conf file was modified, the /system/xbin partition was modified. Let's cd to that and get an ls -al.
shell@hammerhead:/system/etc $ cd ../xbin
shell@hammerhead:/system/xbin $ ls -al
lrwxrwxrwx root root 2015-06-25 22:10 [ -> /system/xbin/busybox
lrwxrwxrwx root root 2015-06-25 22:10 [[ -> /system/xbin/busybox
lrwxrwxrwx root root 2015-06-25 22:10 acpid -> /system/xbin/busybox
.....
-rwxr-xr-x root root 1095836 2015-06-25 22:10 busybox
.....
-rwxr-xr-x root root 75364 1970-11-15 06:44 su-rwxr-xr-x root root 75364 1970-11-15 06:44 sugote
-rwxr-xr-x root root 157412 1970-11-15 06:44 sugote-mksh
.....
lrwxrwxrwx root root 2015-06-25 22:10 zcat -> /system/xbin/busybox
lrwxrwxrwx root root 2015-06-25 22:10 zcip -> /system/xbin/busybox
shell@hammerhead:/system/xbin $
So what does this all mean? It means that on 2015-06-25 at 22:10 EST, I installed busybox on my device. Busybox installed all these logical links at /system/xbin which point to busybox, and busybox additionally changed the /system/etc/resolv.conf to point to Google.
Additionally, you can see that on November 15, 1970, I rooted my device as you can see the su binary.
Wait, what? In 1970, neither the device nor me existed. Google didn't exist, cellular connectivity didn't exist, computers used punch cards as input, and bell bottom jeans were hot fashion
No, most likely, I rooted my phone in June 2015. However, I rooted my phone via recovery mode, which does not use the Android clock, so all activity appears to take place in 1970. I hate to disappoint you all, but I am in fact not a time traveler. Additionally, this explains the file /system/etc/.installed_su_daemon as seen above, also modified in 1970.
So quick takeaways. If you are worried that your phone might be compromised, do an ls -l in /system and see if anything looks like it was modified at strange times. Additionally, see if /system/xbin/su exists.
Now some caveats:
- The system clock can be changed. Easily.
- A smart attacker can change the clock around and do changes so that a simple analysis as seen above will not uncover changes made.
- The su binary need not be called su and placed in /system/xbin
- It could be elsewhere and called something else. As long as it has the right permissions, the file can be placed anywhere on the device with execute privileges.
See what apps have been installed and if there are any you do not recognize
You install apps on your phone and you know what you've installed. Or you install so many apps that you forgot what you've installed but the fact is you did personally install the app and you can account for it.
But what if somebody else gets their paws on your phone and installs something? We've all read articles about scares over spyware on phones, and we've all seen those movies where the bad guy gets the good guy's phone and installs something nasty which lets the bad guy listen on and everything the good guy is doing. The truth is the Android development environment can be exploited to allow such apps to run.
So what if you think somebody has "tapped" your phone? There is a good chance that if your phone has not been rooted and yet somebody put something on your phone, the little gift they left for you is an app. It may be hidden, but it can be found with some simple command lines.
I'll give a quick and simple method which gets a list of all user-installed apps and then another method which tells details of all apps on the device.
So the quick way first. Adb shell into your phone and type the following command:
pm list packages -3
pm is a command which stands for "package manager". It does just as you may think - it manages packages, or apps, on the device. The command above lists all third party apps, or user-installed apps. The output from my phone is as follows:
shell@hammerhead:/ $ pm list packages -3
package:stericson.busybox
package:com.redfin.android
package:com.weather.Weather
... a bunch more third party apps ...
package:com.google.android.apps.chromecast.app
package:com.lookout
package:com.fandango
package:com.hp.android.printservice
shell@hammerhead:/ $
If any of the apps listed look like something you do not recognize, perhaps you should look into it. I personally recognize all the apps installed. stericson.busybox is a shortcut way to install busybox. I care about the weather, hence a weather app. My wife and I went to go see Deadpool last week, hence the Fandango app.
Now let's say you want to look into a specific app. You can use the dumpsys command, which accesses all types of system logs. For example, let's do a look into the WatchESPN app. I may be a massive nerd, but I love my sports.
I enter the following line ...
dumpsys package air.WatchESPN
And I get the following info about the WatchESPN app
shell@hammerhead:/ $ dumpsys package air.WatchESPN
... a bunch of developer related activity at the top ... Packages:
Package [air.WatchESPN] (2f619c56):
userId=10111 gids=[3003, 1028, 1015]
pkg=Package{2ab5f4d7 air.WatchESPN}
codePath=/data/app/air.WatchESPN-2
resourcePath=/data/app/air.WatchESPN-2
legacyNativeLibraryDir=/data/app/air.WatchESPN-2/lib
primaryCpuAbi=armeabi
secondaryCpuAbi=null
versionCode=2100103 targetSdk=22
versionName=2.4.1
splits=[base]
applicationInfo=ApplicationInfo{36a34671 air.WatchESPN}
flags=[ HAS_CODE ALLOW_CLEAR_USER_DATA ALLOW_BACKUP ]
dataDir=/data/data/air.WatchESPN
supportsScreens=[small, medium, large, xlarge, resizeable, anyDensity]
timeStamp=2015-10-31 08:03:15
firstInstallTime=2015-10-10 15:09:36
lastUpdateTime=2015-10-31 08:03:16
installerPackageName=com.android.vending
signatures=PackageSignatures{155cf1c4 [2bd4d8ad]}
permissionsFixed=true haveGids=true installStatus=1
pkgFlags=[ HAS_CODE ALLOW_CLEAR_USER_DATA ALLOW_BACKUP ]
User 0: installed=true hidden=false stopped=false notLaunched=false enabled=0
grantedPermissions:
android.permission.INTERNET
android.permission.READ_EXTERNAL_STORAGE
android.permission.READ_PHONE_STATE
android.permission.ACCESS_NETWORK_STATE
android.permission.WRITE_EXTERNAL_STORAGE
android.permission.ACCESS_WIFI_STATE
shell@hammerhead:/ $
So what does all this mean? Let's break down some important highlights.
- codePath=/data/app/air.WatchESPN-2
- The apk is in the /data/app/air.WatchESPN-2/ directory
- legacyNativeLibraryDir=/data/app/air.WatchESPN-2/lib
- Any native libraries are in /data/app/air.WatchESPN-2/lib/
- dataDir=/data/data/air.WatchESPN
- Data associated with the app is stored in /data/data/air.WatchESPN - though you need to be root to access that data
- firstInstallTime=2015-10-10 15:09:36
- I installed the app in October 2015. I'm guessing it was to watch this game. My Bowling Green Falcons put on a show on offense.
- lastUpdateTime=2015-10-31 08:03:16
- The app was last updated on Halloween 2015. The update must have been scary.
- installerPackageName=com.android.vending
- The app was installed by the standard method, not by ADB or other manual methods
- grantedPermissions
- The app has the following permissions:
- android.permission.INTERNET
- android.permission.READ_EXTERNAL_STORAGE
- android.permission.READ_PHONE_STATE
- android.permission.ACCESS_NETWORK_STATE
- android.permission.WRITE_EXTERNAL_STORAGE
- android.permission.ACCESS_WIFI_STATE
So this app is obviously legit. And if this information looks awfully familiar, it is because the same information shows up in the packages.xml file.
You can also type the following command:
dumpsys package
and you will get a similar listing for every app installed on the device. Now I would recommend catting this all out to a file. The way to do that is get out of your adb shell and cat the output to a file on your computer. It would look like the following, and note that I am shelled into my computer, not my phone:
adb shell dumpsys package > dumpsyspackage.txt
You will have a file on your computer called dumpsyspackage.txt with a full listing of every app on your device.
Now let's say I found something in the listing for the WatchESPN app that bothered me. I may want to reverse engineer the app. I can pull the app without root access. Here would be the line to pull the app onto the local computer:
adb pull /data/app/air.WatchESPN-2/base.apk
Based on the output above, the app is in the directory /data/app/air.WatchESPN-2/, and I happen to know the apks for third party apps in Android 5 get installed in that directory as the file base.apk. The above command pulls that file to your local computer.
Continuing with that nifty dumpsys command ...
Fun with dumpsys
As I said before, dumpsys is a command which accesses system logs. It can tell you a whole lot more than just what apps are installed.
Now if all you want to do is obtain an entire system log, do a similar command as the previous command to dump all package logs to a single file. Type the following command ...
adb shell dumpsys > dumpsys.txt
... and go grab a drink because it will run for a while.
The resulting file dumpsys.txt will be quite large, unorganized, and difficult to prod through. So let's get a finer view of it. ADB shell into the device and type the following:
dumpsys -l
I get the following output:
shell@hammerhead:/ $ dumpsys -l
Currently running services:
DockObserver
SurfaceFlinger
accessibility
account
activity
alarm
android.security.keystore
appops
appwidget
assetatlas
audio
backup
battery
batteryproperties
batterystats
bluetooth_manager
... a bunch more services ... voiceinteraction
wallpaper
webviewupdate
wifi
wifip2p
wifiscanner
window
shell@hammerhead:/ $
It is a list of all running services that can be dumped. So let's say I want to find out about my wifi. I can enter the following command from the computer, similar to previously dumping all app info.
adb shell dumpsys wifi > dumpsyswifi.txt
And I will get an output about what WiFi I am connected to, packet usage, etc. You can do the same for any of these running services. Want to know what your bluetooth is up to? You know what to do now.
dumpsys is a good tool to play around with and it works on live running devices. This is not something you can do to an image. An image is just a file, a dead, flat file. A device is a live, running computer that you can interact with, or in the above cases, interrogate.
Summary
- There are some ways to get useful information from a live device, even without rooting or imaging.
- Looking at files in your system partition by timestamp can be an indicator if your device has been compromised, though remember that timestamps can be faked with relative ease.
- Dumpsys is a useful tool.
- You can use dumpsys to learn about what apps are installed on a device, and you can use an adb pull to remove the app and examine if you wish.
