Case Study : Android OS

A PROJECT REPORT
SUBMITTED IN PARTIAL FULFILLMENT OF THE REQUIRMENTS
FOR THE AWARD OF THE DEGREE
OF

BACHELOR OF TECHNOLOGY
IN
SOFTWARE ENGINEERING

Submitted by:
ANKIT KUMAR
(2K19/SE/009)
Under the supervision of
Dr. Akshi Kumar
DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING
DELHI TECHNOLOGICAL UNIVERSITY
(Formerly Delhi College of Engineering)
Bawana Road, Delhi-110042

NOV, 2020
 DELHI TECHNOLOGICAL UNIVERSITY
(Formerly Delhi College of Engineering)
Bawana Road, Delhi-110042

CANDIDATE’S DECLARATION

I , (Ankit Kumar, 2K19/SE/009) of B. Tech. (SE). hereby declare that the project Dissertation
titled “CASE STUDY: ANDROID OS” which is submitted by me to the Department of Computer
Science and Engineering, Delhi Technological University, Delhi in partial fulfillment of the
requirement for the award of the degree of Bachelor of Technology, is original and not copied
from any source without proper citation. This work has not previously formed the basis for the
award of any Degree, Diploma Associateship, Fellowship or other similar title or recognition.

Place : Delhi Ankit Kumar

Date: 17-11-2020
(2K19/SE/009)

2
 COMPUTER SCIENCE AND ENGINEERING
DELHI TECHNOLOGICAL UNIVERSITY
(Formerly Delhi College of Engineering)
Bawana Road, Delhi-110042

CERTIFICATE

I hereby certify that the Project Dissertation titled “CASE STUDY: ANDROID OS”
which is submitted by Ankit Kumar, 2K19/SE/009 department of Computer
Science and Engineering, Delhi Technological University, Delhi in partial fulfillment
of the requirement for the award of the degree of Bachelor of Technology, is a
record of the project work carried out by the student under my supervision. To
the best of my knowledge this work is has not been submitted in part or full for
any Degree or Diploma to this University elsewhere.

Place: Delhi Dr. Akshi Kumar

Date: 17-11-2020 SUPERVISOR

3
Acknowledgement : I would like to express my special thanks of gratitude
to my teacher Dr. Akshi Kumar as well as our college (Delhi Technological
University, Delhi )which gave me the golden opportunity to do this wonderful
project on the topic “CASE STUDY: ANDROID OS” , which also helped me in doing
a lot of Research and I came to know about so many new things I am really
thankful to them.
Secondly, I would also like to thank my parents and friends who helped me a lot in
finalizing this project within the limited time frame.

4
 Contents

1. Introduction 6
2. Android Platform Architecture 7
3. Android Security Mechanisms 10
4. Android Security Issues and Threats 12
5. Proposed Solutions 15
6. Conclusion 35
7. References 38

5
1. INTRODUCTION
In the last few years, Android has acquired a large amount of users since its first
release in 2008. The fastest rising market area for technology is smartphones. In
2014 alone, 1.1 billion smartphones running on Google's Android OS were
delivered, marking its 80 percent smartphone market share, according to Gartner,
a technology consulting and consultancy company. The proliferation of Android
applications, which have an ever-growing application environment, is due to this
quick-pace rise. In early 2015, the number of applications in the marketplace
reached over 1.6 million, officially announced by Android Google Play Store,
surpassing its biggest rival, Apple Apps Store. For the smartphone experience,
mobile applications are critical. Mobile apps are becoming increasingly dynamic,
durable, life-engaging, and privacy-intrusive. The industry has a broad spectrum
of entertainment applications, Productivity, health insurance, internet dating,
security at home, and group management. Users depend on mobile devices and
apps more and more.
The privacy and protection of smartphone users are becoming an issue as
mobile apps are gaining growing popularity among users. Smart devices are used
to store confidential personal information more commonly than laptops and
desktops, because of the large user base. As a result, not only can a malicious
third-party app steal private information from its owner, such as the contact list,
text messages, and location, but it can also cause users to suffer financially by
allowing hidden premium-rate phone calls and text messages. Around the same
time, the exponential rise in the number of apps on the Android market makes it
impossible for app marketplaces, such as the Google App Store, to thoroughly
check whether an app is genuine or malicious. As a consequence, it is left to
smartphone users to determine for themselves if an app is safe to use.
Furthermore, unlike iOS, Android device owners do not have to root or "jailbreak"
their smartphones from "unknown sources" to install applications. This allows
Android users a broad opportunity to simply change a device setting to install

6
pirated, compromised or restricted Google Play applications. This offers
consumers with extra options to install third-party apps, but exposes their privacy
to critical applications.
There are a wide range of bugs in Android and they can appear in any Android
OS stack layer, such as the application layer or the framework layer. By the
accidental addition of coding errors or design defects, vulnerabilities also occur in
benign applications. The faulty Android App offers a fertile ground for attackers,
as we mentioned previously.  On Android phones, there are a variety of security
issues, such as unauthorized access from one app to the other (information
leakage), previledge escalation, repackaging apps to insert malicious code,
collusion, and Denial of Service (DoS) attacks.
Realizing these loopholes, efforts have been made to overcome these problems.
In addition to security measures such as Android permission model and
sandboaxing, many security and privacy solutions were proposed to cope with the
existing security breaches in Android OS, including some resource management
system and security solution using different approaches and techniques.

2. Android Platform Architecture

The architecture of the android operating system is mainly divided into six sub
sections.
• The Linux Kernel
• Hardware Abstraction Layer(HAL)
• Android Runtime
• Native C/C++ Libraries
• Java API Framework
• System Apps

