Information Security Journal: A Global Perspective

ISSN: 1939-3555 (Print) 1939-3547 (Online) Journal homepage: https://www.tandfonline.com/loi/uiss20

A modular framework for mobile security analysis

Francesco Bergadano, Milena Boetti, Fabio Cogno, Valerio Costamagna,

Mario Leone & Marco Evangelisti

To cite this article: Francesco Bergadano, Milena Boetti, Fabio Cogno, Valerio Costamagna,
Mario Leone & Marco Evangelisti (2020): A modular framework for mobile security analysis,
Information Security Journal: A Global Perspective, DOI: 10.1080/19393555.2020.1741743

To link to this article: https://doi.org/10.1080/19393555.2020.1741743

Published online: 14 Apr 2020.

Submit your article to this journal

Article views: 10

View related articles

View Crossmark

data
 Full Terms & Conditions of access and use can be found at
https://www.tandfonline.com/action/journalInformation?journalCode=uiss20
2 F. BERGADANO ET AL.
widely used because many static approaches are
implemented on top of frameworks such as Soot
(Lam et al., 2011) and WALA (Dolby et al., 2015).
In fact, they provide some facilities for construct-
ing of the call-graph (Li et al., 2017) and other
features for analyzing Android bytecode, e.g.,
points-to analysis, data-flow analysis (Allen &
Cocke, 1976; Fosdick & Osterweil, 1976), control-
flow graph. However, static analysis methods have
some known limitations: they lead to over-
approximations, because all the code is analyzed,
including dead code, and it is undermined by the
use of code transformation techniques such as
obfuscation, Java Reflection, and dynamic code
updates.
On the other hand, dynamic analysis methods
execute the application in a protected environment
and inspect its interaction with the system, in
order to understand its behavior. A typical
dynamic analysis process executes the target func-
tion, monitors the flow of sensitive data and
reports the possible data leaks through method
tracers or dynamic taint analysis. An example of
a tool for pure dynamic analysis is given by
TaintDroid (Enck et al., 2014); it implements
a dynamic taint analysis in order to track how
private information is propagated during the
execution of the app. Unfortunately, dynamic
approaches also have some limitations. It is gen-
erally difficult to cause the execution of all mobile
application paths, as this amounts to a particular
case of the code coverage problem. As
a consequence, dynamic analysis tends to produce
false negatives because some malicious paths may
be missed. In particular, if we consider the execu-
tion of an Android application, it is event-based
with asynchronous and multiple entry points. It is
very hard to trigger all those events, even with
tools like Monkey (Android.com, 2019m).
The present research provides the following
contributions:
● App analysis business process
Long-term consulting experience by some of the
authors has led them to understand the main
difficulties that arise when proposing and execut-
ing a security analysis of a mobile app. Analyzing
the potential security flaws of an app is often
a difficult and time-consuming process, requiring
skilled personnel and deep insights. It should be
performed by a team of experts who are separate
and independent from the development team, it
should be repeated periodically, and for every new
release. This is the theory. In practice, this easily
results in costs that are comparable to the devel-
opment costs. This is unacceptable for the clients,
also because of time constraints (the so-called
“rush to release”), that has motivated recent ana-
lysis tools and platforms (Amin et al., 2019;
MobSF, 2019; MwrLabs, 2019b; Qark, 2019;
Zheng et al., 2017). When the approach is made
extreme and totally automated, there is a risk of
producing low quality analyses, where some vul-
nerabilities are never found, and/or too many are
found that are almost always false positives, lead-
ing developers to ignore their outcome. We pro-
pose a semi-automated approach, where our tool is
seen as a weapon in the hands of the analyst,
speeding up the process and reducing the costs.
The approach follows the OWASP Mobile Security
Testing Guide (github.com/OWASP, 2017),
a comprehensive guide for mobile application
security, that describes the technical process for
verifying the security requirements of mobile
applications.
● Integration of static and dynamic analysis
We have created a practical implementation of
a hybrid, integrated static/dynamic app analysis
approach (section 2), descending from the concept
of dynamic hooking and app instrumentation, and
based on recent previous research (see section 5). In
fact, app analysis cannot be only static because of the
high variability of dynamic behavior depending on
the real-world context, and because there is not
a linear start-to-stop flowchart of the execution,
and the app functionalities may be triggered from
external events and smartphone components (e.g.,
messages, telephone, camera, user interaction).
Dynamic analysis, on the other hand, suffers from
code coverage difficulties and app component inter-
action. Our method injects analysis components into
the apps, based on static analysis, and executes
them
at runtime (hence in the execution context.
dynamically) in order
to detect security flaws ● Partial automation
 INFORMATION SECURITY JOURNAL: A GLOBAL PERSPECTIVE 3
to make it easy for
experimentation and Our approach has the
The intent of the developers and analysts
represent a core set of purpose of partially
approach is to provide to build new test cate-
tools that are already automating the analysis
a more effective and gories and include them
available in the of mobile applications,
more automated tool in the provided frame-
framework. The in order to cover more
for the process of work. The framework
modules are discussed vulnerabilities in an all-
vetting applications, also takes care of
in detail in section 3. in-one tool. The frame-
when compared to routinary duties, such
work is based on a
other existing hybrid as establishing a
● Experimentation combination of static
approaches. This is connection to the
and dynamic analysis –
done by ana- lyzing a device, and activate the
With the present it is therefore based on
pre-determined list of services that are
framework, we have a hybrid approach. With
vulnerability classes, necessary for the test.
tested a set of 105 apps its powerful modules
that can be tailored to a The analyst developing
downloaded from the and effective interface,
particular applica- tion a new test can then
Google Play Store. it is possible to improve
context and risk concentrate on the
The corresponding the overall accuracy of
profile. The analyst purpose of the test itself
experimental results the analy- sis, increase
can rely on the tool in w.r.t. security
are reported in section code coverage, and
order to execute steps requirements.
4. These days find additional
that would otherwise individuals share vulnerabilities.
be time-consuming. ● The modules personal data more
We provide a than ever before, that
helpful graphic A major contribution of 2.1. Methodology
is, every time they use
interface that can be this research consists of : a modular and
an online service, such
used both for setting the modules, that extensible
as e-commerce, or
up the needed tests and implement fundamental framework
online banking
for producing a proof security analysis for the applications. We The intent of the
report, to be validated apps, and are integrated collected especially approach is to provide
and enhanced by the in the proposed applications belonging a tool that can be
analyst. framework. The most to categories like useful in the process of
important are shopping, finance, and vetting applications. It
● Extensible and SecureFlag, social networks. Our is based on the
modular SharedPreferences, results show that it is OWASP reports and
architecture and Clipboard. This necessary to increase guidelines for mobile
corresponds to security the awareness on cyber security. In particular,
Based on the OWASP best practices sug- security for both the approach adopts, as
classification and gested by OWASP mobile app developers a security guideline,
rating of mobile when developing and mobile users. The the OWASP report on
vulnerabilities mobile apps. The results also show that the new vulnerability
(Owasp.org, 2019), the modules were found to tools such as the statistics in the field of
fra- mework follows a be effective during the proposed framework mobile applications:
modular approach, can be effective for the latest “OWASP
where each module analyzinga large Mobile Top 10”
addresses a number of mobile (Owasp.org, 2019).
corresponding type of apps, and then isolating This covers 10 cate-
vulner- ability, vulnerabilities and gories that contain the
allowing for easier security criticalities in most common and
maintenance and a semi-automated way. most severe
exten- sibility. Every vulnerabilities. The
module can execute a classification of
2. Materials and
specific test, and the vulner- abilities into an
methods
tool is designed so as ordered list, based on
4 F. BERGADANO ET AL.
their
importance and
severity, is often based
on the analysis of
relevant context and
characteristics, e.g.,
system weakness,
attacker access, and
attacker capability
(Garg et al., 2019).
OWASP and ISO-
27001 guidelines and
standards also suggest
that vulnerabilities
should be tagged with
importance scores also
based on a risk
analysis activity, that
normally also includes
system features
(robustness,
redundancy), external
context (attacker
power) and business
impact (economic,
reputational,
compliance).
As a further support
for the analysis, we
adopted the OWASP
Mobile Security
Testing Guide (github.
com/OWASP, 2017), a
comprehensive guide
for mobile applications
security testing and
reverse engineering.
Security requirements
of applications are
instead defined as in
the OWASP Mobile
Application
Verification Standard
(Github.com/ OWASP,
2019).
The research has
mainly focused, for the
time being, on the
analysis of Android
applications, on the
areas related to Data
Storage, Network
extraction of relevant
a library into the
information from the
Communication, and to process, in order to
Android Manifest
the Android Manifest. intercept module loads
(AndroidManifest.xml).
The whole work has led and instrument the
On the other hand, the
to the development of a methods in the
approach to Dynamic
framework and a modules with
Analysis adopted in the
modular software tool. appropriate user-
framework is based on
Modular design is an defined routines
dynamic hooking, i.e., it
approach that partitions a (Schmich & Huene,
performs dynamic, in-
system into independent 2012). This is
memory software code
components with performed with the
instrumentation by
standard interfaces. In help of Frida
injecting
this specific case, each (Frida.re, 2019).
module aims at Frida is a powerful
analyzing a specific cross-platform
vulnerability. Each framework for
module contains dynamic code
everything that is instrumentation. It
necessary to execute does not require any
only one aspect of the modification of the
desired functionality. device other than
This allows the running the Frida
framework to be easily server binary. It allows
customized and to inject JavaScript
upgraded. Moreover, the code into the
modules can be reused application by using
and independently appropriate APIs
modified and extended. (Ravnas, 2019). This
Finally, it is agentless: it provides a wealth of
does not require the useful functionalities
installation of an agent like calling and
on the device, where hooking of native
tasks could be natively functions, replacing
executed. The Java method imple-
framework offers a mentations,
graphical interface, instantiating Java
where the results of the objects and enumer-
analysis are reported. ating live instances of
The interface is multi- specific classes by
platform and allows to scanning the Java
perform ana- lyses on heap.
both Android and iOS Other tools used in
devices. For iOS, only a the modules include
raw analysis has been the Android Debug
performed and more Bridge (ADB)
research will be needed. (Android.com, 2019c),
The interface is currently Fridump (Fridump,
tested for Linux and Mac 2019), an open- source
platforms. memory dumping tool,
Static Analysis was and mitmproxy (Mitm,
mainly applied to the 2019), a console tool
pat- tern-based that allows for the
 INFORMATION SECURITY JOURNAL: A GLOBAL PERSPECTIVE 5
