Linköpings universitetSE–581 83 Linköping

+46 13 28 10 00 , www.liu.se

Linköping University | Department of Computer and Information Science

Bachelor thesis, 16 ECTS | Information Technology

2018 | LIU-IDA/LITH-EX-G--18/030--SE

Functional and Security Test-ing of a Mobile Client-ServerApplication

Daniel HolmbergVictor Nyberg

Supervisor : Simin Nadjm-TehraniExaminer : Marcus Bendtsen

Upphovsrätt

Detta dokument hålls tillgängligt på Internet – eller dess framtida ersättare – från publicer-ingsdatum under förutsättning att inga extraordinära omständigheter uppstår. Tillgång tilldokumentet innebär tillstånd för var och en att läsa, ladda ner, skriva ut enstaka kopior förenskilt bruk och att använda det oförändrat för ickekommersiell forskning och för undervis-ning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd.All annan användning av dokumentet kräver upphovsmannens medgivande. För att garan-tera äktheten, säkerheten och tillgängligheten finns lösningar av teknisk och administrativart. Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i den om-fattning som god sed kräver vid användning av dokumentet på ovan beskrivna sätt samtskydd mot att dokumentet ändras eller presenteras i sådan form eller i sådant sammanhangsom är kränkande för upphovsmannens litterära eller konstnärliga anseende eller egenart.För ytterligare information om Linköping University Electronic Press se förlagets hemsidahttp://www.ep.liu.se/.

Copyright

The publishers will keep this document online on the Internet – or its possible replacement– from the date of publication barring exceptional circumstance. The online availability ofthe document implies permanent permission for anyone to read, to download, or to printout single copies for his/her own use and to use it unchanged for non-commercial researchand educational purpose. Subsequent transfers of copyright cannot revoke this permission.All other uses of the document are conditional upon the consent of the copyright owner.The publisher has taken technical and administrative measures to assure authenticity, secu-rity and accessibility. According to intellectual property law the author has the right to bementioned when his/her work is accessed as described above and to be protected againstinfringement. For additional information about the Linköping University Electronic Pressand its procedures for publication and for assurance of document integrity, please refer to itswww home page: http://www.ep.liu.se/.

©Daniel HolmbergVictor Nyberg

Students in the 5 year Information Technology program complete a semester long softwaredevelopment project during their sixth semester (third year). The project is completed in mid-sized groups, and the students implement a mobile application intended to be used in a multi-actor setting, currently a search and rescue scenario. In parallel they study several topicsrelevant to the technical and ethical considerations in the project. The project culminatesby demonstrating a working product and a written report documenting the results of thepractical development process including requirements elicitation. During the final stage ofthe semester, students form small groups and specialise in one topic, resulting in a bachelorthesis. The current report represents the results obtained during this specialization work.Hence, the thesis should be viewed as part of a larger body of work required to pass thesemester, including the conditions and requirements for a bachelor thesis.

Abstract

Today’s massive usage of smartphones has put a high demand on all application develop-ers in the matter of security. For us to be able to keep using all existing and new appli-cations, a process that removes significant security vulnerabilities is essential. To removethese vulnerabilities, the applications have to be tested. In this thesis, we identify six meth-ods for functional and security testing of client-server applications running Android andPython Flask. Regarding functional testing, we implement Espresso testing and RESTfulAPI testing. In regards to the security testing of the system, we do not only implement fuzztesting, sniffing, reverse engineering and SQL injection testing on a system developed bya student group in a parallel project, but also discover a significant security vulnerabilitythat directly affects the integrity and reliability of this system. Out of the six identified test-ing techniques, reverse engineering exposed the vulnerability. In conjunction with this, weverified that the system’s functionality works as it is supposed to.

Acknowledgements

We would like to thank our supervisor Simin Nadjm-Therani for all the help and supportwe have received during this thesis. We would also like to acknowledge all the support andvaluable feedback received from our classmates.

v

Contents

Abstract iv

Acknowledgements v

Contents vi

List of Figures viii

List of Tables ix

1 Introduction 11.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Aim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Research questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.4 Delimitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.5 Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Background 32.1 The system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

3 Tools for software testing 53.1 Functional testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53.2 Fuzz testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63.3 Sniffing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63.4 Reverse engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63.5 RESTful API testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83.6 SQL injection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83.7 Related works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

4 Applying these testing tools 104.1 Functional testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104.2 Fuzz testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124.3 Sniffing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134.4 Reverse engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134.5 RESTful API testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154.6 SQL injection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

5 Results 195.1 Functional testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195.2 Fuzz testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195.3 Sniffing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205.4 Reverse engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225.5 RESTful API testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

vi

5.6 SQL injection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

6 Discussion 256.1 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256.2 Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276.3 The work in a wider context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

7 Conclusion 29

Bibliography 31

A Appendix - Espresso testing 34

B Appendix - RESTful API testing 40

C Appendix - Code analysis 43

D Appendix - Code manipulation 45

vii

List of Figures

2.1 System topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

3.1 SQLIA flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

4.1 Login activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114.2 Map related activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114.3 Contacts related activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124.4 SQL injection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

5.1 Trace of a log in . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205.2 Trace of adding a case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215.3 Trace of a call between two clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225.4 Relevant data stored in user table before manipulation . . . . . . . . . . . . . . . . 225.5 Relevant data stored in user table after manipulation . . . . . . . . . . . . . . . . . . 235.6 Unauthorized access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235.7 API testing results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245.8 App crashes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

C.1 Source code of target application shown in the JD-GUI program . . . . . . . . . . . 43

viii

List of Tables

5.1 Espresso testing results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195.2 Monkey testing results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

ix

1 Introduction

From 2014 to 2020, the number of smartphone users in the world is expected almost to double[1]. Android plays a big part in this since it contributes to approximately 85 % of the globalsmartphone usage [2]. Whether you believe this is a good or a bad thing, a more connectedworld implies that more devices are exposed to various threats.

1.1 Motivation

The smartphone is one of the most common categories of all connected devices we use on adaily basis. We use them for a considerable amount of tasks, and the area of use is expandingrapidly. So is the application market. When handling data, we do not want anyone to manip-ulate or access our data without our consent. Since we are so dependant on the technology,we also want it to work seamlessly. These requirements put a demand on developers to testtheir applications for flaws that might lead to unwanted consequences.

Today, the word security, especially information security, concerning connected devices is asupreme topic about which many people are worried. We believe that this might depend onlack of knowledge by the public. With all this in mind and the fact that being an engineer doesnot just come with abilities, but responsibilities, engineers nowadays really need to considerthe security aspect when developing new technology and software. Would you trust a newcar although it has not yet gone through extensive tests?

In this thesis, we are going to test a system that has been developed in parallel with the projectthat aimed to implement a proof-of-concept system for the Swedish Emergency Service usedin a search and rescue scenario. This system consists of an Android application that commu-nicates with a Python Flask server. A detailed description of the system will be presented inchapter 2.

If an application needs to store any form of information, it is most likely using a databasewhich runs on a server. The number of ways that this server can be set up in, is quite afew. In conjunction with different programming languages there also exists a wide range offrameworks that can be used to make the server suit one’s needs.

1

1.2. Aim

Flask is a micro-framework based on Python which was developed in 2010 [3]. With rela-tively new frameworks comes a great need for testing to make sure that they do not have anysignificant security flaws.

1.2 Aim

The aim of this thesis is to briefly acquaint the reader with functional testing and give a moreprofound and comprehensive understanding of a few security testing techniques in regardsto Android applications. The thesis also aims to chart which of these techniques that aremost suited for determining the confidentiality, integrity, availability and the reliability of thesystem that is going to be tested.

1.3 Research questions

Based on the purpose of this project, we in this thesis will:

1. Investigate which security vulnerability of the developed system that affect the confi-dentiality, integrity, availability and the reliability of the system.

2. Identify methods for client-server applications running Android and Python Flask toilluminate the system’s security vulnerabilities.

3. Apply the identified methods to the developed system to detect security vulnerabilities.

1.4 Delimitations

As we mentioned in the aim of this report, we will limit the scope of this thesis in regards tothe number of testing methods. It is not possible to cover all existing testing techniques. Wewill specifically not treat denial of service attacks since this topic is widely covered in anotherthesis similar to ours in parallel with this project.

Due to our previous knowledge of the system under test, this thesis does not perform ex-tensive SQL injection tests. Knowing that the system utilises libraries which mitigates SQLinjection attacks, the expected outcome of such an attack would result in unnecessary timespent. However, since you cannot be sure that a library behaves as it should, some basic SQLinjection testing has been performed.

Worth noticing is that every command used in this study were executed on the macOS andthus has to be changed to work in a Windows environment. Also, all tests performed target-ing the front-end Android application were made during the development process, and thusnot on a signed application.

1.5 Structure

The rest of the paper will be structured according to the following. First, chapter 2 will coverthe background relevant to this thesis and chapter 3 will include the theory. After this chapter,the method is added. This is later followed by the results and discussion. Last but not leastour conclusion regarding this thesis is presented.

2

2 Background

As mentioned in chapter 1, we are conducting another project in a larger group in parallelwith this one. This other group consists of seven people, and the project goal is to develop aproof-of-concept system for a user group such as the Swedish Emergency Service.

2.1 The system

The system consists of an Android application which communicates with a back-end serverto:

• Store and retrieve data about different emergency cases.

• Setup a communication channel between various employees and also with other rescueauthorities, such as the police and paramedics.

The purpose of the system is to be used both on a daily basis as well as in emergency situ-ations. Another aspect to consider is that to access the system, every user is required to beauthorised.

The application is developed for the Android OS using Android Studio, and the back-endserver runs on Python and utilises the Flask microframework. The server also consists ofa single MySQL database which is implemented with the help of SQLAlchemy, a Pythonspecific database toolkit [4]. There exist two identical sets of servers and databases where thesecond set is just a replica which will be used if something happens to the first one, that is, abackup. The topology can be visualised according to the following figure.

3

2.1. The system

Android client

Python Flask server

MySQL database

Figure 2.1: System topology

To understand what will be tested and why, we will now present the functionality of the app.This is later in chapter 4 followed by the course of events that will have to take place to testthe system.

One of the most important functionalities of the application is that it demands a valid user-name and corresponding password by the user to be able to log in. Every user has a certainrole within the organisation and reciprocal app permission which allows the user to interactwith different functions.