7
1. Linux Kernel: This is the foundation of the android platform. Basically a kernel is
a program that continuously runs in the system. Android’s kernel is based on the
Linux kernel’s long term support (LTS) branches. The Linux kernel is the bottom
most layer of the android architect with some architectural changes ma. As of
2020, Android uses versions 4.4, 4.9 or 4.14 of Linux kernel. The Linux kernel
provides support for process management, device management, memory
management and security management. It also consists of a list of device drivers
that are used to communicate with other peripheral devices. A device driver is a
software that provide software interface to the hardware devices. The android
runtime relies on the Linux kernel for underlying functionalities such as multi-
threading and low-level memory management.
2. Hardware Abstraction Layer (HAL) : The Hardware abstraction layer basically
bridges the gap between the hardware and software. It provide standard

8
interfaces that expose device hardware capabilities to the higher level java API
framework.
3. Android Runtime: The android runtime consists of a collection of the core
android libraries and the Dalvik virtual machine (although the android versions
after Kit Kat uses the more optimized Android runtime(ART) ).The android
runtime is used to run multiple virtual machines on low-memory devices and its
main features are better debugging support and garbage collection.
• The ART is more optimised than the Dalvik virtual machine because the DVM
uses the JIT (just in time) compiler technology meaning that every time the code
gets compiled to the native code during the execution of the application each
time when the application run whereas ART uses AOT (ahead of time) technology
in which the apps are compiled to the native code once during the installation
process. Since the code is compiled once so it makes the ART better than DVM.
• The advantages of ART are that it improves speed (app start-up time), improved
garbage collection and reduced memory footprints i.e. less referencing of
memory by an application.

4. Native C/C++ libraries : The native c/c++ libraries are used as supporting
mechanism for many components and services like android runtime, hardware
abstraction layer and other components that require direct access of these
libraries. The e.g. of these libraries are OpenGL (for 3D graphics rendering), SQLite
(for database management), web kit (for html content), SSL (for internet security).

5. Java API framework: All the features of the android OS are available to the user
and developers with the help of Java API that act as a building block to create the
android apps. The java API framework provides number of components and
services like resource managers, notification managers, activity manager content
providers and view system etc. which are helpful in building rich and modular
applications.
6. System Apps: This section include the all the applications that are present in
the android devices either they come with the android OS preinstalled or the user

9
manually installs third party apps with functionalities ranging from a simple
calculator to a complex maps application.

3. Android Security Mechanisms

Android is an open source and free platform. Securing an open source platform
requires a careful security program and powerful security architecture. In this
section we will discuss mechanisms used by Android to make secure application
envirement.

 Android Permission Framework

A basic Android app initially has no permissions associated with it to get
access to the resources of device. Before installing an app, the current version
of Android OS displays all required permissions by app. The requested
permissions is to enforce restrictions on the resources of the devices such as
Storage, Camera, SMS, Telephone and Location, etc.

Figure 2: Android apk file structure

10
 Figure 3: Android componets and their interactions

The user can review the permission and can choose to refuse or accept them.
There are four classes of permissions: Normal, Dangerous, Signature and
SignatureOrSystem.
Normal : A lower-risk permission that gives requesting applications access to
isolated application-level features, with minimal risk to other applications, the
system, or the user.
Dangerous : A higher-risk permission that would give a requesting application
access to private user data or control over the device that can negatively impact
the user.
Signature : A permission that the system grants only if the requesting application
is signed with the same certificate as the application that declared the
permission.
SignatureOrSystem : A permission that the system grants only to applications that
are in the Android system image or that are signed with the same certificate as
the application that declared the permission.

 Application Sandboxing

Application sandboxing, also called application containerization, is an

approach to software development and Mobile Application Management
(MAM) that limits the environments in which certain code can execute.
11
 Android applications run in a sandbox, an isolated area of the system that
does not have access to the rest of the system’s resources, unless access
permissions are explicitly granted by the user when the application is
installed. In order to protect the application’s data from unauthorized access,
Android kernel implements the Linux Discretionary Access Control (DAC) to
manage and protect the device’s resources to be misused. Each app process is
protected with an assigned unique ID (UID) within an isolated sandbox.

 Inter- Component Communication (ICC)

Although each application executes within a dedicated sandbox, Android

allows applications to communicate with each other through a well-defined
Inter-Component Communication (ICC) mechanism or Binder. Android
middleware mediates the ICC between application’s components. The Binder
or ICC takes care of migrating the execution of a request from the requester to
the target process transparently to the applications. Applications can call the
components or services of other applications as service.

4. Android Security Issues and Threats

Android protection is built on a permission-based system that controls access to
sensitive resources on an Android device through third-party Android apps. Such
permission-based system is highly criticized for its coarse-grained regulation of
program permissions and the inefficient permission management, by developers,
marketers, and end-users. Users may allow all authorization requests from an app
to install it for instance, or not install the app. This kind of administration of
authorization has proven to be unacceptable for the protection of computers. The
key security concerns of Android are addressed in this section, which leads to the
leaking of user information and puts the safety of the user at risk.
4.1 Information leakage
Apps are prohibited from accessing services or other apps under the latest
Android architecture specification, unless approved by users. Before downloading

