Android Application Assignment Help

Programming Assignment Help

PROGRAMMING ASSIGNMENT HELP

Anti-Malware Evaluation for Android Platform

Introduction:
With the increase in mobile computing devices which works on Android app platform or uses android as an operating
system there is problem which is increasing too and i.e. Malwares.
Malware is a generic term used to describe all the malicious executable programs like viruses, spyware, Trojans and
worms. Malicious software becomes a serious threat to integrity, personal data and computer systems. Unfortunately,
malware has turned to a profitable business for malware authors and their customers. Malware authors or writers sell
their malicious software toolkits to inexperienced customers who can easily create their own customized malware
software in no time. There are tens of thousands of new malicious variants which are used to launch attacks, where
each variant may only be targeted at a single machine. Thus the problem of the large distribution of malicious software
is most probably to grow in future.
Malware detectors use various anti malware techniques like virus signature scanners and heuristic methods, to protect
from malicious software. Most of the current commercial anti-viruses tools depend on a database which includes
syntactical patterns or regular expressions that characterize known malware variants. Anti-virus companies very
frequently updates their databases whenever an unknown variant of malware is found in the environment. According
to a study we found that the number of variants approximately triples every year.
It is been reported that on android (one of the most common platforms for mobile devices like cellphones or tablets)
the growth of malware has constantly been on the rise and the platform is seen as clearly todays target. With the
growth of malware activities, anti-malware tools or anti viruses also grows there production and features. There are
various anti malware tools available on android app store Google Play Store.
Androids open design allows users to download and install applications that not necessarily supplied by Google Play
Store. There are around 20,000 new applications being released every month which consists of applications from
Googles official channel and also the applications from the third party app stores. This figure needs malware
researchers and app stores administrators to have access to a scalable solution to quickly analyze new apps and
identify malicious applications.
Google reacted to the growing interest of malware authors by producing BOUNCER in Feb 2012, a service that checks
apps submitted to Google Play Store contains malicious matter or not. Whereas, researches done on BOUNCER
declared that it has a very low detection rates and it can be easily bypassed.
In this work we present an evaluation platform for Android applications development to detect suspicious possibly
malicious applications. We provide ways to aid malware researchers to fully understand the behavior of malwares. By
using evaluation techniques we have the advantages that our results are not hindered by obfuscation techniques used
in the application. Running application in a sandboxed environment allows us to keep track of applications entire flow
control without applying complex decompilation and deobfuscation techniques.

Background information:

www.programmingassignmenthelp.net

Before discussing the details of our evaluation framework, it is insisted that you understand the concepts of how Android
and Android apps work. In this topic we explain a short introduction with the Android Architecture.
There are four subsections in this topic:

Architecture of Android System:

Figure 1 Android low level System Architecture

The Android platform stack depicted in the above figure. In the above figure, green items are components written in
native code(C/C++), while blue items are java components interpreted and executed by Dalvik Virtual Machine. The
Linux Kernel components are represented by the bottom red layer and these runs in kernel space.

Kernel:
Android consists of a specialized version of Linux Kernel with a few special additions. These include wakelocks.
Wakelocks are the mechanisms which are used to indicate that applications need to have the device stay on. These
also include memory management system that is more powerful and aggressive in preserving memory, the Binder IPC
driver, and other features that are important for a mobile embedded platform like Android.

Libraries:
Libraries are a set of native C/C++ codes. These libraries are exposed to the Application Framework and Android
Runtime via Libraries component. These are mostly external libraries with very minute modifications such as OpenSSL,
WebKit and bzip. The essential C libraries, codename Bionic, were ported from BSDs libc and were rewritten to support
ARM hardware and Androids own implementation of pthreads based on linux futexes.

www.programmingassignmenthelp.net

Runtime environment of Android:

Android Runtime the middleware component consists of Dalvik Virtual Machine or Dalvik VM or DVM and a set of Core
Libraries. It is responsible for the execution of applications that are written in the java programming language. The core
libraries are an implementation of general purpose APIs that can be used by the applications executed by the DVM.
Categories of core libraries are distinguished into two categories:

DVM specific libraries:

It allows processing or modifying VM-specific information and is mainly used when byte code needs to be loaded into
memory.

Java programming language interoperability libraries:

It provides familiar environment for Java programmers. It implements most of the popular java packages such as
java.lang and java.util .

Framework used by application:

Various android.* packages are provides by the framework as high level building blocks. Most components in this layer
are implemented as applications and run as background processes on the device. Whereas, some components are
responsible for managing basic phone functionalities like text messages or receiving phone calls or monitoring power
usage. Read more about Website design Assignment

Applications:
Applications are built on top of the framework for application. They are responsible for the interaction between the users
and the device. An average user never has to deal with components which are not in this layer.

Dalvik Virtual Machine:

Android device offers users extra functionality that is why software developers are encouraged to write applications on
this platform. Google uses java as the platforms main programming language as it is the most popular language: It has
been the number one programming language over the last decade and a large number of development tools are
available for it like Netbeans or Eclipse. Java code is normally compiled to and distributed as java bytecode which, at
runtime is interpreted and executed by a virtual machine. For android, Google uses different bytecode and VM (Virtual
Machine) format. These format is named as Dalvik. During the compilation process of Android apps, Java bytecode is
converted to Dalvik bytecode which can later be executed by the specially designed Dalvik VM.