Another critical functionality of the app is providing a service where employees can call eachother. Both via a standard voice connection and via video. The second primary activityfor this app is the map functionality. Users can put out pins on a map which symbolisedifferent cases. These cases could, for example, be fires or car crashes. Since different userscan have separate authorisation (with the use of a stored role_id-attribute) when it comesto functionality, some might be able to add pins, and some might also be able to edit anddelete them. A user’s location is also shown on the map in order to facilitate distribution ofresources. Thus, a user’s latitude and longitude is stored on the back-end server as lon- andlat-attributes.

These permissions also play a big part regarding the call functionality. Some users should notbe able to call everyone whereas others should have the ability to call whoever they want.This requires the app to use multiple layers of validation and security checks to providedependable and secure functionalities.

This thesis will use the system mentioned above as a tool for investigating its problem state-ments.

4

3 Tools for software testing

In this chapter, we aim to give an overview of software testing. The focus will lay on thesecurity testing, but as mentioned in the introduction, we will also synoptically present thenecessary background for Android client-side functional testing. The following chapter willlay the foundations of our method.

3.1 Functional testing

To fully understand the security testing scope, we must first understand the system vulner-abilities and why it is important to also test the user interface (UI) on the client-side. Theprimary purpose of these UI tests is to test the actual functionality of the app and possibleunwanted activities it might generate. These UI tests can be categorized as functional tests.

From a user perspective, and possible attackers, the UI is what defines the Android appli-cation and is one of the most exposed parts of the whole system. The UI enables a varietyof possible unwanted user inputs and activities that need to be investigated and tested bythe developers. Fortunately, there exists multiple different frameworks and tools to help de-velopers to create automated UI tests on the client side. One of the most used and mostappreciated frameworks is the JUnit, with the use of the Android specific Espresso API [5].

JUnit & Espresso

JUnit is an open source framework that provides functionality to create unit tests, which inobject-oriented programming is referred to testing a specific method or class. This frameworkmakes it possible to build UI tests in Android with the Espresso API. Espresso is providedby the Android Testing Support Library and is a comprehensive tool for automated UI tests[6]. It utilises the AndroidJUnitRunner class which is a JUnit test runner that simplifies theprocess of running tests in three steps [7]:

1. Deploys the developed app and tests onto an emulator or device.2. Runs tests on the emulator or device.3. Finally reports back the results of the performed tests.

5

3.2. Fuzz testing

One of the main strengths of Espresso is its comprehensible syntax, and the UI testing canbe integrated with a back-end server by simulating the server response time. This can beachieved by utilising the Java-specific Thread.sleep(int milliseconds) function to pause the UIinteractions until a successful response is received from the server [8].

3.2 Fuzz testing

Fuzz testing, or fuzzing as it is also commonly known by, is the art of intentionally giving aprogram unexpected inputs to discover bugs and thereby vulnerabilities [9]. The problemwith this method is that there may be an infinite number of inputs that can be tried to finderrors.

The process itself might not be so complicated. Even though most fuzzing is executed au-tomatically, the most trivial form of fuzzing can be hammering the keyboard and see whathappens. It is not hard to find inputs to try. The difficulties consist of exploring and inves-tigating all possible inputs. This is an NP-complete and thereby combinatorially intractableproblem.

Monkey testing

Monkey testing is one form of fuzzing and is very easy to use. It can for example run directlyon your emulator in Android Studio via the command line and simulates a specified numberof pseudo-random inputs for the application. The compelling thing about this feature is thatthe testing environment is customisable. It can, for example, be customised to disable andenable individual input types depending on the intention of the tester [10].

3.3 Sniffing

Sniffing is one of the most common types of security vulnerability exploitation techniquesand has the intent of accessing information sent between communicating parts, e.g. exploit-ing the communication between a client and a server. This type of connection can, for exam-ple, be sniffed by using an open source program called Wireshark.

Wireshark

Wireshark is developed for analysing network packets and tries to display packet informationas detailed as possible. Thus giving the user a way of measuring the network layer activityand its content [11].

3.4 Reverse engineering

Reverse engineering is a technique with the objective of dissecting a target application tofacilitate the analysing process of the application for maintenance or further developmentpurposes. This technique can be further divided into two main parts; code reverse engineer-ing and data reverse engineering. The goal of code reverse engineering is to understand howthe application logic is implemented by analysing the source code, whereas data reverse en-gineering attempts to illuminate which data is stored by the application and how it can beused in a different context [12]. Reverse engineering is not a technique of altering the targetapplication but merely an analysing procedure [13].

With the knowledge obtained from reverse engineering, the developers can then perform aso-called restructuring of the target application. The primary objective of restructuring is tomodify the retrieved source code concerning unmet specifications of the original application

6

3.4. Reverse engineering

without altering the actual functionality of the application [13]. This can be used in differentcontexts, rather than just further development, through manipulation of data stored in thesystem by modifying the source code.

Reverse engineering process

All Android applications are packed into a single Android Package Kit (APK) file. Thus, theprocess of reverse engineering an Android application is initiated by obtaining that specificAPK-file. This can be done by extracting the APK directly from a device with the use ofapplications like APK Extractor [14] or Assistant for Android [15]. Once the APK-file has beenextracted, the applications class-files (of type .java) can be accessed and dissected through theuse of three open source programs:

• apktool [16] - Decompiles Java bytecode into Smali assembly code and binary resourcesinto initial XML format, which enables code reviewing of the important AndroidMani-fest.xml and resources-folder [17].

• dex2jar [18] - Converts the Dalvik Executable classes.dex-file, located inside the APK, intoa .jar-file containing multiple Java specific .class-files.

• JD-GUI [19] - Decompiles .jar-files into readable .java-files.

Each tool plays an integral part in disassembling and disclosing the source code of the targetapplication [20].

However, it is not possible to manipulate the obtained class-files due to incomplete and inac-curate conversion when using dex2jar to convert Dalvik bytecode (written in the .dex-files)into Java source code (stored in the .class-files). Nevertheless, the mentioned JD-GUI can re-strictively be used to understand the higher level implementation logic of the application. So,to successfully manipulate the source code of an Android application, one needs to manipu-late the low-level assembly source code instead. As described in [17], the low-level assemblylanguage used by the Dalvik Virtual Machine (DVM) is called Smali. Each .dex-file consistsof multiple .smali-files and Smali code is a lot easier to comprehend than Dalvik bytecode.

Once the APK has been disassembled, with for example apktool, the previous signature ofthe application is invalid and thus needs to be re-signed. This makes it impossible to createa manipulated APK, extracted from Google Play, and later distribute it as an update on thesame Google Play market. However, this is only true if the source APK has already beeninstalled on the device, thus allowing installation of privately signed manipulated APKs [17].This means that there cannot exist duplicate applications with different signatures on thesame Android device.

There exist multiple approach of mitigating a reverse engineering process. The currently mostused approach is to obfuscate the source code by altering the name of classes, methods andvariables. Some also adds redundant code-snippets to make code analysing exhausting. Oneof the most commonly used tools for obfuscating Android source code, though it is somewhatminimal protection, is a program called ProGuard [21].

An increased need for research and studies on Android application security has inducedmultiple different methods and tools for detecting a repackaged Android application. Jiangand Zhou et al. [22] demonstrates a way of detecting repackaging tendencies with the useof a fuzzy hashing technique. Gonzalez and Stakhanova et al. [23] dictates a less computa-tional heavy detection process referred to as AndroidSOO which instead leverage the layoutof the important .dex-file and its string identifiers offset. All of the aforementioned meth-

7

3.5. RESTful API testing

ods provides a complementary way of testing an Android application for possible securityvulnerabilities made by malicious repackaging intents, such as the one made in this thesis.

3.5 RESTful API testing

The developed system serves a RESTful API. This means that it uses HTTP requests to GET,POST, PUT and DELETE data [24]. For the sake of the reliability of the system, it is essentialthat the API behaves as it is supposed to. To ensure this, the functionality has to be tested.This can be done with any API development environment, such as Postman [25]. Postman is atool used to send a requests to a server and will be used in our case due to prior experiences.

One can use this tool to test functionalities such as response time, the presence of contenttypes and validation of JavaScript Object Notation (JSON) schemas. A server also needs to betested by sending requests to it. The system holds information about several cases that mapsemergencies as explained in section 2.1. What happens if we feed the system with masses ofrequests in short intervals of time? This could potentially cause the server to overload. Thisis called denial of service attacks [26], also known as DoS attacks, and is out of the scope ofthis thesis as mentioned in section 1.4.

3.6 SQL injection

SQL injections is a technique where the attacker inserts a mischievous string of SQL syntaxinto an SQL query. This mischievous string can be entered into a web page input or someother input field where the string later is sent to an SQL database. This gives the attacker anopportunity to retrieve or tamper with data inside the targeted database [27].

The course of events that take place during an SQL injection attack (SQLIA) can be visualisedaccording to the following figure.

SQL queries

Unauthorised dataextraction

Figure 3.1: SQLIA flow

Many web applications have some input fields that are required for accessing specific data.The app sends this input to its server for validation where the input most often is a part of aquery. The query that runs on the database could, for example, look like the following.

Listing 3.1: Example query

SELECT * FROM t a b l e WHERE user = ' user id ' AND password = ' password ' ;

where userid and password are input from the user as explained above. table and user are tableand column names respectively in the database and could be named anything. This meansthat without arrangements, there exist countless opportunities for attackers to type in stringsof data directly into the server with the purpose of achieving the desired effect.

8

3.7. Related works

The primary process of an SQL attack sequence is that you learn from each error messagethat you get and evolve your attacks accordingly [28]. The error messages might give usefulinformation regarding vulnerable parts of the application and the database schema.

3.7 Related works

The technique adopted in this thesis are a selection of many commonly known techniqueswhen it comes to application security testing. Therefore, the methodologies of these tech-niques are covered in several earlier reports. Haibin Hu [27] for example performs a widelycovered SQL injection review which presents different kinds of SQLIA more in-depth. Sjös-trand and Westberg [29] present Espresso testing among other things on a similar applicationas ours. The intention of that thesis was not to investigate the availability and reliabilitywhich we thought left a gap for us to explore. Their focus was on investigating client sideconfidentiality and integrity related vulnerabilities of their system, whereas our focus lays onthe server side.

Flask’s website state that they try to provide defence against a few different security attacksbut explicitly state that the attacks not mentioned are to be taken care of by the developer [30].The only topic Flask says they have been working on that relates to any of our security testingmethods is the JSON security. This means that there are a lot of attacks that are relevant toinvestigate. A search for scientific articles regarding Flask security testing does not providemuch information, and gives us even more room for unexplored attacks.