12
and using an app, users have to approve all requests for resource access. Data
leakage occurs when services are provided by users without any OS restrictions.
The permission control system of Android, however has been proven ineffective
in protecting the privacy and resources of users from malicious applications.
Studies have shown that more than 70% of mobile phone users call for
Collect information unrelated to the app's key feature. A huge number of
malware applications have been exposed to Android users for download, with
more than 1.4 million available apps in Google Play, and a vast number of apps
from different third-party markets. However, only a limited portion of users pay
attention to the resource being demanded while downloading a new program, as
they prefer to rush to get to use the application through triggered authorization
request screens. Just a limited portion (3%) of users are vigilant and have correct
answers to questions about authorization. Furthermore the latest alerts of
Android authorization do not help most users making right security decisions. The
policy of "blaming the users" has been a weakness to defend Android users.
The reasons for the ineffectiveness of the new permission control system, as
noted, include: (1) novice users do not understand that resource demands are
irrelevant and will weaken their permission control system. (2) users are allowed
to use the app and will be expected to trade their privacy for the use of the app.
4.2 Privilege escalation
Through leveraging freely accessible Android kernel vulnerabilities, privilege
escalation or authorization escalation attacks have been leveraged to obtain
elevated access to resources that are usually shielded from an application or
consumer. This method of attack will result in unwanted behavior from more
privileged than expected applications, triggering many sensitive leaks of
information. Exported components from Android can be used to obtain access to
sensitive permissions .
4.3 Repackaging Apps
Repackaging is one of the Android OS's most serious and widespread security
problems. Repackaging is the method of using reverse-engineering techniques to
disassemble/decompile .apk files and incorporate (inject) malicious code into the
main source code. On the Android platform, repackaging techniques that can be

13
used allow malicious code to be disguised as a regular app. The repackaging steps
are as follows:
Unpacking : Use available software such as apktool, which is a program focused
on reverse-engineering, to unpack APK files.
Decompiling : Decompilation of the Java source code using JAD and retrieval of
the Java class source code.
Code injection : Using Java creating environments to insert code and incorporate
capital into the core source code.
Repacking : Using apktool to reconstruct files and sign the created files using
jarsigner.
Examples of Trojans which are based on APK repackaging are Geimini and KungFu.
You can pack these Trojans into several legitimate Android applications.
4.4 Denial of Service (DoS) attack
The growing number of smartphone users and the prevalence of Internet-
connected mobile devices (phones, tablets) can be a forum for the growth of DoS
attacks. Although the bulk of smartphones not fitted with the same security (i.e.
anti-virus programs) as PCs, it is detected by malicious apps as a suitable DoS
attack platform. The key targets of DoS attacks are the overuse of available
Processor, memory, network connectivity and battery capacity.
4.5 Colluding
The possibility of collusion is a client-side attack. Users install a series of apps
created by the same creator and the same certificate in this attack and grant
various permission types, including sensitive and non-sensitive. These applications
can take advantage of a shared UID after installing applications and get access to
all their permissions and resources.

5. Proposed Solutions
In view of the protection problems we identified in section 4, several studies on
the standards and procedures for handling the use of resources and security
strategies to fix these vulnerabilities have been proposed so far. The current
technologies for protection and privacy are divided into three groups. In similar

14
pages, we clarify the divisions in more description. Because of the proposed
works we cover in this survey, various instruments and methods are used to
incorporate their solutions.
5.1 Existing techniques and mechanisms
5.1.1 Static Analysis
These works that use the method of static analysis are focused on the
specification and code of the program. We determine the main static analysis
techniques in this section.

 Application Signature Any Android program has a special signature, as we

mentioned before. Signature-based solutions search against a dictionary of
malware signatures for the substance or patterns of an application. They will
take action if they find a matching one. This approach is somewhat restricted
by the fact that only a limited range of emerging threats, such as generic
signatures or extremely broad ones, can be detected.
 Permission Analysis This system operates on the basis of permissions given
for applications. They determine the danger of the permits issued and the
sensitivity of the capital. They analyze and identify malicious apps depending
on the risk level.
 Control Flow Analysis In this type of static analysis techniques, it needs to
extract apps' Control Flow Graph  and scan inside the application's code for
current future resource misuse and vulnerabilities. They make a decision on
the maliciousness or insecurity of the program based on the risks and
vulnerabilities found.
5.1.2 Dynamic Analysis
Current works that predominantly operate on the basis of application behavior
analysis during the runtime process. Three key parameters can be assumed to be
the actions and behaviors of the application: system calls, battery consumption,
and use of the network.
5.1.3 Crowdsourcing
By soliciting input from a broad number of individuals, crowdsourcing is the
method of providing the required resources, suggestions or material. It is defined

15
in the scope of Android OS protection as a mechanism in which we collect data
from users or devices in order to enhance system security and protect privacy.
For eg, it could be gathering a device's system call log or the feedback of users on
an app.
5.1.4 Policy-based
Solutions enable consumers to specify several policies on the prepared services
using this technique in order to optimize the service. For example, the policies in
the mobile protection area might be the degree of permission to restrict apps.
5.1.5 Recommendation-based
In this technique, they assist inexperienced users by giving guidance on difficult
software protection and privacy options, such as granting app permissions and
limiting resource access to applications.
5.2 Taxonomy of existing solution
We present our taxonomy of current relevant protection frameworks on Android
OS in this subsection. Because existing works are applied using various
techniques and procedures in different ways and architectures, we can categorize
them in several ways. Our category is objective-based. If they have the same
function and functionality, we group current works into a category. We classify
them into three key ones, Category: (1) Prevention-based, (2)  Analysis-based and
(3)  Runtime monitoring.
5.3 Prevention-based
Hackers are gradually targeting binary code targets to conduct attacks on high-
value mobile apps (paid/free) across all platforms, as Dalvik bytecode is
vulnerable to reverse engineering. The binary code (e.g., analyze or reverse
engineer critical code, alter code to change program behaviour, or inject
malicious code) may be downloaded, compromised and exploited directly. 97
percent of the top 100 paying Android apps and 87 percent of the top 100 paid
Apple iOS apps have been hacked using repackaging, based on a recent analysis
report conducted by ARXAN.

16
 In this section we review excellent current work focused on app repackaging
attacks (code manipulation or code injection) and reverse engineering (code
analysis) in this subsection.

Figure 4: Overall AppInk architecture Figure 5: Kirin based software installer a

and its components