www.programmingassignmenthelp.net

Figure 2 Dalvik Virtual Machine

Apps:
Apps of Android are distributed as Android Package (APK) files. APK files contain the apps bytecode with all its data,
resources, third party libraries and a manifest file that explains the apps capability.

Figure 3 Generation of the APK file.

Applications run in a sandboxed environment. During installation applications receive a unique Linux user ID from the
Android OS.

Code in Native languages:

Native languages like C or C++ are found to be helpful for certain type of applications. Native codes runs directly on
the processor and is thus not interpreted by DVM, unlike Java byte codes.

Malware:
www.programmingassignmenthelp.net

In Android malwares are mostly using social engineering to trick users into installing the malicious software.

Different types of Malware:

SMS trojans: They are also known as fake installers. These apps acts like an installer for legitimate software
and trick users by installing themselves on their devices. On execution, the app displays a service agreement
mostly and once the user accepts for the agreement, it starts to send premium rated text messages. And the
promised functionality is never available, most of the time. These includes variants which consists of
repackaged applications that provide the same functionality as the original paid app, but have additional code
which secretly sends messages at the background. These are relatively easy to implement. These consists of
only a single main activity with a button that initiates the sending of a SMS messages whenever it is clicked.
This type of fraud is also known as toll fraud. These apps are very popular amongst malware authors as it is
easy to implement / manufacture and gives a high profit.
Botnets: These are also known as Spywares. It forwards the private data of the user to a remote server. In a
typical spyware malware can receive instructions from the server to start specific activities on the device, that
is how it becomes a part of a botnet. It uses components which are discussed above. Mostly components
such as broadcast receivers are used to secretly forward incoming messages to a remote server from which
it is getting instructions.

Distribution of Malwares:
There is a lack of accountability in in third-party applications. There are no restrictions on the number of applications
which are uploaded by the developers on the application market which gives rise to poor and unreliable applications
uploaded on these market places. Juniper networks finds that malicious applications are often originated from these
marketplaces, China holds 173 stores hosting some malware and Russia holds 132 such infected stores holding
malwares. These both are the worlds leading suppliers of malwares.
Android has loose management of devices thats why it has to deal in respect to malware distribution. Android have
been fragmented various times. This fragmentation creates new security features and these security features are
available to a small group of users who uses latest versions of Android release. This fragmentation has a drawback
that users who havent purchased the new device will never reach the majority of Android users, until they purchase a
new device.
There are security enhancements done whenever a newer version of Android launches like the more control of SMS
feature. In this feature the user gets notified whenever an application tries to send a SMS message that might cause
additional charges. This feature prevents a large amount of Android users from previously well discussed SMS trojans.
New releases of Android versions also consists of bugfixes for core components to prevent against random code
execution exploits. After Android version 2.3.7 all the versions are vulnerable to these root exploits. These exploits
were mainly developed to overcome the limitations that carriers and hardware manufactures put on some devices, also
a higher level privilege level without a users consent is obtain by malware using this. Using this approach malware are
allowed to request for only a few permissions during app installation, but they can still access the entire system once
the app gets started.

Data Sets of Malware:

Android Malware Genome Project and Contagio Mobile provides public access to Android Malware samples which are
known. A project discovers over a 1200 Android malware distribution which are classified in 49 malware families and
were searched in the period of August 2010 and October 2011. This project is named as malgenome project which was

www.programmingassignmenthelp.net

conducted by Zhou and Jiang. To share mobile malware samples among security researchers, Contagiodump offers
an upload dropbox. It also hosts 114 items.

Design of the framework:

In this topic we are defining the scope of our analysis framework.

Design:
To implement this framework for the analysis of Android applications, we have to consider things and their solutions:

Kind of information to be collected from the Application.

How to run the application in a sandboxed environment.

Collection:
In this section we discuss that what kind of information is to be collected. Dynamic analysis of applications are used to
get a description of the system calls made by the application which is targeted. And this overview provides a good
understanding of applications capabilities. Android applications are java based unlike the regular binary files seen on
the desktop PCs. To run these apps, the DVM is responsible for doing all the functions necessary to run the app like
interpreting, translating, and executing. The bytecode of the app. This place between the code blob and execution of
the code is where we should implement our dynamic analysis platform: we can display detailed information of apps
internal processes like its function calls, return statements etc by installing hookups within the bytecode interpreter.
Using this we can implement our own method tracer. We can still use strace utility to get an exclusive list of system
calls to run targeted apps while tracing on them. This combination of method and system calls gives us the detailed
information on the apps functioning internally. Anti-Virus analysts can use this information to reverse engineering
suspicious applications and identify malicious behavior.

Designing of Framework:
Android qemu-based emulator is used here which comes with the standard Android SDK. SDK stands for Software
Development Kit. Simulations like initiating phone calls, receiving text messages etc are being served by AVD which is
deployed and triggers all the activities mentioned above. AVD stands for Android Virtual Device which deploys every
time we need do any simulations. Here we decide to base our framework on Android 2.3.4 which is also called as
GingerBread.
See Basic Web Designing Assignment
Here we build a Phython based framework that accepts an APK file as an input and give log directory which holds the
results as output.