Batyuk and Herpich et al. perform reverse engineering of an Android application [17]. Thispaper presents a course of events that are of high relevance for us in this thesis. We do,however, besides the reverse engineering, manipulate the exploited code and later build theapplication again which is not covered in the aforementioned article.

Fledel and Shabtai et al. [31] identify threats to the Android framework by providing a se-curity assessment. They explain how the Android environment is built and also conduct acode review of various Android components. Their primary focus lays on malicious codeinjections through different inputs and discover that an attacker can inject code via the webbrowser. They also state that WebKit, which is Android’s web engine, are prone to injectionsaccording to previous attack history. These injections are especially XSS injections which isproposed as future work in this thesis. On top of that, the writers point out that Androidhandles SQL injections well. These are all general insights for the whole Android frameworkwhereas our work in more specialised towards a specific app. Moreover, our focus lays oninvestigating the app itself, not so much how it is interacting with potential vulnerabilitieswithin the Android framework.

How developers test Android applications is a precious knowledge to determine how toevolve new testing techniques. M. Linares-Vásquez et al. [32] considered this topic by in-vestigating 102 contributors of open source mobile apps. Through extensive interviews andanalysis of quite a few of today’s existing testing methods for Android apps, they found thatdevelopers urge for automated tests. Still, since manually written test cases with automationAPIs are very fragile to changes in the GUI, many automated tests have a low usage rate. Oneexample is the Google tool Monkey which we will use in this report. Another conclusion thatthe writers’ state is that code coverage when it comes to testing nowadays is not somethingmany developers consider a good measure of test case quality. Instead, they propose some-thing like fault detection capability and feature coverage. This is, on the contrary, something thatis not covered in this thesis.

9

4 Applying these testing tools

Now that we have done a review of common tools for developers to test their Android appli-cations, it is time to determine how this will be implemented in this thesis. In this chapter, wedetail how we used the tools and approaches covered in chapter 3 in the context of functionaland security testing of our application.

4.1 Functional testing

As mentioned previously, UI testing has the intention to ensure that the app works as it issupposed to during user interaction. This is not equivalent to good security, but rather reflectsthe reliability of the app. We will, therefore, apply tests on the main functionalities of the appto collect evidence of possible security issues that come with poorly implemented functions.Below are some areas in which the Espresso testing will be applied. The full test codes areshown in Appendix A. By running the source code, Espresso simulates the correspondinghuman interaction for each action presented below.

Authentication testing

The authentication process of the developed application is one of the essential security fea-tures. Due to this, we tested this functionality through two tests; ValidLogInTest and Invalid-LogInTest. Each test tries to log in with either valid or invalid user credentials respectively onthe Login activity screen shown in figure 4.1.

10

4.1. Functional testing

Figure 4.1: Login activity

Map functionality testing

The map functionality is the main usage of the developed application. It needs to be reliable,and thus it should not be able to fail when in use. If so, this would severely inflect on thereliability and availability of the application. With this in mind, we constructed a test inwhich we added a new case to the map through the use of the ValidLoginTest mentioned inthe section above. The map view is shown below in figure 4.2 (a) and visualises several caseson the map for an explanatory purpose.

(a) Map activity (b) Add case activity

Figure 4.2: Map related activities

11

4.2. Fuzz testing

Contacts testing

As mentioned in chapter 2, another important functionality is the access to contacts relatedto cases in which the logged in user is currently working on. To test this functionality, weconducted yet another Espresso-made test which would check if an ordinary voice call couldbe established between the user and a contact relevant to the user.

(a) Contacts activity (b) Call activity

Figure 4.3: Contacts related activities

Because this app is developed as a mockup for the Swedish Emergency Service, the systemlanguage is Swedish. For those who do not understand this language, figure 4.1 asks for ausername and a corresponding password. An example of the so-called input fields. The fig-ure 4.2 (a) shows as mentioned above a map where the different figures on the map symbolisedifferent cases. The figure 4.2 (b) is visualising, as the figure caption implies, the activity foradding cases. In the first input field, the user is asked to add a title for the new case. In the sec-ond input field, a description is needed and lastly the user is supposed to choose a categoryfor the new case. Espresso consequently accomplishes all these app-interactions mentionedabove.

4.2 Fuzz testing

Monkey testing

For this test, the Android Studio built-in support for monkey testing was used. As it cansimulate a vast number of pseudo-random inputs for all parts of the application, the systemis put under tremendous pressure. The following command for this feature is run in theterminal to execute the test.

Listing 4.1: Monkey testing command

adb s h e l l monkey ´p se . raddning . l e k r a ´́ pct´syskeys 0 ´v 5000

12

4.3. Sniffing

The number at the end of the string is the number of tests that were executed. This numbercan be set to an arbitrary number. In our case, we ran 5000 tests for each of the activitiesshown in figure 4.1 and figure 4.2.

Running 5000 tests on these activities means that 5000 pseudo-random inputs were executedon these activities. These inputs can be everything from typing in invalid strings as user-names to trying to add invalid cases to the map. By ”invalid” we refer to something that isnot in the correct format or, for example, when a mandatory field is excluded. The reason forrunning the specific number of 5000 tests is that we thought it seemed like quite a few inputsin conjunction with the time it took to execute them.

4.3 Sniffing

Sniffing could be performed on almost any activity within the tested application, but we havechosen to implement it on, in our opinion, the most security crucial parts. These are the Loginactivity, the Case activity and the Call activity.

We first started a trace in Wireshark and after that performed all the previously mentionedactivities. As mentioned in section 3.3, Wireshark captures all network packets, but we areonly interested in the data that is being sent between the client and the server. Therefore, weimplemented the following filter to extract the relevant data.

ip.addr == 130.236.181.212 and ip.addr == 10.253.252.221 && ssl

The first IP address is our own and the second is our server’s IP address. Since the websitehas a dynamic IP, this means that to reproduce this test, you have to make a lookup on bothyour own and the website’s IP addresses. The website uses HTTPS which means that thedata is sent using HTTP over SSL [33]. Thus, we can also filter by SSL. With this filter, we seeall data of interest that is sent.

4.4 Reverse engineering

As mentioned in section 3.4, one of the main purposes of reverse engineering is to analyse theinner workings of a target application. From an attacker perspective, this can be applied toidentify possible vulnerabilities located within the logical implementation. And as a result,determining different approaches in which a malicious attack can be performed by recon-structing the implementation of, for example, data handling inside the application.

Due to this, we will investigate the possibility of performing data changes on the back-endserver by manipulating the source code on the front-end Android application. The purposeof this investigation is to identify the level of impact in which reverse engineering and recon-struction of a front-end application can have when performing malicious attacks targetingthe back-end server concerning confidentiality, integrity, availability and reliability.

Worth noticing is that the target application in this investigation has not yet been providedwith any method of preventing reverse engineering, such as PostGuard mentioned in section3.4.

Server-side data manipulation

Our test consisted of reverse engineering the application and later repackaging it with recon-structed assembly code. The goal was to change the lat-, lon- and role_id-attributes of a user

13

4.4. Reverse engineering

on the server-side, and thereby changing the location and permission level of this user in-side the app. A successful test would result in security vulnerabilities which could be furtherexploited with more advanced approaches for data manipulation.

To change the desired attributes of a user, we first reverse engineered the APK of the targetapp and later identified how the front-end app communicated to the back-end server, througha code review on the reverse engineered code. Then we manipulated the relevant .smali-files and repackaged, resigned and reinstalled it on an Android device. We performed thefollowing steps compiled from a mixture of guides and scientific papers [34] [20] [17]:

APK Extraction

1. Extracted the desired APK using the app APKExtractor.

Code analysis

1. Obtained classes.dex-file from the APK using macOS provided unzip:

unzip path/to/app.apk classes.dex

2. Converted the classes.dex-file into a classes.jar-file using dex2jar:

bash path/to/dex2jar.sh path/to/obtained/classes.dex

3. Dissected the created classes.jar-file using JD-GUI (see Appendix C):

java -jar /path/to/executable/jd-gui.jarpath/to/created/classes.jarãÑ

Code reconstruction

1. Decompiled the APK using apktool:

apktool d path/to/app.apk

2. Opened the created app-folder with any text editor at hand, in our case we used Atom[35].

3. Manipulated the relevant .smali-file by altering the lat, lon and role_id attributes asshown in Appendix D.

4. Repackaged to an executable APK with apktool:

apktool b path/to/app.apk

5. Signed the modified APK by first creating a private keystore with Android SDK built-inkeytool and then signing it with Java SDK built-in jarsigner:

1 keytool -genkey -v -keystore my-release-key.keystore-alias alias_name -keyalg RSA -keysize 2048-validity 10000

ãÑ

ãÑ

2 jarsigner -verbose -sigalg SHA1withRSA -digestalg SHA1-keystore my-release-key.keystore path/to/app.apkalias_name

ãÑ

ãÑ

14

4.5. RESTful API testing

We could now install the application on our Android device and run the app with the recon-structed source code.

To identify the necessary syntax to change, and the values needed, we identified some keymethods and variables used to update a users lat- and lon-attributes. We then created ourAndroid project, containing the values and commands we wanted to use to manipulate therelevant .smali-file. Lastly, we decompiled the built project APK with apktool to reveal thecorresponding Smali syntax.

4.5 RESTful API testing

Since one fundamental part of the system is its reliability, API testing is a necessary step. Asmentioned previously in this thesis, Postman can be used for this. There exists a considerablenumber of different test skeletons in Postman that can be executed, but we have limited our-selves to perform nine different tests which cover all relevant API functionalities. All testsare written in JavaScript and are performed for each sent request. The skeletons need to becustom fitted for the data that are to be analysed. The source code for the following tests canbe found in Appendix B.

Noteworthy is that since the following tests are functional tests and not direct security tests,they demand prior knowledge regarding user credentials and API structure. All this will beexplained in the following sections.

Authorization test

The first essential step that needs to be taken is certifying that a person needs to be authorisedto receive a valid response from the server when sending a request. This can be tested bysending a request to the server without attaching an authentication bearer. The bearer consistsof a token which in turn is created by a hashing process of a user’s credentials. If this beareris not present or if the token is invalid in the request to the server, it should not respond withany form of valid data, just an error message.

The URL for our main server is https://itkand-2-1.tddd82-2018.ida.liu.se. Toaccess all cases in the database on our server one need to append the prefix /api/case tothe URL mentioned above. To test whether the server demands authorisation or not, a GETrequest is sent to the server using Postman. Note that to test the authorisation, one couldsend any request to the server. The response would either acknowledge you as authorised orgive an error of which you could determine whether it demands authorisation or not. Due toour knowledge of the system, we send a GET request.