5.3.1 Kirin
The primary purpose of Kirin is to mitigate harmful applications using validation
procedures on apps at install time. In order to locate matched malicious
permission requests and functions, Kirin uses a series of predefined protection
rules on applications' requested permissions. Here the rules are established on
the basis of sensitive rights, leading to the misuse of permissions and unsafe
practices.
In order to obtain all authorization requirements for Android applications
without changing the apps, they use a static inspection tool called Pscout. Using
this install time method will help consumers make real-time choices on whether
or not to install the applications. The Kirin was checked using 311 applications
purchased from top-ranking apps from an official Android Business store. Kirin
found 5 malicious apps with a high degree of security risk after experiments. The
Kirin based program installer flow and its elements are shown in Figure 5.
5.3.2 AppInk

17
Zhou et al. are introducing and designing a graph-based hierarchical
watermarking system for Android applications to mitigate software repackaging.
In order to automatically create a new app with a transparently embedded
watermark and the corresponding manifest app, they built and created a method
called AppInk, which takes an application's source code and a watermark value as
inputs.
Through embedding software watermarks dynamically into the running state of
an app to reflect the ownership of developers, they enhance the framework. The
repackaged application can be checked by an authorized verifying party after
embedding the watermarks, and embedded watermarks can be detected without
any user intervention and contact with the manifest app. In order to retrieve the
watermark values, it is worth remembering that the embedded code fragments
can be retrieved later.
Two other works have been analyzed in order to show the efficacy and
resistance of the proposed approach and the findings suggest that AppInk is
effective in defending against typical automatic repackaging attacks.
5.4 Analysis-based solutions

Mobile malware has started taking measures to avoid detection through

camouflaging as benign software, comparable to PC malware. The key focus in
this category is to use static and dynamic analysis to identify apps' security-
sensitive and malicious activities. Proposed works in this category concentrate on
forms of attacks: (1) detection of malicious actions, (2) detection of software
similarities to detect repackaged applications, (3) abuse of given permissions and
(4) detection of vulnerabilities of apps. We analyze works in each of the above
subcategories in this subsection.

18
Figure 6: RiskMon architecture Figure 7 : RiskRanker architecture

5.4.1 RiskMon
RiskMon attempts to address the question "are they actually inappropriate
behaviors?" ”. RiskMon is a machine-learning approach to tackling this issue and
provides an ongoing and integrated platform for risk management.
The basic architecture of RiskMon is shown in Figure 6. RiskMon integrates the
preferences and runtime habits of trustworthy apps from consumers to produce
a baseline risk evaluation that collects applications' acceptable behaviors. The
core part of the framework is the opinions of users on applications. Second, in
terms of their importance to the related program, it gathers the user's
preferences regarding the installed applications on the system and the rating of
authorization classes. Then it builds the risk management baseline for its
applications based on the gathered user knowledge. Finally, RiskMon uses the
produced baseline to rank deployed applications based on the risk of interactions
with the app, which is determined by how far it deviates from the baseline of the
risk evaluation.
Regarding the introduction of RiskMon, interactions between third-party apps
and interactions which do not use Binder are not discussed. This in particular,
indicates possible attack vectors that can bypass RiskMon.
5.4.2 RiskRanker
RiskRanker, a proactive zero-day Android malware spotting scheme. It attempts
to determine the possible security risks caused by untrusted software. In order to

19
dynamically evaluate the risky actions of applications, the writers are designing
an integrated framework.
A two-stage risk analysis is conducted by RiskRanker's estimation method.
Second, high and medium-risk apps are listed. It monitors non-obfuscated
executions of applications that invoke (i) the launch of root vulnerabilities, (ii) the
development of illegal costs, and (iii) attacks against privacy breaches to
recognize these applications. In the second step of research, it conducts a further
investigation by observing unusual app activity in order to uncover certain
programs that encrypt exploit code to escape the first stage analysis. They are
designing a series of heuristics to map applications to similar risk groups (High,
Medium, and Low Risk) to overcome this issue. Figure 7 illustrates the
architecture of RiskRanker.
To assess the potential approach, 118,318 users (104,874 individual apps)
obtained from numerous official and unofficial software markets are used to
evaluate a prototype. After the assessment process, 2,461 suspect apps were
detected in the first-stage risk analysis and 840 apps were reported in the
second-stage analysis. Of these 3,281 distinct applications detected, 322 (or 9.81
% ) zero-day malware belonging to 11 different families were successfully
uncovered. It should be noted that RiskRanker's key problem is to use the same
set of basic encryption and code loading heuristics, which are not successful.

Figure 8: DroidScope’s architecture and its instrumentation interface

20
Figure 9: DroidRanger architecture

5.4.3 DroidScope
DroidScope, an Android research tool focused on Virtualization Malware Analysis
(VMA), is being introduced by Lok et al. The OS level and the Java-level semantics
views are restored by DroidScope. In fact, DroidScope is a dynamic analysis of
Virtual Machine Introspection (VMI) and is based on a QEMU emulator with a
collection of specified APIs as custom analysis plugins. DroidScope exports three
types of APIs connected to three levels of Android devices in order to capture
applications' actions and trace executions: hardware, application and Dalvik
Virtual Machine.
Two Android malware families, DroidKungFu and DroidDream, are used to
research DroidScope, and the findings reveal that they are effectively detected by
DroidScope. The architecture of the DroidScope and its instrumentation interface
are shown in figure 8.
5.4.4 DroidRanger
In this article, researchers present an analysis to assess the protection of
applications on Google Play and some other emerging unofficial markets for
Android apps. To identify existing known malware and zero-day malware, they
suggest a two-stage review. They use a permission-based behavioural
footprinting scheme in order to detect known malware. In the second level, to
classify those intrinsic actions of unknown malicious families (zero-day malware),
they implement a heuristics-based filtering scheme.

21
 Using 204,040 applications obtained from five separate Android markets, they
tested the DroidRanger. The findings reveal that 211 malicious applications were
found by DroidRanger: 32 from the official Android Platform (0.02 % infection
rate) and 179 from alternate marketplaces (0.20 % to 0.47 % infection rates). In
Figure 9, the overall DroidRanger architecture is shown.

