File System, Part 8: Removing preinstalled malware from an Android device - lyuanschool/SystemProgramming GitHub Wiki
Case study: Removing malware from an Android device
This section uses filesystem features and system programming tools discussed in this wikibook to find and remove unwanted malware from an Android tablet.
DISCLAIMER. ENSURE ANY VALUABLE INFORMATION ON YOUR DEVICE IS BACKED UP BEFORE ATTEMPTING TO MODIFY YOUR TABLET. MODIFYING SYSTEM SETTINGS AND SYSTEM FILES IS NOT RECOMMENDED. ATTEMPTING TO MODIFY A DEVICE USING THIS CASE STUDU GUIDE MAY CAUSE YOUR TABLET TO SHARE, LOSE OR CORRUPT YOUR DATA DATA. FURTHER YOUR TABLET MAY FUNCTION INCORRECTLY OR TO STOP FUNCTIONING ALTOGETHER. USE THIS CASE STUDY AT YOUR OWN RISK. THE AUTHORS ASSUME NO RESPONSIBILITY AND MAKE NO WARRANTY ABOUT THE CORRECTNESS OR COMPLETENESS OF THESE INSTRUCTIONS INCLUDED IN THIS CASE STUDY. THE AUTHORS ASSUME NO RESPONSIBILITY AND MAKE NO WARRANTY ABOUT ANY SOFTWARE INCLUDING EXTERNAL THIRD PARTY SOFTWARE DESCRIBED OR LINKED TO IN THIS GUIDE.
Background
An E97 Android tablet purchased from Amazon had developed some peculiar quirks. Most noticeable was that the browser app always opened a website at gotoamazing.com rather than the home page set in the app's preferences (known as browser 'hijacking'). Can we use the knowledge from this wikibook to understand how this unwanted behavior occurs and also remove unwanted pre-installed apps from the device?
Tools used
While it is possible to use the Android developer tools installed on a remote USB-connected machine, this guide uses only system tools on the tablet. The following apps were installed -
- Malwarebytes - A free vulnerability and malware tool.
- Terminal emulator - A simple terminal window that gives us shell access on the tablet.
- KingRoot - A tool that uses known exploits in the linux kernel to gain root access.
Installing any app can potentially allow arbitrary code to be executed if it is able to break out of the Android security model. Of the apps mentioned above, KingRoot is the most extreme example because it exploits system vulnerabilities to gain root access for our purposes. However in doing so, it could also Of these, KingRoot is the most questionable tool to install - we are trusting it not to install any of its own malware. A potentially safer alternative is to use https://github.com/android-rooting-tools/
Overview of terminal
The most useful commands are su grep mount
and Android's package manager tool, pm
.
- grep -s abc * / (search for
abc
in current directory and immediate sub directories) - su ( aka "switch user" become root - requires a rooted device)
- mount -o rw,remount /system (allow /system partition to be writeable)
- pm disable (aka 'package manager' disable an Android app package)
Overview of filesystem layout
On this specific tablet that runs Android 4.4.2, pre-installed apps are unmodifiable and are located in
/system/app/
/system/priv-app/
and preferences and app-data are stored in the /data
partition
Each app is typically packaged inside an apk file, which is essentially a zip file. When an app is installed the code is expanded into a file that can be directly parsed by the Android virtual machine. The binary code (at least for this particular virtual machine) has an odex extension.
We can search the code of the installed system apps for the string 'gotoamazing'
grep -s gotoamazing /system/app/* /system/priv-app/*
This didn't find anything; it appears this string was not hardcoded into the source code of the given system apps. To verify that we can find
Let's check the data area of all installed apps
cd /data/data
grep -s gotoamazing * */* */*/*
produced the following
data/com.android.browser/shared_prefs/xbservice.xml: <string name="URL">http://www.gotoamazing...
The -s option "silent option" stops grep from complaining about trying to grep directories and other invalid files. Note we could have also used -r to recursively search directories but it was fun to use file globbing (wildcard expansion of the * by the shell).
Now we are getting somewhere! It looks like this string is part of the app 'com.android.browser' but let's also find out which app binary code opens the 'xbservice' preference. Perhaps this unwanted service is hiding inside another app and managed to secretly load as an extension to the browser?
Let's look for any file that contains xbservice. This time we will recursively search in the directories of /system that include the 'app'
grep -r -s xbservice /system/*app*
Binary file /system/app/Browser.odex matches
Finally - it appears the factory browser was shipped with the the home page hijacking pre-installed. Let's uninstall it. For this, let's become root.
` $ su
pm list packages -s
` Android's package manager has many commands and options. The above example lists all currently installed system apps. We can uninstall the browser app using the following command
pm disable com.android.browser
pm uninstall com.android.browser
Using pm list packages
you can list all installed packages (use -s
options to see just system packages). We disabled the following system apps. Of course there is no real guarantee that we successfully removed all unwanted software, or that one of these is a false-positive. As such we would not recommend keeping sensitive information on such a tablet.
- com.android.browser
- com.adups.fota.sysoper
- elink.com
- com.google.android.apps.cloudprint
- com.mediatek.CrashService
- com.get.googleApps
- com.adups.fota (an over-the-air package that can install arbitrary items in the future).
- com.mediatek.appguide.plugin
It is likely that you could just re-enable a package using pm enable package-name
or pm install
and the relevant .apk file in /system/app or /system/priv-app