interactive and then establishing
examination and the connection between
modification of the tool and the device.
HTTP traffic. All The controller stands
these tools allowed between the core and
us to achieve the the modules, it deals
specific aims of each with the management
individual module. of the modules, and
instanti- ates a new
WebSocket when
2.2. Design and needed. For our
implementation specific purpose, we
Figure 1 shows the used Tornado
overall architecture (Tornadoweb.org,
of the framework. It 2019),
consists of two
macro components:
a back-end and a
front-end.
The front-end is
implemented with
Flask (Pocoo. org,
2019), a micro web
framework written in
Python. The graphical
interface allows the
analyst to perform the
analyses offered by
the modules and to
inspect, in real time,
the results. Figure 2
shows the graphical
interface – in
particular, some
applications installed
on the device are
displayed. It is then
possible to per- form
a security test for
those applications.
The back-end
consists of a core, a
controller, a database
for the analysis report,
the services and the
modules. The core
component is
responsible for
recognizing new
devices, i.e., operating
system and version,
Figure 1. High-level system architecture.
Figure 2. Graphical interface.
a Python web framework, and its implementation of
the WebSocket protocol (Websocket.org, 2019).
WebSockets allow for bidirectional communication
between modules and Services, and also for intra-
module communications. Services, like Frida,
Proxy, and Fridump, allow for the collection and
delivery of dynamic data generated by a running
application. This mechanism is achieved through
Redis (Redis.io, 2019), an open-source in-memory
data structure
its main purpose is to maintain a report for the end
store, used in this context as a message queue, that
implements the publish/subscribe messaging para-
digm (Eugster et al., 2003). In this case, the
publish- ers, i.e., the senders of the messages, are
the services, while the subscriber is the WebSocket.
In this way, specific collected data can be used by
several request- ing modules. WebSocket enables
the routing of mes- sages to the correct module.
Finally, the database component is implemented
with the SQLite library –
of the analysis.
 One of the contributions of the paper is the pro-
posed framework architecture: highly modular, exten-
sible, and integrating static and dynamic analysis in
a partially atuomated tool. To turn this high-level
architecture into a real tool, a number of modules
where implemented, based on OWASP guidelines
and vulnerability listings. The modules then also con-
stitute an important contribution of this research: they
are described in the next section, while their use in an
experimental setting is analyzed in section 4.
Each module is designed in order to deal with
a specific vulnerability. It can be static, dynamic,
or a combination of both. Each module, in turn,
consists of a computing unit, a visualization unit,
a configuration unit, and, in some cases, a unit
represented by Frida’s dynamic scripts. The com-
puting unit processes data arriving from the ser-
vices or from the manifest, carrying out the actual
analysis. The view unit is responsible for showing
the results of the analysis through the graphic
interface. The two components communicate via
WebSocket and allow for real-time analysis. The
configuration unit determines the module proper-
ties and the services it uses.
The framework architecture allows other analysts
to develop additional modules and easily integrate
them in the tool, sharing the tool’s primitives,
device handling capabilities, use interface for
setting up the tesing context, and
reporting/visualization compo- nent. Since the
modules represent one main contri- bution of the
research, we will now list them and provide some
details about their functionalities.
3. The modules
The modules that have been developed up to now
mainly concern the security requirements of
Android applications and are described below.
3.1. Android backup
The “Android Backup” module checks whether the
app allows for backups. In fact, Android offers the
possibility to perform a full-system backup, when
it is configured to do so. The AndroidManifest tag
android:allowBackup allows to specify whether to
allow the application to participate in the backup
Android in three protection levels, i.e., Normal,
Signature, and Dangerous permissions (Android.
com, 2019g).
and restore infrastructure (Android.com, 2019i).
The default value of this attribute is set to true,
thereby allowing to save, via ADB, all the applica-
tion’s data and settings. However, if this attribute
is set to false no backup of the application will ever
be performed. If backup is allowed, the module
will try to execute the function through the
“Android Debug Bridge” (ADB).
This module aims at verifying the value of the tag
android:allowBackup by inspecting the
AndroidManifest of the tested application. If the
value is set to true, it tries to execute the backup
through ADB. The backup may cause the leak of
sensitive data stored by the app. The analyst remains
responsible for inspecting the backup and analyze it
in order to find any kind of sensitive information.
According to OWASP, no sensitive data should
be present in backups generated by the mobile
operating system.
3.2. Android debug
The “Android debug” module checks whether an
app allows for debugging by inspecting the
Android Manifest’s tag android:debuggable. If set
to true, it allows to attach a debugger to an appli-
cation even when running on a device in user
mode (Android.com, 2019k). Otherwise, debug-
ging is not allowed.
The default value is false and in a release build
this value must be set to false. This module aims at
verifying the value of this tag by inspecting the
AndroidManifest, the result is presented to the
analyst through the user interface.
3.3. APK manifest
The module “APK manifest” checks for permis-
sions that are declared in the Android Manifest,
categorizing them as high (i.e., critical), medium
or good (In compliance with the Android best
practices). Moreover, it checks if the app performs
HTTP/S requests without having the Internet
permission.
Because each Android app operates in a sandbox,
apps must explicitly request access to resources and
data outside their sandbox. They request this access
by declaring the permission they need in the
AndroidManifest. Permissions are classified by
From a security point of view, the application
should be able to access only the information and
resources that are necessary for its purpose (i.e., the
principle of least privilege). Therefore, it should be
checked if permissions are really needed within the
app, and removed from the Manifest otherwise. The
aim of this module is to check what permissions are
declared in the Android Manifest, categorizing them
as High (i.e., critical), Medium or Good. More in
detail, Good permissions are those with very little
risk for the user’s privacy or for the operations of
other apps (e.g., SET_ALARM, SET_WALLPAPER,
ACCESS_NETWORK_STATE, etc.). High and
Medium permission are those that involve the
user’s private information or could potentially affect
the user’s stored data or the operations of other apps
(e.g., READ_CONTACTS, RECORD_AUDIO,
CAMERA, CALL_PHONE, etc.). The
ACCESS_MOCK_LOCATION permission is consid-
ered as a High risk permission, because the app is
allowed to override the location and/or status
returned by other location sources such as GPS or
location providers. Malicious applications can
exploit this permission.
3.4. Exported component
The “Exported Component” module checks
which app components are declared as exported
(when this tag is set to true the component is
public, and therefore accessible by other apps).
For each affected component the action declared
in the intent-filter is also reported. All the
results are displayed to the analyst, but further
analysis will be necessary in order to detect if
they actually leak any sensitive data when used.
The AndroidManifest also describes the compo-
nents of the application (i.e., activity, services,
broadcast receiver, and content provider) that
compose the application. Each component can be
public or private, and the exported attribute, in
each component’s declaration, determines this sta-
tus. If this functionality is not properly configured,
it can be exploited by malicious users, and thus it
may leak sensitive data (Chin et al., 2011).
Android versions from 5.0 to 7.1.2 are unable to
detect a partially obscured system pop-up. This
3.5. Root detection
The “Root detection” module statically checks if
the application implements common root detec-
tion techniques. The goal of this kind of techni-
ques should be to make it a bit more difficult to
run the application on a rooted device. However,
typically, for a better user experience, they are
limited to a static verification which does not
hinder any operation or functionality of the
application. For this reason, this module inspects
if the application implements a file existence
check for files typically found on rooted devices,
such as package files of common rooting apps
and associated files. In fact, on a rooted phone,
reverse engineering techniques can be applied
more easily. The evidence is displayed to the
analyst; obviously, it is still necessary to verify
dynamically whether such techniques actually
block the execution of the entire application.
3.6. Secure flag
The “Secure Flag” module checks if the application
instructs the operating system to prevent screen
captures. Developers often want to provide device
users a pleasant user experience, and this is why
the Auto-Generated Screenshot feature was intro-
duced and is used when the application is placed
in the background.
From a security point of view, this feature
may introduce a security risk. Moreover, sensi-
tive data can also be exposed if users deliberately
take a screen capture of the application while
sensitive data are displayed. In this context,
a study published by MWRLabs is significant
(Menezes, 2019). With the introduction of the
MediaProjection service in Android 5.0, it is
possible for a developer to capture screen con-
tents without root privileges or without the
requirement to sign the applications with the
device’s release keys. To use these services an
application can simply request the access via an
Intent, and a SystemUI pop-up is displayed to
the user to warn that an application would like
to capture the screen. Unfortunately in this way,
an attacker could overlay this System pop-up
and display an arbitrary message to deceive the
user and gain the permission. This is because the
vulnerability has been addressed in Android 8.0, but
it is not addressed in previous versions.
 Android allows to treat the content of