5.4.5 DroidMOSS
In this work, a DroidMOSS device similarity measuring method is proposed that
applies a fuzzy hashing technique to find and detect improvements in the
behavior of app-repackaging. In reality, in third-party Android marketplaces,
DroidMOSS is proposed to detect repackaged applications. They test the
similarity with certain applications from the official Android stores, provided an
app from a third-party Android marketplace.
DroidMOSS extracts an app's DEC opcode sequence and produces a signature
fuzzy hashing signature from the opcode in order to detect a repackaged app.
Lastly, to see how close each app pair is, they measure the edit size. They
consider one app in the pair to be repackaged until the resemblance reaches a
certain threshold. Figure 5.4.5 indicates the example above.

DroidMOSS has many drawbacks. Next, it just measures the DEX bytecode
comparability and lacks the native code. Second, high-level semantic information
does not consist of the opcode series and this creates false negatives.
5.4.6 WHYPER

22
 To test the compatibility of requested permissions from applications, Pandita et
al. suggest WHYPER as a Natural Language Processing (NLP) solution. The
explanations given by developers of the relevant applications and the responses
to why the app requires the permissions needed are used to access the
consistency of permission requests. WHYPER takes the definition of the
application from the market (provided by the developers) and a semantic
permission model as input, and decides which expression (if any) indicates the
use of the permission in the description.
Using 581 apps obtained from established Android app markets, they checked
the WHYPER. The findings show 82.8 % accuracy, and an average 81.5 % recall for
three special permits (address book, calendar, and audio record) that secure
sensitive security and privacy services that are commonly used. WHYPER's biggest
problem is certain applications that app creators do not describe and this triggers
false-positive identification. The WHYPER summary, including its associated
elements, as shown in Figure 11.
5.4.7 PScout
In order to extract the permission definition (permission map) from the Android
OS source code using static analysis, PScout is suggested as a tool. Centered on a
call tree, built from API calls, PScout works. The way PScout derives authorization
requirements is by doing repetitive analyses of reachability between API calls and
permission checks on a call graph developed from the code base of the Android
framework.
PScout is able to obtain more authorization requirements relative to the nearest
associated job, Stowaway. They are using PScout in the recorded project to
analyze 4 versions of Android ranging version 2.2 up to the newly launched

23
 Figure 11: Overview of WHYPER Figure 12: PScout architecture

Android 4.0.0. On Android 2.2, 17,218 mappings are extracted by PScout, while
only 1,259 are derived by Stowaway. PScout Design as shown in Figure 12.
5.4.8 AndroSimilar
The authors recommend AndroSimilar, an approach that produces signatures to
detect malicious Android apps by removing statistically impossible functions. It is
successful against code obfuscation and repackaging, they say. In order to detect
Android malware, AndroSimilar uses methods such as string encryption, process
renaming, junk method insertion, and control flow modification. In order to
identify such unknown, zero day samples, AndroSimilar is a syntactic footprinting
mechanism that identifies regions of statistical similarities with known malware.
They use a statistical attribute extraction method in AndroSimilar that explores
unlikely byte characteristics for capturing code homogeneity among variants of
known apps. They define the code similarity of an unknown sample after
collecting the general similarities between known apps and investigate its
similarity to the known malicious family.
As a database of information, they actually produce signatures of known
malware applications for various malware families. They later equate the
unknown apps with the caught features. If the comparison's similarity score
passes the pre-defined threshold, the app is labelled as a malware or repackaged
pp.

24
5.4.9 ComDroid
To detect device connectivity vulnerabilities, ComDroid was proposed. Since most
of these vulnerabilities are due to the fact that Intents can be used for intra- and
inter-application communication, ComDroid investigates interactions with the
Android application and detects security risks in components of the application.
Vulnerabilities include destruction and corruption of personal data, phishing, and
other unexpected behavior.
A two-stage solution is ComDroid. Next it unpacks the DEX files of the program
using the publicly accessible Dedexer method. It parses the disassembled output
from Dedexer after disassembling applications, and logs potential part and
purpose vulnerabilities. The findings of the recorded experimentation on 20 apps
reveal that 34 exploitable vulnerabilities have been discovered by ComDroid; 12
of the 20 apps have at least one vulnerability.
There are several other similar works, besides the works mentioned in this
section: FlowDroid, Amandroid, AppsPlayGround, ScanDroid, VetDroid, Pegasus,
AppIntent, Mobile-Sandbox, PiggyApp, AnDarwin, Juxtapp, Stowaway,
DNADroid,  Androguard, APKInspector, JEB, AndroTotal, RobotDroid, CHEX,
Androwarn, MAdFraud, DECAF, MARVIN, Shinichi et al., DroidChecker, and
ProtectMyPrivacy. Both of these operations use static and dynamic review
methods to recognise the vulnerabilities of applications and spot malicious apps.

Figure 13: RecDroid Components and Architecture Figure 14: FireDroid Components and Architecture