www.programmingassignmenthelp.net

Figure 4 Design for Android Analysis Platform

This figure depicts the apps behavior, in it the app will be installed and executed in a modified Operating System that
runs on the top of qemu. The operating system have tracing capabilities added which generates method trace output
on per process, per thread basis.
The given framework works mostly on dynamic analysis, but there should be also some static analysis which is
important to understand how to simulate different events. Mainly, we need to parse the apps Manifest file i.e.
AndroidManifest.xml to get the information about the app. This information can be its package name, names of the
activities and services it holds. We are using ANDROGUARD project to get this information. Manifest file could be
corrupted and became unidentifiable by our static analysis tool. This is discovered recently as OBad malware sample
which demonstrates the above. Although we still continue dynamic analysis and try to get the information later in
analysis flow.
Plug-ins are accepted in this framework which acts as post processing scripts. The location of the log output directories
are received by these scripts which contains the method traces and network traffic capture. Also these scripts receive
the location of the original input APK and may use these files to compute more analysis results.

Native Code:
In this we excludes the native code execution from our work. Manifold is the reason why we are doing so. According to
a statement given by Spreitzenbarth et al. there are only 13% malicious apps that uses native code. This means that
most of the apps which uses native codes are less likely to be malicious with respect to the apps which does not uses
native codes at all. The statement is given using the fact that most Android functionalities are not accessible using only
native codes that is why we are not focusing on them specially. At last, there are two effective tools to trace the native
codes:

One for system call tracing.

Another to keep the track of library.

www.programmingassignmenthelp.net

Using combination of the above specified tools we are able to get ample amount of information as an output to check
or study the native code execution.

Description:
In this topic, we give a brief of the requirement and the desired outputs. In this we also included a discussion on existing
solutions and their inefficiency.
1.

2.

Specification: We want it to generate readable and easily understandable output files. According to
convention the output file should look like original source file of the application which is analyzed by it. It is
difficult to get, using dynamic analysis alone, because the initiation of all control flow paths in the automated
simulation of events lefts the output incomplete. Here loop detection is also being considered and also the
detection of rewrite for and while statements. An overview of all called methods including all API calls gives a
good information for the analyzer. All the methods that the app makes are the thing we should check, including
the values which are provided as parameters to these methods and their return statements or thrown
exceptions.
Solution which are already existing: The Android operating system and Software Development Kit already
gives a tracing method and profiling solution that collects all the information when the profiling occurs on the
executed methods. The drawback of this method is this, that it does not provide information about the
parameters, return values and thrown exceptions used in the methods. We cannot start the tracer at the time
of the startup of application without altering source of the app. This tracer omits the internal system library to
system library method calls. At last, overhead in generated by this tracer which is quite big in size.

There is also an existing solution in which we use JDWP (Java Debug Wire Protocol) and a Java debugger like jdb.
But here also to work like this we have to define a way by which the applications which are targeted can be made debug
able and also write the setting and unsetting the breakpoints which are in jdb, to get automated code execution.
Debugger is used to get more and more information about the apps internal working, including the field operations.
Now, we will extend these existing solutions of tracing methods and profiling functionality.

Implementation:
Here we explains that how we implements our automated framework for the analysis of the Android applications.
There are following sections in which implementation notes are divided:

Framework of Android: Except the alterations which are made to the virtual machine of Android i.e. Dalvik
Virtual Machine, a set of alterations are also done to the internal framework of Android which are necessary
to successfully integrate the new Virtual Machine into the framework of Analysis.
Framework of Analysis: The implementation of the framework is responsible for initiating analysis that starts
automatically and which simulates the events which ore mentioned. Here we also specify the post processing
plugins and the tool which allows the easy inspection of analysis results.
Weaving of the bytecode: It is explained below in detail.
Tracing of method: Our framework for analysis is mainly biased to the tracing of the app which is been targeted
to be likely malicious app.

Implementation:
Here we discuss the implementation of the method which traces for Android OS by giving it a technical analysis of the
alterations made to the Dalvik Virtual Machine internal system.

www.programmingassignmenthelp.net

Extension of the profiling section of the Virtual Machine for Android (DVM) gives us the capability of the getting the
desired log outputs as depicted. Here the work which should be concerned the most is modifying the function which is
called every time whenever a method is entered or exited. This gives us the opportunity to look up the calling class, as
well as the methods and parameters which gets executed, and also the value which is returned to it called as return
value whenever a method returns.

Tracing starts:
Firstly we need to tell the VM that which application is to be traced. Now we modify the DVM initialization code in two
ways, firstly the uid of the app which can be used as a conditional variable is added to the function which initializes
apps in the Virtual Machine. This option is then forwarded to zygote process which is the parent of all the instances of
Virtual Machine by providing the proper argument, whenever the emulator starts. The assignment or giving the uid
parameter is possible only when the boot procedure is going on. And this process is only started once. The new uid is
matched with the provided uid whenever Zygote process forks and this enables tracing method if it requires. It doesnt
matter that application forks new processes itself or not the provided uid will be the same in any case. From the above
statement it is clear that tracing method is called automatically for children created by the app in every case.
Secondly, this step is added just after where a new Virtual Machine is forked and starts its initialization. Here if we try
to read an integer from a file. And if it is able to read it as well as matches the uid of a new process created by the
Virtual Machine then the tracing method is called.
The output of all this is traced in the memory card. Virtual Machines are running as ordinary users, they might not have
the write access on memory card by default, so to write it in the memory card we modifies the Manifest file
AndroidManifest.xml. By doing this we are always able to write the output logs in the memory card.