JSON schema validation

A schema is the structure of the API, so the purpose of this test is to validate that the incomingschema matches the schema that already exists [25]. Below is a data snippet showing a case.Here, case is an array containing all the cases, this time only the case with id = 1 is extracted.

Listing 4.2: Example case

{" cases " : [

{" d e s c r i p t i o n " : " " ," id " : 1 ," l a t i t u d e " : 5 8 . 4 1 4 5 ,

15

4.5. RESTful API testing

" longi tude " : 1 5 . 6 0 0 2 ," t i t l e " : " Sver ige " ," type " : " Eld "

}]

}

This JSON data follows a particular structure, and can be validated by being compared withthe response to a sent request. The request that will be sent is a GET to our URL with theprefix /api/case/?id=1 and is the same for all these test cases. Note that depending onthe outcome of the first test regarding verification requirements of a user mentioned in section4.5, you may or may not need to be authenticated to access this kind of information throughthe URL. Even if you need to be authenticated, we still think that the following tests arenecessary since they are meant to check the functionality of the API. The authorisation test isa more security-oriented test.

To make a JSON schema out of the code snippet shown above, we used a website calledjsonschema.net [36]. This website enables input of JSON data and a root id upon whichit then automatically creates the corresponding schema. This schema is then later validatedagainst the incoming JSON data extracted from the server response.

Content type header check

A content type header check is as the name implies, a check that verifies that some applicationdata is present in the header. It is a simple test that only takes a few rows of code to implementas seen in Appendix B.

Contains string check

This test verifies that every expected string is present in the response from the server. In ourcase we expect the following strings:

• Description

• Id

• Latitude

• Longitude

• Title

• Type

JSON value check

If an API is to be able to work correctly, it is crucial that it returns correct values. This couldbe implemented on every string that our case contains, but we limited the amount of tests toone since this should give a fair indication of whether the functionality is correct or not. Thevalue that is going to be checked is ”id” and as the code snippet in listing 4.2 shows, the valuethat the data is compared against is 1.

16

4.6. SQL injection

4.6 SQL injection

There are two ways of sending data to the server in this system. One is through the URL field,and one is through the input fields of the applications. It is easy to see that the API does notprovide any form of query string handling in the URL, thus giving us no choice but to sendthe queries through the input fields of the application.

As explained in chapter 3, a complete query to access some information demands at leasta table name. Since we act as external attackers without any knowledge about neither thesource code nor the database schema, all table and column names are unknown. We dohowever know what the application does and which service it provides. This gives us theopportunity to make legit guesses regarding these names.

The app demands a username and a password. This makes us believe that there is a table inthe database called ”user” and a column named ”password”. We, therefore, try to insert thefollowing query into the password input field of the login page of the application as shownin figure 4.4.

Listing 4.3: Inserted query

SELECT * FROM user WHERE password = password OR 1 ' = ' 1 ;

Figure 4.4: SQL injection

The reason for trying ”... or 1 ’=’ 1;” is that it always returns true. This is a simple techniquewhich is commonly known. Kaur and Kour [37], for example, mention this, among manyother methods, in their article. The goal is that the server should validate the password andthereby authenticate the user without typing in the correct password.

17

4.6. SQL injection

The reason for the fact that we do not try to inject the server through the username field isthat the application has a constraint which allows the user only to type in non-letters. If youdecide to insert a letter, nothing shows. This, however, forces the attacker to know a validpersonal number of an employee. For this test, we assume that the attacker has this kindof information which is far from unbelievable since complete personal username is publicinformation.

18

5 Results

In this chapter we describe the results of the tests described earlier in chapter 4.

5.1 Functional testing

Espresso testing

Table 5.1: Espresso testing results

Tested activity Related functionality Test Passed FailedValidLogInTest XLogin activity Authorization InvalidLogInTest X

Map-/Add case activity Map AddCaseFunctionalityTest XContact-/Call activity Contacts CallFunctionalityTest X

The table 5.1 states all the test results from our four functional tests made with Espresso. Allour tests run to completion and were successful in performing desired user interactions.

5.2 Fuzz testing

Monkey testing

It is almost impossible to visualise all the results of the monkey testing since it applied 5000pseudo-random inputs. Here is, however, a collocation of all the tests.

Table 5.2: Monkey testing results

Tested activity Number of pseudo-random inputs Number of unexpected resultsLog in 5000 0Main 5000 0

Adding a case 5000 0

19

5.3. Sniffing

As shown in table 5.2, no unexpected results were found. By ”unexpected” we are referringto some action that is not allowed or that accesses some information in an invalid way.

5.3 Sniffing

Here we present the Wireshark results from all traces captured. Overall, this illustrates thatno information could be obtained in clear text. Everything is encrypted.

Log in activity

Figure 5.1: Trace of a log in

The figure shows the traffic captured when logging into the system. The packet sent firstbetween the client and the server, Client hello, is marked in deep blue and its data is shown atthe bottom of the figure. As we see, the data is encrypted and makes thereby no sense.

20

5.3. Sniffing

Case activity

Figure 5.2: Trace of adding a case

Just as the first trace, these packets do not contain any readable data. Since we are adding acase instead of logging in this time, the data that is being sent is Application data. An arbitrarypacket is marked above, and the corresponding data is shown in the bottom of the figure.

21

5.4. Reverse engineering

Call activity

Figure 5.3: Trace of a call between two clients

The last trace is captured during a call from one client to another. Once again, Application datais sent between the two parties, and as expected, no information is readable.

5.4 Reverse engineering

In figure 5.4 we can see the database before the manipulated APK has been installed andexecuted. The row which we wanted to manipulate with false data, is the row containingpersonal_number = 9602301114. As shown in figure 5.5 we can see how our manipulatedAPK has successfully changed the stored data of the user’s lat- and lon-attributes but wereunsuccessful in changing the role_id-attribute. The result of this will be discussed in chapter6.

Figure 5.4: Relevant data stored in user table before manipulation

22

5.5. RESTful API testing

Figure 5.5: Relevant data stored in user table after manipulation

5.5 RESTful API testing

Below, all the test results regarding the API testing are presented.

Authorization test

A GET request is sent, and the server responds with this

Figure 5.6: Unauthorized access

The body of the response also contains the message ”Unauthorized Access”. This means thatthe server demands a valid bearer with the request.

All API test cases

Since all the API tests could be executed at once, all test results were presented at once. Theseare the results of the tests described in chapter 4.

23

5.6. SQL injection

Figure 5.7: API testing results

As clearly stated in the figure above, all test cases passed and thus implies that all function-alities within the API work as they are supposed to.

5.6 SQL injection

When inserting the SQL query presented in section 4.6, the following action occurs.

Figure 5.8: App crashes

The application crashes for some reason. We are going to investigate the reason behind thisfurther in chapter 6.

24

6 Discussion

In this chapter we summarise and discuss the outcomes of our tests. We will also discuss thework in social and ethical aspects.

6.1 Results

We performed several kinds of tests on our system, and just a couple of them gave someresults worth discussing in more detail. The only tests that resulted in something that couldpoint at some vulnerability in the system were the reverse engineering, and the SQL injectiontrails. Regarding all other tests, it only showed that the system works as it is meant to andare thereby not going to be discussed in detail.

Functional testing

The Espresso testing worked as it was supposed to and gave no sign of bugs. Since functionaltesting is fundamental and perhaps the first thing that developers test during the processof creating the app, this result is not surprising since the system does not have that manydifferent functionalities that can go wrong. As mentioned in section 3.1, we only constructedone Espresso test regarding adding a case to the map. There exists endless of different casesthat could have been added if you consider all possible inputs for all input fields as shownin fig 4.2 (b). One could have changed both the input strings that is typed in manually andthe category selection. We did, however, not think that it was necessary to put more time intoinvestigating a larger verity of inputs since one test covers the functionality at large.

The API testing was, however, a bit harder to have preconceptions about. These tests are alsofundamental, but not as intuitive as the user interface tests. All performed API tests passedand we could of course, given a broader scope, have completed more test cases. It is hardto predict if it is probable that more test cases would have resulted in some error. Since wecovered the vast majority of the API calls the system makes, we do not expect that the resultswould have been notably different.

25

6.1. Results

Security testing

Overall, many of the executed security tests did not reveal any vulnerability. Since the fuzztesting performed quite a few random inputs to our system, we thought that somethingunexpected would occur. So was not the case and with a accumulated amount of 15 000pseudo-random inputs, none caused the application to behave unexpectedly. This result isquite surprising but is probably based on a well-performed exception handling during thedevelopment of the app.

The sniffing showed that the data sent between the client and the server is encrypted. To-day, HTTPS is widely used and thus has gained trustworthiness. Therefore, the result wasexpected.

Reverse engineering

Although the front-end app did not disclose any obvious implementation mistakes made bythe developers, we were still able to perform some actions which successfully changed thedata stored on the designated back-end server as shown in section 5.4. This is directly relatedto both integrity and reliability vulnerabilities. Data manipulation in the database, in ourcase the change of location coordinates, could potentially affect the use of the application. Ifa case or a user appears to be at one location but is somewhere else, the application cannot betrusted, and the system is deemed compromised.

Why were we only successful to change the lat- and lon-attributes but not the role_id-attributeof a user? The answer to this question lays in the implementation of the communicationbetween the app and the API under test. While analyzing the source code of the application,we realised that the app only sends data to the API endpoints /api/update and /api/case. This, in turn, meant that we were only able to change the location-attributes whenthe app automatically updated the user’s position to /api/update once the user had beenauthenticated and successfully logged in to the application. And the only time in which theapplication sent information to /api/case were when a user added a new case to the map-functionality. This meant that the role_id-attribute of the current user were never addressedthrough the communication between the front-end application and the back-end server, thusshielding it from manipulation.

With more time to investigate, it is not unbelievable that we could have managed to manipu-late some other data in conjunction with user interaction. This could, for example, have beensome more personal information and would thereby compromise an employees integrityeven worse than just changing the location.

An attacker could also use this reverse engineering technique together with restructuring andrepackaging, to distribute a manipulated version of the app to end users without their knowl-edge of a re-installation. Thus, allowing further data manipulation as mentioned previously,for example altering the data retrieved from the server, such as updating the user location orother vital information about contacts and cases without altering the actual functionality ofthe application.