25
5.5 Runtime Monitoring
As we have mentioned before, each application is sandboxed at the middleware
stage i.e. it runs in its own Dalvik VM case, and contact and sharing between apps
is only permitted by an inter-process communication (IPC) framework. A
collection of tools and utilities, such as sending SMS, access to contacts, or
internet access, is provided by the Android middleware. Via its authorization
process, Android enforces regulation of access to these services. Each
service/resource is associated with a certain special authorization tag in the
Android permission process, and each app must request permission for the
resources it needs at installation time. An Android runtime protection controller
tests if the app has the appropriate authorization tags for that specific
service/resource if a client requires access to a particular service/resource. In
addition to privilege escalation protection, it is also possible to track the leakage
of information.
In this segment, we identify certain activities that are focused on tracking the
operations and permissions of applications. Proposed works are constantly
operating on a device in this category to either prevent, track malicious activity,
or implement fine-grained policy. It is worth noting that policies can either be
specified by users or by systems.
5.5.1 RecDroid
RecDroid, through crowdsourcing, is a resource access permission control
framework. RecDroid aims to help users make the correct decision as to whether
to approve a permission request. RecDroid is a recommendation framework for
crowdsourcing that gathers permission requests from apps and permission replies
from users, from which a rating algorithm is used to determine the level of
competence of users and a voting algorithm is used to compute (accept or reject)
an acceptable response to the permission request. RecDroid depends on a limited
number of seed expert users to bootstrap the recommendation system that might
make accurate suggestions for a small set of applications. To classify the malicious
users and ignore their replies, RecDroid also uses a game-theoretical Bayesian
model.
Figure 13 demonstrates the architecture of the RecDroid and its elements.
Second, as authorization requests occur, the framework enables users to use
26
applications without granting all permissions and obtain support from
experienced users. In "probation" mode, RecDroid allows users to install
untrusted applications, while trusted apps are installed in usual "trusted" mode.
When applications are running, users make real-time resource awarding decisions
in probation mode. The framework also encourages the user-help-user
environment, where novice users are advised to make choices by professional
users. The functionalities provided by framework are as follows :

 For applications that are about to be installed, two app installation modes:
Trusted mode and Probation mode. In probation mode, when a resource is
required, an app must request user permission to access confidential
resources (e.g. GPS records, contact information, friend list) at runtime. The
app is trusted in Trusted Mode and all permissions are granted.
 An interface for intercepting and gathering applications' requests and replies
for authorization, from which recommendations are made as to what
permission should and should not be given to apps
 A recommendation system to direct users with decision-making permission by
providing users with expert user reviews on the same applications.
 A user-based ranking algorithm for ranking mobile app security risks.
5.5.2 FireDroid
FireDroid, by interleaving process machine calls, is a policy-based mechanism to
implement security policies. An application control is generated in FireDroid to
track all processes spawned in Android and allow/deny them based on policies
controlled by humans. At runtime, FireDroid detects whether an application is
performing illegal or potentially harmful behavior by intercepting function calls
that are performed by the application. No matter whether the malware is new or
a repackaged version of an existing one, FireDroid will recognise and implement
the necessary security protocols when the malware performs unsafe system calls.
They use the ptrace() feature in FireDroid to control the actions of the apps at
runtime without changing the application or Android code. The architecture of
the FireDroid and its current components can be shown in Figure 14.
FireDroid's biggest benefit is that it is fully open to both the applications and the
Android OS. This suggests that a strong interaction would not involve users. Users

27
just need to identify the applications' policies and load them into the system
through the policy portal offered by FireDroid.
5.5.3 MockDroid
The aim of MockDroid is to prevent confidential data from being exposed by
granting false permission and allowing the user to interactively give fake or 'mock'
data to applications while the application is being used. MockDroid helps users to
withhold access to specific resources at execution time and encourage them by
using an application to understand the trade-off between accessibility and
disclosure of personal information. For instance, a way to defend against
confidential data leakage may be to have no place fix available" for GPS location
access.
Although such techniques minimize the risk of leaking private data and vital
information, MockDroid allows users to make decisions on each request for
resource authorization, which is difficult for inexperienced users and time
consuming for others.

Figure 15: TaintDroid Components and Architecture

28
Figure 16: Crowdroid Architecture

5.5.4 Crowdroid
Crowdroid is a malware identification scheme dependent on actions. In
Crowdroid, using a crowdsourcing framework, they identify abnormally acting
applications. In order to differentiate between applications that have the same
names and versions, but function differently, the authors suggest a framework to
examine the behavior of Android applications.
It has two parts, a lightweight client application that needs to be installed on the
computers of users and a remote malware detection server, as Figure 16
indicates. The program tracks the actions of applications installed, such as device
calls, and sends them to a centralized remote server as a log file. Via a system
utility named Strace, the application tracks the system calls. The log file consists
of information about the device, a list of applications installed and behavioral
data. The remote processor, on the server side, will be in charge of parsing data
and generating a system call vector for users within their programs per
encounter. Finally, to detect whether the applications are benign or malicious, the
collected data would be clustered through 2-mean partition clustering.
Although the client apps must still be open, the key drawback of Crowdroid is
the draining of the available device resources. The biggest downside of this job is
that the data is transmitted to the FTP protocol, which is not stable.
5.5.5 TaintDroid
TaintDroid is a tracking device for data flows that helps users to monitor and
analyze confidential data flows and potentially detect suspicious applications.
TainDroid offers specialist users with a tool to spot misbehavior from future apps.

29
In order to keep track of when the marked data leaves the device, the confidential
data is immediately tainted. TaintDroid records the mark of the data and the app
that sent the data, along with its destination address, when the branded data
leaves the device.
Variable-level, method-level, file-level, and message-level fine-grained labels are
used by TaintDroid. Using the interpreter's variable-level semantics provides
useful context for mitigating the taint explosion found in the x86 instruction set.
In order to reduce IPC overhead when expanding the study system-wide,
TaintDroid uses message-level monitoring between messages from applications.
For Android native libraries that are not specifically available to applications but
by browsers, method level tracking is used. Firmware Changed. Finally, TaintDroid
uses File-level tracking to guarantee that the taint marks are conservatively
maintained by permanent data. In Figure 15, the above situation is shown.

Figure 17: AppGuard architecture Figure 18: Overview of FlaskDroid

