ArticlePDF Available

Mobile Apps Analysis: A Hybrid Approach using Dynamic Syntax Tree



Mobile devices are rapidly expanding as per user's need and they are potential risky for personal and professional privacy, because of the various malware and increasing security issues and threats. With lots of frequent application releases and updates happening, conducting a complete security analysis of mobile Apps becomes crucial. In this paper, we present a different approach to ensure the security of these devices starting from the Apps development. We examine the two major platforms in the mobile space, iOS and Android, and for each we provide a thorough investigation of existing and historical security features, evidence-based discussion of known security bypass techniques, and concrete recommendations for remediation.
Mobile Apps Analysis: A Hybrid Approach using Dynamic Syntax Tree
Elina Petrovna
Department of Software Engineering
BitBrainery University, London - UK
Ruth Goldberg, David Syman
Security Reviewer Srl, Grosseto - Italy
[2015- 15th of October]
Abstract Mobile devices are rapidly expanding as per user's
need and they are potential risky for personal and
professional privacy, because of the various malwares and
increasing security issues and threats. With lots of frequent
application releases and updates happening, conducting a
complete security analysis of mobile Apps becomes crucial.
In this paper, we present a different approach to ensure the
security of these devices starting from the Apps
development. We examine the two major platforms in the
mobile space, iOS and Android, and for each we provide a
thorough investigation of existing and historical security
features, evidence-based discussion of known security
bypass techniques, and concrete recommendations for
Keywords - Mobile analysis, Sandboxing, Hybrid analysis, code
analysis, SAST, MAST, Vulnerability prediction
Most of Mobile Apps analysis techniques process the
following three aspects only:
The top five permissions [4] that Apps request are:
An App is vulnerable if requests more than permissions
really required, or in case of invalid usage [2] of such
A vulnerability comes from either the application’s source
code [3] or from the external libraries it uses, in most cases
early versions of open-source libs. Hundreds of code
vulnerabilities are referenced by the National Vulnerability
Database (NVD), the OWASP mobile security project and US-
A mobile application can perform unwanted actions
because of the external libraries adopted, compromised by
malware [1] [5], or because of a development mistake.
Therefore, the development techniques using current
programming languages cannot work properly if based on
languages’ security constructs or external libraries only,
because there is not complete set of information needed for
The main contribution of this paper is a description of an
automated, all-in-one, mobile application (Android and iOS)
penetration testing, malware analysis and security
assessment framework capable of performing and
correlating static and dynamic analyses. This framework,
hereby named Hybrid Analyzer, should support mobile app
binaries (APK, XAPK, IPA) along with zipped source code and
provides REST APIs for seamless integration with your CI/CD
or DevOps pipeline. The Hybrid Analyzer helps you to
perform runtime security assessment and interactive
instrumented testing.
Further than above listed Mobile Apps analysis techniques,
the Hybrid Analyzer also covers the following:
Android Hardcoded Secrets- Rooted phone, Hard disk
forensics, ADB backup, Debuggable application allowing
run-as (mitigated by Android). Social engineering, Bug in
application allowing for data exfiltration, Bug in
application allowing arbitrary command execution (not
mitigated by Android).
Apple iOS Key Security Flaws- Limited benefit of
encryption for powered-on devices, Evidence of past
hardware (SEP) compromise, Limitations of “end-to-end
encrypted” cloud services.
iOS IPA and APK/XAPK binary analysis- .ipa and .apk files
are just zipped files that include the application
executable and a bunch of other stuff. In most cases they
are not 100% encrypted and contains images, web
pages, db files, configuration files and even zipped
source code.
Image Interpreting- detects Async Inputs, Application
Status Changes, Lost Connections, Unhandled Errors by
interpreting the images dynamically
Decompilation- Decrypt and decompile binaries for
obtaining a seamless source code in Java/Dalvik or
Static Analysis- Static Analysis of decrypted code,
configuration files, db files
Protocol testing- Find in the code references to security
protocols, execute Dynamic Analysis of TLS/SSL Security,
SSL Pinning Bypass, LGTM issues, and REST API exposed
for TLS/SSL included.
Intent/app extension dumper- Through auxiliary Frida
Correlation- between Static Analysis and Dynamic
In the following sections we try to briefly describe the hybrid
analysis techniques listed above. It is necessary for a better
understanding of the proposed new hybrid approach, based
on Dynamic Syntax Tree [6] representing the real scope of
this publication.
Android Hardcoded Secrets
Google’s Android operating system, and many third-party
phones that use Android, incorporates several security
features that are analogous to those provided by Apple
devices. Unlike Apple, Google does not fully control the
hardware and software stack on all Android-compatible
smartphones: some Google Android phones are
manufactured entirely by Google, while other devices are
manufactured by third parties. Moreover, device
manufacturers routinely modify the Android operating
system prior to deployment. To determine the level of
security currently provided by these Android devices against
sophisticated attackers, we considered the full scope of
Google’s public documentation, postings from mobile
forensics companies, and other documents in the public
record. Our main findings are as follows:
Limited benefit of encryption for powered-on devices. Like
Apple iOS, Google Android provides encryption for files and
data stored on disk. However, Android’s encryption
mechanisms provide fewer gradations of protection. Android
provides no equivalent of Apple’s Complete Protection (CP)
encryption class, which evicts decryption keys from memory
shortly after the phone is locked. Therefore, Android
decryption keys always remain in memory after “first unlock,”
and user data is potentially vulnerable to forensic capture.
De-prioritization of end-to-end encrypted backup. Android
incorporates an end-to-end encrypted backup service based
on physical hardware devices stored on Google’s datacenters.
The design of this system ensures that recovery of backups
can only occur if initiated by a user who knows the backup
passcode, an on-device key protected by the user’s PIN or
other authentication factor. Unfortunately, the end-to-end
encrypted backup service must be opted-in to by app
developers and is paralleled by the opt-out Android Auto-
Backup, which simply synchronizes app data to Google Drive,
encrypted with keys held by Google.
Large attack surface. Android is the composition of systems
developed by various organizations and companies. The
Android kernel has Linux at its core, but also contains chip
vendor- and device manufacturer-specific modification. Apps,
along with support libraries, integrate with system
components and provide their own services to the rest of the
device. Because the development of these components is not
centralized, cohesively integrating security for all of Android
would require significant coordination, and in many cases
such efforts are lacking or nonexistent.
Limited use of end-to-end encryption. End-to-end encryption
for messages in Android is only provided by default in third-
party messaging applications. Native Android applications do
not provide end-to-end encryption: the only exception being
Google Duo, which provides end-to-end encrypted video calls.
The current lack of default end-to-end encryption for
messages allows the service provider (for example, Google) to
view messages and logs, potentially putting user data at risk
from hacking, unwanted targeted advertising, subpoena, and
surveillance systems.
Availability of data in services. Android has deep integration
with Google services, such as Drive, Gmail, and Photos.
Android phones that utilize these services (most of them)
send data to Google, which stores the data under keys it
controls - effectively an extension of the lack of end-to-end
encryption beyond just messaging services. These services
accumulate rich sets of information on users that can be
exfiltrated either by knowledgeable criminals (via system
compromise) or by law enforcement (via subpoena power).
Android also makes heavy use of SELinux to further sandbox
applications, including its own services so that compromising
them doesn’t necessarily mean full root access. In some cases,
these protections are already strong enough to require no
extra encryption.
Rooted Phone The case of a rooted phone is straightforward:
Android does not allow a regular user to root their phone
easily. Given this, we know that a user with a rooted phone
has either done so willingly or has fallen victim to
sophisticated malware that exploits Android itself. In the first
case we have two options: employ rooting detection and
change the applications behavior on a rooted phone, or we
can accept the risk of a user who rooted their own phone
being more vulnerable. The second case requires a more
sophisticated attacker so we will need to evaluate the
probability that our application will be the target for this
attacker. The second case is particularly difficult to deal with,
but Android can still potentially protect some application
secrets even in the case of rooting.
Hard Disk Forensics would be an issue if a user’s phone were
to fall into the hands of someone who knows how to image
and read a hard disk. This isn’t as hard as it sounds, so it is a
worthwhile method to consider. Luckily Android provides file
based or full disk encryption to help here.
Social Engineering is always a possibility for stealing a user’s
secrets and encryption doesn’t necessarily help here. While it
would help in the case where the attacker is trying to convince
someone to install some malware on their phone that targets
your application, that is also mitigated through general
Android security practices. If this is our only reason for
encrypting application data and we think it is valid, then it
might be better to tackle this problem at a different level.
ADB Backup is a well-publicized issue in which users with
Android debugging enabled could be vulnerable to
inadvertently allowing application data to be backed up by a
malicious USB port or an attacker with physical access to their
phone. The idea for the former would look something like
plugging a phone into some USB port that “looks safe” but
attempts to use the adb backup command. Neither of these
are particularly easy to pull off anymore since the phone
needs to be unlocked and there is user interaction required
to start the backup. This can also be mitigated through other
means, particularly configuration option in the
AndroidManifest.xml file.
run-as Applications that are debuggable allow anyone that
can get a shell on the phone to use the run-as {application}
command to access the filesystem as if they were the
application itself. Android warns you when applications are
hard coded to be debuggable, but the mitigation here is
simple: don’t deliver a debuggable application.
Application Bugs are an interesting vector to consider. The
risk here is that data will be exfiltrated from the application
due to an issue with application logic. Exposed IPC services
things such as exported Services, Broadcast Receivers, and
Content Providers would be a good place to look for these
types of issues. These are some of the things that make
Android so versatile but are also a major target for malware.
If we have exported IPC services, we can bet that is the first
place an attacker will look for an entrypoint into our
Code Execution Vulnerabilities in the application itself could
be game over for any application data without a sufficiently
robust encryption mechanism. We could consider attempting
to mitigate the damage this causes to application data
integrity and secrecy, but it is difficult in general.
Apple iOS Key Security Flaws
Apple is also noteworthy for three reasons: (1) the company
has overall control of both the hardware and operating
system software deployed on its devices, (2) the company’s
business model closely restricts which software can be
installed on the device, and (3) Apple management has, in the
past, expressed vocal opposition to making technical changes
in their devices that would facilitate law enforcement access.
To determine the level of security currently provided by
Apple against sophisticated attackers, we considered the full
scope of Apple’s public documentation. Our main findings are
as follows:
Limited benefit of encryption for powered-on devices. Apple
advertises the broad use of encryption to protect user data
stored on-device. However, we observed that a surprising
amount of sensitive data maintained by built-in applications
is protected using a weak “available after first unlock” (AFU)
protection class, which does not evict decryption keys from
memory when the phone is locked. The impact is that most
sensitive user data from Apple’s built-in applications can be
accessed from a phone that is captured and logically
exploited while it is in a powered-on (but locked) state. We
also found circumstantial evidence from a 2014 update to
Apple’s documentation that the company has, in the past,
reduced the protection class assurances regarding certain
system data, to unknown effect. Finally, we found
circumstantial evidence in both the DHS procedures and
investigative documents that law enforcement now routinely
exploits the availability of decryption keys to capture large
amounts of sensitive data from locked phones. Documents
acquired by Upturn, a privacy advocate organization, support
these conclusions, documenting law enforcement records of
passcode recovery against both powered-off and simply
locked iPhones of all generations.
Weaknesses of cloud backup and services. Apple’s iCloud
service provides cloud-based device backup and real-time
synchronization features. By default, this includes photos,
email, contacts, calendars, reminders, notes, text messages
(iMessage and SMS/MMS), Safari data (bookmarks, search
and browsing history), Apple Home data, Game Center data,
and cloud storage for installed apps. We examine the current
state of data protection for iCloud and determine
(unsurprisingly) that activation of these features transmits an
abundance of user data to Apple’s servers, in a form that can
be accessed remotely by criminals who gain unauthorized
access to a user’s cloud account, as well as authorized law
enforcement agencies with subpoena power. More
surprisingly, we identify several counter-intuitive features of
iCloud that increase the vulnerability of this system. As one
example, Apple’s “Messages in iCloud” feature advertises the
use of an Apple-inaccessible “end-to-end” encrypted
container for synchronizing messages across devices.
However, activation of iCloud Backup in tandem causes the
decryption key for this container to be uploaded to Apple’s
servers in a form that Apple (and potential attackers, or law
enforcement) can access. Similarly, we observe that Apple’s
iCloud Backup design results in the transmission of device-
specific file encryption keys to Apple. Since these keys are the
same keys used to encrypt data on the device, this
transmission may pose a risk if a device is subsequently
physically compromised. More generally, we find that the
documentation and user interface of these backup and
synchronization features are confusing and may lead to users
unintentionally transmitting certain classes of data to Apple’s
Evidence of past hardware (SEP) compromise. iOS devices
place strict limits on passcode guessing attacks through the
assistance of a dedicated processor known as the Secure
Enclave processor (SEP). We examined the public
investigative record to review evidence that strongly
indicates that as of 2018, passcode guessing attacks were
feasible on SEP-enabled iPhones using special tools. To our
knowledge, this most likely indicates that a software bypass
of the SEP was available in-the-wild during this timeframe.
We also reviewed more recent public evidence and were not
able to find dispositive evidence that this exploit is still in use
for more recent phones (or whether exploits still exist for
older iPhones). Given how critical the SEP is to the ongoing
security of the iPhone product line, we flag this uncertainty
as a serious risk to consumers.
Limitations of “end-to-end encrypted” cloud services. Several
Apple iCloud services advertise “end-to-end” encryption in
which only the user (with knowledge of a password or
passcode) can access cloud-stored data. These services are
optionally provided in Apple’s CloudKit containers and via the
iCloud Keychain backup service. Implementation of this
feature is accomplished via the use of dedicated Hardware
Security Modules (HSMs) provisioned at Apple’s data centers.
These devices store encryption keys in a form that can only
be accessed by a user and are programmed by Apple such
that cloud service operators cannot transfer information out
of an HSM without user permission.
As noted above, our finding is that the end-to-end
confidentiality of some encrypted services is undermined
when used in tandem with the iCloud backup service. More
critically, we observe that Apple’s documentation and user
settings blur the distinction between “encrypted” (such that
Apple has access) and “end-to-end encrypted” in a manner
that makes it difficult to understand which data is available
to Apple. Finally, we observe a fundamental weakness in the
system: Apple can easily cause user data to be re-provisioned
to a new (and possibly compromised) HSM simply by
presenting a single dialog on a user’s phone. We discuss
techniques for mitigating this vulnerability.
Based on these findings, our overall conclusion is that data
for iOS devices is highly available to both sophisticated
criminals and law enforcement actors with either cloud or
physical access. This is due to a combination of the weak
protections offered by current Apple iCloud services, and
weak defaults used for encrypting sensitive user data on-
device. The impact of these choices is that Apple’s data
protection is fragile: once certain software or cloud
authentication features are breached, attackers can access
most sensitive user data on device. Later in this work we
propose improvements aimed at improving the resilience of
Apple’s security measures.
iOS IPA and APK/XAPK binary analysis
App binary files are zip files from which a lot of sensitive data
can be extracted.
List of Targets for NIST Mobile Device Acquisition Forensics
• Cellular network subscriber information: IMEI, MEID/ESN
• Personal Information Management (PIM) data: address
book/contacts, calendar, memos, etc
• Call logs: incoming, outgoing, missed
• Text messages: SMS, MMS (audio, graphic, video)
• Instant messages
• Stand-alone files: audio, documents, graphic, video
• E-mail
• Web activity: history, bookmarks
• GPS and geo-location data
• Social media data: accounts, content
• SIM/UICC data: provider, IMSI, MSISDN, etc.
In accordance with NIST standards, DHS tests forensic
software for mobile device acquisition of the above categories
of data [Source: NIST].
Further, the extracted Images during Dynamic Analysis can
be an important source of sensitive information (see the
relative section below).
App binaries are easy to decompile or reverse-engineering to
Android Dalvik or iOS opcode. The obtained source code
cannot be compiled but executing a Static Analysis on it can
detect a bunch of vulnerabilities that really exist in the App.
The human readable Dalvik or opcode is a great hint for
understanding executable code. For example, all iOS opcode
selector names reside in the __objc_methname section of the
__TEXT segment. Reverse engineering is a helpful approach
that can be used for investigating and analyzing software code
to research malware, fix software issues, ensure software
compatibility, simplify support for undocumented legacy
code, etc. To reverse engineer a piece of software, you need
to know the basic binary executable structure and have a set
of tools for browsing and disassembling executables.
The Hybrid Analyzer will apply:
Reversing open-source code
Getting an executable to reverse engineer
Reversing emulator binaries
Finding the cause of application-specific issues
Reverse engineering using private or internal functionality
Communicating with a daemon
Static Analysis
It will perform source code-based analysis without running
the application to not depend on the runtime environment.
So that static analysis can be used in line with application
development. Static testing will be more effectively carried
out regularly within a predetermined time so that every time
an update or release of App is carried out, at the same time,
the test has been done without having to run the application.
Protocol testing
Hybrid Analyzer introduces SSL/TLS traffic decryption on the
fly. A traditional packet-capture tool is useless when you need
to inspect the contents of an encrypted session, be it the App
downloading a webpage or contacts an unknown server for
an obscure reason. Today, virtually all network traffic is
encrypted. Hybrid Analyzer is a game-changer: It intercepts
SSL and TLS traffic and displays the contents as if you were
capturing an unencrypted TCP session.
Intent/app extension dumper
During Dynamic Analysis Intents (Android) or App Extensions
are detected using Frida or Needle, without the need for a
jailbroken or rooted mobile device. It will be able to detect
data storage usage, inter-process communication, network
communications, hooking and binary protections.
Static and Dynamic analyses will be correlated using Dynamic
Syntax Tree, combining, and correlating the results. You are
able to identify which vulnerabilities are truly exploitable and
should be at the top of your remediation list.
Mapping of constructs from the dynamic language into a
Dynamic Syntax Tree (DST) is a kind of semantic analysis.
Information implying from the syntax is analyzed and the
results are inserted back into the same tree, but in the form
of complete static information. Thereafter this preprocessing
enables us to work with the syntax tree of the dynamic code
as it is in a static code with some limitations, that are not
resolvable until runtime in dynamic languages. For that
reason, we provide a binaries analysis. Binaries will be
sandboxed collecting dynamic information at runtime, using
a very fast algorithm that will be discussed in a future paper.
Mixing source code and binaries analysis will fix the above-
mentioned limitations.
Future Work
Hybrid Analyzer sandboxing feature will be used in a Eu-
Funded project, MOBILE Lab - PANOPTESEC project lead by
BitBrainery University, together with NVISO Labs and
Security Reviewer Srl.
[1] Olalere, M., et al., A review of bring your own
device on security issues. Sage Open, 2015. 5(2):
p. 2158244015580372.
Google Scholar
[2] Altuwaijri, H. and S. Ghouzali, Android data storage security: A review.
Journal of King Saud University-Computer and Information Sciences,
2020. 32(5): p. 543552.
Google Scholar
[3] Wu, L., X. Du, and X. Fu, Security threats to mobile multimedia
applications: Camera-based attacks on mobile phones. IEEE
Communications Magazine, 2014. 52(3): p. 8087.
Google Scholar
[4] Alepis, E. and C. Patsakis, Unravelling security issues of runtime
permissions in android. Journal of Hardware and Systems Security,
2019. 3(1): p. 4563.
Google Scholar
[5] Doğru, İ.A. and Ö. Kiraz, Web-based android malicious software
detection and classification system. Applied Sciences, 2018. 8(9): p.
Google Scholar
[6] Moses, T. and Syman D. Dynamic Syntax Tree: Implementation Results,
ResearchGate has not been able to resolve any citations for this publication.
Full-text available
Mobile computing is conquering human-computer interaction and user Internet access over the last years. At the same time, smartphone devices are equipped with an increasing number of sensors, realizing context awareness, while accompanying their users in their daily life. As a result, these highly sophisticated and multi-modal devices deal with a surprisingly big amount of data, much of which is private and sensitive. To control data access, OSes have special permission mechanisms, often controlled by the users. The Android permission model has radically changed over the last years, in an effort to become more flexible and protect its users more effectively. This work presents a thorough analysis of the new android permission architecture, accompanied with a criticism regarding its advantages and disadvantages based on a number of disclosed security issues.
Full-text available
Android is the most used operating system (OS) by mobile devices. Since applications uploaded to Google Play and other stores are not analyzed comprehensively, it is not known whether the applications are malicious software or not. Therefore, there is an urgent need to analyze these applications regarding malicious software. Moreover, mobile devices have limited resources to analyze the applications. In this study, a malicious detection system named “Web-Based Android Malicious Software Detection and Classification System” was developed. The system is based on client-server architecture, static analysis and web-scraping methods. The proposed system overcomes the resource restriction issue, as well as providing third-party service support by means of client-server architecture. Based on the performance evaluation conducted in this research, the developed system’s success rate is 97.62% on benign and malicious datasets.
Full-text available
The broad adoption of smartphones has superseded the desktop computers and laptops as a primary computing platform, due to mobility, constant connectivity and application diversity. Mobile devices encompass storage of extensive information including sensitive ones such as authentication credentials, pictures, videos, personal data, work information, and many more. Thus, securing data stored on mobile devices becomes a critical issue. In this review, we investigate the security of Android storage model between 2013 and 2018. Several threats are found in the literature that can be categorized as physical or software threats. Additionally, the existing solutions for each category are highlighted. Although Android provides valuable encryption systems including full disk encryption and keychain to enhance the data storage security, the encryption key, which is stored in the device, is still vulnerable to physical threats.
Full-text available
In our earlier research[1], we described the Dynamic Syntax Tree method implementation for enhancing the Static Analysis process. After 10+ years of experience, we collected the significant results presented in this paper
Full-text available
Mobile computing has supplanted internet computing because of the proliferation of cloud-based applications and mobile devices (such as smartphones, palmtops, and tablets). As a result of this, workers bring their mobile devices to the workplace and use them for enterprise work. The policy of allowing the employees to work with their own personal mobile devices is called Bring Your Own Devices (BYOD). In this article, we discuss BYOD’s background, prevalence, benefits, challenges, and possible security attacks. We then review contributions of academic researchers on BYOD. The Universiti Putra Malaysia online databases (such as IEEE Xplore digital library, Elsevier, Springer, ACM digital library) were used to search for peer-reviewed academic publications and other relevant publications on BYOD. The Google Scholar search engine was also used. Our thorough review shows that security issues comprise the most significant challenge confronting BYOD policy and that very little has been done to tackle this security challenge. It is our hope that this review will provide a theoretical background for future research and enable researchers to identify researchable areas of BYOD.
Full-text available
Today's mobile smartphones are very powerful, and many smartphone applications use wireless multimedia communications. Mobile phone security has become an important aspect of security issues in wireless multimedia communications. As the most popular mobile operating system, Android security has been extensively studied by researchers. However, few works have studied mobile phone multimedia security. In this article, we focus on security issues related to mobile phone cameras. Specifically, we discover several new attacks that are based on the use of phone cameras. We implement the attacks on real phones, and demonstrate the feasibility and effectiveness of the attacks. Furthermore, we propose a lightweight defense scheme that can effectively detect these attacks.