a Window as secure, i.e., preventing it from
appearing in screenshots, by means of the
FLAG_SECURE flag of the class android.view.
WindowManager.LayoutParams (Android.com,
2019b). Our module aims to check if this kind of
flag is set in the application’s view, and its beha-
vior is represented in Figure 3.
The goal is achieved through the development of
two of Frida’s dynamic scripts. The first hook lists all
registered activities from the Android
PackageManager (Android.com, 2019f) and, for
each of them, it traces the onResume method of the
Activity Life Cycle (Android.com, 2019a) (step 1 in
Figure 3). The second hook checks if the
FLAG_SECURE flag is set for the current Activity,
i.e., the Activity running in foreground. In this way,
to check the views of the application, the analyst
must merely browse the app. The first hook, always
active, becomes aware when a new activity is present
in foreground. At that moment, the second script is
attached, the flag checked, and the screen is captured
through the ADB shell command, subsequently,
the second script is detached.
Figure 3. Behavior of the SecureFlag module.
were deprecated in the API level 17. The
MODE_PRIVATE is the default mode; the created
object can only be accessed by the application.
OWASP suggests to avoid Shared Preferences for
3.7. SharedPreferences
The “SharedPreferences” module inspects the
SharedPreferences files, intercepted at runtime, to
check if sensitive data in plain-text are present. Best
practices suggest that a small amount of sensitive
data should be saved permanently on local storage,
even if in some cases storing data is necessary for
many mobile applications. Some applications, for
example, use local storage to save user settings or
user-provided data. Sensitive data stored within the
application must be protected; otherwise, an attacker
can steal and use the information for additional
attacks. There are several ways to store information
on Android devices, e.g., Shared Preferences,
SQLite Databases, Internal and External Storage
(github. com/OWASP, 2017).
In this module, the analysis is focused on the
Shared Preferences that are commonly used to store
private data in the form of key-value pairs. Data
stored in this kind of object are written in an XML
file. The Android security guideline, concerning
storage options (Android.com, 2019h), suggests to
avoid the MODE_WORLD_WRITEABLE or
MODE_WORLD_READABLE modes when
a SharedPreferences object is declared because
they can cause security holes in applications. They
allow all other applications to have write access and
read access to the created object. These constants
storing sensitive data, because, by default, they are
insecure and unencrypted. All of these security
concerns are checked by the module, with the help
of dynamic analysis and the implementation of a
Frida script.
First of all, with this script the module is able to
scan the process memory, in order to find Shared
Preferences objects, and retrieve their names and
their mode (i.e., the name of the.xml file and the
file creation mode). This functionality is achieved
through the Frida API Java.choose, that enumer-
ates live instances of the Android class
SharedPreferencesImpl.java.
Listing 1: Excerpt of code of the script
All the results are reported to the analyst, who can
search for sensitive information such as e-mail
addresses, credit-card numbers, phone numbers
and passwords.
The second part of the script allows to dynami-
cally intercept, during application execution, if sen-
sitive information is written, in clear text, in the
Shared Preferences files. To this end, our script
starts by intercepting calls to the function open of
the standard C library libc.so (see Listing 1). This is
performed through the Frida API Interceptor. More
in detail, only the calls to the function open on
Shared Preferences files are intercepted and, for
each of them, the path name and also the return
value (i.e., the file descriptor) are stored. In parallel,
calls to the function write, also in the C library, are
intercepted and, with the aforementioned file
descriptor, it is possible to filter only the calls of
interest. Then, it is possible to retrieve data written
by the function. When a file is closed, the call to
the close function, of the C library, is intercepted,
too.
3.8. SQLite
The “SQLite” module traces the main operations
performed by the application on SQLite Databases.
The main package used to manage this database is
android.database.sqlite. An SQLite database is just
a file, stored by Android in clear text, in the/data/
data/packagename/databases directory. In this con-
text, according to OWASP, sensitive data should
not be stored in unencrypted SQLite databases, or
with- out encrypting the sensitive data. Furthermore,
Android provides a series of best practices related
to the operations exposed for the management of an
SQLite Database.
The aim of the module is to inspect whether
sensitive data are stored in clear text within the
Application Database, and to verify if the methods
are used in compliance with the Android best
Listing 2 Excerpt of code of the script
3.9. Clipboard
The “Clipboard” module inspects what clipboard
functionalities (i.e., copy and paste) are available
in each text field of the application. When users
practices on database management. For example,
When manipulating a content provider it is better
to use query methods with parameters, in order to
avoid SQL injection attacks.
This is achieved with the implementation of
a Frida dynamic script. The script is attached
when the module starts. It is able to trace the
operations related to the opening of Databases, in
order to retrieve useful information such as the
name of the Database, and the mode (i.e., the
operating mode like MODE_PRIVATE), remem-
bering that modes like
MODE_WORLD
_READABLE and MODE_WORLD_WRITEABLE
are to be avoided. The script is also able to trace
the principal operation performed by the applica-
tion on the Database (e.g., insert, update, query
and delete). All the useful information such as the
inserted values, updated values, and the result set
returned by a database query is retrieved. This
allows the analyst to evaluate the operation in
terms of compliance and to verify if sensitive
information are present in clear text within the
Databases (see Listing 2).
type in text fields, on a mobile device, they are able
to use the Clipboard’s functionalities (e.g., copy and
paste). Android provides a powerful Clipboard
framework for these features (Android.com, 2019j),
and it supports both simple and complex data types.
In this case the most important aspects are that
copying and pasting work both within single
application and between different applica- tions,
and that they hold only one clip object at
time.
However, this also means that the Clipboard is
public and accessible to all the running processes
without the need of any special permission or
interaction with the user. From a security point
of view this globally accessible nature can intro-
duce risks (Zhang & Du, 2014).
The module aims at inspecting which clipboard
functionalities are available in each text field of the
application. This is because, as suggested by
OWASP, the clipboard functionalities should be
disabled for text fields that process private
information.
To achieve this purpose the module is quite
complex. Four of Frida’s dynamic scripts have
been implemented, and their behavior is repre-
sented in Figure 4.
Figure 4. Behavior of the clipboard module.
must simply touch the field. At this point of the
First of all, to test the Clipboard’s functionality
for a text field it is necessary that some data, or,
more precisely, a clip object is already present in
a the Clipboard. Since one of the main aims of the
present framework is automation, it is necessary
that this operation is done by the module itself at
its start. This is exactly the purpose of the first
script. The script deals with inserting an alphanu-
meric text string into the Clipboard (step 1,
Figure 4). At the end of this operation it sends
a message to the computing unit of the module to
indicate the achievement of the operation, this
hook is released, and a second script is attached
(its use will be explained later). At this point the
third and fourth scripts come into play. The aim of
the third script is, in fact, to retrieve the coordi-
nates of the touched text field. More precisely, the
script returns the original raw X and Y coordinates
of the touch event on the screen (step 3, Figure 4).
This is done through the methods getRawX and
getRawY of the Java Android class MotionEvent
(Android.com, 2019l). These coordinates are
returned only if the touch event is performed on
an object of the class EditText (Android.com,
2019d). If a name has been associated, by the
developer, to this text field, it is also retrieved.
Then, the aim of the third script is to trace the
methods CanPaste and CanCopy of the Java
Android Class TextView (Android.com, 2019e).
The analyst, in order to know which clipboard’s
functionalities are available on a specific text field
execution the third script is already attached, and it
is able to retrieve the coordinates of the text fields.
When a text field is touched to be tested, the
coordinates are sent to the computing unit. At this
point, with the ADB command input text
00
alphanumericstring 00 , an alphanumeric string is
written in the text field (step 4, Figure 4), and
the second script is temporarily released, while
the fourth script is attached. These coordinates
are processed through ADB, with the command
line (step 6, Figure 4):
hx1ihy1ihx2ihy21i ½duration in ms]
where x1 ¼¼ x2, and y1 ¼¼ y2. This will
simulate a swipe, but since the starting point and
the end point are the same, it will act as a long
press event. During this event, the fourth script is
able to capture the information that it needs and
then it is released (step 5, Figure 4). The control
switches again to the computing unit, where all the
necessary information for the tested text fields is
present, and a screen capture is performed.
The module is able to test text fields present
within the activities. Conversely, it is not able to
test the text fields present in the WebView (i.e.,
a view that displays web pages). A WebView
allows to display web pages as part of activity
layout. The behavior of the view is therefore con-
trolled by the web page and no longer by the
Android Activity.
The results are reported to the analyst in the
graphical interface. For all the tested text fields the
analyst can see: the name of the field (if assigned
by the developers), which Clipboard’s functionality
is available (i.e., copy, paste and cut), and the
screen capture of the view. It is important to
point out that, when the content of the view is
treated as secure, the module uses the second of
the above described Frida scripts to clear the flag
FLAG_SECURE, and then captures the screen.
3.10. Fridump
The module “Fridump” allow the analyst to dump
and analyze the memory used by the application. In
fact, Android Applications need memory and
resources to be executed. The Android system
As the aim of the framework is also to automate the
operations, these steps are carried out through the
implementation of three of Frida’s dynamic scripts.
needs to manage memory allocation efficiently.
Analyzing memory is important for identifying pro-
blems such as application crashes or memory leaks.
Sensitive assets have normally loaded into mem-
ory at some point, but this information should be
exposed just for the time needed. Therefore, the
aim of this module is to check memory for sensi-
tive data and to get statistics related to exposure
timing. The module, in order to investigate the
application’s memory, executes a memory dump.
This is achieved through Fridump. The tool exe-
cutes the dump of accessible memory addresses.
More precisely, the module performs two memory
dumps, at arbitrarily fixed time intervals.
A differential analysis is performed on the two
generated dumps. Trough the graphic interface,
the analyst can search, by regular expressions, for
sensitive or target data.
3.11. Session timeout
The module “Session Timeout” checks if the session
is invalidated after a predefined period of inactivity
and if access tokens expire. In fact, any application
should implement an inactivity timeout for sessions.
This defines the amount of time in which the
session remains active in case of no activity by the
user. This timeout should be a fair trade-off between
a security point of view (i.e., a shorter timeout) and
usability (i.e., a longer timeout). Obviously it also
depends on the kind of data maintained by the
application, if it is sensitive or not (e.g., as in the
case of the data handled by a banking application).
The module checks if the session is invalidated
after an arbitrary period of inactivity by starting an
arbitrary activity at different time intervals and
checking whether a timeout exists. The macro-
steps performed by the module, with the interac-
tion of the user, in order to verify the session
timeout are therefore as follows:
(1) the module starts the application to be
tested,
(2) the module performs some operations that
require authentication by the user,
(3) the module keeps the phone inactive for
a certain amount of time;
(4) the module tries to perform some of the
previous operations
The first hook retrieves and sends all the registered
activities from the Android PackageManager to the
computing unit of the module. The second hook
retrieves the name of the current Activity (i.e., the
authority or if it has been signed with a trusted
activity running in foreground). Finally, the third
certificate. Unfortunately, they may be vulnerable
hook takes care of starting an Activity through an
to man-in-the-middle attacks, as presented in
Intent.
(Sounthiraraj et al., 2014); in this case, in fact,
To the test session timeout, the analyst must
a third unauthorized party is able to intercept the
simply start the test on an Application and per-
communication between clients and servers. The
form some operations that require authentica-
Certificate Pinning process is useful against this
tion. During this time the information about all
type of attack.
the registered activities are collected by the first
Certificate pinning is the process of associating
hook, which is then released. Through the gra-
the back-end server with a particular X.509 certi-
phical interface the analyst can select which
ficate or a public key, instead of accepting any
activity to start, the number of iterations and
trusted certificate. Once a certificate or a public
the time interval between each iteration (e.g., by
key is known for a host, it is associated or
starting an activity after 5 minutes, then after
“pinned” to the host. This practice can reduce
10 minutes, and so on). Clearly, through the
the attack surface.
graphical interface, the analyst can change all
Dynamic analysis is used by the module in order
the parameters necessary to the purpose of the
to verify if certificate pinning is correctly
test. When an Activity has been selected for the
implemen- ted by the application. More in detail,
test, it can be started. The analyst must simply
dynamic ana- lysis is performed by launching a
leave the application under test idle. After the
MITM (man-in- the-middle) attack. This is
time set by the analyst, the module starts the
implemented with mitm- proxy. In this way, the
activity through the second script, which is then
module is able to intercept the traffic between the
released. At this point the third hook is injected,
application and the backend ser- ver, as shown in
it retrieves the information about the name of
Figure 5.
the current activity; this verifies if the current
To perform the analysis it is necessary to install
activity is actually the one previously started.
inside the device, among the system Certificate
Authorities, the CA generated by the proxy (i.e.,
3.12. Pinning the mitmproxy CA certificate). Through this
approach, the mitm-proxy is able to decrypt the
The module “Pinning” checks if the application
communications that are not protected by certificate
associates the backend server with a particular
pinning (step 8, in Figure 5). Otherwise, handshake
X.509 certificate or public key, instead of
failure is intercepted (step 7a, in Figure 5).
accepting any certificate signed by a trusted
When the application to be tested is started, the
certificate authority. The protocols used to make
proxy starts to collect data. Each new http request
communi- cations secure above the transport layer
is processed, and the domain is extracted. This
are typi- cally SSL or TLS. This type of protocols
infor- mation is reported to the visualization unit.
uses digital certificates to make the communication
All the intercepted domains are reported in the
channel authenticated and encrypted. It is in the
graphical interface.
hand- shake phase that client and server exchange
the certificates and all the information necessary
(e.g, encryption algorithm, keys). A certificate is 3.13. HTTPS traffic
con- sidered reliable if it is digitally signed by a
The “HTTPS Traffic” module checks if the appli-
root certificate belonging to a trusted
cation performs data encryption over HTTPS and
certificate
if it does not implement certificate pinning. This
module is closely related to the previous one,
because its purpose is to analyze the communica-
tions between the application and the server. This
is because the HTTPS protocol is vulnerable to
a number of dangerous attacks, including man-in-
the-middle attacks. Therefore, a good best practice
Figure 5. Behavior of the mitmproxy.
is to perform data encryption over HTTPS, when
certificate pinning is not implemented.
To achieve this purpose the module analyzes the
header and the body of HTTP requests. This is
achieved by launching an MITM attack with the
mitmproxy, as show in Figure 5. More in detail,
the analysis of the header allows to verify that
cryptographic techniques considered to be vulner-
able (e.g., SSL v2 and v3) have not been used.
Moreover, the analysis of the body allows to eval-
uate if sensitive data are present in clear text
within the HTTP requests.
To perform the test, the analyst must start the
application and navigate it. In this way the proxy
starts to collect data. Each new http request is
processed, and the domain is extracted. At this
point, if the application does not implement certi-
ficate pinning for that domain, the mitmproxy is
able to analyze the header and the body.
Otherwise, a possible solution to overcome the
problem could be to introduce a Frida script to
bypass the pinning. Obviously further tests and
refinements are needed.
4. Results and evaluation
In this section we present the experimentation work
done until now, that has led to some interesting
All the information collected by the proxy is
forwarded and processed by the computing and
visualization unit. Through the graphic interface
the analyst can inspect each intercepted domain,
and search for sensitive data inside the http
request through regular expressions or keywords.
3.14. Logcat
The “Logcat” module examines the application
logs to determine whether sensitive information
is present. Log files are created on a mobile device
for debug purposes and then disabled when the
application is released on the store. From
a security point of view, it is important to avoid
logging sensitive data. This is because such data
may be exposed to malicious applications. The
analysis is performed with ADB Logcat. The out-
put is very verbose. As a consequence logs are
filtered by the application, with the Unix com-
mand grep, and included in the output reports
through the graphical interface.
results. In particular, we provide the results obtained
from the following modules: Android Backup, Root
Detection, Secure Flag, SharedPreferences, SQLite,
Clipboard.
 In the experimentation process, two rooted