Profiler control flow: A function is called every time on the entry or exit of the original virtual machines
bytecode. For upgrading the tracing method we can do several things. Like changing its prototype so that they
want two extra variables. To differentiate between the specific function calls which are in-lined from regular
functions we modifies the prototype to int. Extra information which are to be stored in the tracing method are
stored in a pointer named options having datatype void. This pointer also stores the exception thrown by the
class.
For initialization, checks are performed to see that f is a predefined function or not, which means is it a function
from the system library. If it is, we simply continue. Otherwise the functions bytecode is matched with the
bytecode of the applications bytecode which is targeted to be suspicious malware. LL
Starting execution with the method: A function is responsible for creating an entry on the entry method tracing
line which are used to check whether the method has started executing or not. Firstly, we create prefix of the
line (output) which consists of some indentation to get readable output and a timestamp. If f is not a constructor
then we create a representation of the object in a string format. This will be the first argument for other normal
functions which are not constructors. Some functions do not have a this reference, this thing should be kept
in mind because this complicates the function in for loop a little. Function f gets a character pointer to the type
descriptor of the parameter. It then performs a switch/case statement to build a string in a correct format which
simply depends on the descriptor. Till void, all the transformations which are done are mostly straight forward.
Java UTF-16 encoded characters should be converted into printable UTF-8 C String because characters are
very complex due to above specified fact. Arrays can be converted to a readable primitives as well by applying
a little more effort. This method now calls an inline method which first locks a dedicated mutex used for write
lock which is then carried out by creating the output file. The above is only done when it is not done before.
The output file is open in append mode using a function. If the file is ready for writing then true is written
otherwise it returns a false as a result. The mutex which is used here as a write lock is used to make sure that
there should be no other writing operations to be done while this thread is writing on the file, at this time the
tracing method is disabled. The memory regions in the method which are used to store lines which are output
of the method. The depth value of the method is being increased for this thread so that indentation is done
correctly for the next function entries. The performance of our application can be improved by replacing a
function calls by modified/altered version of function which does log writing for the present Android tracing

www.programmingassignmenthelp.net

method. This is a modification of Android qemu sources to increase support for tracing Java method
entries/exits. A memory mapped page is used to enable the communication between emulator and the
application, and this is the concept which is used by this method.
Exiting a method, method is exited whenever a return statement is interpreted or otherwise any exception
does not occurs. When done with it, it decreases the depth value of the thread to do the indentation correctly
for the function entry which is to be occurred next. Implementing this is also similar to the above method.
Exception throwing, A function is called which handles the exceptions which are pending and this method
prints the trace line of the thrown exception. Whereas another method unrolls the thrown exception which
indicates that the next parent in line gets the exception which is forwarded. The functions which intermediates
unrolls the exception. All the exceptions which are stored in options argument are stored as a pointer of Object
class. For exiting from the method we fetches the exception our selfs using a function.
Tracing stops, All the trace lines generated by tracing method are written to the files which resides on the disk
using a fprintf() statement. So to flush all the output from the buffer to the file which resides on disk we need
to explicitly stop the tracing method. Tracing method is stopped by executing the stop command on normal
conditions which calls the method that is used to exit the tracing method. Here, a additional code I added
which checks one by one the thread list using loop and closes any open tracing methds output file. Whenever
any exception is left uncaught the exiting method does not calls then to avoid log files to be incomplete we
add the above closing loop here also so that whenever a thread gets into such exception it is closed using the
above specified function i.e. fclose(). There is no compulsion that uncaught exceptions will always result in a
total crash of Virtual Machine. This is the reason why trace output files can be reopened again in append
mode.
Extra options for Virtual Machine are added. These extra options needs different way of starting the virtual
machine with these extra options. Some of these extra options are uid which is used to check with the UID,
tracepath where all the traced outputs are stored to use this option the caller should be sure that the folder is
already created in which the traced outputs are to be stored, a flag which is used to disable parameter lookups,
another flag used to disable timestamps, another flag which is used to disable method to string which converts
any object into its string representation and these all flags are used for debugging and benchmarking
purposes.

Integration of Andrubis:
ANUBIS and ANDRUBIS are platforms which are online services used for analyzing malwares which are developed by
ISS (International Secure Systems) lab. The goal of both of us similar that is why cooperation is beneficial for us. This
ANDRUBIS framework works on the framework which is based on DROIDBOX which is originally developed for Android
2.1 which was then updated by ANDRUBIS developers for Android 2.3.4 after a few months of the first release. The
modified DROIDBOX output is used to create XML files which holds or contains the analysis results, and this modified
DROIDBOX is used by ANDRUBIS. It produces a rating also which is given by an algorithm. The rating is given from 0
to 10, where 0 stands for benign and 10 stands for malicious. API calls which are traced by it results to the dependency
of analysis results which highly depends upon these API calls and also on the functions that are called within the
package. The statements of the effectiveness of the complete framework is created using the outputs. Due to this, we
decides to implement it by making changes into the existing Android source trunk directory of ANDRUBIS.