As mentioned in section 3.4, developers could proactively counteract reverse engineering andrepackage with the use of code obfuscation. However, developers need to consider ways inwhich a code obfuscation could potentially be deobfuscated. Thus, if an attacker would dis-tribute a repackaged version of the application to end users without their knowledge, somedetection method, such as AndroidSOO or DroidMOSS, should be applied as a proactivecountermeasure. To adequately protect a specific algorithm (implemented within the An-droid application) from an attacker, that particular algorithm could instead be transferred to

26

6.2. Method

a remote server with a connected REST API. This REST API could then communicate backthe desired results from this specific algorithm instead of disclosing the entire algorithm.

SQL injection

Considering that the database server is implemented with the help of SQLAlchemy, the resultof finding a bug is quite surprising. SQLAlchemy is supposed to handle many different kindsof SQL injections [4], which we after our tests found was true even in this system.

When trying to find out what caused the application to stop, we noticed that the same thinghappened when we inserted a non-query string of similar length into the password field.This means that it was not the server that responded something invalid and caused the appto crash. It was the client end code. When troubleshooting the application source code, itturned out to be one if -statement that was erroneously configured to handle large inputs.This investigation was validated by, first of all, accessing the server log and secondly, fixingthe if -statement. The server log showed no activity after the query was typed in and themodified if -statement made the error go away.

Seen in an attackers perspective, the reason for the error was not what we had hoped for. Wedid, however, through this test find an availability related bug which might not have beendiscovered otherwise. Since the methodology of SQL injections tests are that one performsone test upon which after getting some result, one bases the next test, and since the applica-tion did not respond with an error message, just a crash, we saw no reason within the scopeof this project to continue the injections. There is, however, a possibility that we could havefound more bugs in the app if we had continued with the injections.

6.2 Method

The hardest part of this project has no doubt been identifying what parts to test and how. Sincethe application is developed not only by just us but several other computer science studentswith quite a lot of security-oriented knowledge, we knew that finding flaws was not goingto be easy. The fact that we had almost no prior experience of software testing made it evenharder.

With the benefit of hindsight, we would have dug deeper into reverse engineering. We seesome real potential in what could be accomplished with more time since we with no priorexperience managed to tamper with data within the database.

One could also argue that with more time for research, some of the implemented tests couldeasily have been scoped out. This, because some libraries used as help when developing theapplication handles many security threats. The usage of HTTPS, for example, is meant for en-cryption of the communicating channels. Assuming this works as it should, the sniffing couldbe predicted not to give any desired results. We do however show that the implementationworks as intended.

The primary focus of the description in chapter 4 is that some future reader should be able toreplicate the tests and receive similar results. In this manner, we think that the chapter fulfillsits purpose. However, it takes some time to get used to new programs, and if the futurereader is not familiar with for example Postman, it will perhaps take some time to be ableto execute the tests. Something evident for us might not come naturally for someone else.Overall, we found some interesting results and were reassured of a few security mechanismsfunctioning as intended.

27

6.3. The work in a wider context

6.3 The work in a wider context

The application that has been tested is developed as a mockup for the Swedish EmergencyService. This puts an extra demand on the app’s availability and security. The servers areto store sensitive and privileged information which could cause catastrophic consequencesif the application got in the hands of an attacker. To prevent this from happening, testing isa must. Without testing, you have no evidence that the implementation works as it should.With testing at least, you have hopefully prevented some undesirable actions.

Because of the fact that this application are to store information about persons who did notgive informed consent to openly share their data, there exists an apparent ethical dimensionto the development. A server breach that for example revealed either personal informationor information regarding existing emergency cases could decrease the credibility of the emer-gency service and perhaps be taken to court. Is it okay to store personal data to simplify thework at the cost of the risk of it being compromised? According to our ethical analysis per-formed during the early stages of the development of the application in the more extensiveproject group, it is okay. We made the judgment that it is worth the risk.

It may however not have been judged okay if several security mechanisms had not beenimplemented. The credibility of the system is also affected by whether comprehensive testson the system were performed or not. The importance of the testing that has been carried outspeaks for itself.

28

7 Conclusion

In this chapter, we return to the purpose and the research question given in section 1.3. Wewill also investigate to what extent the aim of this thesis has been achieved. Below are ourresearch questions specified as headlines upon which we will discuss the outcomes.

As described in section 1.2, the purpose of this thesis is both to acquaint the reader withAndroid functional testing and give a more in-depth understanding of a few security testingtechniques. We managed to both perform functional tests and dig a little deeper into some ofthe security testing methods.

Investigate which security vulnerability of the developed system thataffect the confidentiality, integrity, availability and the reliability of thesystem

We found vulnerabilities regarding the availability of the system when performing SQL in-jections. It turned out to have nothing to do with SQL injections per se but revealed a func-tionality bug that could be removed.

The security vulnerabilities found when we reverse engineered the application are connectedto the system’s integrity and reliability. Meddling with data caused the app to contain invalidinformation which directly affects the system’s reliability. Since the information that waschanged was personal, integrity was also violated.

We did not find any confidentiality vulnerabilities because neither SQL injections nor sniffingenabled us to access any confidential information.

Identify methods for client-server applications running Android andPython Flask in order to illuminate the system’s security vulnerabilities

After reading several different scientific articles regarding different topics within securitytesting, we decided to use the following techniques to test our system:

29

• Espresso testing

• Fuzz testing

• Sniffing

• Reverse engineering

• RESTful API testing

• SQL injections

Overall we assess that this was a useful selection of techniques to try and identify securityvulnerabilities. With the benefit of hindsight, we would have scoped out a few of the methodsto dig deeper into reverse engineering. Mainly because we see potential in the topic when itcomes to exploiting flaws in the application.

Of course, there exist quite a few other techniques within software testing that could havebeen used, but it is almost impossible to cover all of them. In regards to the scope of thisthesis and the fact that we included both the client and the server side of the application, wethink that our choice is relevant and reasonable.

Apply the identified methods to the developed system in order to detectsecurity vulnerabilities

We managed to apply all identified methods to our developed system to an almost full extent.By ”full extent” we mean what we had planned to do. The real security vulnerabilities wewere able to detect was tampering with data in the database in conjunction with reverseengineering. This is a great deal and a severe weakness of the system.

The fact that we only detected one security vulnerability could mention one of two things.Either the application overall has a high level of security, or we have failed when implement-ing the other testing techniques. It is hard to determine what the answer to that question is,but we are quite convinced that the tests that have been executed are executed correctly andshows a valid result.

Future work

In the future, it would be interesting to dig deeper into reverse engineering and experimentwhat can and cannot be done according to what is mentioned in section 6.1. It would alsobe interesting to perform an extensive investigation of SQL injections in regards to the microframework Python Flask as well as other types of injections. XSS injections for example,which is not covered in this thesis, would be of great interest in a future work.

As mentioned in section 3.7, this thesis did not focus on fault detection capability and featurecoverage. By digging deeper into this, one could perhaps produce a more general testing guidefor mobile applications including concrete metrics as results.

30

Bibliography

[1] Number of smartphone users worldwide from 2014 to 2020 (in billions). Last visited: 2018-05-11. 2018. URL: https://www.statista.com/statistics/330695/number-of-smartphone-users-worldwide/.

[2] Smartphone OS. Last visited: 2018-05-08. May 2018. URL: https://www.idc.com/promo/smartphone-market-share/os.

[3] Flask. Last visited: 2018-03-30. URL: http://flask.pocoo.org.

[4] SQLAlchemy. Last visited: 2018-05-22. URL: https://www.sqlalchemy.org.

[5] Linus Esbjörnsson. “Android GUI testing: A comparative study of open source An-droid GUI testing frameworks”. In: MA thesis (2015). URL: http://urn.kb.se/resolve?urn=urn:nbn:se:his:diva-11107.

[6] Testing UI for a Single App. Last visited: 2018-03-14. URL: https : / / developer .android.com/training/testing/ui-testing/espresso-testing.html.

[7] Espresso. Last visited: 2018-03-14. URL: https : / / developer . android . com /training/testing/espresso/index.html.

[8] Pausing Execution with Sleep. Last visited: 2018-05-11. 2018. URL: https://docs.oracle.com/javase/tutorial/essential/concurrency/sleep.html.

[9] M. Sutton, A. Greene, and P. Amini. Fuzzing: Brute Force Vulnerability Discovery. 2007.URL: https://books.google.se/books?hl=sv&lr=&id=DPAwwn7QDy8C&oi=fnd&pg=PT4&dq=fuzzing&ots=4xt3G3gIyj&sig=CwcLxW1Bby5RuEmmrFK_YfBjs-0&redir_esc=y#v=onepage&q=fuzzing&f=false.

[10] UI/Application Exerciser Monkey. Last visited: 2018-03-14. URL: https://developer.android.com/studio/test/monkey.html.

[11] Wireshark User’s Guide. Last visited: 2018-03-18. URL: https://www.wireshark.org/docs/wsug_html/.

[12] Hausi A. Müller, Jens H. Jahnke, Dennis B. Smith, Margaret-Anne Storey, Scott R. Tilley,and Kenny Wong. “Reverse Engineering: A Roadmap”. In: Proceedings of the Conferenceon The Future of Software Engineering. ICSE ’00. Limerick, Ireland: ACM, 2000, pp. 47–60.ISBN: 1-58113-253-0. DOI: 10.1145/336512.336526. URL: http://doi.acm.org/10.1145/336512.336526.

31

Bibliography

[13] E. J. Chikofsky and J. H. Cross. “Reverse engineering and design recovery: a taxon-omy”. In: IEEE Software vol. 7, no. 1 (Jan. 1990), pp. 13–17. ISSN: 0740-7459. DOI: 10.1109/52.43044.

[14] APK Extractor. Last visited: 2018-04-17. URL: https://play.google.com/store/apps/details?id=com.ext.ui&hl=sv.

[15] Assistant for Android. Last visited: 2018-04-02. URL: https://play.google.com/store/apps/details?id=com.advancedprocessmanager&hl=en.

[16] Apktool - A tool for reverse engineering Android apk files. Last visited: 2018-05-01. URL:https://ibotpeaches.github.io/Apktool/.

[17] L. Batyuk, M. Herpich, S. A. Camtepe, K. Raddatz, A. D. Schmidt, and S. Albayrak. “Us-ing static analysis for automatic assessment and mitigation of unwanted and maliciousactivities within Android applications”. In: Proceedings of the 6th International Conferenceon Malicious and Unwanted Software. Oct. 2011, pp. 66–72. DOI: 10.1109/MALWARE.2011.6112328.

[18] dex2jar. Last visited: 2018-04-25. URL: https : / / bitbucket . org / pxb1988 /dex2jar.