phones have been used. A OnePlus 3 T with
Android 7.1.2 and a Google Nexus 5X with the
same Android version. Frida’s version 10.6.3 was
used in this experimentation. The experiments
were carried out using a set of 105 apps, and the
method for selecting those apps is detailed below.
4.1. App selection method
The approach followed in this paper aims at
a combination of dynamic and static analysis and
has a goal of partial automation. This means that
for each app that has been selected, a significant
amount of manual inspection is still necessary. As
a consequence, we decided to select a good num-
ber of apps (more than a hundred), that could not
have been inspected by purely manual methods
with reasonable time and budget limitations. Yet,
we could not target thousands of apps, as it would
be necessary for a totally automated tools. We
believe that this “ in medio stat virtus” approach
is very adequate for app evaluation, were clients
cannot afford to spend as much effort in security
analysis as they have for the development phase.
Yet, totally automatic evaluation fails to capture
many vulnerabilities and/or generates a high per-
centage of vulnerabilities that are false positive or
cannot truly be exploited. The app selection
method was based on the following steps:
● we collected the apps from the Google Play
Store, for the Italian country;
● we identified applications contexts that would
be relevant w.r.t. user privacy, like travel and
shopping, and security-critical actions, like
payments, as well as applications with a high
degree of interaction among users, like social
networks;
● based on the previous analysis, we focused on
the following app categories: Shopping,
Finance & Bank, Cryptocurrency, Social,
Travel, and Communications;
● for each such category we selected the most
popular apps suggested by the Google Play
Store;
● since many apps in the Finance & Bank cate-
gory require the opening of real banking
accounts to be used and then tested, we
were forced to exclude such apps, and replace
them with others that did not cause this lim-
itations, by scrolling down in the popularity-
ordered list of apps in the corresponding
category;
● similarly, some apps had to be removed from
the set, and substituted by others in that same
category, because they were protected against
dynamic hooking (a key component of our
approach), and consequently they could not
be tested using our tool. This happened in
a very limited number of cases, and this
should also be considered and interesting by-
product of out experimentation, because one
could claim that this type of protection
should actually be adopted by a large majority
of apps, so as to avoid third-party analysis,
reverse engineering, and other actions rele-
vant for integrity and security.
We believe that the set of apps resulting from the
above selection process is highly representative
and constitutes a good test-bed for security-
oriented testing.
4.2. Evaluation
For each module that was tested, we now show the
main results obtained. Consider that a total num-
ber of 105 applications were tested, but some of
them (a small portion) protected themselves by
preventing their reverse compilation and/or
dynamic hooking. Therefore, the tests failed to
produce results in these cases.
4.2.1. Root detection
The results for the root detection module are
shown in the left hand side of Figure 6. We
found that 93% of the tested apps implements
Figure 6. Results obtained by the root detection and by the secure flag modules.

