![](bg6.png)
Thus, AVP treats TaintDroid as its own virtualization
technology (similar to Google emulator except it sup-
ports the taintdroid data collection process and instru-
ments the start mechanism in a different way).
Other pieces of data are always collected by AVP;
this information serves mainly as debug information.
More specifically, the logcat
14
stream and system logs
from the scenario execution (executed actions and is-
sued commands) are collected.
In the future we plan to integrate new data collec-
tion capabilities to AVP. In particular, by adding sup-
port for tools similar to TaintDroid (see Section 7).
5 USING AVP
As shown in Figure 1, the user interacts with AVP at
two moments. Initially, the user must create an XML
scenario describing an experiment (see Section 5.1);
this is the input to AVP. Then, after the experiment
has been executed, the user can visualize the data col-
lected (see Section 5.2).
5.1 Scenario
A scenario is made of two sections: devices and ac-
tions. The first section specifies which Android de-
vices will be used in the experiment. For each device,
the user must provide an ID, the underlying technol-
ogy and the device name. The ID is used through
the scenario to identify this device. The technology
refers to the virtualization technology used to power
the device (e.g., taintdroid meaning the Google emu-
lator with the TaintDroid images is used). Finally, the
name refers to the AVD filename on the host.
The second section is the sequential list of actions.
All actions are non-blocking (that is AVP will go to
the next action right after having issued the command
to execute the specified action) with the exception of
wait actions.
For instance, let’s consider an experiment for the
behavioral analysis of an application. Such an experi-
ment can be specified with 3 stages of actions: setup,
start collecting information, application execution.
In the setup phase, the lab will poweron (Star-
tAVD) the necessary AVDs. We can suppose only one
AVD "A" to host the appliction. In order to maintain
this AVD clean, we could use the option to boot from
an existing snapshot but not persist the changes, hence
leaving the snapshot unmodified after the experiment.
After waiting for device "A" to boot (WaitForAVD-
Boot), the unlock command is issued (UnlockAVD).
14
The Android logging system:
http://developer.android.com/tools/help/logcat.html
Then, data collection mechanisms are activated.
Depending on what we expect to observer, we can
decide what data to collect. For instance, if we
want to observe the communication behavior of
an App, the following would be interesting: SMS
(StartRecordSMS), calls (StartRecordCalls), network
traffic (StartRecordNetworkTraffic) and tainted data
(StartRecordTaintDroid).
Now the application is ready to come in play. The
app must first be installed (InstallApp). Once the in-
stallation is over (WaitForAppInstall), the app can be
launched (StartApp). Then, we can use the Monkey
tool to perform a specified number of random actions
in the application context (StartMonkey). It would
also be possible to interact with the App in a more
precise manner (e.g., clicking on specific buttons in a
specific sequence); however, this requires a very App-
specific sequence to be specified.
Finally, it is possible, but not mandatory, to stops
the data collection mechanisms and the AVD. Upon
reaching the end of the scenario, the lab will close
each open handle in a specific way (e.g., open AVD
are turned off, data collection feeds are stopped).
5.1.1 Scenario Validation
Before the execution of an experiment begins, the sce-
nario must be validated. Validation occurs at three
different levels: syntactic, resources, and semantic.
5.1.1.1 Syntactic Validation. The syntactic vali-
dation is straightforward enough in XML. First, the
document structure is tested (e.g., is there a list of
devices before the list of actions?). Then, each ac-
tion is validated by first making sure the action exists
and then verifying that the parameters to those actions
are correct, that required parameters are present, and
that they all have meaningful values. A last syntac-
tic check is performed to make sure all the devices
referenced in the actions belong to the list of devices
defined in the scenario.
5.1.1.2 Resources Validation. Resources are val-
idated using a simple validation process that makes
sure the devices listed in the scenario exist and that
they can be used by the specified technology. The
Google emulator, Modified Google emulator, and
TaintDroid emulator can all support the same set of
QEMU-based AVDs. However, Genymotion has its
own set of VirtualBox-based AVDs. In addition, the
validation process verifies that the applications used
in the different actions exist in their given locations.
DCNET2014-InternationalConferenceonDataCommunicationNetworking
18