Framework modifications:
There are also some changes left which are to be applied to the framework of Android to give a better support. Here
we specifies the steps which are required to update in the framework of Android to get an optimal solution using
integrated tracer and Android OS.

Process killing: During analysis a problem may get arise in which the app which is being analyzed is killed by
the Activity Manager (AM). And on this operating system means Android operating system killing an app
means killing the VM (Virtual Machine) on which the particular app is running and this leads to destroying the
data which is being given as a output of the tracing method which is not yet being flushed into the file on the

www.programmingassignmenthelp.net

disk. To overcome this problem we would modify the Kernel signal handler of Android. It is modified in a way
such that the tracing method is stopped prior the actual signal is sent to the Virtual Machine (VM). Almost all
the kills are done by a single class within the Activity Manager Service. Thats the reason we decides to alter
the implementation of Activity Manager (AM) rather than writing the kernel code for it. To decrease the number
of incomplete log files we change all the kill processes to the new prototype, to make sure that tracing method
is stopped before an app is killed.
Stop the blocking of am profile: Here we uses existing activity manager command to stop, this ensures that
all the output data id flushed to the disk before it fetches files from the device. All the files which are opened
are flushed using fclose() operation which is a result of stopping of tracing method. It is difficult to understand
that when the files are ready to be retrieved for the framework, this is so because the activity manager profile
command is non-blocking. Internals of Activity Manager are modified to make the command (am) work until
the tracing method disables completely. Follow the function calls and understanding how changes are
necessary, it is an interesting process done due to different layers of abstraction. Now we discuss that how
Android IPC and its abstraction layers are developed or implemented
Moving from am to AM: am command is the entry point. To talk with the activity manager service we have an
interface implemented which is according to the study is a system private API calls. This reverses the flow
back from application to activity manager. Now the interaction between am and activity manger is possible by
using proxy. The IPC is triggered between am and the Activity Manager by proxy function calls using the
Binder kernel driver. At last we successfully switched to the activity manger from the user process am to the
global activity manager which contains information on all running processes on the Android device.
Moving from activity manager to targeted app: Some sanity checks and looking up for the requested process
in its map of Process Records are done by a function which Is implemented only to serve these functionalities.
If the sanity checks which are performed are passes by the app then a method is called to control the profile.
Here also the abstraction layer which is used is similar to the above specified abstraction layer. It contains a
class that is used to create proxies requests between apps and Activity Manager. A function is called to initiate
Binder IPC with the thread of the Activity. To tell the Activity Manger about the things which are needed by the
application or it needs to do, an application is implemented which on startup provide all the data of things the
app needs do.
Moving from application to Dalvik Virtual Machine: Here a function is patched which is used in the case of stop
request. A function which is implemented to be called directly instead of using other mechanisms. Due to this
change we are sure that before am profile stop request in done or completed the function does not returns.
Values of Timeout: The overhead of our application is likely to leave an impact on the performance of the
operations system i.e. android. Earlier we have discussed that android manager uses a fixed amount of
timeout values before the apps are marked unresponsive and also a dialog is shown on which it is written like
App Not Responding (ANR). They are a bit annoying because they consume valuable analysis time,that is
why they are of no use for our platform. To overcome this problem we decides to increase the timeout value
of app by 20s to compensate the overhead which is produced by our application. Another thing is that we
changed the behavior of activity manager in which the Activity Manger simply kills an unresponsive app without
showing the ANR (App Not Responding) dialog. The timeout value for dismiss is decreased from 5 minutes to
10 second, this is done by modifying the Activity Manger by which unexpected crash dialogs are only shown
for a very brief amount of time before they are dismissed.

Framework of Analysis:
Analysis of Android Applications are done by our application. In short our application accepts an APK file as an input,
analyzes it and then give the traced logs into files as an output. These files are known as output logged files. In analysis
first static analysis is done after which dynamic analysis starts and at last it searches for plug-ins. After searching post
processing is performed on the plug-ins to the log output.

Static Analysis: In static analysis we search for the Manifest file of the app i.e. AndoridManifest.xml file. After
searching for it a short description is written on a file. This description can be further used in dynamic analysis.
Dynamic Analysis: It initiates a virtual device which uses our systems image which is being modified on
installation. There are various steps which are done one by one for the dynamic analysis of the framework.
These steps are installing the application first, then starting the logcat, then establishing the network capture
and then before returning into the main loop it enables the tracing method of the Virtual Machine. All the
actions, simulations and executions are then iterated by the main loop. Here if we want to speed up the
runtime, we provide a subset of simulations as arguments. To allow the manual analysis of the targeted

www.programmingassignmenthelp.net