[19] JD-GUI - Java Decompiler. Last visited: 2018-04-20. URL: http://jd.benow.ca/.

[20] P. Faruki, A. Bharmal, V. Laxmi, V. Ganmoor, M. S. Gaur, M. Conti, and M. Rajarajan.“Android Security: A Survey of Issues, Malware Penetration, and Defenses”. In: IEEECommunications Surveys Tutorials vol. 17, no. 2 (Secondquarter 2015), pp. 998–1022. ISSN:1553-877X. DOI: 10.1109/COMST.2014.2386139.

[21] ProGuard. Last visited: 2018-03-25. URL: https://www.guardsquare.com/en/proguard.

[22] W. Zhou, Y. Zhou, X. Jiang, and P. Ning. “Detecting Repackaged Smartphone Appli-cations in Third-party Android Marketplaces”. In: Proceedings of the Second ACM Con-ference on Data and Application Security and Privacy. CODASPY ’12. San Antonio, Texas,USA: ACM, 2012, pp. 317–326. ISBN: 978-1-4503-1091-8. DOI: 10.1145/2133601.2133640. URL: http://doi.acm.org/10.1145/2133601.2133640.

[23] H. Gonzalez, A. A. Kadir, N. Stakhanova, A. J. Alzahrani, and A. A. Ghorbani. “Ex-ploring Reverse Engineering Symptoms in Android Apps”. In: Proceedings of the EighthEuropean Workshop on System Security. EuroSec ’15. Bordeaux, France: ACM, 2015, 7:1–7:7. ISBN: 978-1-4503-3479-2. DOI: 10.1145/2751323.2751330. URL: http://doi.acm.org/10.1145/2751323.2751330.

[24] M. Massé. REST API Design Rulebook. O’Reilly Media, Inc., 2011. ISBN: 978-1-449-31050-9. URL: https://books.google.se/books?id=eABpzyTcJNIC&printsec=frontcover&hl=sv&source=gbs_atb#v=onepage&q&f=false.

[25] Postman. Last visited: 2018-05-22. URL: https://www.getpostman.com.

[26] S. S. Thakare and P. Kaur. “Denial-of-service attack detection system”. In: 2017 1st In-ternational Conference on Intelligent Systems and Information Management (ICISIM). Oct.2017, pp. 281–285. DOI: 10.1109/ICISIM.2017.8122186.

[27] H. Haibin. “Research on the technology of detecting the SQL injection attack and non-intrusive prevention in WEB system”. In: American Institute of Physics Conference Pro-ceedings (May 2017). URL: https://doi.org/10.1063/1.4982570.

[28] M. Stampar. “Inferential SQL Injection Attacks”. In: International Journal of Network Secu-rity vol. 18 (2016). Last visited: 2018-05-20. URL: https://pdfs.semanticscholar.org / ac06 / 2f5f4ad1af43a6d963b419835b936dd87728 . pdf ? _ga = 2 .238394178.333244406.1526909984-2059663332.1526909984.

32

Bibliography

[29] J. Sjöstrand and S. Westberg. “Functional and Security testing of a Mobile Application”.In: Bachelor thesis, Linköping University (2017). URL: http://www.diva-portal.org/smash/get/diva2:1113288/FULLTEXT01.pdf.

[30] Flask Security Considerations. Last visited: 2018-05-03. URL: http://flask.pocoo.org/docs/1.0/security/.

[31] A. Shabtai, Y. Fledel, U. Kanonov, Y. Elovici, S. Dolev, and C. Glezer. “Google Android:A Comprehensive Security Assessment”. In: IEEE Security Privacy vol. 8, no. 2 (Mar.2010), pp. 35–44. ISSN: 1540-7993. DOI: 10.1109/MSP.2010.2.

[32] M. Linares-Vásquez, C. Bernal-Cardenas, K. Moran, and D. Poshyvanyk. “How do De-velopers Test Android Applications?” In: 2017 IEEE International Conference on SoftwareMaintenance and Evolution (ICSME). Sept. 2017, pp. 613–622. DOI: 10.1109/ICSME.2017.47.

[33] J. Clark and P. C. van Oorschot. “SoK: SSL and HTTPS: Revisiting Past Challengesand Evaluating Certificate Trust Model Enhancements”. In: IEEE Software (May 2013),pp. 511–525. ISSN: 1081-6011. DOI: 10.1109/SP.2013.41.

[34] From APK to readable java source code in 3 easy steps. Last visited: 2018-05-17. URL: http://pof.eslack.org/2011/02/18/from-apk-to-readable-java-source-code-in-3-easy-steps/.

[35] Atom - A hackable text editor for the 21st century. Last visited: 2018-04-10. URL: https://atom.io/.

[36] JSONSchema.net. Last visited: 2018-04-19. URL: https://jsonschema.net.

[37] P. Kaur and K. P. Kour. “SQL injection: Study and augmentation”. In: 2015 InternationalConference on Signal Processing, Computing and Control (ISPCC). Sept. 2015, pp. 102–107.DOI: 10.1109/ISPCC.2015.7375006.

33

A Appendix - Espresso testing

Listing A.1: ValidLogInTest

