Some non-root methods to learn about a device

Sometimes you cannot image or root a device

All blog posts to date

Introduction	Acquisition	Analysis
Introduction	Imaging an Android Device	Examining the image
Picking a Toolkit	Live imaging an Android device	Some hidden artifacts in a physical image
	Why not load ClockworkMod or TWRP to image a device?	Using Autopsy to examine an Android image
	Identifying your Userdata Partition	Some artifacts in the /data/system/ directory
	Some non-root methods to learn about a device	Viewing SQLite Databases
	A quick note on imaging newer Android devices	Facebook for Android Artifacts
	Using Windows to Live Image an Android device	Interpreting data from apps
	Obtaining all files in the data partition without a physical image	Waze for Android forensics
		Magnet Forensics App Simulator
App Reversing	Other Topics
Reverse Engineering an Android App File	The differences between a physical image and a logical extraction
Fun with Apktool	Dirty cow
Deep dive into an app	Imaging and examining an Android car stereo
	Unpacking boot and recovery kernels
	MTPwn

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:  

• Data connection between the device and the computer
• Exploit
• Imaging command

Now what if you cannot or choose not to exploit (root) your device?  This is a real situation.  So long as you have the ability to adb shell into the device, there still are some ways to get useful data from the device.  This post is all about some simple ways to gain some insight into the device.

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.

As always, if you are concerned there is some advanced attacking going on against your device which may employ some clock modification or a hidden root, you can contact me for further assistance with your device.


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.

Questions, comments?  Sports memories?  Leave a comment below, or send me an email.