A robot which automatically interacts with Android app.
DroidBot sends keyevent, gestures and simulates system events in order to exploit more app states automatically. droidbot decides which actions to take based on static analysis result of app and dynamic device information (view hierarchy).
DroidBot mainly does following two things:
-
Setting up device environments, include the contacts, SMS logs, call logs, GPS mocking, etc. The target app may have access to these resources, thus we prepare them before starting the app.
Multiple env policies can be used for setting up environments. We support:
none
policy which does not set up any environment;dummy
policy which just mocks same basic environment for all apps;static
policy which set up environment according to static information of app, for example permissions and files which the app have access to;file
policy which read environment configurations from a json file.
-
Sending events during the app is running. Events includes touch, drag gestures on screen, keyevents, and simulated broadcasts, etc.
Similarly, we have several policies to produce events:
none
policy which does not send any event;monkey
policy which make use of adbmonkey
tool, to produce randomized events;random
policy which sends randomized events to devicestatic
policy produces a list of events based on static information of app. Eg. the intent-filters of each app.dynamic
policy. It is actually the real human-like policy. It monitors the device states, including the running activities, the foreground window, and the hierarchy of current window and sends events according to these information. It avoids going to same state too many times by comparing the window hierarchies, and it sends activity-specific intents based on static analysis of app.file
policy which generates events from a json file.
Moreover, to evaluate whether our bot exploit more app states, I plan to implement a
Android test coverage tool which does require repackaging or source code.
(note that Emma
can evaluate coverage with source code)
Android's traceviewer
is able to record entering and exiting of each method, and we can get a list
of all methods of app via reverse engineering. By comparing traceviewer
log and app dex, hopefully
we can get the method coverage of app. The challenge is, traceviewer
brings too much overhead, because
it records much information we don't need.
Java
version1.6+
Python
version2.7
Android SDK
, make sure thatplatform_tools
andtools
added toPATH
- (Optional)
DroidBox
version4.1.1
Clone this repo and cd to the directory.
Run:
python setup.py install
- Start an emulator (recommended) or connect to a device using adb.
- Start droidbot:
python start_droidbot.py -h
Step 1. Start droidbox emulator:
1.1 Download DroidBox image
wget https://droidbox.googlecode.com/files/DroidBox411RC.tar.gz
tar xfz DroidBox411RC.tar.gz
1.2 Create an avd named droidbox
You can either use android avd manager or use android create avd
command.
1.3 Start the avd with droidbox image
cd DroidBox411RC
sh startemu.sh droidbox
Step 2. Start droidbot:
git clone https://github.com/lynnlyc/droidbot.git
cd droidbot
python start_droidbot.py -a <sample.apk> -event dynamic -duration 100
Prepare the environment on your host by creating a folder to be shared with the DroidBot Docker container. The folder will be used to load samples to be analyzed in DroidBot, and also to store output results from DroidBot analysis.
mkdir -p ~/mobileSamples/out
Now pull the ready-made Docker container (about 1.8 GB after extraction) from Honeynet Project's hub:
docker pull honeynet/droidbot
or, if you prefer, build your own from the GitHub repo:
git clone https://github.com/lynnlyc/droidbot.git
docker build -t honeynet/droidbot droidbot
To run the analysis, copy your sample to the folder you created above, then start the container; you will find results in the "out" subfolder.
cp mySample.apk ~/mobileSamples/
docker run -it --rm -v ~/mobileSamples:/samples:ro -v ~/mobileSamples/out:/samples/out honeynet/droidbot /samples/mySample.apk
ls ~/mobileSamples/out
Droidbot is evaluated by comparing with droidbox default mode (which does nothing) and adb monkey tool. The results are in result.
Or see my visualized evaluation reports at DroidBot Posts.
- AndroidViewClient is an amazing tool simplifies test script creation providing higher level operations and the ability of obtaining the tree of Views present at any given moment on the device or emulator screen.
- Androguard is well-known for reverse-engineering of Android Apks.