5.5.6 AppGuard
AppGuard is a flexible system for enforcing user-customizable security policies on
Android applications that are not trusted. Indeed, AppGuard operates on the
basis of Inline Reference Monitoring (IRM) and lets users implement third-party
applications with predefined user policies. Not only does AppGuard limit the
outreach of third-party applications, but also the operating system.
The total view of the AppGuard can be seen in figure 17. First this solution
modifies third-party application APK packages in such a way that it invokes a
security monitor prior to running each security-relevant program. It simply calls
30
the protection call to the Android system libraries prior to each feature call.
Secondly, the security monitor tests whether the currently implemented security
policies allow the application to call the device, and then relies on the predefined
policy to allow the user to execute or reject the requested authorization and to
call a method to return the dummy data as a result.
AppGuard provides the user with a standalone application that is installed on
the user's device in order to determine user policies. Because AppGuard only
modifies the application package and not the operating system, it makes the key
benefit of this approach to implement policies without rooting phones or
changing the operating system.
5.5.7 FlaskDroid
To provide Mandatory Access Control (MAC) concurrently on both the
middleware and kernel layers of Android, FlaskDroid is proposed as a
standardized security architecture. As a scalable and productive ecosystem,
FlaskDroid facilitates the implementation of numerous security technologies and
various fine-grained security policies. They develop a policy language inspired by
SELinux, adapted to the specifics of Android middleware semantics, in order to
extract organizational semantics from the Android middleware.
Policy-driven instantiations of chosen security models, such as the current Saint
task, as well as a new privacy protection, user-defined and finegrained per-app
access control model assessed the flexibility of the FlaskDroid. The accuracy and
effectiveness of the work on SE Android 4.0.4 were also assessed. Figure 18
demonstrates the architecture of the FlaskDroid and its components.
5.5.8 Porscha
To secure DRM-based content (e.g., MP3-based MMS, SMS, or email), Ongtang et
al. suggest Porscha as a mechanism built within the Android middleware in
content proxies and comparison monitors to implement DRM policies contained
in content obtained. Porscha's key objective is to enhance the enforcement
mechanism of the DRM regulation to ensure: (1) authorized access to protected
content (2) accessibility of content by provider applications, and (3) capacity to

31
Figure 19: XManDroid architecture Figure 20: TrustDroid architecture

access content under policy-defined contextual restrictions, e.g. limitation of

time, maximum number of views, etc.
Policy compliance at Porscha is a two-stage process: the safety of the
information sent to the device and the control of the use of content on the
phone. For the first point, Porscha links policy and guarantees "on the wire"
content secrecy using Identity-Based Encrypted communication construction and
infrastructure. Porscha enforces policies by proxying content channels (e.g., POP3,
IMAP, Active Sync) for the second stage and placing reference monitor hooks
within the Binder IPC framework of Android. Using the three most popular
content types: SMS messages, MMS messages, and email, they analyzed the
Porscha. Porscha has less than 1 second of low content delivery latency in the
recorded experimentation.
5.5.9 QUIRE
Dietz et al. suggested QUIRE, a security mechanism focused on a call-chain
monitoring strategy that gives important context to local and remote apps
communicating through IPC and RPC in the form of provenance and OS controlled
data security in order to deal with ICC-based attacks and control interapp ICC.

Based on two key techniques, QUIRE has been developed. The first approach is
focused on observing the call chain of IPCs and annotating IPCs that exist within
the telephone so that the IPC request receiver can observe the entire call chain