application there is a special command available called manual command that will leave the shell very quickly
after the app is installed. Now to initiate specific functions like sending a SMS, receiving a call, could use the
internal emudroid object. The pseud random generator is currently set to 1337 and is always started with the
same seed value for it. This gives us the guarantee that re-executions of this create the same sequence of
events. These events which are created include clicks, touches, and gestures as they could be created by the
user also. After all the tracing is done the tracing method is disabled and log files are fetched from the device.
Post processing: Post processing means the processing which is done after all the tracing operations are
performed on the app which is targeted to be suspicious. The post processing files and directories are
searched and runs the python modules found on it. There exists a special function in which the post processing
is done which expects the path of the app which is targeted and also the path of the output log directory in
which the logs of tracing are to be stored and a static analysis object which holds the results of static analysis
which is helpful in post processing. Here, we created some of tools for post processing that adds required
functionalities to the platform for dynamic analysis. These functionalities are described in a detail below. The
percentage of APK functions that are initiated during the dynamic analysis of the targeted app can be
calculated by using listed methods that were executed by tracing method in dynamic analysis. Static analysis
results in a list of functions provided by the APK and these functions are then mapped to the functions found
against it. Mapping of methods are done on the basis of their signature which excludes the parameters types
which they expect and also the modifiers. There are two types of coverage calculation: one is conservative
and other is nave. The functions are ignored whose function signature matches to the signature of the APIs
of Android libraries. There are also apps which come with the third party advertisement libraries and these
third party advertisement libraries comes with many method signatures, and thus we exclude these libraries
from coverage calculation to get a good quality of number of methods called which are only written by the
apps author only. Those methods are excluded from the coverage calculation whose signature matches with
the signature of the methods found in excluded APIs. The above step consists of a risk to loose signatures
which are a part of applications core packages. But these are named according to the APIs that are popular.
That is why the option was kept as default calculation technique. Our second plug-in is used to generate a
footprint of the app which is targeted along with their return values and parameters. This is used to identify
the app as a malicious or benign using the resulting features which are used by machine learning programs
or algorithms which cluster and generalize the result. Bloom vectors are created to store the record of number
of function/API calls. To store the log results we use MYSQL database so that it is easy and fast later to use
the information of the analysis results.
Output is inspected from the parser which comes with the framework. This parser parses the files that are
created by our framework. Parser typically works on the concept of first loading the function or loading the
constructor entries and also the return values or thrown objects respectively into one object. Fields here are
described in detail the main motive of the function is to search log files or directories and then parse them.
The trace results can be then accessed by the analyst using the traces dictionary. These trace results are
then used to create traced objects which stores the functions field and constructors list is stored in the
constructor object. All these objects come with number of fields like modifiers, parameters, exception, return
type, return value, name, depth, line number, time stamp. The parser also consists of a function that is used
for creating a graph for the analyzed app. There is also a function which is used to give a textual representation
of the graph with no parameters. See also Website Document Assignment

Bytecode Weaving:
This is a technique which connsists of bytecode of Java with new code segments which are also called aspects. These
aspects are used in Aspect Oriented Programming (AOP) paradigm. Here we are discussing that how AOP helps us
to write the alternative of our Application that completely works on the level of application.

www.programmingassignmenthelp.net

Figure 5 Bytecode Weave Process

AOP makes it possible to add or weave new functionalities into the already working or existing bytecode. This
thing does not requires permission to access the original source codes. Tracing methods functionalities are
added by this technique into the existing application. We now describes how the tracing method can be made
enabled for the application and also how the sources are to be compiled with how the apps are to run or
executed without doing any further alterations. Tracing aspect added to the method which calls the target
method are ensured using a set of specifications of when the code is executed. The prologue and epilogue of
the target methods are used in the case when API calls are missed by us as they cannot be rewritten by the
compiler. The above is a simplified version and some more important functionalities are still left to be
implemented. When porting this mechanism to Android applications a problem arises that is manipulation of
existing bytecode libraries which are used by Aspect oriented programming compilers. There are some
compilers which do not support the modifications of Dalviks bytecode. To solve this problem the dalviks
bytecode is first converted back to the java classes first, before this the tracing method is weaved with the
bytecode. The patched java classes are repacked into a new APK that can be installed on any Android device
only when weaving gets succeeded. A tool is used to decompile the Dalviks bytecode back to Java bytecode.
The compiler which are used by us seems to be crashed many times during the weaving process when the
analysis is performed. It is more to jump rather than jumps are too far to arise in it when large methods are
weaved with the trace aspects.

www.programmingassignmenthelp.net

Bytecode weaving has both merits and demerits, here we discuss them. While there are better results of the
analysis which are traced and are more specific or sophisticated but the bytecode weaving does not need to
change Android environment to perform actual analysis, this is the advantage of bytecode weaving over virtual
machine method tracer. There are some disadvantages also such as the signature of the packages codebase
can be detected by an application which is malicious when we are rewriting the app. The app hides its
malicious behavior and hence getting a low malicious rating when the malware writers decides not to initiate
detrimental activities if he finds that the classes have changed. Signature of the app does not matches after
the repackaging in which the signature of the signed jar file i.e. APK of the app is replaced with another
signature. The complication which occurs in the process for signature checking that is possible to be
intercepted. This interception is done by special aspects. The repackaging process can break the process can
be broken in the obfuscation techniques if the size of method is increased from its maximum. Smaller chunks
are made of the large methods to solve this problem. Advantages that bytecode weaving has are like the need
of the modified version of Android operating system does not exists anymore because now the code is injected
directly into the app directly as code snippets. By this the platform is made independent as the apps are
installed and simulated as version independent. There is no need of creating and installing a new customized
firmware, the apps can be installed and analyzed on real hardware. So by this it is possible for the users to
analyze the applications using their own devices. Malware authors become worthless as they use emulator
detection mechanisms. Extending the tracing method becomes easy when compilers traces are used. These
are the advantages of bytecode weaving over the application.