1 @LargeTest2 @RunWith(AndroidJUnit4.class)3 public class ValidLogInTest {4

5 private static final String VALID_USERNAME = "9602301111";6 private static final String VALID_PASSWORD = "password";7

8 @Rule9 public ActivityTestRule<LoginActivity> activityActivityTestRule = new

10 ActivityTestRule<LoginActivity>(LoginActivity.class);11

12 @Before13 public void setup() {14 // Initializing Intent recorder.15 Intents.init();16 }17

18 @Test19 public void logInTest() {20

21 // Clear all input fields.22 ViewInteraction clearUsernameInputField = onView(23 withId(R.id.username));24 clearUsernameInputField.perform(clearText());25

26 ViewInteraction clearPasswordInputField = onView(27 withId(R.id.password));28 clearPasswordInputField.perform(clearText());29

30 // Typing in valid user information into text fields.31 ViewInteraction typeValidUsername = onView(32 withId(R.id.username));33 typeValidUsername.perform(typeText(VALID_USERNAME));34

35 ViewInteraction typeValidPassword = onView(36 withId(R.id.password));

34

37 typeValidPassword.perform(typeText(VALID_PASSWORD), closeSoftKeyboard());38

39 // Clicking the sign in button.40 ViewInteraction pressLoginButton = onView(withId(R.id.sign_in_button));41 pressLoginButton.perform(click());42

43 // Checking that the ProgressBar is displayed.44 ViewInteraction checkProgressbarVisability = onView(45 withId(R.id.login_progress));46 checkProgressbarVisability.check(matches(isDisplayed()));47

48 // Added a sleep statement to match the communication with the server.49 try {50 Thread.sleep(5000);51 } catch (InterruptedException e) {52 e.printStackTrace();53 }54

55 // Check if MainActivity is displayed.56 intended(hasComponent(MainActivity.class.getName()));57

58 }59

60 @After61 public void tearDown() {62 // Tearing down Intent recorder.63 Intents.release();64 }65 }

Listing A.2: InvalidLogInTest

1 @LargeTest2 @RunWith(AndroidJUnit4.class)3 public class InvalidLogInTest {4

5 private static final String INVALID_USERNAME = "0123456789";6 private static final String INVALID_PASSWORD = "falsePw";7

8 @Rule9 public ActivityTestRule<LoginActivity> activityActivityTestRule = new

10 ActivityTestRule<LoginActivity>(LoginActivity.class);11

12 @Test13 public void logIn() {14

15 // Clear all input fields.16 ViewInteraction clearUsernameInputField = onView(17 withId(R.id.username));18 clearUsernameInputField.perform(clearText());19

20 ViewInteraction clearPasswordInputField = onView(21 withId(R.id.password));22 clearPasswordInputField.perform(clearText());23

24 // Typing in invalid user information into text fields.25 ViewInteraction typeValidUsername = onView(26 withId(R.id.username));27 typeValidUsername.perform(typeText(INVALID_USERNAME));28

29 ViewInteraction typeValidPassword = onView(30 withId(R.id.password));31 typeValidPassword.perform(typeText(INVALID_PASSWORD), closeSoftKeyboard());

35

32

33 // Clicking the sign in button.34 ViewInteraction pressLoginButton = onView(withId(R.id.sign_in_button));35 pressLoginButton.perform(click());36

37 // Checking that the ProgressBar is displayed.38 ViewInteraction checkProgressbarVisability = onView(39 withId(R.id.login_progress));40 checkProgressbarVisability.check(matches(isDisplayed()));41

42 // Added a sleep statement to match the communication with the server.43 try {44 Thread.sleep(2000);45 } catch (InterruptedException e) {46 e.printStackTrace();47 }48

49 // Check if the Login form is still being displayed.50 ViewInteraction checkLoginFormVisibility = onView(51 withId(R.id.login_form));52 checkLoginFormVisibility.check(matches(isDisplayed()));53

54 }55 }

Listing A.3: CallFunctionalityTest

1 @LargeTest2 @RunWith(AndroidJUnit4.class)3 public class CallFunctionalityTest {4

5 ValidLogInTest validLogInTest = new ValidLogInTest();6

7 @Rule8 public ActivityTestRule<LoginActivity> mActivityTestRule = new

ActivityTestRule<>(LoginActivity.class);ãÑ

9

10 @Before11 public void setup() {12 validLogInTest.setup();13 }14

15 @Test16 public void callActivityTest() {17 validLogInTest.logInTest();18

19 ViewInteraction openNavigationDrawer = onView(20 allOf(withContentDescription("Open navigation drawer"),21 childAtPosition(22 allOf(withId(R.id.toolbar),23 childAtPosition(24 withId(R.id.appbar),25 0)),26 1),27 isDisplayed()));28 openNavigationDrawer.perform(click());29

30 // Added a sleep statement to match the communication with the server.31 try {32 Thread.sleep(2000);33 } catch (InterruptedException e) {34 e.printStackTrace();35 }

36

36

37 ViewInteraction pressContactsMenuItem = onView(38 allOf(childAtPosition(39 allOf(withId(R.id.design_navigation_view),40 childAtPosition(41 withId(R.id.navigation_view),42 0)),43 2),44 isDisplayed()));45 pressContactsMenuItem.perform(click());46

47 // Added a sleep statement to match the communication with the server.48 try {49 Thread.sleep(2000);50 } catch (InterruptedException e) {51 e.printStackTrace();52 }53

54 ViewInteraction pressContactCallButton = onView(55 allOf(withId(R.id.call_button),56 childAtPosition(57 childAtPosition(58 withClassName(is("android.widget.LinearLayou u

t")),ãÑ

59 1),60 0),61 isDisplayed()));62 pressContactCallButton.perform(click());63

64 // Added a sleep statement to match the communication with the server.65 try {66 Thread.sleep(5000);67 } catch (InterruptedException e) {68 e.printStackTrace();69 }70

71 /**** SUCCESSFULLY ESTABLISHED A CALL CONNECTION ****/72

73 ViewInteraction pressHangUpButton = onView(74 allOf(withId(R.id.hangup_button), withText("Lägg på"),75 childAtPosition(76 childAtPosition(77 withClassName(is("android.widget.LinearLayou u

t")),ãÑ

78 3),79 0),80 isDisplayed()));81 pressHangUpButton.perform(click());82

83 }84

85 private static Matcher<View> childAtPosition(86 final Matcher<View> parentMatcher, final int position) {87

88 return new TypeSafeMatcher<View>() {89 @Override90 public void describeTo(Description description) {91 description.appendText("Child at position " + position + " in parent

");ãÑ

92 parentMatcher.describeTo(description);93 }94

95 @Override96 public boolean matchesSafely(View view) {97 ViewParent parent = view.getParent();98 return parent instanceof ViewGroup && parentMatcher.matches(parent)

37

99 && view.equals(((ViewGroup) parent).getChildAt(position));100 }101 };102 }103

104 @After105 public void tearDown() {106 validLogInTest.tearDown();107 }108 }

Listing A.4: AddCaseFunctionalityTest

1 @LargeTest2 @RunWith(AndroidJUnit4.class)3 public class AddCaseFunctionalityTest {4

5 ValidLogInTest validLogInTest = new ValidLogInTest();6

7 @Rule8 public ActivityTestRule<LoginActivity> mActivityTestRule = new

ActivityTestRule<>(LoginActivity.class);ãÑ

9

10 @Before11 public void setup() {12 validLogInTest.setup();13 }14

15 @Test16 public void addCaseFunctionalityTest() {17 validLogInTest.logInTest();18

19 // Clicking the FloatingActionButton to add a new case.20 ViewInteraction floatingActionButton = onView(withId(R.id.markerButton));21 floatingActionButton.perform(click());22

23 // Added a sleep statement to match the communication with the server.24 try {25 Thread.sleep(2000);26 } catch (InterruptedException e) {27 e.printStackTrace();28 }29

30 // Typing in a new case information.31 ViewInteraction typeNewCaseTitle = onView(32 allOf(withId(R.id.map_marker_title),33 childAtPosition(34 childAtPosition(35 withClassName(is("android.widget.LinearLayou u

t")),ãÑ

36 1),37 1),38 isDisplayed()));39 typeNewCaseTitle.perform(replaceText("Fire"), closeSoftKeyboard());40

41 ViewInteraction typeNewCaseDesc = onView(42 allOf(withId(R.id.map_marker_desc),43 childAtPosition(44 childAtPosition(45 withClassName(is("android.widget.LinearLayou u

t")),ãÑ

46 1),47 3),

38

48 isDisplayed()));49 typeNewCaseDesc.perform(replaceText("An apartment is on fire"),

closeSoftKeyboard());ãÑ

50

51 // Choosing the new case type.52 ViewInteraction chooseNewCaseType = onView(53 allOf(withId(R.id.map_marker_type),54 childAtPosition(55 childAtPosition(56 withClassName(is("android.widget.LinearLayou u

t")),ãÑ

57 1),58 5),59 isDisplayed()));60 chooseNewCaseType.perform(click());61

62 DataInteraction selectFireType = onData(anything())63 .inAdapterView(childAtPosition(64 withClassName(is("android.widget.PopupWindow$PopupBackground u

View")),ãÑ

65 0))66 .atPosition(1);67 selectFireType.perform(click());68

69 // Clicking 'Done' button70 ViewInteraction pressAddCaseToMapButton = onView(71 allOf(withId(R.id.register_map_marker_button), withText("Lägg till

händelse"),ãÑ

72 childAtPosition(73 childAtPosition(74 withClassName(is("android.widget.LinearLayou u

t")),ãÑ

75 1),76 6),77 isDisplayed()));78 pressAddCaseToMapButton.perform(click());79

80 }81

82 private static Matcher<View> childAtPosition(83 final Matcher<View> parentMatcher, final int position) {84

85 return new TypeSafeMatcher<View>() {86 @Override87 public void describeTo(Description description) {88 description.appendText("Child at position " + position + " in parent

");ãÑ

89 parentMatcher.describeTo(description);90 }91

92 @Override93 public boolean matchesSafely(View view) {94 ViewParent parent = view.getParent();95 return parent instanceof ViewGroup && parentMatcher.matches(parent)96 && view.equals(((ViewGroup) parent).getChildAt(position));97 }98 };99 }

100

101 @After102 public void tearDown() {103 validLogInTest.tearDown();104 }105 }

39

B Appendix - RESTful API testing

Listing B.1: API testing code

1 // Schema validation2 var schema = {3 "$id": "https://itkand-2-1.tddd82-2018.ida.liu.se/api/case/?id=1",4 "type": "object",5 "definitions": {},6 "$schema": "http://json-schema.org/draft-07/schema#",7 "properties": {8 "cases": {9 "$id": "/properties/cases",

10 "type": "array",11 "items": {12 "$id": "/properties/cases/items",13 "type": "object",14 "properties": {15 "description": {16 "$id": "/properties/cases/items/properties/description",17 "type": "string",18 "title": "The Description Schema ",19 "default": "",20 "examples": [21 ""22 ]23 },24 "id": {25 "$id": "/properties/cases/items/properties/id",26 "type": "integer",27 "title": "The Id Schema ",28 "default": 0,29 "examples": [30 131 ]32 },33 "latitude": {34 "$id": "/properties/cases/items/properties/latitude",35 "type": "number",36 "title": "The Latitude Schema ",

40

37 "default": 0,38 "examples": [39 58.4145011901855540 ]41 },42 "longitude": {43 "$id": "/properties/cases/items/properties/longitude",44 "type": "number",45 "title": "The Longitude Schema ",46 "default": 0,47 "examples": [48 15.60019969940185549 ]50 },51 "title": {52 "$id": "/properties/cases/items/properties/title",53 "type": "string",54 "title": "The Title Schema ",55 "default": "",56 "examples": [57 "Sverige"58 ]59 },60 "type": {61 "$id": "/properties/cases/items/properties/type",62 "type": "string",63 "title": "The Type Schema ",64 "default": "",65 "examples": [66 "Eld"67 ]68 }69 }70 }71 }72 }73 };74

75 var jsonData = pm.response.json();76 pm.test('Schema is valid', function() {77 pm.expect(tv4.validate(jsonData, schema)).to.be.true;78 });79

80 // Response headers: Content-Type header check81

82 pm.test("Content-Type is present", function () {83 pm.response.to.have.header("Content-Type");84 });85

86 // Response body: Contains string87

88 pm.test("Description is present", function () {89 pm.expect(pm.response.text()).to.include("description");90 });91

92 pm.test("ID is present", function () {93 pm.expect(pm.response.text()).to.include("id");94 });95

96 pm.test("Latitude is present", function () {97 pm.expect(pm.response.text()).to.include("latitude");98 });99

100 pm.test("Longitude is present", function () {101 pm.expect(pm.response.text()).to.include("longitude");102 });

41

103

104 pm.test("Title is present", function () {105 pm.expect(pm.response.text()).to.include("title");106 });107

108 pm.test("Type is present", function () {109 pm.expect(pm.response.text()).to.include("type");110 });111

112 // Response body: JSON value check113

114 var jsonData = pm.response.json();115 pm.test("ID should be " + jsonData.cases[0].id, function () {116 pm.expect(jsonData.cases[0].id).to.eql(1);117 });

42

C Appendix - Code analysis

Figure C.1: Source code of target application shown in the JD-GUI program

43

In figure C.1, we can see how a successful reverse engineering process described in 4.4 isdisclosing the source code of the target application.

44

D Appendix - Code manipulation

Listing D.1: Initial source code

630 .method public doCompleteUpdate()V631 .locals 6632

633 .line 89634 sget-object v0, Lse/raddning/lekra/Manager/MapManager;->TAG:Ljava/lang/String;635

636 const-string v1, "Updating..."637

638 invoke-static {v0, v1},Landroid/util/Log;->d(Ljava/lang/String;Ljava/lang/String;)IãÑ

639

640 .line 90641 move-object v0, p0642

643 .line 91644 .local v0, "mMapManager":Lse/raddning/lekra/Manager/MapManager;645 new-instance v1, Lorg/json/JSONObject;646

647 invoke-direct {v1}, Lorg/json/JSONObject;-><init>()V648

649 .line 93650 .local v1, "postData":Lorg/json/JSONObject;651 const-string v2, "battery_level"652

653 invoke-virtual {v1, v2},Lorg/json/JSONObject;->opt(Ljava/lang/String;)Ljava/lang/Object;ãÑ

654

655 .line 95656 const-string v2, "lat"657

658 invoke-virtual {v1, v2},Lorg/json/JSONObject;->opt(Ljava/lang/String;)Ljava/lang/Object;ãÑ

659

660 .line 96661 const-string v2, "lon"662

45

663 invoke-virtual {v1, v2},Lorg/json/JSONObject;->opt(Ljava/lang/String;)Ljava/lang/Object;ãÑ

664

665 .line 98666 :try_start_0667 new-instance v2, Lorg/json/JSONObject;668

669 invoke-direct {v2}, Lorg/json/JSONObject;-><init>()V670

671 .line 100672 .local v2, "pos":Lorg/json/JSONObject;673 const-string v3, "lat"674

675 iget-object v4, p0, Lse/raddning/lekra/Manager/MapManager;->latestKnownUserLocat u

ion:Landroid/location/Location;ãÑ

676

677 if-nez v4, :cond_0678

679 sget-object v4, Lorg/json/JSONObject;->NULL:Ljava/lang/Object;680

681 goto :goto_0682

683 :cond_0684 iget-object v4, p0, Lse/raddning/lekra/Manager/MapManager;->latestKnownUserLocat u

ion:Landroid/location/Location;ãÑ

685

686 invoke-virtual {v4}, Landroid/location/Location;->getLatitude()D687

688 move-result-wide v4689

690 invoke-static {v4, v5}, Ljava/lang/Double;->valueOf(D)Ljava/lang/Double;691

692 move-result-object v4693

694 :goto_0695 invoke-virtual {v2, v3, v4}, Lorg/json/JSONObject;->put(Ljava/lang/String;Ljava/ u

lang/Object;)Lorg/json/JSONObject;ãÑ

696

697 .line 101698 const-string v3, "lon"699

700 iget-object v4, p0, Lse/raddning/lekra/Manager/MapManager;->latestKnownUserLocat u

ion:Landroid/location/Location;ãÑ

701

702 if-nez v4, :cond_1703

704 sget-object v4, Lorg/json/JSONObject;->NULL:Ljava/lang/Object;705

706 goto :goto_1707

708 :cond_1709 iget-object v4, p0, Lse/raddning/lekra/Manager/MapManager;->latestKnownUserLocat u

ion:Landroid/location/Location;ãÑ

710

711 invoke-virtual {v4}, Landroid/location/Location;->getLongitude()D712

713 move-result-wide v4714

715 invoke-static {v4, v5}, Ljava/lang/Double;->valueOf(D)Ljava/lang/Double;716

717 move-result-object v4718

719 :goto_1720 invoke-virtual {v2, v3, v4}, Lorg/json/JSONObject;->put(Ljava/lang/String;Ljava/ u

lang/Object;)Lorg/json/JSONObject;ãÑ

46

721

722 .line 103723 const-string v3, "battery_level"724

725 iget-object v4, p0,Lse/raddning/lekra/Manager/MapManager;->app:Lse/raddning/lekra/LekraApp;ãÑ

726

727 invoke-virtual {v4}, Lse/raddning/lekra/LekraApp;->getBatteryPercentage()F728

729 move-result v4730

731 const/high16 v5, 0x42c80000 # 100.0f732

733 mul-float/2addr v4, v5734

735 invoke-static {v4}, Ljava/lang/Math;->round(F)I736

737 move-result v4738

739 invoke-static {v4}, Ljava/lang/Integer;->valueOf(I)Ljava/lang/Integer;740

741 move-result-object v4742

743 invoke-virtual {v1, v3, v4}, Lorg/json/JSONObject;->putOpt(Ljava/lang/String;Lja u

va/lang/Object;)Lorg/json/JSONObject;ãÑ

744

745 .line 104746 const-string v3, "pos"747

748 invoke-virtual {v1, v3, v2}, Lorg/json/JSONObject;->putOpt(Ljava/lang/String;Lja u

va/lang/Object;)Lorg/json/JSONObject;ãÑ

749 :try_end_0750 .catch Lorg/json/JSONException; {:try_start_0 .. :try_end_0} :catch_0751

752 .line 110753 .end local v2 # "pos":Lorg/json/JSONObject;754 goto :goto_2755

756 .line 108757 :catch_0758 move-exception v2759

760 .line 109761 .local v2, "e":Lorg/json/JSONException;762 invoke-virtual {v2}, Lorg/json/JSONException;->printStackTrace()V763

764 .line 112765 .end local v2 # "e":Lorg/json/JSONException;766 :goto_2767 iget-object v2, p0, Lse/raddning/lekra/Manager/MapManager;->requestManager:Lse/r u

addning/lekra/Manager/RequestManager;ãÑ

768

769 const-string v3, "/api/update"770

771 new-instance v4, Lse/raddning/lekra/Manager/MapManager$2;772

773 invoke-direct {v4, p0, v0}, Lse/raddning/lekra/Manager/MapManager$2;-><init>(Lse u

/raddning/lekra/Manager/MapManager;Lse/raddning/lekra/Manager/MapManager;)VãÑ

774

775 invoke-virtual {v2, v1, v3, v4},Lse/raddning/lekra/Manager/RequestManager;->doPostRequest(Lorg/json/JSONObj u

ect;Ljava/lang/String;Lse/raddning/lekra/Utilities/RequestCallback;)VãÑ

ãÑ

776

777 .line 137778 return-void779 .end method

47

Listing D.2: Manipulated source code

630 .method public doCompleteUpdate()V631 .locals 6632

633 .line 89634 sget-object v0, Lse/raddning/lekra/Manager/MapManager;->TAG:Ljava/lang/String;635

636 const-string v1, "Updating..."637

638 invoke-static {v0, v1},Landroid/util/Log;->d(Ljava/lang/String;Ljava/lang/String;)IãÑ

639

640 .line 90641 move-object v0, p0642

643 .line 91644 .local v0, "mMapManager":Lse/raddning/lekra/Manager/MapManager;645 new-instance v1, Lorg/json/JSONObject;646

647 invoke-direct {v1}, Lorg/json/JSONObject;-><init>()V648

649 .line 93650 .local v1, "postData":Lorg/json/JSONObject;651 const-string v2, "battery_level"652

653 invoke-virtual {v1, v2},Lorg/json/JSONObject;->opt(Ljava/lang/String;)Ljava/lang/Object;ãÑ

654

655 .line 95656 const-string v2, "lat"657

658 invoke-virtual {v1, v2},Lorg/json/JSONObject;->opt(Ljava/lang/String;)Ljava/lang/Object;ãÑ

659

660 .line 96661 const-string v2, "lon"662

663 invoke-virtual {v1, v2},Lorg/json/JSONObject;->opt(Ljava/lang/String;)Ljava/lang/Object;ãÑ

664

665 .line 97666 const-string v2, "role_id"667

668 invoke-virtual {v1, v2},Lorg/json/JSONObject;->opt(Ljava/lang/String;)Ljava/lang/Object;ãÑ

669

670 .line 99671 :try_start_0672 new-instance v2, Lorg/json/JSONObject;673

674 invoke-direct {v2}, Lorg/json/JSONObject;-><init>()V675

676 .line 101677 .local v2, "pos":Lorg/json/JSONObject;678 const-string v3, "lat"679

680 iget-object v4, p0, Lse/raddning/lekra/Manager/MapManager;->latestKnownUserLocat u

ion:Landroid/location/Location;ãÑ

681

682 if-nez v4, :cond_0683

684 sget-object v4, Lorg/json/JSONObject;->NULL:Ljava/lang/Object;685

48

686 goto :goto_0687

688 :cond_0689 # Test implementation: Change Longitude attribute: lat690 const-wide v4, 0x404dbfb1af3a14cfL # 59.49761691

692 invoke-static {v4, v5}, Ljava/lang/Double;->valueOf(D)Ljava/lang/Double;693

694 move-result-object v4695

696 :goto_0697 invoke-virtual {v2, v3, v4}, Lorg/json/JSONObject;->put(Ljava/lang/String;Ljava/ u

lang/Object;)Lorg/json/JSONObject;ãÑ

698

699 .line 102700 const-string v3, "lon"701

702 iget-object v4, p0, Lse/raddning/lekra/Manager/MapManager;->latestKnownUserLocat u

ion:Landroid/location/Location;ãÑ

703

704 if-nez v4, :cond_1705

706 sget-object v4, Lorg/json/JSONObject;->NULL:Ljava/lang/Object;707

708 goto :goto_1709

710 :cond_1711 # Test implementation: Change Longitude attribute: lon712 const-wide v4, 0x40321268a0d349bfL # 18.071909713

714 invoke-static {v4, v5}, Ljava/lang/Double;->valueOf(D)Ljava/lang/Double;715

716 move-result-object v4717

718 :goto_1719 invoke-virtual {v2, v3, v4}, Lorg/json/JSONObject;->put(Ljava/lang/String;Ljava/ u

lang/Object;)Lorg/json/JSONObject;ãÑ

720

721 .line 104722 const-string v3, "battery_level"723

724 iget-object v4, p0,Lse/raddning/lekra/Manager/MapManager;->app:Lse/raddning/lekra/LekraApp;ãÑ

725

726 invoke-virtual {v4}, Lse/raddning/lekra/LekraApp;->getBatteryPercentage()F727

728 move-result v4729

730 const/high16 v5, 0x42c80000 # 100.0f731

732 mul-float/2addr v4, v5733

734 invoke-static {v4}, Ljava/lang/Math;->round(F)I735

736 move-result v4737

738 invoke-static {v4}, Ljava/lang/Integer;->valueOf(I)Ljava/lang/Integer;739

740 move-result-object v4741

742 invoke-virtual {v1, v3, v4}, Lorg/json/JSONObject;->putOpt(Ljava/lang/String;Lja u

va/lang/Object;)Lorg/json/JSONObject;ãÑ

743

744 .line 105745 const-string v3, "pos"746

49

747 invoke-virtual {v1, v3, v2}, Lorg/json/JSONObject;->putOpt(Ljava/lang/String;Lja u

va/lang/Object;)Lorg/json/JSONObject;ãÑ

748

749 # Test implementation: Change Permission level attribute: role_id750 .line 106751 const-string v3, "role_id"752

753 const/4 v4, 0x1754

755 invoke-static {v4}, Ljava/lang/Integer;->valueOf(I)Ljava/lang/Integer;756

757 move-result-object v4758

759 invoke-virtual {v1, v3, v4}, Lorg/json/JSONObject;->putOpt(Ljava/lang/String;Lja u

va/lang/Object;)Lorg/json/JSONObject;ãÑ

760 :try_end_0761 .catch Lorg/json/JSONException; {:try_start_0 .. :try_end_0} :catch_0762

763 .line 112764 .end local v2 # "pos":Lorg/json/JSONObject;765 goto :goto_2766

767 .line 110768 :catch_0769 move-exception v2770

771 .line 111772 .local v2, "e":Lorg/json/JSONException;773 invoke-virtual {v2}, Lorg/json/JSONException;->printStackTrace()V774

775 .line 114776 .end local v2 # "e":Lorg/json/JSONException;777 :goto_2778 iget-object v2, p0, Lse/raddning/lekra/Manager/MapManager;->requestManager:Lse/r u

addning/lekra/Manager/RequestManager;ãÑ

779

780 const-string v3, "/api/update"781

782 new-instance v4, Lse/raddning/lekra/Manager/MapManager$2;783

784 invoke-direct {v4, p0, v0}, Lse/raddning/lekra/Manager/MapManager$2;-><init>(Lse u

/raddning/lekra/Manager/MapManager;Lse/raddning/lekra/Manager/MapManager;)VãÑ

785

786 invoke-virtual {v2, v1, v3, v4},Lse/raddning/lekra/Manager/RequestManager;->doPostRequest(Lorg/json/JSONObj u

ect;Ljava/lang/String;Lse/raddning/lekra/Utilities/RequestCallback;)VãÑ

ãÑ

787

788 .line 139789 return-void790 .end method

50