32
involved with the request. Second, to encrypt data passing over IPC and RPC
channels, QUIRE uses basic cryptographic mechanisms. In this way, QUIRE helps
apps to spread the meaning of the call chain to downstream calls and to validate
the sources of data they receive indirectly.
By conducting a series of tests, they tested QUIRE using two self-developed
applications on the standard Android developer phone. The overhead of QUIRE
for network RPC in the reported experiment is practically insignificant.
5.5.10 XManDroid
Bugiel et al. applied XManDroid to privilege escalation attacks. XManDroid is a
security framework that extends the Android OS monitoring process, based on a
system-centric system policy, to detect and avoid application level privilege
escalation attacks at runtime.
XManDroid records all communications between apps and analyzes the
transitive authorization use of apps dynamically. A review mechanism against a
series of policy rules should be passed through supervised contact connections.
Finally, device representation allows for the successful identification of (covert
channels built by Android system services and content providers, based on

Figure 21: AdDroid design Figure 22: NativeGuard architecture

predefined policies, while optimizing the rate of false positives at the same time.
Figure 19 displays the XManDroid architecture.
In our test suite, they evaluated the effectiveness of XManDroid, which
simulates known application level privilege escalation attacks (including

33
Soundcomber) and demonstrates successful identification of attacks using the
inter-component communication (ICC) framework (standard for most attacks) of
Android.
5.5.11 TrustDroid
TrustDroid, a safety architecture that requires lightweight domain isolation on
each layer of the Android software stack, was introduced by Bugiel et al. In other
words, in a compact way, TrustDroid attempts to separate data and apps from
various layers of trust. Each domain here represents an Android OS protection
level, including the kernel layer, middleware layer and network layer.
They change three layers of the OS in order to deal with the three domain
isolations listed above: extending the Android middleware and the underlying
Linux kernel to mediate IPC apps aligned with various domains, changing the
standard Android kernel firewall to filter network traffic using netfilter, and
manipulating the file system by extending the current Android Linux kernel with
TOMOYO. TrustDroid was tested on an Android device (Nexus One) and the
efficiency of TrustDroid was low overhead and low butter consumption in the
published results. TrustDroid Architecture is illustrated in Figure 20.
5.5.12 AdDroid
AdDroid is suggested to handle and isolate privileged advertisement features
from host apps in such a manner that advertising is viewed by applications
without requiring privacy-sensitive permissions. AdDroid modifies the Android OS
and aims to run the central ads code in different security domains and to separate
the host application. It also implements a new advertisement API and related
Android platform advertising permissions. It is worth noting that AdDroid adds
two new permissions for Android, Ads and Position Advertisement, respectively.
Figure 21 describes the AdDroid architecture and its key components.
In order to control advertisement rights, AdDroid provides a new Android
privilege separation service. In this way, developers can use the predefined
AdDroid advertising APIs to include advertisements in their application. But,
without granting privacy-sensitive permissions, applications will view advertising.
27 % of advertising-supported applications do not require internet access in the
recorded experiment using AdDroid, 25 % do not need location information, and

34
 Figure 23: Paranoid Android overview

8 % do not need phone state information. They report that in 46 % of advertising-

supported applications, AdDroid would reduce over-privileging.
5.5.13 NativeGuard
In NativeGuard[110], Sun et al. presented a framework that utilizes the process
isolation of Android to sandbox an application's native libraries. Through isolating
native libraries from other components of Android apps, NativeGuard leverages
the process-based security of Android. NativeGuard Architecture is seen in Figure
22.
There are two primary facets to the NativeGuard isolation process. First, within
an Android application, it distinguishes the native libraries from a standalone
application, where native code is not given complete access to the entire address
space of the application and the interactions between native libraries and Java
code are satisfied through the IPC mechanism. Second, the permissions given to
the app during the installation process are not granted to the native libraries
during the isolation process. In this manner, NativeGuard reduces the probability
of misuse of authorization and over-privileging attacks.
5.5.14 Paranoid Android
Paranoid Android is a threat control scheme that is extended to a remote security
server hosting reliable phone replicas in virtual environments (cloudbased
detection framework). The key innovation of this work is the shift of the checking

35
process from the user computer to a remote server. It is worth remembering that
the key reason for running security checks on a remote server is because of the
shortage of adequate mobile processing power and battery usage.
A two-stage process is the security monitoring system that PA follows.
Monitoring the actions of the applications and capturing and uploading logs to
the server is the first step that should be performed on the device. To decrease
the log transfer overhead, it only sends the log if the device is awake and
connected to the Internet. Analyzing the obtained logs from devices is the second
step. To search files, PA uses an antivirus based on ClamAV. In addition, a taint
analysis is conducted by PA to spot memory corruption attacks. The system is
tested and documented to be both functional and scalable: generating no more
than 2KiBps and 64Bps trace logs for high-load and idle operation respectively,
and supporting more than one hundred replicas running on a single remote
server.
 There are several other similar works in addition to the works mentioned in this
section: BayesDroid, TISSA, AppFence, LP-Gaurdian, Andromaly, AirBag, AdSplit,
AFrame, LayerCake, CRePE, Apex, ASM, Aurasium, Dr. Android and Mr. Hide,
Saint, IPC Inspection, MalloDroid, L4Android, AppSealer, Pyandrazzi, Morbs,
PatchDroid, CryptoLint, IccTA, DroidBox, Drozer, CooperDroid, DroidPAD,
DroidTracker, ProtectMyPrivacy, Imails et at. . These functions all collect the
actions and system calls of apps, and use a series of predefined policies to limit
the activities of apps.

6. Conclusion
Android has become a very common smart phone operating system these days. In
the android mobile, there are some advanced features for which users can
conveniently share applications from the online market store, i.e. Google store for
the market. But this network contains attacks and risks, such as malicious apps
that target real Android applications as well. Since on-device malware can
generate a variety of threats, creating connectivity problems due to security
problems. This paper explains how the protection of the Android Operating
System can be improved so that consumers can use Android smartphones safely.

36
 This study focused on offering a detailed summary of the established order by
elaborating on the key components that form the Android operating
environment. Android's very impressive, accelerated evolution parallels the
excellent work over the years achieved by the Linux community. As discussed in
this article, in the use of android devices, the android architecture was discussed
in a thorough way and idealized some security concerns and sought several ways
for users and developers to solve security problems.
In such a dynamically changing environment, both in terms of product
advancement and the threat landscape, in the months and years to come, other
protection concerns would quickly evolve. The steps discussed in this text serve as
a reasonable starting point to provide Android devices with a protection
benchmark. Theoretically, not having personal devices on to the network at all
would be the preferred option, and this could prove a successful though often
controversial decision. The risk-reward ratio is never going to appeal to a security
specialist, but for users, this is one of the minor issues. There is no powerful one-
stop protection measure that can be applied on an Android smartphone.
Certainly, when it comes to enterprise applications, one of the emerging products
provides the mobile protection tool kit with some much needed features.
However these solutions are difficult to incorporate on personal devices for
organisations, and do not really offer an appropriate solution on an individual
smartphone. As an user, comparable features and security can be offered by
several of the behavior listed here. In the absence of a systematic approach, a
robust suite of security measures and software must be developed by the
company or customer. The key here is to maintain the balance whereby
protection is used as an enabler and does not impair the device's regular usage
too significantly; inability to do so will lead to security measures being
circumnavigated. It will be prudent to address some of the key security
implications associated with a smartphone as part of security education and
knowledge. Providing a set of software that can be installed on a smartphone by
delivering an encrypted preloaded SD card means that the organisation of
consumers is not impacted by the rapid development in mobile malware. A
enterprise is just as safe as the weakest provider or user, and mobile devices
produce all sorts of possibilities for malicious activity-the path of least resistance
would be the most tempting for cyber criminals, and there are plenty of possible

37
vulnerabilities and attack vectors, both known and unknown, to take advantage of
in such a modern technology area.

7. References
 International Journal of Scientific and Technical Advancements
http://www.ijsta.com/papers/IJSTAV2N4Y16/IJSTA-V2N4R21Y16.pdf
 Android Security Issues and Solutions https://ieeexplore.ieee.org/document/7975551
 Android Security issues and solutions
https://www.researchgate.net/publication/318412307_Android_security_issues_and_solutions
 Android Security issues https://www.purevpn.com/blog/android-security-issues-in-2019/amp/
 Operating System Concepts by Abraham Sitberschatz, Peter Baer Galvin, and Grey Gagne.

38