a control for root detection. However, this is not as
positive as one might think. We found, through
the subsequent dynamic analysis, that only two
applications really prevented their usage with
rooted devices. In this specific case, the application
interrupted its execution. Most applications
choose to make this kind of control without
a real impact on usability for the end user. The
presence of the root can allow untrusted security
decisions to be made, and thus increase the num-
ber of possible attack vectors. This evidence is
particularly important when considering the appli-
cations that belong to the Finance & Bank cate-
gory. This kind of category, in which apps hold
particularly sensitive data, should be more restric-
tive with respect to this kind of control.
4.2.2. Backup
For the Backup Module, a first analysis on the
whole set of tested applications shows that 49%
of them allow to participate in the backup and
restore infrastructure, while the residual 51%
does not provide these features. Unfortunately,
like many other useful functionalities, this kind
of automatic backup is not free from security
concerns. Figure 7 shows the results obtained by
the module, divided by category. The categories
which are most affected by this vulnerability

Figure 7. Results obtained by the backup module, split by categories.

Figure 8. Results obtained by the SecureFlag module: highlights on some categories.
appear to be Shopping Online and Cryptocurrency.
As a consequence, an important recommendation
in order to maintain the security and privacy of
user data is to disable the backup functionality.
This is particularly important for those applica-
tions that handle sensitive information, such as
payment details. On the other hand, positive
results are found for the categories Finance &
Bank and E-Mail & Work.
4.2.3. SecureFlag
The most alarming results are given by the
SecureFlag Module. As it can be seen in the right-
hand side of Figure 6, 94% of the tested
applications treat Windows content as secure
and do not prevent it from appearing in screen-
shots; only 6% of them follow this important
Figure 9. Results obtained by the SharedPreferences and SQLite modules.
4.2.4. SharedPreferences
The results obtained for the SharedPreferences
recommendation. This means that most applica-
tions are vulnerable to the screen capture via UI
overlays, as investigated by MWRLabs (Menezes,
2019).
Figure 8 highlights the app categories which
compose the 6% of insecure applications. Among
the analyzed applications only the Finance & Bank
category seems to be sensitive to the described
vulnerability. Nevertheless, the result cannot be
considered fully positive. Indeed, more than half
of the visited views are not treated as secure (47%
secure, against 53% not secure). Therefore, this
kind of applications may reveal information like
user accounts and financial transactions. More
generally, the results show that the most exposed
data are sign-in and sign-up information, payment
details, and other personal information.
module, represented in the left-hand side of Figure
9, show that 53% of the tested applications expose
sensitive data, in clear text, inside XML files. The
residual 47% of cases is aware of the issue.
Further analysis allowed to highlight that there
are no categories of applications fully aware of the
issue, and none completely unaware of the vulner-
ability. It is therefore important to raise awareness
among the developers.
4.2.5. SQLite
The results obtained for the SQLite Module are
represented in the right-hand side of Figure 9.
SQLite Databases are a widely used tool on the
Android platform to store data on persistent local
storage. However, sensitive information should
not be stored in unencrypted Databases, or in
clear text. Information stored in clear text could
potentially be read by an attacker. Despite this, the
results show that 25% of the tested applications
expose sensitive data, in clear text, inside SQLite
Databases. It is important to note that, once the
device is rooted, databases become highly exposed.
It can be easier to download databases on a rooted
phone. Moreover, when sensitive data are used
within queries that are submitted to an SQL data-
base, SQL injection may be an issue. Developers
must use parameterized queries. Tests on this
module have also allowed to find out that, fortu-
nately, only two captured queries were vulnerable
to SQL Injection.
4.2.6. Clipboard
During the evaluation phase of this Module, the
text fields of each application which have been
taken into consideration, are those that handle
sensitive information (e.g., e-mail or username
for sign-in and sign-up, password, and all the
text fields related to payment methods). These
features are especially critical in mobile phishing
attacks (Shahriar et al., 2019). An important coun-
termeasure consists of disabling the clipboard
functionality. Other anti-phishing methodologies
include IP and SMS traffic analysis, two factor
and strong user authentication, ad-hoc static ana-
lysis, and message classification. However, all
such
measures are preventive, and cannot guarantee
that a phishing message will not actually be acti-
vated. When this happens, device hardening and
the disabling of the clipboard functionality are
essential.
Unfortunately, the results confirmed that the
copy function is always present. This is definitely
a choice related to usability. However, security and
usability are not compatible in this case. Therefore,
we considered the most vulnerable text fields, and
for this reason, we focused on the results concern-
ing the following fields: password sign-in, card
Number, CVV and expire data. These results are
represented in Figure 10. All the cases where it was
not possible to test the text field, because of its
implementation in a Web View, are represented
with “NT” (Not Testable). All the cases where it
was not possible to test the text field, because it
was not present, are represented with the “Field
Missing” value. As noted, in all the represented
cases there is no attention to vulnerabilities related
to the clipboard. Furthermore, in the last few
years, the implementation of password visibility
toggles (i.e., the “show password” features) has
become increasingly popular, not only in mobile
applications but also in web applications. The
main security problem in this context is that,
once toggled, the password field changes from
having an attribute type password to text. If the
input type is password users are not allowed to
copy the value inside the clipboard. Otherwise,
all the clipboard functionalities are available.
It is therefore necessary to raise the security
awareness of developers, but also of users, and to
manage conflicts between usability and security in
order to find a suitable trade-off.
5. Comparison with related work
In this section, we first present related works that
offer techniques for analyzing mobile applications,
then we move to a more detailed discussion of the
approaches that provide a unified analysis frame-
work similar to the one described in the present
paper. We classified them according to the type of
analysis they provide, and we identified three main
categories: static, dynamic, and hybrid analysis. In
fact, most of the security tools provide a static-only
Figure 10. Results obtained by the clipboard module on a subset of the analyzed fields.
analysis or they add a dynamic analysis module
driven by the findings of the static engine.
5.1. Static analysis
The security research community proposed several
static analysis frameworks, especially for Android:
DroidSafe (Gordon et al., 2015), FlowDroid (Arzt
et al., 2014), AndroidLeaks (Gibler et al., 2012),
CHEX (Lu et al., 2012), IccTa (Li et al., 2015) and
IC3 (Octeau et al., 2016), just to mention a few of
them, and some for iOS, such as (Egele et al., 2011).
They differ in terms of the adopted techniques and of
the granularity of the analysis, e.g., control-flow,
data- flow and points-to analysis. Yet, SAAF
(Static Analysis Android Framework) (Hoffmann et
al., 2013), proposed by Hoffman et al., provides
program slicing on smali code. Taint analysis, a kind
of data- flow analysis, is frequently used.
Most of the published tools aim to address
generic threats for mobile applications (i.e., taint-
style vul- nerabilities) or provide frameworks that
ease the process of reverse engineering. In this
category
belong two of the most well-known tools, JAADAS
(JAADAS, 2019) and Androguard (Github.com/
androguard, 2011), as well as apk-tool (Apktool,
2019). The former aims to provide a soot-based
framework for inter-procedural analysis, with the
purpose of finding taint-style vulnerabilities, while
the latter offers a comprehensive framework for
Android application reverse engineering. The main
difficulties in this area often arise from code obfus-
cation techniques used by the app developers (Bacci
et al., 2018). In this work, the authors show that
malware detection systems based on static analysis
are more accurate than dynamic approaches on
non- obfuscated samples, but are negatively
affected by obfuscation to a greater degree. In
another reverse engineering approach, the
SmaliSCA framework
(https://github.com/dorneanu/smalisca) has been
proposed, that provides a set of tools that help in
visualizing and managing the call flow and the
inter- action patterns of the application being
analyzed.
As for static methodologies that are more
relevant in the present context, we identified the
following published tools, that provide a
comprehensive
analysis of mobile application via leveraging only achieve dynamic
on static analysis approaches.

● RiskInDroid (Merlo & Georgiu, 2017),

proposed by Merlo et al., is a tool for
quantitative risk analysis of Android
applications that applies Machine Learning
techniques in order to gener- ate a threat risk
evaluation for the application. It takes into
consideration not only the permis- sions
declared in the application manifest but also
carries out reverse engineering on the apps to
retrieve the bytecode. It then infers (through
static analysis) which permissions are actually
used and which are not.
● The AndroBugs Framework (Lin, 2015) is an
Android vulnerability analysis system that
helps developers (or hackers) find potential
security vulnerabilities in Android
applications.
● QARK (Quick Android Review Kit) (Qark,
2019) aims to look for several security-related
Android application vulnerabilities, either in
source code or in packaged APKs. Even if the
tool offers a dynamic feature for testing the
identified vulnerabilities, it does not offer proper
dynamic analysis but just a way for testing if
a finding was a false positive or not. On the
one hand, it covers different vulnerability cate-
gories, but, on the other hand, it only supports
the analysis of Android applications.

5.2. Dynamic analysis

This section describes tools that offer dynamic analy-
sis of mobile applications, such as tools that provide
runtime monitoring, runtime inspection as well as
dynamic instrumentation. One important issue in
Dynamic Analysis consists in achieve good code
cov- erage, and this is particularly difficult in mobile
appli- cations, that are often triggered by device
behavior and events (Ahmad et al., 2017; Yerima et
al., 2019). Another example is AppAudit (Xia et
al., 2015), a framework designed to detect malicious
flows that leak data, through static API
analysis and a subsequent verification with an
approximated dynamic analysis. The researchers have
also proposed an alternative, identifying security
issues and privacy leaks on the network layer
through a traffic analyzer, AGRIGENTO (Continella
et al., 2017). The static instrumentation approach to
analysis is also implemented in DroidBOX (Desnos
& Lantz, 2014), which provided runtime analysis
by modifying the application’s bytecode and by
repacka- ging it into an instrumented application.
One well-known dynamic instrumentation fra-
mework supporting both Android and iOS
operat- ing systems is Frida (Frida.re, 2019).
Frida is a dynamic code instrumentation
framework. It allows to inject JavaScript code
into native apps on Windows, macOS,
GNU/Linux, iOS, Android, and QNX, using
appropriate Frida APIs (Ravnas, 2019). It also
provides some simple tools built on top of these
APIs. They allow for listing processes and
discovering internal functions in a program,
which can then be traced. Frida’s core is written
in C and injects the Google V8 engine into the
target processes. The Javascript code is executed
into the target process with full access to
memory, so it can hook functions and call native
functions inside it. There is a bidirectional
communication channel between the application
and the script.
5.3. Hybrid analysis
framework (MobSF, 2019). It performs static analysis
of Android, iOS and Windows mobile apps. It can
only perform dynamic analysis of Android binaries
through a Virtual Machine or with an Android device.
Needle: an open source, modular framework for
security assessment of iOS apps created by MWR
InfoSecurity at MWRLabs (MwrLabs, 2019b). It is
composed by (1) an agent, that allows to perform
the analysis tasks natively on the device, and (2) a
core, a command-line environment. No graphical
interface is present.
Drozer: an open source, modular framework for
the security assessment of Android apps created by
MWR InfoSecurity at MWRLabs (MwrLabs, 2019a).
The implementation follows the guidelines of the
above framework. It is modular and is also composed
by an agent and a core. No graphical interface is
present, and it can perform both static and dynamic
analysis.
5.4. Detailed comparison with mobile
security framework (MobSF)
MobSF is an open-source mobile application analysis
framework. Similarly to our framework, its goal is to
Hybrid approaches, that combine static and dynamic
analysis, can be used to provide an effective real-time
application vulnerability assessment, and help over-
come the known limits of both techniques. For exam-
ple, the research reported in (Ali-Gombe et al., 2018)
uses static bytecode instrumentation in order to per-
form dataflow analysis, resource abuse, and
suspicious behavior detection. The detected flaws are
then mon- itored dynamically at runtime. Similarly,
TeICC (Ahmad et al., 2017) is a fully automated
hybrid sys- tem that performs static data-flow
analysis, based on program slicing techniques
(Weiser, 1981). Dynamic analysis is performed with
Stadyna (Zhauniarovich et al., 2015), and by
combining dynamic hooking (Costamagna &
Bergadano, 2016). More recent work addresses the
problem of performing hybrid analysis in presence of
dynamic code updates (Ahmad, Costamagna, Crispo,
Bergadano, & Zhauniarovich, 2020).
As more relevant in the present context, we
identified the following tools that provide
a dynamic analysis module coupled with an initial
static analysis phase:
Mobile Security Framework (MobSF): an open-
source mobile application automated pen-testing
conduct a semi-automated mobile application analy-
sis. This is the one that comes closest to the presented
framework w.r.t the available features. In fact, with
MobSF it is possible to perform static analysis with
both Android and iOS, and to perform dynamic
analysis only on Android. More precisely, as declared
by the community, MobSF is primarily used on the
Android OS. At the current state of development, we
can also perform static and dynamic analysis primar-
ily on Android.
One important difference, when compared to
MobSF, is that, while with the latter it is pos- sible
to perform dynamic analysis with the con-
figuration of a Virtual Machine with Android
4.4.2 or through a Rooted Android device (4.03–4.4
versions supported), with the frame- work presented
in this paper it is possible to perform dynamic
analysis directly on Rooted Android devices, with a
newer Android version supported (7.1.2).
In MobSF, the results of the analysis are pre-
sented to the user through a graphical interface; in
this way, it is easier for the analyst to search and
understand the results of the analysis itself. We
also decided to introduce a graphical interface to
support the analyst. Furthermore, dynamic analy-
sis results are shown to the user in real-time with
its interaction with the device.
Static analysis performed using MobSF
returns information about the application, such
as package name, certificate, version, main activ-
ity, permissions, together with information
related to its status concerning criticality, infor-
mation about components (activity, services,
content provider, etc.), imported libraries, etc.
On the other hand, dynamic analysis is per-
formed through CapFuzz (CapFuzz, n.d.), https
proxy built on top of mitmproxy (Mitm, 2019),
which is able to retrieve information about the
monitored API at runtime, the http traffic cap-
tured, and application logs.
The present paper’s approach in performing the
analysis is quite different from the one adopted
by MobSF. In particular, we provide a tool that
can be useful in the process of vetting
applications. This is the reason why it is based
mostly on the OWASP Mobile Security Testing
Guide (github.com/ OWASP, 2017). In fact, each
applications. One could in fact argue that 105
applications are not sufficiently representative
and some widespread vulnerabilities might have
been missed. This is true for fully automated
approaches, that do not check for the actual
exploitation of the vulnerabilities that are found.
In this approach, each application must also
undergo a manual inspection, that is made faster
or more effective with the use of the proposed tool.
It is therefore difficult to address more than a few
hundreds of applications. Yet, in future work, a set
of additional applications will be addressed, espe-
cially targeting applications areas and vulnerability
types that may have been overlooked in the
described experimentation.
7. Conclusions
In this paper, we presented a new approach and
a corresponding framework for the analysis of
mobile applications. Our methodology is modular
and is based on a combination of static and
dynamic analysis, with a particular emphasis on
partial automation. The methodology is based on
the reports and guidelines published by OWASP
for the security of mobile applications. The main
developed module has the objective of
implementing one or more requirements defined by
OWASP in the context of mobile development.
Moreover, the approach to dynamic analysis is
based on dynamic hooking, and this is performed
with the help of Frida. The mitmproxy is also
integrated into the present fra- mework and allows
for the interactive examination of http traffic.
6. Limitations and future work
At the present development stage, our modules
focus on the analysis of Android applications, but
the idea is to extend the research to iOS applica-
tions, too. Furthermore, the analysis is guided by
the reporting standard proposed by OWASP and
proposes a methodology for validating some of
these requirements. Therefore, also in this context,
the idea is to work on other areas of security
requirements, trying to automate the analysis pro-
cess as much as possible.
Once more security requirements are addressed,
and additional modules are implemented, we plan
to test the framework on a larger set of target
contribution of the whole work is to provide and
evaluate a tool for the process of vetting applica-
tions, capable of achieving this task it in an accu-
rate and simplified way.
We tested the framework by analyzing a total of
105 applications, downloaded from the Google Play
Store. From the results presented in Chapter 4, we
can observe that it is necessary to increase the
security awareness of the developers. However, this
is not enough: it is also necessary to raise the
awareness of the users. At a time when mobile
devices contain an ever-increasing amount of sen-
sitive data, it is important to implement a semi-
automated process for vetting applications. The
present framework can be a useful tool to accom-
plish this task.
ORCID
Francesco Bergadano http://orcid.org/0000-0003-2567-
336X
References
Ahmad, M., Costamagna, V., Crispo, B., & Bergadano, F.
(2017). Teicc: Targeted execution of inter-component
communications in android. Proceedings of the
symposium on applied computing (pp. 1747–1752).
Ahmad, M., Costamagna, V., Crispo, B., Bergadano, F., &
Zhauniarovich, Y. (2020). StaDART: Addressing the
pro- blem of dynamic code updates in the security
analysis of android applications. Journal of Systems and
Software, 159, [110386].
https://doi.org/10.1016/j.jss.2019.07.088
Ali-Gombe, A. I., Saltaformaggio, B., Ramanujam, J., Xu,
D., & Richard, G. G., III. (2018). Toward a more
dependable hybrid analysis of android malware using
aspect- oriented programming. Computers & Security,
73, 235–248. https:// doi.org/10.1016/j.cose.2017.11.006
Allen, F. E., & Cocke, J. (1976). A program data flow
analysis procedure. Communications of the ACM, 19(3),
137. https://doi.org/10.1145/360018.360025
Amin, A., Eldessouki, A., Magdy, M. T., Abdeen, N.,
Hindy, H., & Hegazy, I. (2019). AndroShield:
Automated android appli- cations Vulnerability detection,
a hybrid static and dynamic analysis approach.MDPI
Information, 10(10), article 326,
pages 1-16. https://doi.org/10.3390/info10100326
Android.com. (2019a). The activity lifecycle.
Retrieved
June 07, 2019, from https://developer.android.com/guide/
components/activities/activity-lifecycle.html
Android.com. (2019b). Android class
Android.com. (2019k). Declaration of the application.
Retrieved June 07, 2019, from https://developer.android.
com/guide/topics/manifest/application-element.html
Android.com. (2019l). Motioneevent. Retrieved June 07,
2019, from
https://developer.android.com/reference/android/
view/MotionEvent.html
Android.com. (2019m). UI/application exerciser monkey
(monkey tool). Retrieved June 07, 2019, from https://devel
oper.android.com/studio/test/monkey.html
Apktool. (2019). Apktool: Tool for reverse engineering
android apk files. Retrieved June 07, 2019, from
https://ibotpeaches. github.io/Apktool/
Arzt, S., Rasthofer, S., Fritz, C., Bodden, E., Bartel, A.,
Klein, J., Le Traon, Y., Octeau, D., & McDaniel, P.
(2014). Flowdroid: Precise context, flow, field, object-
sensitive and lifecycle-aware taint analysis for android
apps. Acm Sigplan Notices, 49(6), 259–269.
https://doi.org/10.1145/2666356
Bacci, A., Bartoli, A., Martinelli, F., Medvet, E., Mercaldo,
F., & Visaggio, C. A. (2018, 1). Impact of Code
Obfuscation on Android Malware Detection based on
Static and Dynamic Analysis. (pp. 379–385).
CapFuzz. (n.d.). Capfuzz - capture, intercept, fuzz. Retrieved
June 07, 2019, from https://github .com/MobSF/CapFuzz,
note
Chin, E., Felt, A. P., Greenwood, K., & Wagner, D. (2011).
Analyzing inter-application communication in android.
Proceedings of the 9th international conference on mobile
windowmanager.layout- params. Retrieved June 07 2019,
from https://developer.
android.com/reference/android/view/WindowManager.
LayoutParams.html#FLAG_SECURE
Android.com. (2019c). Android debug bridge (adb).
Retrieved June 07, 2019, from
https://developer.android.com/studio/ command-
line/adb.html
Android.com. (2019d). Android java class edittext. Retrieved
June 07, 2019, from https://developer.android.com/refer
ence/android/widget/EditText.html
Android.com. (2019e). Android java class textview. Retrieved
June 07, 2019, from https://developer.android.com/refer
ence/android/widget/TextView.html
Android.com. (2019f). Android packagemanager. Retrieved
June 07, 2019, from https://developer.android.com/refer
ence/android/content/pm/PackageManager.html
Android.com. (2019g). Android permissions. Retrieved
June 07, 2019, from https://developer .android.com/
guide/topics/permissions/overview
Android.com. (2019h). Android storage options. Retrieved
June 07, 2019, from https://developer.android.com/refer
ence/android/content/Context.html#MODE_WORLD_
WRITEABLE
Android.com. (2019i). Auto backup for apps. Retrieved
June 07, 2019, from https://developer.android.com/guide/
topics/data/autobackup.html
Android.com. (2019j). Copy and paste. Retrieved June 07,
2019, from https://developer.android.com/guide/topics/
text/copy-paste.html
systems, applications, and services (pp. 239–252).
Continella, A., Fratantonio, Y., Lindorfer, M., Puccetti, A.,
Zand, A., Kruegel, C., & Vigna, G. (2017). Obfuscation-
resilient privacy leak detection for mobile apps through
differential analysis. Proceedings of the isoc network and
distributed system security symposium (ndss) (pp. 1–16).
Costamagna, V., & Bergadano, F. (2016). Hookdroid: Dalvik
dynamic instrumentation for security analytics. Int J. on Inf.
Tech. and Security, 8(3), 39–52.
Desnos, A., & Lantz, P. (2014). Droidbox: An android appli-
cation sandbox for dynamic analysis (2011). https://code.
google. com/p/droidbox
Dolby, J., Fink, S. J., & Sridharan, M. (2w0a1t5so).n Tj
libraries for analysis (wala). http://wala. sf. net
Egele, M., Kruegel, C., Kirda, E., & Vigna, G. (2011). Pios:
Detecting privacy leaks in ios applications. Ndss.
Enck, W., Gilbert, P., Han, S., Tendulkar, V., Chun, B.-G.,
Cox, L. P., Jung, J., McDaniel, P., & Sheth, A. N. (2014).
Taintdroid: An information-flow tracking system for real-
time privacy monitoring on smartphones. ACM Transactions
on Computer Systems (TOCS), 32(2), 5.
https://doi.org/10.1145/2642648
Eugster, P. T., Felber, P. A., Guerraoui, R., & Kermarrec, A.-
M. (2003). The many faces of publish/subscribe. ACM
Computing Surveys (CSUR), 35(2), 114–131. https://doi.
org/10.1145/857076
Fosdick, L. D., & Osterweil, L. J. (1976). Data flow analysis in
software reliability. ACM Computing Surveys (CSUR), 8(3),
305–330. https://doi.org/10.1145/356674.356676
Frida.re. (2019). FRIDA dynamic instrumentation toolkit.
Retrieved June 07, 2019, from https://www.frida.re/
Fridump. (2019). Fridump open source memory dumping
tool. Retrieved June 07, 2019, from https://github.com/
Nightbringer21/fridump
Garg, S., Singh, R., & Mohapatra, A. (2019). Analysis of
software vulnerability classification based on different
technical parameters. Information Security
Journal: A Global Perspective, 28(1–2), 1–19.
https://doi.org/10. 1080/19393555.2019.1628325
Gibler, C., Crussell, J., Erickson, J., & Chen, H. (2012).
Androidleaks: Automatically detecting potential privacy
leaks in android applications on a large scale. International
confer- ence on trust and trustworthy computing (pp. 291–
307).
Github.com/androguard. (2011). Androguard. Retrieved
June 07, 2019, from https://github.com/androguard/andro
guardgithub.com/
Github.com/OWASP. (2019m). obOilwe asappplication
security verification standard. Retrieved June 07, 2019,
from https://github.com/OWASP/owasp-masvs
Gordon, M. I., Kim, D., Perkins, J. H., Gilham, L.,
Nguyen, N., & Rinard, M. C. (2015). Information flow
analysis of android applications in droidsafe. Ndss.
Hoffmann, J., Ussath, M., Holz, T., & Spreitzenbarth, M.
(2013). Slicing droids: Program slicing for smali code.
Proceedings of the 28th annual acm symposium on
applied computing (pp. 1844–1851).
JAADAS. (2019). Joint advanced application defect
conference on ict systems security and privacy protection (pp.
538–552).
Mitm. (2019). Mitmproxy. Retrieved June 07, 2019, from
https://mitmproxy.org/
MobSF. (2019). Mobile security framework (MobSF).
Retrieved June 07, 2019, from https://github.com/MobSF/
Mobile-Security-Framework-MobSF
MwrLabs. (2019a). Drozer. Retrieved June 07, 2019, from
https://github.com/mwrlabs/drozer
MwrLabs. (2019b). Needle. Retrieved June 07, 2019, from
https://github.com/mwrlabs/needle
Octeau, D., Luchaup, D., Jha, S., & McDaniel, P. (2016).
Composite constant prop agation and its application to
android program analysis. IEEE Transactions on Software
Engineering, 42(11), 999–1014. https://doi.org/10.1109/
TSE.2016.2550446
OWASP. (2017). Owasp mobile security testing guide.
Retrieved June 07, 2019, from https://github.com/
OWASP/owasp-mstg
Owasp.org. (2019). Owasp mobile top 10 2016. Retrieved
June 07, 2019, from https://www.owasp.org/index.php/
Mobile_Top_10_2016-Top_10
Pocoo.org. (2019). Flask, web development, one drop at a
time. Retrieved June 07, 2019, from http://flask.pocoo.org/
Qark. (2019). Tool to look for several security related android
application vulnerabilities. Retrieved June 07, 2019, from
https://github.com/linkedin/qark
Ravnas, O. A. V. (2019). Javascript API. Retrieved June 07,
2019, from https://www.frida.re/docs/javascript-api/
Redis.io. (2019). Redis. Retrieved June 07, 2019, from
https://redis. io/
assessment for android application. Retrieved June 07,
2019, from https://github.com/flankerhqd/JAADAS
Lam, P., Bodden, E., Lhoták, O., & Hendren, L. (2011). The
soot framework for java program analysis: A retrospective.
In Cetus users and compiler infrastructure workshop
(cetus 2011), Purdue University, (Vol. 15, pp. 35).
Li, L., Bartel, A., Bissyandé, T. F., Klein, J., Le Traon, Y.,
Arzt, S., … McDaniel, P. (2015). Iccta: Detecting inter-
component privacy leaks in android apps. Proceedings of
the 37th international conference on software engineering-
volume 1 (pp. 280–291).
Li, L., Bissyandé, T. F., Papadakis, M., Rasthofer, S.,
Bartel, A., Octeau, D., Klein, J., & Traon, L. (2017). Static
analysis of android apps: A systematic literature review.
Information and Software Technology, 88, 67–95. https://
doi.org/10.1016/j.infsof.2017.04.001
Lin, Y.-C. (2015). Androbugs framework: An android
applica- tion security vulnerability scanner. UBM Tech,
Blackhat Europe 2015.
Lu, L., Li, Z., Wu, Z., Lee, W., & Jiang, G. (2012). Chex:
Statically vetting android apps for component hijacking
vulnerabilities. Proceedings of the 2012 acm conference on
computer and communications security (pp. 229–240).
Menezes, A. (2019). A screen capture via UI overlays in
mediaprojection. Retrieved June 07, 2019, from https://
labs.mwrinfosecurity.com/advisories/screencapture-via-ui-
overlays-in-mediaprojection/
Merlo, A., & Georgiu, G. C. (2017). Riskindroid: Machine
learning-based risk analysis on android. Ifip international
Schmich, C. P., & Huene, P. C. (2012, June 28). Dynamic
instrumentation of software code. Google Patents. (US Patent
App. 12/975,363).
Shahriar, H., Zhang, C., Dunn, S., Bronte, R., Sahlan, A., &
Tarmissi, K. (2019). Mobile anti-phishing: Approaches and
challenges. Information Security Journal: A Global
Perspective, 28(6), 178–193. https://doi.org/10.1080/
19393555.2019.1691293
 Smalisca. (2019). Static analysis of smali files. Retrieved
June 07, 2019, from https://github.com/dorneanu/smalisca
Sounthiraraj, D., Sahs, J., Greenwood, G., Lin, Z., & Khan,
L. (2014). Smv-hunter: Large scale, automated detection of
SSL/TLS man-in-the-middle vulnerabilities in android
apps. Proceedings of the 21st annual network and distrib-
uted system security symposium (ndss 2014).
Statista.com. (2019). Average number of new android app
releases per day from 3rd quarter 2016 to 1st quarter 2018.
Retrieved June 07, 2019, from
https://www.statista.com/statistics/ 276703/android-app-
releases-worldwide/
Tornadoweb.org. (2019). Tornado.Retrieved June 07, 2019,
from http://www.tornadoweb.org/en/stable/index.html
Websocket.org. (2019). Websocket. Retrieved June 07,
2019, from http://www.websocket.org/index.html
Weiser, M. (1981). Program slicing. Proceedings of the 5th
inter- national conference on software engineering (pp.
439–449).
Xia, M., Gong, L., Lyu, Y., Qi, Z., & Liu, X. (2015).
Effective real-time android application auditing. Security
and priv- acy (sp), 2015 ieee symposium on (pp. 899–
914).
Yerima, S., Alzaylaee, M., & Sezer, S. (2019). Machine
learning-based dynamic analysis of Android apps with
improved code coverage. EURASIP Journal on
Information Security, 2019(4). https://doi.org/10.1186/
s13635-019-0087-1
Zhang, X., & Du, W. (2014). Attacks on android clipboard.
International conference on detection of intrusions and
mal- ware, and vulnerability assessment (pp. 72–91).
Zhauniarovich, Y., Ahmad, M., Gadyatskaya, O., Crispo, B.,
& Massacci, F. (2015). Stadyna: Addressing the problem of
dynamic code updates in the security analysis of android
applications. Proceedings of the 5th acm conference on
data and application security and privacy (pp. 37–48).
Zheng, T., Jianwei, T., Hong, Q., Xi, L., Hongyu, Z., &
Wenhui, Q. (2017, November). Design of automated
security assessment framework for mobile applications.
2017 8th ieee international conference on software
engineering and service science (icsess) (pp. 778–781).