Evaluation of existing dynamic analysis platforms:

There are various existing analysis platforms present. In this section we describe about their design, implementation,
merits-demerits and also comparing them with our dynamic analysis platform. Platforms are:
AASandbox:
The first platform developed for dynamic analysis of Android applications was developed by Blasing et al in October
2010. This platform uses static analysis for further analysis. Static analysis includes scanning of the software for
malicious patterns. The further analysis is done on the basis of a loadable kernel module developed to obtain system
logs. For detecting the suspicious applications it uses a system call footprinting approach. Regrettably, at the time to
evaluate this technique there were no known Android malware samples present. It seems to be unmaintained
nowadays.
Compared to it our platform in implemented on a higher abstraction layer, namely the Dalvik VM instead of the Linux
Kernel. It allows our platform to get more details on the executed java components. However, we got the similar result
of executed system calls.

Bouncer:
As discussed above in the introduction, Google announced Bouncer in February 2012. Every application which is
available on Google play or play store for downloading is first executed on the Googles cloud infrastructure and gets
simulated as it is actually running on an Android device. After launch of the Bouncer only little information is provided
about the internal functioning of the applications. Bouncer was been dissected by Oberheide and Miller in June 2012
during Summercon. The time of analysis of Bouncer which it takes is 5 minutes to analyze an application to be malicious
or not. By connecting a connect-back shell to communicate with the application under investigation and were able to
obtain more detailed information on the environment which is used by Bouncer to run the application for analysis. Also,
Google

introduced

an

application

verification

service

by

the

release

of

Android

4.2,

the

ACTION_PACKAGE_NEEDS_VERIFICATION broadcast introduced, used by the OS to verify newly installed

applications and check them for known malware. This was introduced in October 2012. Operating System sends

www.programmingassignmenthelp.net

information about the app and the device to the Cloud of Google and requests for the verification response during
installation.
Andrubis:
It is also discussed above. It is released by ISSL (International Secure Systems Lab) in June 2012. It is also a dynamic
analysis platform for Android Applications. It was the first to offer a web design interface publically where users can
submit Android applications for the dynamic analysis. A XML report is generated at the end of the analysis process
which holds the footprints of behavioral and static analysis of the application which is requested for the analysis. It uses
VMI to intercept the system calls made by the native code execution.
By joining our platform with the Andrubis, our platform performs very extensive dynamic analysis platform that does not
only track taint propagation which detects the privacy leaks. But after all this it also stores or records system calls and
Java method traces.
DroidScope:
It is a detailed dynamic binary instrumentation tool for Android based on Virtual Machine introspection. To obtain the
same results as ours, it reconstructs the Dalvik instruction traces. The main difference between our platform and
DroidScope is only this that the DroidScope is bound to the emulator, whereas ours may run on actual hardware. The
malware authors can implement the functionality in malwares in which the malware does not starts the malicious activity
on the emulator.
AppsPlayground:
It was introduced by Rastogi et al in February 2012. It uses TaintDroid for taint propagation and it also traces Java
APIs and system calls specifically. Its main contribution is an improved execution approach to explore GUIs. This
functionality is been added by us in our platform to increase the coverage of code.
Mobile-Sandbox:
It is released in March 2013. It uses a combination of the three Andrubis, TaintDroid, and DroidBox. It uses a ported
version of the utility to trace natie library invocations rather than VMI to trace system calls. This utility can be a profitable
addition to our platform. It allows users to request for the dynamic analysis of the suspicious applications, which is
served by them.
CopperDroid:
At last, Reina et al introduced CopperDroid in April 2013. This uses the mechanisms which are used by the DroidScope.
The mechanism uses VMI to collect all the system call information applications about analyzed applications. Android
malwares are briefly exposed by the CopperDroid which points out their stimulation techniques and system call-centric
analysis. It also comes with a web interface where suspicious applications can be submitted for analysis.
TaintDroid:
It is released by Enck et al in October 2010. A modified operating system keeps track of taint propagation at runtime
which is used to detect the privacy leaks. Going on with time, the researchers added it as a profitable addition to perform
the dynamic analysis on Android Applications. Its limitation is that it cannot track taint within the native code because it
is implemented as a modification of the Dalvik Virtual Machine. It is different from our platform as it does not come with

www.programmingassignmenthelp.net

set of applications or scripts to allow automated analysis and stimulation of unknown applications. It also doesnt keeps
track of the any specific method invocations like we does. We can make our platform by extending its framework with
the functionalities that keep track of field operations and then using this data to implement taint tracking functionality
as a post processing plug-in.
DroidBox:
It was developed in 2011 by Patrick Lantz as part of Google Summer of Code. Androids core libraries are modified
and then combined with TaintDroid to develop DroidBox.
Different-Different events are logged at the time of execution of an application. Some of them are:

Attempts to send SMS messages.

Phone calls that have been made.
Opened network connections.
Cryptography API activities.
Outgoing network traffic.
File read and write operations.
Information leaks through networks, files or SMS messages.
Visualization of analysis results and automated app installation.

Our platform differs from DroidBox, as our framework traces all method invocations, including those occurring within
the application whereas DroidBox looks for API calls which the developer thinks is interesting. Our approach can also
trace the malware if the application uses third-party API libraries.
Since, DroidBox was the first dynamic analysis platform which is openly available it is taken as a base system for many
other dynamic analysis platforms including above discussed Andrubis, Mobile-Sandbox, and SandDroid.

Read more about Web Application Testing Assignment

Additional Works:
All the research done for the Android security and Mobile malware is becoming the most popular topic of research
these days. The additional work is divided into three points first is the surveys and background details.

Survey reports:
Schimedt et al was the first to discuss about the security of Android smartphones by focusing on its base i.e. Linux in
2008. The nature of Androids open ness provides a great research work on its security aspects. The first research on
it was done by Enck et al on Androids permission. Another research was done by Shabtai et al in 2010, in which an
assessment is done on Android framework. After all these researches and Androids development, most of the threats
still exists. Some of them are like which are exposing the private contents of the user of the device, draining the
resources, exploiting the vulnerability in the Linux kernel or system libraries, uses permissions granted to the installed
applications and last is compromising the network maybe internal or protected. Several recommendations are done to
improve Androids security mechanisms with respect to these threats. Most of the Android malwares originates from
these threats. A paper was also developed that concludes that the current mobile monetization schemes has low

www.programmingassignmenthelp.net

revenue per infection ratio. This ratio should be increased according to expectations when more devices stores
credentials backed by momentary funds.

Knowledge should be systemized:

Dozens of frameworks are proposed with the release of Android which serves variety of purposes fulfilled. In this topic
a brief summary is created which is based on their main purpose and approach. To have a complete overview of the
available Android security mechanisms which are a part of Android related tools. For this the open source applications
are also considered. These tools may not be the tools on which the researches are going on but they are helpful in
developing them and also providing help to develop them for the researchers who are working on Android security. The
systemization of knowledge consists of some things like attributes. Attributes are grouped into small number of subcategories. These sub categories can be one of the three provided below, first is type, second is Technique, and last
is deployment. Type attributes defines the type of research which is done for a particular framework. Some examples
of type are detector framework, analysis framework, Defense framework and attack framework. Technique defines the
various techniques which are used to implement the framework. There are also various types of techniques which are
used to implement the work such as static, dynamic, system calls, de-compiler, weaving, tracing method, virtual
machine introspection, taint tracking etc. Deployment consists of the description that how the framework is deployed
and implemented if the framework is available for download. But there is a way for the frameworks which are not
available for download to be deployed and implemented, in this the proposal techniques are used as guesses on how
it is implemented. There are deployment types also present which are described below like is it an android app, android
operating system, or the application which is an ordinary web application. Different deployment techniques are used
by proposals. Systems which only uses a modified emulator are listed as sole applications with no changes done to
the operating system. Availability is also the factor which should be discussed here as it contains the certificate of open
source or closed source for the development of the framework.
Classification are also necessary for the frameworks as it provides the ease of identifying the particular framework. It
is classified into different categories. Some of them are:
First is, static analysis in which the analysis tools performs static analysis on the applications which are targeted for the
analysis. The result of these are simple tools which are used to aid research analysts.
Second is, dynamic analysis in which the applications which are targeted are executed on in a controlled environment
to get some kind of behavioral footprint. A report is generated in this which contains the result. These reports usually
contains the malicious rating of the application. These also use some form of static analysis during an earlier step.
Third is, Static defenses which helps them to describe the proposals which uses static analysis for detecting the
applications which contains malicious code or are suspicious.
Fourth is, dynamic defenses which helps them to describe the defense mechanism which protects users against
malicious applications by using approach of dynamic analysis. These proposals are developed as a modified operating
system for keeping the track of specific changes which occurs at runtime. They also keeps track of the policies of
permission to prevent the application from accessing components which are restricted.
Fifth is, repackaging, this is used to describe the proposals which are small in number and used to detects or prevents
the repackaging of Android apps. Additional malicious payloads are disassembled and repacked legitimate application.
Mostly this is a type of an app which is paid and given a free version by fooling the user.

www.programmingassignmenthelp.net

Sixth is, Attacks which describes small number of previously attack vectors from the Android platform that are unseen.
Seventh, it contains all the other miscellaneous efforts of research which do not fit in any other class type.

Conclusion:
At the time of high spreading of mobile application malware among Android devices there is a need of a quick approach
to quickly analyze and detect unknown malware families which are not known yet. We presented a platform by which
we can evaluate the anti-malware tools and also provided with a solution for it. In it the tracing method is implemented
by which the malwares can be traced in a targeted application and produced output is written in the log files by which
the rating of the app can be generated that is it malicious (10) or benign (0). These malware samples are then stored
in the database to use afterwards as a signature. These signatures are then used as a matching objects which are then
matched with the other applications afterwards which may contain the signature of the same family type. If the signature
matches the application can be easily considered as malicious. And the version of malicious code is of the family by
which the signature matches. In it we also provided a comprehensive knowledge systemization in which we classifies
and summarizes a large number of research projects focusing on Android security in general.

www.programmingassignmenthelp.net