UBC Theses and Dissertations

UBC Theses Logo

UBC Theses and Dissertations

An intelligent multi-agent based detection framework for classification of android malware Alam, Mohammed Shahidul 2016

Your browser doesn't seem to have a PDF viewer, please download the PDF to view this item.

Item Metadata


24-ubc_2017_february_alam_mohammed.pdf [ 2.31MB ]
JSON: 24-1.0340265.json
JSON-LD: 24-1.0340265-ld.json
RDF/XML (Pretty): 24-1.0340265-rdf.xml
RDF/JSON: 24-1.0340265-rdf.json
Turtle: 24-1.0340265-turtle.txt
N-Triples: 24-1.0340265-rdf-ntriples.txt
Original Record: 24-1.0340265-source.json
Full Text

Full Text

An Intelligent Multi-Agent based Detection Frameworkfor Classification of Android MalwarebyMohammed Shahidul AlamB.Sc., The University of Texas, Austin, 2002M.Sc., The University of British Columbia, Vancouver, 2005A THESIS SUBMITTED IN PARTIAL FULFILLMENTOF THE REQUIREMENTS FOR THE DEGREE OFDoctor of PhilosophyinTHE FACULTY OF GRADUATE AND POSTDOCTORALSTUDIES(Computer Science)The University of British Columbia(Vancouver)December 2016c©Mohammed Shahidul Alam, 2016AbstractSmartphones play an important role in our day to day activities. Some of theminclude monitoring our health such as eating habits, sleep patterns and exerciseschedule. The Android mobile operating system developed by Google is currentlythe most popular operating system for such smart devices. It is also the most vul-nerable device due to its open nature of software installation, ability to dynami-cally load code during runtime, and lack of updates to known vulnerabilities evenon popular versions of the system. Thus, securing such devices from malware thattargets user privacy and monetary resources is paramount.In this thesis, we developed a context-aware multi-agent based framework tar-geted towards protecting Android devices. A malware detection technique hasto be context-aware due to limited battery resources of mobile devices. In somecases however, battery utilization might become secondary. This includes scenarioswhere detection accuracy is given a higher priority over battery utilization. Thus,a detection framework has to be intelligent and flexible. To reach this goal, ourframework relies on building multiple scalable context based models, and observ-ing the behaviour patterns of Android devices by comparing to relevant pre-builtmodels. We make use of machine learning classifiers that are more scalable toiihelp classify features that could be used to detect malware by behaviour analysis.In this framework, the expensive analysis components utilizing machine learningalgorithms are pushed to server side, while agents on the Android client are usedmainly for context-aware feature gathering to transmit the information to serverside classifiers for analysis, and to receive classification results from the serverside agents.iiiPrefaceThis thesis presents research conducted by Mohammed Shahidul Alam under thesupervision of Dr. Son Vuong. All of the research results available here have beenpublished in peer reviewed conference proceedings or in a book chapter.The research work presented in Chapter 3 was published in [2, 4]. The initialidea to use agent based systems for intrusion detection using machine learningapproaches was published in [77].The research work in [4] provided a description of the agent platform, andhow the agents interact with each other using agent communication language inthe Android mobile platform. The research work in [2] expanded on it to providedetails on how the machine learning models stored on servers would be used bythe agent based platform to analyze feature data and provide classification results.[4] was joint work with Zhiyong Cheng, Dr. Vuong’s MSc student. I wasresponsible for designing the initial framework to use JADE mobile agent platformfor feature gathering on Android devices. Zhiyong Cheng was responsible forperforming development of Agent Communication Language (ACL) and for initialtesting on rooted Android devices. Details of his work has been published in [28].The research work presented in Chapter 4 was published in [5] and [3]. Theivresearch work in [5] provided initial experimentation details on a 5-fold cross val-idation approach on Android feature datasets. The research work in [3] expandedthe previous work by adding 10 fold cross validation tests, and comparing the re-sults to a separate training set and validation set. We also measured the space andtime requirements to generate each model.I have received the required permissions for using figures obtained from pub-lished sources.The following are the list of publications related to this thesis:• [4]: Mohammed Alam, Zhiyong Cheng, and Son Vuong. Context-awaremulti-agent based framework for securing android. In 2014 InternationalConference on Multimedia Computing and Systems (ICMCS), pages 961—966. IEEE, 2014.• [2]: Mohammed Alam and Son Thanh Vuong. An intelligent multi-agentbased detection framework for classification of android malware. In ActiveMedia Technology (AMT), pages 226–237. Springer, 2014.• [5]: Mohammed S Alam and Son T Vuong. Random forest classificationfor detecting android malware. In Green Computing and Communications(GreenCom), 2013 IEEE and Internet of Things (iThings/CPSCom), IEEEInternational Conference on and IEEE Cyber, Physical and Social Comput-ing, pages 663—669. IEEE, 2013.• [3]: Mohammed Alam and Son Thanh Vuong. Performance of malwareclassifier for android. In 6th Annual Information Technology, Electronicsand Mobile Communication Conference. IEEE, 2015.v• [77]: Son T. Vuong and Mohammed S. Alam. Advanced methods for botnetintrusion detection systems. In Intrusion Detection Systems. InTech, 2011.viTable of ContentsAbstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iiPreface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ivTable of Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viiList of Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiList of Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiiGlossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xivAcknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.1 Thesis motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Research questions and contributions . . . . . . . . . . . . . . . . 31.3 Organization of the thesis . . . . . . . . . . . . . . . . . . . . . . 62 Background And Related Work . . . . . . . . . . . . . . . . . . . . 72.1 Android security . . . . . . . . . . . . . . . . . . . . . . . . . . 7vii2.2 Agent systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.2.1 Security using multi-agent systems . . . . . . . . . . . . 102.3 Machine learning . . . . . . . . . . . . . . . . . . . . . . . . . . 122.3.1 Machine learning for Android malware detection . . . . . 133 Context-aware Multi-agent Framework For Securing Android . . . 173.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.2 Related work . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.2.1 Context-aware mobile applications . . . . . . . . . . . . . 193.3 Agent-based framework . . . . . . . . . . . . . . . . . . . . . . . 203.3.1 System architecture . . . . . . . . . . . . . . . . . . . . . 203.3.2 Agent categorization . . . . . . . . . . . . . . . . . . . . 243.3.3 Agent types . . . . . . . . . . . . . . . . . . . . . . . . . 253.3.4 Agent communication language . . . . . . . . . . . . . . 333.4 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . 343.5 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423.5.1 Battery context test . . . . . . . . . . . . . . . . . . . . . 443.5.2 GPS context test . . . . . . . . . . . . . . . . . . . . . . 473.5.3 Network context test . . . . . . . . . . . . . . . . . . . . 503.5.4 Android API context test . . . . . . . . . . . . . . . . . . 513.5.5 Rooted device context test . . . . . . . . . . . . . . . . . 523.5.6 Malware detection test . . . . . . . . . . . . . . . . . . . 543.5.7 Verify Correlation agent can correlate 2 devices exhibitingsimilar malware behaviour . . . . . . . . . . . . . . . . . 563.5.8 Server workload measurement . . . . . . . . . . . . . . . 57viii3.6 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 603.7 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 634 Random Forest Classification For Detecting Android Malware . . . 654.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 654.2 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 684.2.1 Android feature collection . . . . . . . . . . . . . . . . . 684.2.2 Random forest . . . . . . . . . . . . . . . . . . . . . . . 704.2.3 Machine learning classifier for Android mobile systems . 714.3 Experiment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 724.3.1 Dataset description . . . . . . . . . . . . . . . . . . . . . 724.3.2 Classification experiment description . . . . . . . . . . . 764.3.3 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . 774.3.4 Software . . . . . . . . . . . . . . . . . . . . . . . . . . 774.3.5 Sample code . . . . . . . . . . . . . . . . . . . . . . . . 774.3.6 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . 794.3.7 Experiment results with a 5-fold cross validation . . . . . 864.4 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 904.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 945 Conclusion And Future Work . . . . . . . . . . . . . . . . . . . . . . 955.1 Thesis summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 955.2 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 975.2.1 Application of machine learning . . . . . . . . . . . . . . 985.2.2 Use of multi-agent systems . . . . . . . . . . . . . . . . . 101ixBibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102xList of TablesTable 3.1 Android Features Observed [5] . . . . . . . . . . . . . . . . . 34Table 4.1 Android Features Observed [5] . . . . . . . . . . . . . . . . . 75Table 4.2 Amount of space required to store Random Forest model filesas depth of trees is increased for a forest of 160 Trees . . . . . 83Table 4.3 Amount of space required to store Random Forest model filesas number of features measured is increased for a forest of 160Trees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85Table 4.4 Experimental Results for varying number of trees and numberof random features with Trees allowed to grow to maximum depth 87Table 4.5 Misclassification Comparison of Different classifiers . . . . . . 91xiList of FiguresFigure 3.1 JADE split-container runtime execution mode. . . . . . . . . 23Figure 3.2 Interaction between client and server Agents. . . . . . . . . . 33Figure 3.3 CPU utilization comparison for battery levels. The x-axis dis-plays the seconds that have passed since the application wasstarted from left to right. The y-axis displays the CPU utiliza-tion in percentage of available CPU. [4, 28] . . . . . . . . . . 42Figure 3.4 Network bandwidth utilization comparison for two battery lev-els. The x-axis displays the time that has passed since the ap-plication was started from left to right. The y-axis displaysbandwidth utilization measured in KiloBytes per second. [4,28] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43Figure 3.5 Memory utilization comparison for two battery levels. The x-axis displays the seconds that have passed since the applicationwas started from left to right. The y-axis displays memoryutilization in Bytes. [28] . . . . . . . . . . . . . . . . . . . . 43xiiFigure 4.1 Classification rate of original dataset as the number of featuresare changed for forest of 10 trees for y range 80 to 96 percent 80Figure 4.2 Classification rate of original dataset as the number of featuresare changed for forest of 160 trees for y range 80 to 96 percent 81Figure 4.3 Classification rate of original dataset when tested on validationset for forests of 10 trees. The results show that as the depthof tree increases, the classification results are poorer due toover-fitting. . . . . . . . . . . . . . . . . . . . . . . . . . . . 82Figure 4.4 Classification rate of original dataset when tested on validationset for forests of 160 trees . . . . . . . . . . . . . . . . . . . 83Figure 4.5 Classification rate on model generated by SMOTE with testingon a validation set with forest of 160 trees. This graph showsthe performance of the Random Forest algorithm on a balanceddataset. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84Figure 4.6 Classification rate on model generated by SMOTE with 10Fold cross validation testing with forest of 160 trees . . . . . . 85Figure 4.7 Misclassification comparison with 20 trees as depth of tree isvaried . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88Figure 4.8 Out Of Bag error rate comparison with 40 trees as depth of treeis varied . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89Figure 4.9 Root Mean Squared error rate comparison with 80 trees asdepth of tree is varied . . . . . . . . . . . . . . . . . . . . . . 90xiiiGlossaryACL Agent Communication LanguageADB Android Debug BridgeAID Agent IdentificationAMS Agent Management ServiceAPI Application Programming InterfaceARM Advanced RISC MachineAVD Android Virtual DeviceCFG Control Flow GraphCPU Central Processing UnitCONUCON Context-aware usage controlDCL Dynamic Code LoadingDDMS Dalvik Debug Monitor ServerDEX Dalvik BytecodexivDF Directory FacilitatorFIPA The Foundation for Intelligent Physical AgentsGPS Global Positioning SystemGUI Graphical User InterfaceIDS Intrusion Detection SystemIPC Inter Process CommunicationJADE Java Agent Development FrameworkJICP Jade Inter Container ProtocolJSON JavaScript Object NotationLEAP Lightweight Extensible Agent PlatformMMS Multimedia Messaging ServiceNFC Near Field CommunicationOOB Out-Of-Bag Used to measure the error rate in case of the Random ForestClassifierP2P Peer To PeerPDA Personal Digital AssitantREST REpresentational State TransferRMA Remote Monitoring AgentxvSMOTE Synthetic Minority Oversampling TechniqueSMS Short Message ServiceSVM Support Vector MachineTCP Transmission Control ProtocolUI User InterfaceUID User Identification Used in Android to partition access permissions ofone application from anotherXML Extensible Markup LanguagexviAcknowledgementsFirst and foremost, I would like to thank my parents and my wife, for their un-conditional love and support during the completion of this thesis. They were mysupport throughout my PhD studies during very difficult times, and helped me takemajor decisions, to keep me going. I will be forever in their debt. I would like todedicate this thesis to them.The amount of appreciation, love and respect I have for my supervisor, Dr.Son Vuong cannot be measured in words. He was my guide over the years andkept pushing me to try my best during the years that I have spent with him ashis student. I would like to thank him for believing in me, and guiding me inmy studies, exposing me to various industry-based research opportunities and onmaking life choices.To both my children, thank you for being there, with your smiles, to keep memotivated during difficult times, and to remind me what life is all about.To my committee members, thank you for pointing me in the right directionwith my thesis, and for the valuable feedback that you provided.I would like to thank all my colleagues in the Networks and Internet Com-puting laboratory (NICLab) for their insight and valuable feedback. My specialxviithanks to Jonatan Schroeder for being a close friend, providing valuable feedbackregarding research and being there together during our struggles to complete ourPhD programs.I thank the almighty Allah for allowing me to complete this journey, and forteaching me more about life thorough my struggles.xviiiChapter 1Introduction1.1 Thesis motivationInternet connected smartphones play an important role in our day to day commu-nication needs. They are not only used for traditional cost incurring activities suchas long distance phone calls and Short Message Service (SMS), but for a varietyof other tasks that contribute to the domain of Internet-Of-Things. Today, smart-phones are used to browse personal and corporate accounts on social networks suchas Facebook and Twitter; conducting monetary activities such as paying for goodsand services via credit card information saved on mobile devices using Near FieldCommunication (NFC) [33]; paying for parking using pay-by-phone applications[61]; and are used by security conscious users as 2-factor authentication devicesfor banking, email and cloud repositories such as Dropbox and Gmail. As such,malware authors have begun focussing their interest on coding malicious applica-tion for smartphones similar to what has been done for personal computing devicesover the last three decades.1The most popular smartphone platform today is the Android platform devel-oped by Google. Three out of four smartphone devices shipped today are based onthe Android operating system. Over a billion devices based on the Google Androidplatform have been deployed since 2008. In Android, each application has an asso-ciated .apk file which is synonymous to a .exe file on the Windows platform. Dueto the open software installation nature of Android, users are allowed to install anyexecutable file from any application store. This could be from the official GooglePlay store [43], or a third party site. This ease of installing applications comparedto other smartphone platforms such as Apple’s iOS [15] platform makes Androidusers vulnerable to malicious applications. Moreover, unlike the iOS platform, ini-tially Google did not verify if applications in their official Play store have maliciousintent prior to making it publicly available. As such, malware had been found inthe official Google Play store applications by security vendors [75]. The platformallows software downloads from third party sites; allows loading additional code atruntime Poeplau et al. [62] using Java-reflection or Dynamic Code Loading (DCL);and does not support patching vulnerabilities in older Android devices. As such,malware authors have predominantly focused on the Android platform. Today, itis the most vulnerable mobile platform with over ninety eight percent of malwarebuilt for it [27].A recent vulnerability with the Android system includes the Stagefright librarybug that leaves 950 million Android phones vulnerable to attack by a single Mul-timedia Messaging Service (MMS) that is undetectable by a user of the phone 1.Devices based on the Android platform can be infected to send SMS to premiumrate numbers to cause financial harm to users [76], used as part of botnets to cause1http://blog.zimperium.com/experts-found-a-unicorn-in-the-heart-of-android/2distributed denial of service attacks [79], and steal banking credentials when thesedevices are used for 2-factor authentication [35]. Android devices can be pre-fittedwith rootkits to track sensitive activities such as keystrokes and SMS messages[65]; and recently researchers have proposed the use of context-aware Androidmalware [47] that makes use of sensors on the device to trigger malware. As canbe observed, many of the security threats identified with the PC industry have madetheir way into the mobile operating system space. A broad characterization of An-droid malware was presented by Zhou and Jiang [82] that provides the observedtrends of malware for Android. They presented over 1260 malware samples in 49malware families with a best-case detection rate of 79.6 percent and a low detec-tion rate of 20.2 percent by commercial antivirus companies. Many of the malwaresamples diagnosed by them used drive-by-download attacks and update attackssimilar to infection vectors used for personal computing devices.1.2 Research questions and contributionsMost of the security solutions that have been proposed in literature requires mod-ification of the Android operating system framework. In this thesis we proposethe use of a multiagent system framework that attempts to detect Android malwarefrom user space, without modification to the Android Operating System. The onlyaddition is the optional addition of rooting of Android devices, which is an accept-able method in the Android environment. The primary base for making decisionshowever is using a machine learning approach. We make use of the Random Forestmachine learning algorithm [22] to make decisions.In this thesis, we try to answer the following research questions:• How could existing machine learning algorithms be applied on features col-3lected for the detection framework for Android in novel ways?• Would it be possible to detect Android malware without modifications tothe Android framework? i.e. Could features be monitored by an Androidapplication (at user level) to detect malware without modifying the AndroidOperating System?• Could context awareness of Android devices, or feature correlation betweenAndroid devices be used to better detect Android malware? How could thisbe enabled given the resource constraint nature of mobile devices and theever changing behaviour of mobile malware?The following are our thesis research contributions:• Contribution 1: We have identified that the machine learning classificationalgorithm Random Forest is a good candidate for detecting Android malwaredata features. This algorithm is a multi-class classifier that is robust to inter-dependence between the features that have been collected while monitoring asystem, and the number of features that are observed to make a classificationdecision. This algorithm requires observing log m features to yield results,where m represents the total number of features observable in the system.This allows the algorithm to compute a decision faster. We published 2 pa-pers that modify the hyper parameters of the algorithm on feature vectorsof Android to classify Android malware. The results of our papers are dis-cussed in Chapter 3. In the first paper [5] we provided initial experimentalresults by performing just a 5-fold cross validation. In our second relatedpaper [3], we performed both 10-fold cross validation experiments and sep-arate training - validation set comparisons by modifying the parameters of4the Random Forest algorithm. Moreover, we performed 3 experiments withrandom seeding for each setting of the algorithm and reported the medianvalues.• Contribution 2: We identified that machine learning algorithms are highlysensitive to parameter settings. There is a significant difference in the de-tection accuracy of a machine learning algorithm, such as Random Forest ifit is used with the default parameters, as is done in most literary work, ver-sus manipulating the parameters of the algorithm. In our experimentation,we varied the number of trees in a Random Forest algorithm, the number ofrandom features compared at each decision point, and the depth of each tree.We find significant difference in results. We also find a variation in the detec-tion rate while performing a 10-fold cross validation and validation set test.A 10-fold cross validation provided a 96.40 percent detection rate whereas avalidation set provided 81.64 percent detection rate. Thus, we observe thatthe results obtained are very sensitive to the parameter settings.• Contribution 3: We have used Java Agent Development Framework (JADE),an agent based middleware, to design our detection framework, to gather rel-evant features from Android devices. We have not come across any other re-search work that uses multiagent systems for detecting malware on Androiddevices. Our current system uses reasonable amount of Central ProcessingUnit (CPU) and memory on Android devices to gather context aware fea-tures. We emphasize the use of context-awareness as many mobile malwaretoday are launched based on the network the user is connected to, or regionthat a user is located in physically, or the version of the operating system5the user uses. Our architecture pushes the model generation and detectioncomponent to server side as it is a more computationally intensive task. Weprovide work-load statistics on the server such as CPU time, and memoryutilization in running the agent-platform.1.3 Organization of the thesisThe rest of the thesis is organized as follows. In Chapter 2, we provide relatedbackground work to this thesis. In Chapter 3, we provide the design and experi-mentation results of using a multi-agent environment for collecting Android-basedfeatures. In Chapter 4, we propose the use of the Random Forest machine learningalgorithm on an Android dataset. We perform extensive experiments and provideour results. Finally in Chapter 5, we summarize the thesis and include possible ex-tensions to this research based on emerging research in the area of machine learningapproaches to malware detection on Android.6Chapter 2Background And Related WorkIn this chapter, we review relevant background and related work that are founda-tional to this research work. This thesis addresses the subject of Android securityusing multi-agent systems as a detection framework. The multi-agent system usesa machine learning algorithm for detection and analysis of Android malware. Thus,we provide background information on the following three research domains:1. Android security2. Agent systems3. Machine learning2.1 Android securityResearch and development for malware detection for Android mobile systems canbe divided into two primary types. Static malware detection, and dynamic mal-ware detection. Work in static detection is done by reverse engineering Android7executable files (.APK) using tools such as Androguard [32] to statically analyzethe .dex byte code of Android executable files, or by signature matching by listen-ing to executable installations on Android by monitoring Android intent messagesfor file downloads. Dynamic detection of malware uses monitoring of device be-haviour either by monitoring the state of the system by inspecting the sensors onAndroid devices such as screen being turned off while an SMS is being sent, or bymonitoring various system parameters. Given the extensive size of the data that isto be processed, many solutions now use machine learning approaches to solvingthe problem instead of manually working with available data.Given that most malware threats have been targeted for Android systems, manyapproaches have been proposed in literature for securing Android devices. Taint-Droid [37] modified the Android Dalvik virtual machine code to taint and tracksensitive data stored on the device by causing a 32 percent overhead on CPU.They tracked the flow of user private information. Kynoid [68] extended the so-lution to provide real-time security policy enforcement for Android by using user-defined security policies defining temporal, spatial and destination constraints ondata. Nauman et al. [60] provided an extended Android package installer allowingusers to have more control over runtime constraints on Android applications by al-lowing fine grained access control policies on applications and adding constraintson resources allowed to be used. Shabtai et al. [70] classified Android threatsinto five categories and recommend incorporating Linux security solutions usingSELinux [69]. Their evaluation results show significant performance degradationon CPU and memory usage. Limited resource issues were also faced by Schmidt etal. [67] when they recompiled various Linux tools to enhance Android security. Asmentioned previously, most of these approaches require modifications to the base8Android framework which makes the solutions difficult for easy deployment.2.2 Agent systemsThe term agent or software agent is usually deciphered well in the artificial intel-ligence community, where it stands for a program that can behave autonomouslyto perform a multitude of dynamic tasks based on the logistics that have been pro-grammed into it by a user. Advantages of using multi-agent platforms include [21]:asynchronous autonomous interactions between agents, easy software upgrades,and ability to function in heterogeneous environments.Asynchronous autonomous interaction: This advantage is vital in a networkwhere network connections are volatile, such as wireless networks. Even if theconnection breaks, the agent could continue processing data on the mobile deviceand report back whenever the connection is reestablished. This adds to the agent’scapability to work in a fault tolerant mode.Software Upgrades: Usually in order to update software on multiple hosts, anadministrator has to first stop the server functionality, then uninstall the old versionof the software, and then reinstall the new version. The entire software system hasto be stopped for upgrades. The advantage of agents in general in this situationis that if each component of the upgraded software is managed by an agent, thenit is as easy as disabling the old agent and deploying a new agent which has therequired functionality. In this way one could avoid bringing down the entire systemand instead stop just a single agent-based component.Functionality in heterogeneous environments: Most agents today can work inheterogeneous environments. This is due to the fact that these agents are usuallywritten in a language which is portable to multiple platforms, such as java or perl.9Since agents sit on top of an agent framework, they can easily function regardlessof if the host runs a version of Linux or Windows operating system. The significantreduction in costs of placing agent frameworks in hosts over the past few years haveadded to the benefits of running agents.A disadvantage is the need for an agent platform to be supported by the under-lying operating system (such as Android) for agents to deploy and communicatewith each other. Communication between agents is achieved using The Founda-tion for Intelligent Physical Agents (FIPA) 1 compliant Agent Communication Lan-guage (ACL). This is the primary reason in choosing JADE agent platform as it iscontinually supported on Android devices. Other platforms supported for Androidinclude JaCa-Android [66].2.2.1 Security using multi-agent systemsThe use of multi-agents for security had been done earlier for computers. We nowdiscuss some related work in the field.The earliest work in this area was started by Purdue University’s CERIAS (TheCenter for Education and Research in Information Assurance and Security) groupwhen they put forward a proposal for building an autonomous agent based securitymodel by using genetic programming [29]. This was followed up by their workin implementing the earlier proposal [19]. This system was called AAFID (Au-tonomous Agents for Intrusion Detection) written earlier in Perl, Tcl/Tk and C,and later revised and written in the perl language to make it more portable. Helmeret al. [48] used an anomaly detection technique by using the Ripper algorithm onsendmail system calls. The architecture mimicked a portion of the Java Agents for1www.fipa.org10Meta-Learning (JAM) project [73]. A distributed hierarchical Intrusion DetectionSystem (IDS) was proposed by Mell and McLarnon [55] that tries to randomizethe location of agents and decentralizing directory services. The system also resur-rects agents killed by an intruder as there always exists multiple copies that trackthe original agent and vice versa. The Micael IDS was proposed by [31]. They pro-posed an additional feature of periodically checking if all agents are active in thesystem. Another prominent work that detects intrusions using mobile agents is theIDA system [16]. This system tries to backtrack intrusion attempts by looking intoMLSI (Mark Left by Suspected Intruders) left at each host. They also emphasizetracking the steps that an attacker takes.The Sparta system by Kruegel et al. [50, 51] is the most extensive work donetill date on using mobile agents and intrusion detection. Sparta, which stands forSecurity Policy Adaptation Reinforced Through Agents, is an architecture that iscapable of monitoring a network to detect intrusions and security policy violationsby providing a query like functionality to reconstruct patterns of events acrossmultiple hosts. This is a network-based IDS that correlates data from multiplesensors located throughout the network. The authors have created an EQL (EventQuery Language) with syntax similar to SQL (Sequence Query Language) used indatabases.Other mobile agent based IDS’s include a Peer To Peer (P2P) based IDS [63]that works in a neighbourhood watch manner where each agent looks after otheragents in its vicinity by using a voting procedure to take action against a com-promised agent; the MA-IDS system [52] which uses encrypted communicationbetween the mobile agents in the system, and use a threshold mechanism to de-tect the probability for each intrusion depending on the quantity of each intrusion11type obtained allowing it to learn in a one dimensional method. Some other agentbased IDS’s include the work by Foukia et al. [39, 40] which uses a social insectmetaphor and immune systems to model an intrusion detection system.2.3 Machine learningThe domain of machine learning is used in solving problems where the problemsize is large enough such that it would be difficult for humans to adequately makesense of data. Machine learning algorithms are used to extract features from thedata such that it could be used for solving predictive tasks such as classifying,decision making and forecasting results [30]. Since this thesis uses predictive orsupervised learning approach, we provide basic meaning of such a method. Insupervised learning, given a labeled set of input-output pairs (the training set) withN training examples, the goal is to predict a future y value given an input. Theinput to such a system is xi which is a D-dimensional vector, also called a featurevector. xi is a set of values used to determine yi. When yi is categorical (such asmalware, goodware, etc.), the problem is considered as classification [58].Classification techniques such as Support Vector Machines, K-Nearest Neigh-bours, Decision Trees, Logistic Regression and Naive Bayes have widely been usedin the area of intrusion detection research in the security community. They are pre-dominantly used for behaviour based detection methods, also called anomaly de-tection methods. We now present some related work in the use of machine learningapproaches used for Android malware classification.122.3.1 Machine learning for Android malware detectionAllix et al. [6] observed over 50000 applications including malware from the genomeproject by Zhou and Jiang [82] which is a dataset of Android malware used forresearch purposes. The authors created a set of features based upon textual repre-sentation of basic blocks extracted from Control Flow Graph (CFG) of applicationbyte codes. They observed 2.5 million features. Since these features are com-puted statically, they will however miss dynamically loaded features in Android,made possible by using the Android dexClassLoader library. The authors com-pared C4.5, ripper, Support Vector Machine (SVM) and Random Forest algorithmwith their default settings and conduct experiments by adjusting the good ware tomalware ratio and the number of features to use.Yury et al. in [81] addressed the problem of dynamic code loading in Androidby using a client-server model where a client runs the dynamically loaded mod-ules from an Android device emulator, and feeds it to a server that conducts staticanalysis. They use the concept of method call graph to capture new method callsgenerated by dynamic loading and pass it to the static component to add it to thelist of features observed.Glodek and Harang [41] created 19137 features from 2 or 3 permission sets ob-tained by setting a threshold value of 0.05 where the threshold defines the featurebeing present in malicious vs benign sample. They used the random forest algo-rithm with 25 trees and maximum depth and had results of 92 percent true positiveand 3 percent false positive.Kim et al. [49] developed an automatic feature extraction tool implementedin JavaScript for static detection. The input to their system is a .apk Android exe-13cutable file. The authors use JavaScript code to extract the following as features:Number of permissions requested by the application (gathered from the mani-fest.xml file in Android .apk package file); API count of each method related tophone management invoked from the code; API count of each method related tophone control and privacy information called from the code. Based on these fea-tures collected, the authors use J48 Decision Tree classifier from the Weka libraryand perform 10 fold cross validation on 1003 Android applications. They receiveda true positive rate of 82.7 percent and false negative rate of 17.3 percent.Burguera et al. [24] used a rooted Android device. The Linux based tool stracewas used to capture system calls. The authors captured the number of each systemcall invoked by a given Android application to form the feature vector. Each fea-ture vector was composed of 250 linux 2.6.23 system calls. Based on experimentalresults, the most relevant system calls for malware detection were read(), open(),access(), chmod() and chown(). The authors used a simple 2-means clusteringalgorithm to distinguish between benign applications and their corresponding mal-ware version. The distance between clusters is just a Euclidean distance betweenthe feature vectors. Their solution would cluster similarly named applications intotwo different clusters, one for the malware and the other for the benign sample.The solution works under the assumption that a benign sample is re-fitted withmalicious code before being uploaded. Thus, a malware without a benign versioncannot be detected. One weakness of the system is that their tool cannot detectmalware that uses very few system calls, as was exhibited in Monkey Jump 2 mal-ware.Dini et al. in [34] used a rooted device to design a host based real time anomalydetector based on 1-Nearest Neighbour classifier. They monitor 13 features. At14user-level 2 features are monitored: if the phone is active/inactive; and if SMS isbeing sent when the phone is inactive. At the kernel level, they created a kernelmodule to monitor 11 system calls: open, ioctl, brk, read, write, exit, close, sendto,sendmsg, recvfrom, recvmsg. Their model monitors system wide behavior using 2models, one which captures the features every 1 second interval, and another whichcaptures every 1 minute interval. The system was tested on 10 genuine malwaresamples. The authors claim a malware detection rate of 93 percent in general witha false positive rate of 0.0001.Shabtai et al. in [71] monitored 88 features on an unrooted device. They mon-itor the features on 2 real devices used by 2 different users. They tested theirapproach on 16 benign applications and 4 self generated malware. Their modelmonitors features at 2 second intervals. The authors compared the use of thefollowing classifiers: k-Means, Logistic Regression, Histograms, Decision Tree,Bayesian Networks and Naive Bayes. The authors use a filter approach for fea-ture selection by comparing Chi-Square, Fisher Score and Information Gain. Theyused top 10, 20, 50 features for computing the scores for each feature out of the88 features available. Based on their evaluation, they have a detection rate of 80percent. Their false positive rate is 0.12. They claim that Naive Bayes and Lo-gistic Regression were superior for most configurations. Fisher score with top 10features scored the best among their experimentation. The authors identified thefollowing features as being of importance in distinguishing malware and benign ap-plications: Anonymous pages, Garbage Collections, Battery Temp, Total Entries,Active Pages, and Running Processes.Amos in [10] created an automated system to analyze malware samples. Thetool allows for the automated analysis of benign and malicious Android applica-15tions by running adb scripts in Linux systems. Since we used data gathered by [10]for our experiments, section 4.3.1 provides more details about the dataset. The au-thor compared results from using the following classifiers: Bayes Net, J48 decisiontree, Logistic Regression, Multilayer Perceptron, Naive Bayes and Random Forest.We would like to point out that Random Forest was only tested with the defaultsetting of 10 trees and 6 parameters.Z. Aung and W. Zaw [17] performed a static analysis of 500 Android .apk filesby inspecting the permissions requested by a given application. They used 160permissions as their feature vector. They compared Random Forest, J48 DecisionTree, and Classification and Regression Tree (CART) algorithms. Unfortunatelythey do not discuss the parameter setting used for Random Forest, nor the numberof benign and malicious applications used for experimentation.16Chapter 3Context-aware Multi-agentFramework For SecuringAndroid3.1 IntroductionMany commercial and research prototypes have been developed to deal with se-curing Android. Independent testing of commercial solutions show that less thanhalf of them are efficient in detecting malware [54]. Many of the security solutionsproposed in literature require modification to the Android framework. Moreover,the frequent release cycle of Android causes modifications to the underlying An-droid API, making many of the proposed security solutions no longer viable. Lackof available resources such as battery, memory and CPU on these devices furtherlead to constraints that need to be satisfied before traditional Linux security tools17can be directly applied.Given the availability of multiple sensors on Android mobile devices that canbe accessed by Android applications using Android API; and the lack of availableon-device resources such as battery, memory and CPU; we propose the use of acontext-aware multi-agent based framework to monitor and dynamically launchinvestigative agents on Android mobile devices. We provide a framework design,implementation details and evaluation of our proposed framework to show that amulti-agent based system is a viable option for securing such devices. We proposethe use of spatial context-information gathered using location information(GPS,network) and device context (battery level, Android API level, rooted device) tomake context-aware decisions for the framework. We also show that we can usecontext information to reduce frequency of network connections and CPU utiliza-tion overhead caused by the Multi-Agent framework.According to our knowledge, we have not come across any other research workthat uses multi-agent based systems on Android devices that make context-awaredecisions to detect malware threats. Our primary goal is to gather context awaredata from Android devices to choose which machine learning classifier model touse [5]. The main contributions of this chapter can be summarized as follows:• Provide the design and implementation of a context-aware agent-based frame-work based on the Java Agent Development Framework (JADE) [74] multi-agent platform.• Use both spatial context information gathered using location information(GPS, network); and device context (battery-level, Android API, rooted de-vice detection) to make context-aware decisions by dynamically modifying18detection behaviour of deployed agents.• Provide evaluation of the agent system applied to the Android context toevaluate system overhead incurred by the use of the detection framework.• Provide experimental usage scenarios for detecting Android based malwareby collecting features.The rest of the sections are organized as follows. Section 3.2 provides back-ground information needed to understand the problem domain. Section 3.3 pro-vides the proposed multi-agent based framework; Section 3.4 provides implemen-tation details; Section 3.5 provides initial results of experimenting with the system;Section 3.6 discusses concerns that might be raised with the proposed framework.3.2 Related work3.2.1 Context-aware mobile applicationsInitial development based on JADE-LEAP was provided by Moreno et al. [57] fordevelopment of a taxi-cab service application on Personal Digital Assitant (PDA)using bluetooth communication. The closest related work to context-awareness inthe Android operating system space for security was proposed by Bai et al. [18].The authors proposed a context-aware methodology for securing Android operat-ing system based on Context-aware usage control (CONUCON) model. Their sys-tem requires modification to the Android framework to hook the checkComponent-Permission function to monitor objects and associated permissions. Similarly, theMOSES system proposed in [80] also requires modifications to be made to the un-derlying Android operating system. The purpose of MOSES is to use context to19maintain security profiles and allow switching between profiles during runtime. Inour system, we do not require modifications to be made to the Android framework.We optionally require devices to be rooted if privileged tools are to be used forpacket inspections. Rooting a device is a more acceptable solution based on thepopularity of rooted application in the Google Play store.3.3 Agent-based framework3.3.1 System architectureThe system that we have developed has a client-server model. A client-servermodel is necessary because of the pre-condition set by the Java Agent Devel-opment Framework (JADE) agent platform which requires the server to host twoJADE specific services: the Agent Management Service (AMS), and the DirectoryFacilitator (DF). These services allow agents in the system to discover each other.JADE platform servicesAMS: Agents in the system have to register with the AMS. The AMS supervisesthe entire platform of agents. It checks the validity of the unique Agent Identifi-cation (AID) of an agent, and keeps track of the life-cycle of agents in the system.There exists a single AMS for the entire system. The AMS resides in the maincontainer of the platform and communicates messages in the system using thejade.domain.JADEAgentManagement.JADEManagementOntology ontology class.Some of the management functionality performed by the AMS include:1. create-agent: This action allows the AMS to create an agent of a given classtype with a chosen agent name in a specific container.202. kill-agent: This action allows the AMS to destroy the uniquely identifiedagent.3. kill-container: This action allows the AMS to destroy an agent container.4. query-platform-locations: This action allows the retrieval of all containersthat are available in the platform.5. query-agents-on-location: This action allows the retrieval of all agents in agiven container.6. where-is-agent: This action allows locating the containerID where the agentresides.As can be seen, using a combination of queries, the location of all agents andtheir associated containers can be queried from the AMS. The AMS also allowsany agent in the platform to subscribe to platform events using a FIPA-Subscribeprotocol. Though we do not use subscription in our framework, some of the tasksthat are allowed include: subscribing to agent state such as creation, suspension, re-sumption, movement, cloning and destruction; container creation and destruction;and platform shutdown requests.DF: The DF is an optional yellow page service that allows agents in the systemto advertise their services in the system and also query to find agents that providea service. There exists zero or more DF services that can interact with each otheras a federation. Some of the services allowed by the DF include:1. Registration: Agents that want to publicize their capabilities have to locate aDF to register its agent description.212. Deregistration: Agents can also request to de-register from a DF when it nolonger wants to publicize its services.3. Description modification: Agents can also modify their agent-description ifthey want to modify their advertised services.4. Search: Agents can query the DF to look-up agents providing an advertisedservice through their registered agent descriptions.Split container runtime execution modeIn JADE, every agent that runs in the system has to exist in a JADE runtime con-tainer. For mobile devices however, JADE also allows a split execution mode us-ing the Lightweight Extensible Agent Platform (LEAP) add-on. The split-containermodel is recommended for resource constraint mobile devices. This approach runsa thin front-end client on the mobile device, and runs the back-end on a server. Thefront-end and back-end communicate using a dedicated connection that is robustto connection failures [20].The communication setup between the front-end and the back-end is made pos-sible by the use of a dedicated server in JADE called the mediator. The mediatorruns at a well-known address that is network accessible by all mobile devices andby the various containers in the platform. During startup, the front-end sends aCREATE MEDIATOR request using Jade Inter Container Protocol (JICP). The me-diator then creates a back-end and connects the front-end to it. The back-end thentries to establish a connection with the main container hosting the AMS. Once thenewly created split-container is registered with the main-container, the mediatornotifies the front-end that the registration was successful. The mediator takes no22Figure 3.1: JADE split-container runtime execution mode.part once the connection has been established between the front-end and the back-end. Fig. 3.1 shows the interaction between the various components just described.Some of the advantages of the split-container mode include:1. Connection loss transparent to applications: The front-end and back-enduses a store and forward methodology to transmit messages i.e. if there is aconnection disruption between the front-end on the mobile device, and theback-end on the server, then all messages are buffered in both ends. Whenthe connection resumes, the messages are exchanged.2. IP address of mobile-devices can be dynamic: Since the agents on the mobiledevice interact with other agents in the platform using the back-end, a changein the IP address of the mobile device hosting the front-end causes no issues.Agents on other containers need to know the IP address of the back-endserver only.233. Lightweight communication: The front-end hosted on the mobile device ismore lightweight than a full container as most of the communication withother containers is taken care off by the back-end.Though there are advantages to using the split-container on mobile devicesas mentioned, cloning of agents and mobility of agents are not supported in thesplit-container method. If such functionality is required, the JADE platform allowsdynamic behaviours to be loaded into mobile devices running in a split-containerexecution mode by using the jade.core.behaviours.LoaderBehavour class.In our framework, the Android devices are considered as clients. Each Androiddevice hosts the front-end. Each Android device runs an Android application thatis wrapped using a Jade split-container runtime service as described. We also useservers that host multiple framework specific service agents. The service agentsperform more computationally expensive operations, and as such have not beenplaced on mobile devices to conserve resources. The agents launched on the serverare detailed in section Agent categorizationOur agent-based framework consists of two categories of agents. The first typeof agents can be categorized as the data or feature collector agents. These agentsreside on Android devices to perform data collection tasks at various intervals oftime. Some of these agents persistently reside on the device, whereas others arelaunched based on contextual information of the device. Some of the contextualinformation used includes: location of the mobile device; Android-API level ofthe operating system; device root status; and applications available on the device.The second type of agents are the service or analysis agents. These agents usually24consume higher resources, and are preferably placed on the server side. Theseagents are active for longer durations of time and are responsible for maintaininglong term profile information of Android devices.3.3.3 Agent typesBased on the design principles of JADE [56] agent-oriented development method-ology, all users of the framework; all devices that exist in the framework; and all re-sources available in the framework are to be identified as agents. Each agent in turn,can then be further partitioned based upon their role as providing support service toother agents; help in agent and resource discovery; work as agent-framework man-agement; or perform device or framework monitoring. As shown in Fig. 3.2, afterthese refinements, we have the following agent types with associated functionality.Following are the agents that reside on the client side (Android device):• Profile agent: This agent is active for the entire life cycle of the agent plat-form on the device. This is the primary agent on the client side. Some of thetasks performed by this agent includes:1. Responsible for communicating with the Profile Service provider onthe server to receive commands.2. Maintains a local copy of the profile information of the Android deviceit is installed on.3. Register with the Profile Service provider on startup.4. Launches Action agents after communicating with the Location andSensor agents on the Android device to collect context-aware data whenrequested.255. Maintaining threshold levels to optimize use of device resources. Mon-itoring battery is one of those resources.6. Performs notification tasks to inform the Profile Service agent aboutcompleted tasks. Providing computed feature vectors through pre-definedAgent Communication Language (ACL) ontology is one of the tasks.• Sensor agent: The primary task of this agent type is to monitor sensorsavailable on the Android device. The tasks performed by this agent includes:1. Subscribes to sensor event that occur on the Android device by usingintent messages. This is required so that the agent is notified by theAndroid operating system of any changes that occur with network orsensor events on the device.2. Monitor static information of the Android device. This includes check-ing: if the device is rooted; and the Android version of the operatingsystem that has been installed on the device.3. Monitor network information of the Android device. This includeschecking the network type the device is connected to i.e. if it is con-nected to a wireless access point; the name of the wireless access point;the IP address assigned to the Android device.4. Reports any changes to the information gathered to the Profile agent onthe Android device so that the Profile agent always contains updatedinformation. This is required as the Profile agent will perform tasksbased on context information received from the Sensor agent.• Location agent: The primary task of this agent is to handle all location26related procedures. The tasks performed by this agent includes:1. Subscribes to Global Positioning System (GPS) events using the an-droid.location.LocationListener Android class. The LocationListenerclass is used to receive notifications sent by the LocationManager dur-ing reported location changes. The Android LocationManager reportsto the Location agent as it registered with it during startup.2. Directly communicates the location information to the Location Ser-vice agent on the server in terms of its latitude and longitude.3. Directly communicates the location information to the Profile agent onthe Android device.4. Can retrieve list of nearby Android devices from the Location Serviceagent.• Action agent: This agent type is the most important data collector agent inthe framework. The tasks performed by this agent includes:1. Dynamically launched by the Profile agent. The dynamic launch be-haviour is caused either because one of the rules maintained by theProfile agent is triggered; or the Profile Service has asked the Profileagent for data, that can only be collected by launching an Action agent.2. Maintains context-aware data. This is required as not all Action agentscan perform its tasks without certain context information. Every Ac-tion agent maintains the Android API-level required for functionality.This is required as the functionality of the Agent might not be compat-ible with certain Android API-levels. For example, Android 4.3 allows27applications to access Android notifications by creating a notificationslistener. This feature was not available in earlier API levels.3. Stores its resource utilization level in terms of memory, CPU, disk andnetwork utilization. A higher value denotes a higher resource utiliza-tion. Currently we have set it manually, but we foresee agents beingable to automatically compute these values based on the specific deviceresource such as the amount of memory in the device and the processorused.4. A particular Action agent runs on the Android device, if and only if theresource constraints and API constraints pass. The decision is madeby interacting with the Profile agent on the device as it keeps track ofall running agents on the device. The Action agent reports its resourceutilization score to the Profile agent. The Profile agent verifies thatthe summation of resource utilization of all Action agents is below thethreshold. If it is, then the Action agent is notified to perform its tasks.5. Tasks performed by the Action agents include– monitor application installations– report memory and CPU usage– report binder API statistical values– IP addresses being communicated with and which services arecausing the network traffic– detect if device is rooted– use tcpdump for Advanced RISC Machine (ARM) to capture net-work packets if the device is rooted and the tcpdump service exists28on the mobile deviceNow that we have described all the agents on the client side, we now providedetails of the tasks performed by the agents on the server side. The server-sideagents are also called service agents. It should be clarified that not all the serverside agents have to reside on the same physical machine. Given the existence ofAMS and DF agents in the platform, they can be queried to locate the relevantserver side agents. The agents communicate with each other using pre-specifiedAgent Communication Language (ACL) messages.The server side agents in ourframework are:• Subscription Service agent: The primary task of this agent is to maintainhistorical information of connected Android devices and their state. Thetasks performed by this agent includes:1. Register Android devices when they join the framework.2. De-register Android devices when they want to exit the platform. Notethat since the Android devices in our system use a split-container exe-cution mode as discussed prior, the Android device would have to quitthe Android application to disconnect the back-end from the frame-work.3. Maintains list of currently connected Android devices in the system.4. Maintains historical information about each connected Android deviceregardless of if it is currently connected or not.• Location Service agent: The primary task of this agent is to maintain his-torical information of the location history of each Android device that has29ever connected to the system. The tasks performed by this agent includes:1. Responsible for receiving location updates from Android devices throughthe Location agent on the Android device.2. Maintains a time-stamped list of all reported locations for each Androiddevice. This is useful for obtaining historical information of locationfor each Android device.3. Responsible for providing list of nearby devices when queried by anyagents in the system.• Profile Service agent: The primary task of this agent is to maintain an eventfeed for all active Android devices. The tasks performed by this agent in-cludes:1. Maintains the profile of every Android device. This includes both staticand dynamic information of the Android device such as the API levelof the Android device, if the device is rooted, the IP address assignedto the Android device, e.t.c.2. The Profile Service agent periodically receives updated profile infor-mation from the Profile agent on the Android device.3. This agent sends recommendations to Android device Profile agent tostart new (Action) agents.4. This agent launches a Device Analysis agent for each Android devicein the system, if one does not exist.5. This agent requests Profile agent on the Android device to modify mon-itoring behaviour based on feedback from the Device Analysis agent30associated with the Android device.6. This agent relays the feature vectors sent by the Profile agent on theAndroid device to the Device Analysis agent for analysis / classifica-tion.7. Maintains historical data regarding the number of malware feature vec-tors observed. This value is used to modify observation behaviours onthe Android device by informing the Profile agent on the device.• Device Analysis agent: The primary task of this agent is to verify if an An-droid device exhibits malware behaviour. There exists one Device Analysisagent for each Android device in the system. The tasks performed by thisagent includes:1. This agent receives the feature vector to compare, and how it was com-puted from the Profile Service agent. The Device Analysis agent needsto know how the feature was computed, so that it can pick a subset ofpre-generated models to compare against.2. This agent uses the machine learning classification models built usingWeka to compare the feature vectors [5].3. Notifies the Profile Service agent if malware behaviour was observedfrom the sent feature vector. Our current design compares the featurevector against each relevant model stored in our system. If malwarebehaviour is reported by more than a set threshold number of models,only then is it reported to the Profile Service agent.4. Maintains historical information of feature vectors observed to be mal-ware, and models that marked it as malware. This information is useful31to correlate devices that exhibit similar maliciousness by the Correla-tion agent.• Correlation agent: The primary task of this agent is to correlate Androiddevices that exhibit similar malware behaviour. This agent is launched by asystem administrator. The tasks performed by this agent includes:1. Locate all Device Analysis agents in the framework. This is requiredas the Device Analysis agents contain data related to:– If the associated Android device has exhibited malware behaviour.– The feature vector that caused the malware behaviour.– The machine learning models that caused the detection.2. Query the Device Analysis agents if it detected malware on a particularmachine learning model. If yes, the Device Analysis agent sends theunique name of the Android device and the feature vector that causedfailure on the model.3. Query the Device Analysis agents if it detected malware on a certainnumber of models. If yes, the Device Analysis agent sends the uniquename of the Android device and a key:value pair of the model andfeature vector that caused failure on the model.4. Correlate all Android devices that have exhibited malware infection onthe same model.Though the Correlation Agent performs basic operations now, greater logiccan be included. This includes correlating Android devices infected in asimilar location using information obtained from Location Service agent;32Figure 3.2: Interaction between client and server Agents.or correlating Android devices infected in a particular time frame by usingsubscription information from the Subscription Service agent.3.3.4 Agent communication languageGiven that our data collection agents reside on Android devices with a split-container,and the service agents are placed in a server on a Linux or Windows installation, themechanism for communication between the agents is via a FIPA-compliant AgentCommunication Language (ACL). We developed an application specific ontologyusing the SL codec of JADE to compose ACL message concepts, predicates andagent actions [28]. Concepts are entity classes that encapsulate the values that needto be stored such as the resource threshold of the device, geo-coordinates of the de-vice. Predicates are propositions which have to be verified such as registering andde-registering an Android device. Agent actions indicate tasks performed by agentsin the system such as updating the location of android devices to the server, andquerying nearby devices.33Table 3.1: Android Features Observed [5]Category FeatureBattery IsCharging, Voltage, Temperature, BatteryLevel, BatteryLevelDiffBinderTransaction, Reply, Acquire, Release, ActiveNodes,TotalNodes, ActiveRef,TotalRef, ActiveDeath, TotalDeath,ActiveTransaction, TotalTransaction,ActiveTransactionComplete,TotalTransactionComplete, TotalNodesDiff, TotalRefDiff,TotalDeathDiff, TotalTransactionDiff, TotalTransactionCompleteDiffCPU UserCPU, SystemCPU, IdleCPU, OtherCPUMemorymemActive,memInactive, memMapped, memFreePages,memAnonPages, memFilePages, memDirtyPages, memWritebackPagesNetworkTotalTXPackets,TotalTXBytes, TotalRXPacketsTotalRXBytes, TXPacketsDiff, TXBytesDiff, RXPacketsDiff, RXBytesDiffPermission Permissions3.4 ImplementationIn order to build and test our prototype system, we used JADE version 4.2. Thiswas the most current version of JADE at time of implementation. We built anAndroid application that was set for Android API version 4.0.3. In the Androidapplication, we used the jade-android library available for JADE version 4.2. Wefollowed the procedures provided by authors of the JADE system in [25]. As men-tioned previously, we used a JADE split-container execution mode in our frame-work. This is done by using the jade.android.MicroRuntimeService service classprovided in the jade-android library provided. To use the MicroRuntimeService,the Manifest.xml file in Android needs to be modified to read:<application ...>34<service android:name="jade.android.MicroRuntimeService" /></application>This allows the JADE split-container runtime to be wrapped by an Android servicethrough Android code.The application specific ontology for Agent Communication Language (ACL)communication between agents was developed using Protege [59] and Ontology-BeanGenerator [1]. The OntologyBeanGenerator allows to create JADE ontologyusing Protege to create the necessary classes. There exists only one instance of thecreated ontology as a singleton pattern is used. The following code snippet showshow our ontology JASOntology is declared in an agent:private Codec slCodec = new SLCodec();private Ontology jasOntology = JASOntology.getInstance();protected void setup(){...ContentManager contentManager = getContentManager();contentManager.registerLanguage(slCodec);contentManager.registerOntology(jasOntology);contentManager.setValidationMode(false);...}35More details regarding ontology generation and ACL message creation are pro-vided in our related work [28].In order to test our JADE-based framework, we used both a rooted Android Vir-tual Device (AVD) emulator and a physical rooted Android device as clients. Theserver side Service agents mentioned previously are located in a network reachablemachine on the network.To test on a rooted Android Virtual Device (AVD) for testing the use of deeppacket inspection applications such as tcpDump for ARM [13], we installed supe-ruser [12]. Superuser is a software package that allows Android applications tohave access to root shell. Without this program, agents on the Android emulatorcannot access the root shell.We used Busybox [11] for using uname, netstat commands. The Busybox exe-cutable contains commonly used Linux utilities that is not available in Android bydefault. The tool has been optimized for use in embedded Linux environments.In order to test if an Android device is rooted, we used the RootTools [38]application.To find context information such as the API level of a device, we use the valuefrom android.os.Build.VERSION.SDK INT. We retrieve GPS locations by receiv-ing updates from Android LocationManager using the requestLocationUpdatesfunction. In order to access network related information, our application requestscoarse, fine, and internet network permissions in the Android manifest file. This isdone using the following code:<uses-permission ..."...INTERNET" /><uses-permission ..."...ACCESS_NETWORK_STATE" />36<uses-permission ..."...ACCESS_FINE_LOCATION" /><uses-permission ..."....ACCESS_COARSE_LOCATION" />For retrieving values mentioned in Table 3.1 used by our Action agent we readsystem files on Android. Following is a description of the features obtained:The battery related feature information was collected by using an intent objecton the BatteryManager class. The battery-based features measured are:• IsCharging: Use the BatteryManager class of Android to check if the deviceis currently connected to a power source and in a charging state• Voltage: Use the BatteryManager class of Android to check the current Volt-age of the battery• Temperature: Use the BatteryManager class of Android to check the currenttemperature of the battery• BatteryLevel: Use the BatteryManager class of Android to check the currentamount of battery power remaining (in range 0—100)• BatteryLevelDiff : Change in battery level since the last time the featurevector was computedAll processes in Android communicate with each other using Inter ProcessCommunication handled by Binder. The binder related feature information wascollected by reading /sys/kernel/debug/binder/stats or /proc/binder/stats dependingon the kernel version. The binder-based features measured are:• Transaction: Number of Inter Process Communication (IPC) transactionsperformed37• Reply: Number of Reply Transaction messages processed• Acquire: Number of Acquire Transaction messages processed• Release: Number of Release Transaction messages processed• ActiveNodes: Nodes (Processes) that are active• TotalNodes: Total Nodes (Processes) maintained by Binder• ActiveRef : Active references to binder objects• TotalRef : Total References to binder objects• ActiveDeath: Total Active processes killed and resources cleared• TotalDeath: Total Processes killed and resources cleared• ActiveTransaction: Number of Active IPC Transactions open• TotalTransaction: Total number of Transactions performed since startup• ActiveTransactionComplete: Number of Active Transactions that have beencompleted• TotalTransactionComplete: Total number of transactions that have beencompleted• TotalNodesDiff : Difference between current reading of TotalNodes and theprevious reading of TotalNodes• TotalRefDiff : Difference between current reading of TotalRef and the pre-vious reading of TotalRef38• TotalDeathDiff : Difference between current reading of TotalDeath and theprevious reading of TotalDeath• TotalTransactionDiff : Difference between current reading of TotalTransac-tion and the previous reading of TotalTransaction• TotalTransactionCompleteDiff : Difference between current reading of To-talTransactionComplete and the previous reading of TotalTransactionCom-pleteThe CPU related feature information was collected by running the Linux topcommand every 1 second. The CPU-based features measured are:• UserCPU: CPU usage by User processes• SystemCPU: CPU usage by System processes• IdleCPU: Idle percentage of CPU usage• OtherCPU: Other CPU usageThe memory related feature information was collected by observing the procdirectory in the underlying Linux system of Android. The files that were read are/proc/meminfo and /proc/vmstat. The memory-based features measured are:• memActive: The total amount of memory being used as per /proc/meminfo• memInactive: The total amount of page cache memory that are available asper /proc/meminfo• memMapped: The total amount of memory used to map files, libraries ordevices as per /proc/meminfo39• memFreePages: Virtual memory free pages as per /proc/vmstat• memAnonPages: Virtual memory anonymous page count as per /proc/vmstat• memFilePages: Virtual memory file system page count as per /proc/vmstat• memDirtyPages: Virtual memory dirty page count as per /proc/vmstat• memWritebackPages: Virtual memory write-back page count as per /proc/vm-statThe network related feature information was collected using the TrafficStatsAndroid package. The network-based features measured are:• TotalTXPackets: Total number of transmitted packets obtained from an-droid.net.TrafficStats• TotalTXBytes: Total number of transmitted bytes obtained from android.net.TrafficStats• TotalRXPackets: Total number of received packets obtained from android.net.TrafficStats• TotalRXBytes: Total number of received bytes obtained from android.net.TrafficStats• TXPacketsDiff : Difference in value between current TotalTXPackets, andthe previous reading• TXBytesDiff : Difference in value between current TotalTXBytes, and theprevious reading• RXPacketsDiff : Difference in value between current TotalRXPackets, andthe previous reading40• RXBytesDiff : Difference in value between current TotalRXBytes, and theprevious readingAndroid maintains the list of active applications in the system and the asso-ciated permissions requested by the applications. The permission-based featuremeasured is:• Permissions: This feature is the summation of the total permissions re-quested by all running applications on the mobile deviceIn order to test the location-based context awareness, we programmed a helperAndroid application to generate time stamped mock GPS locations that is com-patible with Dalvik Debug Monitor Server (DDMS) [45]. This application gener-ates location events every 1 to 5 seconds using a time-stamped location dataset.The location update information in generated at random intervals to mock thatusers change their location at random. This allowed us to test launching of ac-tion agents based on the locations reported by the Location agent on the Androiddevice. Dalvik Debug Monitor Server (DDMS) is a debugging tool which allowsto monitor the system resource utilization of Android applications. Some of therelevant tasks that the tool allows includes:• Screen capture of the device• Radio state information of the device• Location data spoofing• Thread and heap information of the device• Causing Garbage Collection41Figure 3.3: CPU utilization comparison for battery levels. The x-axis dis-plays the seconds that have passed since the application was startedfrom left to right. The y-axis displays the CPU utilization in percentageof available CPU. [4, 28]• Tracking memory allocation of objects on the device• Profiling individual methods of the application• Using network traffic tool to monitor network usage3.5 EvaluationIn order to evaluate the proposed framework, we run multiple experiments to cap-ture the behaviour of the system based upon various contexts. The context-basedtests that we describe next are based on:1. Measuring the battery resource available (Battery context test)2. Location of the mobile-device (GPS context test)3. Network the device is connected to (Network context test)4. Android API version of the operating system (Android API context test)5. Device root status (Rooted device context test)42Figure 3.4: Network bandwidth utilization comparison for two battery lev-els. The x-axis displays the time that has passed since the applicationwas started from left to right. The y-axis displays bandwidth utilizationmeasured in KiloBytes per second. [4, 28]Figure 3.5: Memory utilization comparison for two battery levels. The x-axisdisplays the seconds that have passed since the application was startedfrom left to right. The y-axis displays memory utilization in Bytes. [28]43It is to be noted that other context-based decisions could also be tested. Someof them include:1. Application Context: What applications are installed on the mobile device,have they been marked as suspicious and are they in a running state;2. IP based Context: What IP addresses are being communicated with and ifany of them have been marked as suspicious;3.5.1 Battery context testFor the Battery Context Test, we used a generic Android tablet containing an All-winner A10 processor, Android 4.0.4 operating system installed, 512 Mb of phys-ical memory and 4 gigabytes of storage space.In order to test the changing behaviour of the system based on battery context,we conduct performance test runs to monitor the changes in CPU utilization, net-work usage patterns and memory usage for two different battery level contexts i.e.we use battery context to evaluate the system. We evaluate the system at a 95 per-cent battery level, and at 40 percent. In this test our system modifies its behaviourif battery is higher or lower than 50 percent.The performance test run consists of the following steps:1. Launch JADE agent platform on a network reachable server. This launchesthe JADE platform specific Directory Facilitator (DF) Agent and Agent Man-agement System (AMS) agent; and the framework specific service agents:Profile Service, Subscription Service, Location Service in a main-container.2. An Android agent application is next launched on the Android tablet men-tioned previously. We provide the address of the network reachable server44activated in the previous step to allow the Android device to register itselfwith the Agent platform. Currently the mediator is hosted on the same ma-chine where the main-container is placed. As previously mentioned, themediator hosts the back-end of the split-container execution mode, whereasthe front-end is hosted on the Android device.3. We execute multiple scripts on the Android device using an Android DebugBridge (ADB) terminal connected to the Android device to record CPU andMemory usage patterns on the Android device. The CPU utilization is mea-sured using the Android Debug Bridge (ADB) command adb shell top -d 1 -n1 to measure CPU patterns at 1 second intervals. Similarly we use the pro-crank [36] tool to monitor a process’s memory using the command adb shellprocrank to monitor virtual memory set size (Vss), the resident memory setsize (Rss), the proportional memory set size (Pss) and unique memory setsize (Uss).4. We monitor the network traffic by starting the network statistics tool inDalvik Debug Monitor Service (DDMS).5. We then connect to the JADE service on the Android device and create therelevant data collection agents: Profile Agent, Sensor Agent, Location Agent.6. We collect the data results for analysis.We run these steps twice. One when the battery was set at 95 percent level, andthen again at 40 percent level. In order to change the reported battery level of thedevice, we used the dumpsys program through the Android Debug Bridge. It is tobe noted that though we have used an actual device for the battery context test, the45same test could be run on an emulated Android device and modifying the reportedbattery level.Some of the relevant dumpsys commands used include:1. The following command provides battery information of the connected de-vice: adb shell dumpsys battery The information listed includes:Current Battery Service state:AC powered: falseUSB powered: trueWireless powered: falsestatus: 2health: 2present: truelevel: 100scale: 100voltage: 4100temperature: 2200technology: Li-ionHere, level lists the amount of battery available in the connected device.2. The remaining battery level of a connected device can be set using the com-mand: adb shell dumpsys battery set level 40 Using this command, the bat-tery level of the connected device has been set to 40.3. To reset the battery level of the device connect we use the following com-mand: adb shell dumpsys battery reset This command is required since once46a set command is run, the device no longer reports battery information fromthe actual device.Using Action agents are not accounted for in the values as the behaviour ofthe system has wide variations in system performance based upon the tasks of theAction agent. For example, an Action agent that computes feature vectors every2 seconds from multiple system files will have higher memory and CPU usagethan one that computes its models once every minute. The values measured in thisexperiment shows base resource utilization based on profile, location and sensoragents on the Android device.As shown in Fig. 3.3, the average CPU utilization is lower at low battery levels.For the test, a 6.5 percent average CPU was observed at 95 percent battery level.At 40 percent battery level, average CPU used was 5.53 percent. With our pro-file settings, we also observe fewer network transmissions at a lower battery levelas shown in Fig. 3.4. Our memory measurements don’t show significant changein behaviour as no action agents are launched for this test as seen in Fig. 3.5. Inthis test, our current setting of the profile agent monitors the battery level of theAndroid device, and adjusts the frequency of data collected by the sensor and lo-cation agents. At lower battery levels, the profile and location update informationis combined into a single ACL message. Thus, reduced traffic patterns is observedin Fig. GPS context testThis test was performed similar to the Battery Context Test. The primary obser-vational difference however was that instead of measuring the CPU, memory ornetwork utilization, as was done in the Battery Context Test, we observe which47Action agent is launched. Since Action agents are launched by the Profile agent,and die immediately after it performs its task, we log its output.In order to test GPS context, we set our Profile Agent on the device to activatespecific Action Agents only when we are within certain bounds of the Mock GPS.We create two zones for GPS tests. If the location agent reports GPS information inzone 1, the profile agent launches an Action agent named zone1GPSActionAgentwhich computes the values in Table 3.1. Otherwise it launches an Action agentcalled zone2GPSActionAgent that computes the same values. These computed val-ues are sent to the Profile agent on the device using Agent Communication Lan-guage (ACL), which are then sent to the Profile Service agent on the server for com-putation. These feature values are passed to the relevant Device Analysis agentswhen launched to apply machine learning classifiers [5] using Weka [46].This test run consists of the following steps:1. Launch JADE agent platform on a network reachable server. This launchesthe JADE platform specific Directory Facilitator (DF) Agent and Agent Man-agement System (AMS) agent; and the framework specific service agents:Profile Service, Subscription Service, Location Service.2. An Android agent application is next launched on an Android Virtual De-vice. We provide the address of the network reachable server activated in theprevious step to allow the Android Virtual Device to register itself with theAgent platform.3. We then connect to the JADE service on the Android device and create therelevant data collection agents: Profile Agent, Sensor Agent, Location Agent.This launches a Device Analysis agent on the server.484. We generate Mock GPS location events using a helper Android application.This causes the Location Agent to communicate with the Profile agent onthe device and the Location Service agent on the server. This applicationgenerates location events every 1 to 5 seconds using a time-stamped locationdataset. This is achieved using the following code snippet:private Runnable mockgpsRunnable = new Runnable() {public void run() {Random r = new Random();if (counter % 2 == 0) {Intent i = new Intent();i.setAction(MAIN_INTENT_ACTION_LOCATION);i.putExtra(AGENT_LOCATION_LATITUDE, mock_lat);i.putExtra(AGENT_LOCATION_LONGITUDE, mock_long);getApplicationContext().sendBroadcast(i);}counter++;TextviewLog("Mock location event generated");mockgpsHandler.postDelayed(this,1000 + r.nextInt(5000 - 1000 + 1));}};5. We check the log to verify that the agent was started.493.5.3 Network context testThis test was performed similar to the GPS Context Test. The primary obser-vation was to check which Action agent is launched. Since Action agents arelaunched by the Profile agent, and die immediately after it performs its task, welog its output. In order to test Network context text, we set our Profile Agent on thedevice to activate specific Action Agents only when we are connected to certainwifi access points. We create two rules for Action agents. If the Sensor agent re-ports connection to wifi access point 1, the profile agent launches an Action agentnamed zone1WifiActionAgent which computes the values in Table 3.1. Otherwiseit launches an Action agent called zone2WifiActionAgent that computes the samevalues. These computed values are sent to the Profile agent on the device usingAgent Communication Language (ACL), which are then sent to the Profile Serviceagent on the server for computation as mentioned previously.This test run consists of the following steps:1. Launch JADE agent platform on a network reachable server. This launchesthe JADE platform specific Directory Facilitator (DF) Agent and Agent Man-agement System (AMS) agent; and the framework specific service agents:Profile Service, Subscription Service, Location Service.2. An Android agent application is next launched on an Android Virtual De-vice. We provide the address of the network reachable server activated in theprevious step to allow the Android Virtual Device to register itself with theAgent platform.3. We then connect to the JADE service on the Android device and create therelevant data collection agents: Profile Agent, Sensor Agent, Location Agent.50This launches a Device Analysis agent on the server.4. We connect to the first wifi access point. This triggers the launching ofAction agent zone1WifiActionAgent.5. We check the log to verify that the agent was started.6. We then connect to the second wifi access point. This triggers the launchingof Action agent zone2WifiActionAgent.7. We check the log to verify that the agent was started.3.5.4 Android API context testThis test was performed to verify if Action agents only perform their tasks if theyhave the appropriate Android API level. As mentioned previously every Actionagent maintains the Android API-level required for functionality. This is requiredas the functionality of the Agent might not be compatible with certain AndroidAPI-levels. For example, Android 4.3 allows applications to access Android noti-fications by creating a notifications listener. This feature was not available in earlierAPI levels. For this test, we incorrectly set an Action agent to be launched by theProfile agent on the Android device for an Android Virtual Device Version 4.0.3.If a check is not performed by the Action agent before launching a command, thenit would fail with an exception NoSuchMethodError.This test run consists of the following steps:1. Launch JADE agent platform on a network reachable server. This launchesthe JADE platform specific Directory Facilitator (DF) Agent and Agent Man-agement System (AMS) agent; and the framework specific service agents:51Profile Service, Subscription Service, Location Service.2. An Android agent application is next launched on an Android Virtual Deviceset to 4.0.3. We provide the address of the network reachable server activatedin the previous step to allow the Android Virtual Device to register itself withthe Agent platform.3. We then connect to the JADE service on the Android device and create therelevant data collection agents: Profile Agent, Sensor Agent, Location Agent.This launches a Device Analysis agent on the server.4. After a time interval, we launch an Action agent that could only work withouterrors since version 4.35. We check the log to verify that the agent was started.6. We check the log again to verify that the agent prints a message stating: APIversion of the Android device is not in range of the Action agent. We observethat no NoSuchMethodError exception was thrown.3.5.5 Rooted device context testThis test was performed to verify if a rooted device can be successfully detected.In order to test this behaviour, we tested on a nexus-S Android device runningin rooted mode. We also tested on a rooted Android Virtual Device, and a non-rooted Android Virtual Device. To perform this test, during the launch of Profileagent on the Android device, in its setup() method, we call a method in a helperclass to check if the device is rooted. The helper class uses the RootTools program52mentioned previously. Following is a snippet of code that returns if the device isrooted:import com.stericson.RootTools.RootTools;public class JASHelpers {/*** Check if root is available.* @return*/public static Boolean isRooted() {return RootTools.isRootAvailable();}}This test run consists of the following steps:1. Launch JADE agent platform on a network reachable server. This launchesthe JADE platform specific Directory Facilitator (DF) Agent and Agent Man-agement System (AMS) agent; and the framework specific service agents:Profile Service, Subscription Service, Location Service.2. We provide the address of the network reachable server activated in the pre-vious step to allow the Android Virtual Device to register itself with theAgent platform.3. We then connect to the JADE service on the Android device and create therelevant data collection agents: Profile Agent, Sensor Agent, Location Agent.53This launches a Device Analysis agent on the server.4. We check the log to verify that a message was printed by the Profile agent,stating the device root state of the device.In all three instances of our test, the Profile agent successfully detected the correctroot state of the device.3.5.6 Malware detection testThis is a core functionality test of our agent-based malware detection framework.The purpose of this test was to verify if a feature vector that is known to exhibitmalware is observed by our agent system, could it detect it.In order to perform this test, we programmed an Action agent, that would reportmock feature vectors known to be malicious from a previous training sample. i.e.We picked feature vectors from the training set that were marked as malicious, andwere used to train the machine learning models.This test run consists of the following steps:1. Launch JADE agent platform on a network reachable server. This launchesthe JADE platform specific Directory Facilitator (DF) Agent and Agent Man-agement System (AMS) agent; and the framework specific service agents:Profile Service, Subscription Service, Location Service.2. An Android agent application is next launched on an Android Virtual De-vice. We provide the address of the network reachable server activated in theprevious step to allow the Android Virtual Device to register itself with theAgent platform.543. We then connect to the JADE service on the Android device and create therelevant data collection agents: Profile Agent, Sensor Agent, Location Agent.This launches a Device Analysis agent on the server.4. The Profile agent launches the Action agent that has been programmed toreturn mock feature vectors.5. The Profile agent receives the feature vector from the Action agent, andpasses it to the Profile Service agent on the server.6. The Action agent is destroyed as its task is complete.7. The Profile Service agent forwards the feature vector to the Device Analysisagent.8. The Device Analysis agent marks the feature vector as malware, and for-wards the response to the Profile Service agent.9. The Profile Service agent reports to the Profile agent on the device that it hasexhibited malware behaviour at a certain timestamped value.10. The Profile agent reports to the User Interface (UI) of the Android applicationthat malware was detected.11. The Profile agent writes to log the same information.We observed the reported message in the UI of the Android device, and the log,confirming that the report is correct.553.5.7 Verify Correlation agent can correlate 2 devices exhibitingsimilar malware behaviourThe purpose of this test is to verify if a Correlation agent can be used to connectmultiple Android devices that exhibit malware on the same models. This test runconsists of the following steps:1. The pre-requisite for this test is that all steps of the Malware Detection Testdescribed in the earlier section need to be done on 2 Android Virtual Devices.2. We then launch another Android Virtual Device that does not exhibit mal-ware behaviour.3. We then launch a Correlation agent in a container.4. The Correlation agent Queries the DF to find all Device Analysis agents inthe system.5. The Correlation agent sends queries to each Device Analysis agent to returnit a list of models that have verified malicious behaviour and the set of featurevectors that caused it.6. The Correlation agent then Correlates the information using the model as akey, a list of Android devices that failed the model, and the set of featurevectors that were sent to it when the model failed.7. This information is stored in a JavaScript Object Notation (JSON) output file.We observed a JSON output file created with the information about the two An-droid devices that did send mock malware feature vectors, and did not observe thethird device listed in the JSON file.563.5.8 Server workload measurementIn order to stress test the scalability of our solution on the server hosting the agentplatform, we perform multiple experiments to measure the memory and CPU usageon the server.HardwareThe server was run in a MacBook Pro 2012 with a 2.5 GHz Inter Core i5 processorand memory of 8GB DDR3 at 1600 MHz with a 5400rpm disk.Memory measurementsIn order to test the memory utilization on the server, we make measurements ateach step of the server initiation. i.e. We make measurements every time a newAgent is launched in the main-container.1. When only the main-container is launched: This measurement provides usthe base resource utilization of a JADE system, without any framework spe-cific agents launched. In this case by default a JADE Graphical User Inter-face (GUI) is launched with the AMS, DF and Remote Monitoring Agent(RMA) agents. The total memory reportedly used when the main-containeris launched with these agents only is 91 MB.2. When main-container is launched with framework specific agents: This mea-surement provides us the base resource utilization when the JADE system islaunched with framework specific service agents. In our case, the frameworkspecific service agents are: Location Service, Profile Service and Subscrip-tion Service. The total memory reportedly used when the main-container is57launched with a GUI and framework specific agents is 105 MB. Thus, theoverhead for the three framework specific agents is 14 MB.3. When Device Analysis agent is launched: This measurement provides us theresource utilization of the server when an Android device joins the frame-work, thus causing the Profile Service agent to launch a Device Analysisagent on the server. At this measurement instance, the agents on the serverinclude: AMS, DF, RMA, Location Service, Profile Service, SubscriptionService and a Device Analysis agent. The total memory reportedly used inthis instance is 111 MB. When a second Device Analysis agent is launched,the total memory usage is 118 MB. Thus, a Device Analysis agent has anoverhead of 7 MB. Note that at this instance, no machine learning modelshave been loaded by the Device Analysis agent. The models are loaded onlywhen one or more feature vectors are received by the Device Analysis agentfrom the Profile Service.4. When Device Analysis agent is loaded with models: This measurement pro-vides us the resource utilization of the server when a feature vector is re-ceived by the Device Analysis agent, causing it to load pre-existing ma-chine learning models to compare against. At this measurement instance,the agents on the server include: AMS, DF, RMA, Location Service, ProfileService, Subscription Service and a Device Analysis agent. Moreover theDevice Analysis agent loads 1350 preexisting models. Each model ranges insize from 76 KB to 15.2 MB depending on the complexity of the model. Thetotal memory utilization reported is 559 MB. Thus, 448MB extra is used toload preexisting models per Device Analysis agent in our case. This value58shows that if there are many models to compare against, or the size of eachmodel is large, the number of Device Analysis agents launched in a serverhave to be reduced.CPU usage time measurementsMost of the agents on the server side have limited CPU utilization. The only agentthat consumes large amounts of CPU is the Device Analysis agent. This is becausethe Device Analyis agent is the one that has to load machine learning models andcompare the feature vectors received with each of the models available. Basedon [22], as the number of trees in the model increase, the CPU time required willincrease linearly. Similarly, if the depth of trees in the model increases, the CPUtime required will increase. Here we compare the CPU utilization time in differentscenarios when the Device Analysis agent is run. We run each test 3 times toreduce the variance in times between test runs. For all tests, the Device Analysisagent compares feature vectors with 1350 stored machine learning models. Unlessstated otherwise, the number of feature vectors compared by the Device Analysisagent against each model is 256.1. When only 1 Device Analysis agent runs: In this case, there exists only 1Device Analysis agent in the system. The CPU usage times reported forthree test runs were: 27.4 seconds, 27.6 seconds, 28.9 seconds. Thus, we seean average CPU utilization of 28.0 seconds.2. When 2 Device Analysis agents run simultaneously: In this case, there ex-ists 2 Device Analysis agents, that have received 256 feature vectors each,to compare against 1350 stored machine learning models. The CPU usage59times reported by the first Device Analysis agent for three test runs were:33.4 seconds, 32.4 seconds, 33.6 seconds. The CPU usage times reportedby the second Device Analysis agent for three test runs were: 32.6 seconds,32.3 seconds, 33.6 seconds. Thus we see an average CPU utilization of 33.0seconds. This shows that the CPU utilization time increased by 5.0 secondswhen another Device Analysis agent is introduced in the same server.3. When only 1 Device Analysis agent runs with 1 feature vector comparison:In this test, we measure the CPU utilization overhead when only 1 featurevector needs to be compared by the Device Analysis agent. In previousinstances, the Device Analysis agent had to compare 256 feature vectors.The CPU usage times reported by the Device Analysis agent for three testruns in this case were: 25.2 seconds, 22.6 seconds, 25.0 seconds. Thus, wesee an average CPU utilization of 24.3 seconds. This is 3.7 seconds quickerthan comparing 256 feature vectors. This shows that though a single featurevector can be processed faster, the time required per feature processing isreduced if more feature vectors are compared at a time together.3.6 DiscussionBased on our experimental results, we make the following observations:• Server memory should be high If the number of machine learning mod-els to be loaded is high, based on the amount of memory required by De-vice Analysis agents either the Device Analysis agents need to be distributedamong multiple servers, or the memory used to run the agent frameworkneeds to be high. In our experimentation loading the models caused a 44860MB memory overhead. Each server-side agent itself uses between 5 - 7 MBof memory.• Pre-loaded machine learning models can give quick results Based onmeasuring the CPU time required to compute if a mobile device exhibitsmalware, we can say that multiple models can be loaded quickly, and classi-fication results obtained. We observed that it took 24.3 seconds to compareone feature vector against 1350 stored machine learning models; and 28.0seconds to batch-process 256 feature vectors against 1350 stored models.• Context-based decisions In our experimentation, our framework made changesto its monitoring behaviour based on battery availability context, networkcontext, GPS context, Android API context, and rooted device context. Forexample, we reduced the CPU and network usage when the available batterywas below a certain threshold level. As mentioned previously, the context-based decisions depend on having access to sensors and appropriate API toread the state of the device. With the changing nature of the Android operat-ing system, either more context-based behaviours could be modeled or fewerobtainable if the system becomes more closed.• Agent-based approach is viable In our experimentation, our frameworkused agents on the Android device in a split-container execution mode, com-munication with agents on the server side for analysis. The communicationbetween the client and server was done using Agent Communication Lan-guage. Given that some of our agents are resource intensive, such as theDevice Analysis agents, the agent-based approach allowed us to launch onlythe minimum data gathering agents on the client, while allowing the resource61intensive server agents to handle storage and computations using machinelearning models.• Device infections can be correlated based on model failure In our exper-imentation, Correlation agents can be used to query Device Analysis agentsto detect devices that fail on the same models. This is done by first queryingthe Directory Facilitator agent service to find all Device Analysis agents inthe system, and then querying each Agent to provide its saved results. Thisresult is saved in a JSON file for future reference.Some of the concerns that could be considered as issues or weaknesses of theproposed agent-based framework includes:• Privacy The information collected by the agents in the system cover a widerange of features such as GPS position information; network access pointsconnected to; application installations; memory and CPU usage monitoring;IP addresses and possible packet inspection if a device is rooted. This couldraise privacy concerns if our current solution is to be widely acceptable. Itshould be mentioned that the current Android API allows access to most ofthis information to all installed applications on the device without having toroot the device. For example, the Network Connections applications by AntiSpy Mobile [14] allows capturing the IP addresses and ports being commu-nicated with; the application package causing the communication; amountof data transferred and the Transmission Control Protocol (TCP) state of thecommunication. All this information can be accessed without having to rootthe device. Moreover, Android requires any access permissions required by62our application to be accepted by the user before the application can be in-stalled on the device. Thus, users are well-aware of what kind of informationcan be accessed.• Agent-based client-server communication As mentioned previously, thecurrent system architecture is a client-server model with most analysis ser-vices residing at the server side. This would mean that no malware can beclassified while the device cannot connect to the server. Use of the currentJADE agent-based architecture allows asynchronous communication duringclient-server disconnections. This is made possible by the split-containerexecution mode in JADE supported by the LEAP add-on. In case of con-nection loss, feedback is stored in the Android devices. Once a connectionis re-established, the relevant data gathered during the disconnection time ispassed to the agent on the server side with appropriate time stamped data.As mentioned previously, one of the advantages of an agent-based system isasynchronous communication. Moreover, as mentioned in section 3.3.3 useof Agent Communication Language allows us to distribute the agents on theserver side on multiple physical machines for scalability.3.7 SummaryTo summarize, in this chapter we provided an agent-based framework based on theJADE middleware to make context-aware decisions to detect Android malware.The contexts that we used included battery context, network context, GPS context,Android API level context and rooted-device context. We conducted multiple ex-periments based on these contexts, and measured the client and server workload63measurements in terms of CPU and memory utilization. We also performed corre-lation experiments to detect if mobile devices that fail on the same models can becorrelated together.64Chapter 4Random Forest Classification ForDetecting Android Malware4.1 IntroductionThe purpose of this chapter was to demonstrate the feasibility of using the Ran-dom Forest classification algorithm to detect if an Android device has been com-promised by malware by inspecting application behaviour data. As mentioned inthe previous chapter, the Device Analysis agents in our framework use pre-builtmachine learning classification models to classify devices as exhibiting malwarebehaviour. The classification model generated is based on the Random Forest al-gorithm, as described in this chapter.There were 3 primary reasons for choosing the Random Forest classificationalgorithm over other machine learning algorithms. They were:1. No previous research work had verified the classification performance ofthe algorithm on an Android dataset by modifying the parameters of the65algorithm.2. As shown in Table 4.5, our initial investigation showed that the algorithm al-ready performed better than other machine learning classifiers on our dataset.3. As will be described in Section 4.2.2, the algorithm is highly scalable as itrequired a log scale comparison of available features to generate a classifica-tion model. This allows models to be generated quickly from large datasets.In this chapter we focus on training a classifier based on an offline analysis ofAndroid application behaviour. Once trained, this technique could then be used toanalyze new Android applications prior to deployment on a real Android device.This could be done by testing computed feature vectors collected during run-timeof the application on an Android Virtual Device.For experimentation, we used a modified dataset made available by Amos [9]under the Creative Commons Attribution 3.0 Unported License downloaded in Feb28, 2013. This dataset was obtained from emulating user action using adb-monkey[44]. More information regarding the dataset is provided in Section 4.3.1. Wefocus on the detection accuracy of Random Forest as the number of trees, depth ofeach tree and number of random features selected are varied for the algorithm. Weperform a 10-fold cross validation on our dataset for the error estimate, and alsouse a separate training and validation set test. We had also performed a 5-fold crossvalidation experiment for which an optimal Out-Of-Bag (OOB) error rate [22] of0.0002 for forests with 40 trees or more, and a root mean squared error of 0.0171for 160 trees was obtained.According to our knowledge, we have not come across any other related workthat has exclusively worked with the free parameters of Random Forest algorithm66on an Android feature dataset for malware classification. The main contributionsof this chapter can be summarized as follows:• Apply Random Forest classification algorithm for behavior detection on fea-tures [9] obtainable from an unrooted Android devices by predominantlymonitoring features based on the Android Binder Application ProgrammingInterface (API), Memory and Central Processing Unit (CPU) measurementsto detect Android malware.• Conduct detailed experimentation to measure the accuracy of Random Forestclassifier as the number of trees and the depth of each tree in the forest isvaried for different size of random features selected.• We provide a 10-fold cross validation of results of application of the Ran-dom Forest classifier on android applications to detect malware. For this weconduct 3 test runs for each combination of the Random Forest parametersby using 3 random seeds for each of our tests to provide adequate error mea-surements. We test for the number of trees, number of features compared ata tree node, and the depth of the tree. For the number of trees, we test with10, 20, 40, 80 and 160 Trees. For features we compare 4, 6, 8, 16 and 32features. For tree depth we compare 1 (decision stump), 2, 4, 8, 16, and 32depth trees.• We perform similar test to see how a Random Forest training model performsif there is a separate training set and a separate validation set. We comparethe performance of the original dataset, and our modified data set to measureperformance trends in terms of using a validation set.67• We also perform a comparison of 10-fold cross validation by the usage ofSMOTE [26] (Synthetic feature vector generation using the default settingsof Weka) as the publicly available set did not have enough samples of thebenign applications. There was a 2:1 ratio of malware to benign samples.• We also measure the amount of space required in storing different RandomForest models on disk. This is required as once models are precomputed,they can be used to evaluate incoming feature vectors.The rest of the sections are organized as follows. Section 4.2 provides rele-vant background to understand the problem domain. In Section 4.3 we describeour experimental approach. Section 4.4 discusses our results, the advantages anddisadvantages.4.2 BackgroundIn order to understand the application domain of this research work, we now dis-cuss three related areas: feature collection for Android operating system, key fea-tures of the Random Forest algorithm, and application of machine learning in thedomain of mobile security.4.2.1 Android feature collectionIn order to apply any machine learning classifier, it is important to first be ableto collect relevant features that can be observed from the system. These featuresthat are observed are stored as a feature vector. As mentioned in Section 2.3, insupervised learning, given a labeled set of input-output pairs (the training set) withN training examples, the goal is to predict a future y value given an input. The68input to such a system is xi which is a D-dimensional vector, also called a featurevector. xi is a set of values used to determine yi.The features that the Android system allows access permissions to depends onif the device has been rooted. Rooting is the process whereby one has privilegedaccess control to the system. As mentioned in Android Security Overview [42],Android uses the Linux Kernel as the bottom layer. All layers on top of the kernellayer run without root privilege. i.e. All applications and system libraries are insidea virtual application sandbox. Thus, applications are prohibited from accessingother application data (unless explicitly granted permission by other applications).As described in [42], each Android application is assigned a unique User Identi-fication (UID). Each of these Android applications run as that user in a separateprocess with the UID. Thus, if a feature vector is created from features of AndroidAPI in unrooted mode, then only system information made available by Androidcan be used. On the other hand, having a rooted device allows one to install sys-tem tools that could gather features from underlying host and network behaviour.Example of features that can be obtained from rooted devices include: data beingsent by applications, IP addresses being communicated with in the network, num-ber of active connections, the system calls being invoked, etc. The related work inthe area of machine learning approaches to Android data either deal with featurecollection from unrooted devices [9, 71], or rooted devices [24, 34, 49]. Hence, ifmodels are to be generated with root mode observable features, then root accessis required. If models are to be generated without root mode features, then rootaccess is not required.694.2.2 Random forestFor the experimentation in this chapter, we have used the Random Forest classi-fication algorithm implemented in the standard Weka [46] package. Weka is theonly Java-based package available that provides implementation of all machinelearning algorithms, including the Random Forest classification algorithm. As ouragent-based system is based on the Java language, and as Android is a derivativeof Java, we have used the Weka package. Random Forest is an ensemble learn-ing algorithm developed by Breiman [22]. An ensemble learner method generatesmany individual learners (in this case a tree) and aggregates the results (a forest).Each classifier (a tree in the forest) is built individually by working with a boot-strap sample (random sampling with replacement) of the input data (features of thetree). In a regular decision tree classifier, a decision at a decision point is madebased on all the feature attributes of a feature vector. But in Random Forest, thebest parameter at each node in a decision tree is chosen from a randomly selectednumber of features. In our experimentation we choose 4, 6, 8, 16 and 32 features tocompare at a decision point. The feature that is chosen to classify the data is basedupon trying to minimize the entropy value. This random selection of features helpsRandom Forest to scale well when there exists many features per feature vectoras the algorithm usually requires as few as log m features being compared at theclassification decision point of a tree, where m represents the total number of fea-tures available in the feature vector. This feature selection helps it to reduce theinterdependence (correlation) between the feature attributes. The error rate of theforest classification depends on the optimal value of random features selected.As mentioned by the author [22], the number of random features m selected70per decision node in a tree determines the error rate of the forest classification.The error rate of the Random Forest classifier depends on the correlation betweenany two trees, and the classification strength of each individual tree. Reducing therandom features selected m causes reduction in both the correlation between clas-sification trees and the strength of classification of each individual tree. Increasingm increases both the correlation between the trees and the strength of each tree.Breiman explains that the Out-of-Bag (OOB) error rate is an indication of howwell a forest classifier performs on the dataset. The out-of-bag model leaves outone-third of the input dataset for building the kth tree from the bootstrap samplefor each tree. This one-third sample is used to test the kth tree and the results ofmisclassification averaged over all trees. The author claims that for most casesOOB error estimate is a good estimate of the error and hence cross validation orseparate test set is usually unnecessary when using the Random Forest algorithm[23].4.2.3 Machine learning classifier for Android mobile systemsApplication of machine learning methodologies for classification of Android mal-ware is currently an emerging area of interest. Malware detection can be doneeither via static detection or dynamic detection. Static detection techniques (alsocalled signature matching) have high detection rates and require less computationalresources. This is the traditional approach taken by anti-virus software. Dynamicdetection techniques (also called anomaly/behavior detection) on the other hand,suffer from low detection rates and require more resources to reduce the amountof false positives reported. They usually are prone to high false positives withoutadequate training. The primary advantage of dynamic detection techniques over71static detection techniques is however that it can detect new malware, and providesbetter coverage. A description of machine learning classification used on Androiddataset was provided in Section Experiment4.3.1 Dataset descriptionFor our experimentation, we worked with a modified dataset provided by Amos etal. in [10] available at 1 under the Creative Commons Attribution 3.0 UnportedLicense. The author developed a shell script to automatically analyze .apk An-droid application files by running them in available Android emulators. For each.apk file, the emulator simulates user interaction by randomly interacting with theapplication interface. This is done using the Android adb-monkey tool [44]. Eachfeature vector of the dataset is collected at 5 second intervals. The memory featureswere collected by observing the“proc” directory in the underlying Linux system ofAndroid. The CPU information was collected by running the Linux “top” com-mand. The Battery and Binder information was collected by using an “intent” ob-ject. The “permissions” feature is the summation of the total permissions requestedby each running application (package) obtained from the PackageManager class inAndroid.As mentioned in [10], the test set or the validation set consists of 47 applica-tions of which 24 are benign applications and 23 are malicious applications. Thetraining dataset consists of 6832 feature vectors computed. Eight applications areduplicated across both the sets. The feature vectors in the training set were com-1https://github.com/VT-Magnum-Research/antimalware72puted from 1330 malicious applications and 408 benign applications. As can beseen, there is an imbalance in the number of applications observed in the train-ing set. A classifier becomes more biased towards the oversampled class if thereis a class imbalance. In order to balance the two classes, we used the SyntheticMinority Oversampling Technique (SMOTE) package from Weka to create moredata points of the under-sampled class (benign class). We then applied the randomfilter to randomize the distribution of the two classes in the data file used. Ran-domization was required as SMOTE adds data entries to the end of the data file.The synthetically generated data without randomization would be a problem duringcross validation because we would have points primarily from the under sampledclass in the last few folds.For the SMOTE tests, we generated more samples of the under sampled benignclass to cause the total number of feature vectors to increase from 6832 to 10254feature vectors. 5133 instances were of one class whereas 5121 were of the otherclass. In our initial experiments reported in [5], we used a data set collected from2 that had a total of 32342 data (feature vector) samples with 7535 benign samples(classified as positive class) and 24807 malicious samples (classified as negativeclass). A reduced version of the dataset was reported in [10] which has been usedby us now. For completeness, we report our results in [5] in section 4.3.7.The feature vectors were computed every 5 seconds from 10,000 user inputsgenerated by the Android Monkey program. The primary disadvantage of thedataset however as mentioned by the authors is that when they worked with 1500events that were sent with random delays, their classifier performed only as goodas random behaviour with around a 50 percent classification rate. The primary fo-2https://github.com/VT-Magnum-Research/antimalware73cus of [10] was to create an architecture for large amount of testing using the basesettings of machine learning classifiers. They tested the Random Forest algorithmusing just 10 trees, 6 features, with maximum tree depth. We tested their unbal-anced dataset, and compared with our balanced SMOTE generated dataset for thevarious parameter settings of the Random Forest algorithm. We test by modifyingthe following parameters: The number of trees, number of features compared ata classification decision, and the depth of the tree. For the number of trees, wetest with 10, 20, 40, 80 and 160 Trees. For features we compared with: choos-ing the best among 4 features, choosing the best among 6 features, choosing thebest among 8 features, choosing the best among 16 features and choosing the bestamong 32 features. For tree depth we compare trees of depth: 1 (decision stump),2, 4, 8, 16, and 32. We also run each experiment three times and report the medianvalue for each combination of the tests. We run a total of (5 trees * 5 features *6 depth * 3 random seed) = 450 tests for each of our test setups. We run 4 set oftests. 1) 10-fold Cross Validation on original dataset, 2) 10-fold Cross Validationon our Synthetic data test (SMOTE generated), 3) Separate Validation set test onthe original data, 4) Separate Validation test on our Synthetic data test (SMOTEgenerated). Thus, we run a total of 1800 tests. The features that are measured inthe feature vector are listed in Table 4.1. This is the same set of features that weredescribed in Table 3.1. They are shown again here for easier reference.This study has two additional limitations that we observed based on inspectingthe raw dataset. The most notable areas are in the battery data features and thenetwork features. Given that these data samples were collected by running in anemulator, there were no observed change in battery data among any of the featurevectors for both classes of data. Similarly, the Network data was fixed for all the74Table 4.1: Android Features Observed [5]Category FeatureBattery IsCharging, Voltage, Temperature, BatteryLevel, BatteryLevelDiffBinderTransaction, Reply, Acquire, Release, ActiveNodes,TotalNodes, ActiveRef,TotalRef, ActiveDeath, TotalDeath,ActiveTransaction, TotalTransaction,ActiveTransactionComplete,TotalTransactionComplete, TotalNodesDiff, TotalRefDiff,TotalDeathDiff, TotalTransactionDiff, TotalTransactionCompleteDiffCPU CPU UsageMemorymemActive,memInactive, memMapped, memFreePages,memAnonPages, memFilePages, memDirtyPages, memWritebackPagesNetworkTotalTXPackets,TotalTXBytes, TotalRXPacketsTXPacketsDiff, TXBytesDiff, RXPacketsDiff, RXBytesDiffPermission Permissiondata points. The authors reported in [10], that the network was switched off duringtests due to complaints by the information technology team. This would meanthat 13 of the observed 42 features do not contribute to classification as the 13features will not contribute to information gain (reduction in entropy) score usedby Random Forest algorithm at each decision node. These limitations could onlybe addressed if the network is allowed to remain open so that Android applicationscan access network data, and actual mobile devices are used instead of Androidvirtual devices. But running 1738 Android applications, as was done to gatherthis dataset, would be time consuming on actual devices as it would require devicesoftware reset after each installation of Android application.754.3.2 Classification experiment descriptionThe following are a list of experiments performed:• Experiment 1: Use initial dataset to train classifier on the training datasetprovided in [10]. Perform a 10-fold cross validation of results. We perform3 runs with seed values, 1, 2 and 3 to measure the performance with multiplesettings of the Random Forest classifier as described above.• Experiment 2: Next, again train the Random Forest classifier on Amos etal. [10] training dataset, but now check the performance of each RandomForest model on a separate validation set. As mentioned previously, the testset or the validation set consists of 47 applications of which 24 are benignapplications and 23 are malicious applications.• Data Generation: We then modified [10] training dataset using the SMOTEpackage of Weka to generate synthetic feature vectors for the training set.This was done as the number of feature vectors of goodware was signifi-cantly low. This causes the learned classifiers to be over trained on the classthat is oversampled. We applied the randomize filter then since the SMOTEpackage adds the synthetic features to the tail of the Weka .arff file. Thiswould create errors during the process of cross-validation.• Experiment 3: We then performed a 10-fold cross validation on the balanceddataset generated using SMOTE. We perform 3 runs with seed values, 1,2 and 3 to measure the performance with the settings of the Random For-est classifier we mentioned previously. This is similar to what was done inexperiment 1, and would help us compare the effect of a balanced dataset.76• Experiment 4: Next, again train the Random Forest classifier on the balanceddataset, but now check the performance of each Random Forest model on theseparate validation set, as was done in Experiment 2. This would allow usto compare the performance of the two models: One generated from theoriginal dataset, to the one generated from synthetic oversampling.4.3.3 HardwareA Macbook Pro 2012 was used for testing with a 2.5 GHz Intel Core i5 processorwith 8 GB 1600 MHz DDR3 of available RAM.4.3.4 SoftwareFor generating synthetic data for solving the class imbalance issue, we used SMOTE(Synthetic Minority Oversampling Technique) [26] package available as part ofWeka 3-6-12. For experimentation and model generation, we used the experimen-tal release 3-7-12 of Weka as it allows parallel processing of classifier for Modelgeneration for the Random Forest algorithm. We set the number of threads avail-able to be used by the Random Forest algorithm to four as that is the limitation ofour current hardware.The Random Forest classifier implementation for Weka does not implementfeature importance computation. Availability of this feature would have helpedin observing the features that are weighted higher by Random Forest algorithm.Hence, we have not computed feature importance.4.3.5 Sample codeAs mentioned previously, in order to be able to compute if a feature vector exhibitsmaliciousness, we have to use pre-computed Random Forest models stored in the77system. To do this, we write java code to store models once they have been gen-erated. This is done using serialization support available in Weka. Below is oursample on how this is performed.rfa.buildClassifier(data);// serialize modelweka.core.SerializationHelper.write(inputFileName+"RandomForest"+rfa.getNumTrees()+"Trees"+rfa.getNumFeatures()+"Features"+rfa.getMaxDepth()+"Depth"+rfa.getSeed()+"Seed.model", rfa);In order to load a classifier model already created and stored on disk, we usethe following java code to deserialize.// retrive the model file to test withClassifier cls = (Classifier) weka.core.SerializationHelper.read(modelFile);// EvaluateeTest = new Evaluation(data);eTest.evaluateModel(cls, data);Once loaded, the new incoming feature vectors are compared using the datavariable. Weka provides the necessary infrastructure to either load multiple featurevectors to test at a given time, or a single feature vector can be compared at a time.78In our code, the incoming features stored in the data variable are collected on anactual or emulated Android device. The classification is done on a server side.If required, the model files can be stored on an Android device as Weka is sup-ported on an ARM architecture as well, and the comparison can be done on theAndroid device. It should be mentioned that building the classifier is a CPU inten-sive task requiring tens of minutes even on a multicore desktop or laptop for thecurrent data set that we have. The evaluation however can be done on a handhelddevice as they are memory intensive, but not CPU intensive tasks. As explained inour previous chapter, it took 28 seconds to compare against 1350 models.4.3.6 ResultsAs mentioned before, for experimentation, we run tests for each of the Number ofTrees , Depth of Tree and Attribute combination. We tested with 10, 20, 40, 80 and160 trees for each Random Forest. For each setting of trees we tested with 4, 6, 8,16 and 32 randomly selected attributes compared for each decision node. For eachTree and attribute combination, we tested with 1, 2, 4, 8, 16 and 32 depth trees.Fig. 4.1 shows the 10 fold cross validation performance of the original dataset.As can be seen, as the depth of tree increases, the classification rate increases upto a certain point. The range shown is from 80 percent to 96 percent on the y-axis.The highest correct classification detection rate was a value of 94.96 percent for 16features at 32 depth for a Random Forest of 10 trees.As shown in Fig. 4.2, a similar trend follows if we use more trees compared toFig. 4.1. However, though it is not noticable, the detection rate increases slightlyby one to three percent for 10 trees vs 160 trees. For 160 trees, the highest cor-rect classification detection rate was a value of 95.74 achieved with 32 features79Figure 4.1: Classification rate of original dataset as the number of featuresare changed for forest of 10 trees for y range 80 to 96 percentcompared at a depth of 32.In Fig. 4.3 we compare the performance of the various Random Forest modelson the original dataset where we have a separate training set and a separate valida-tion set. As can be seen, the performance of the test on a forest of 10 trees on avalidation set is much lower than in the 10-fold cross validation test for 10 Trees.This shows that a 10-fold cross validation set does not always show the true natureof a classification algorithm. The highest detection rate observed was 80.46 for 16features compared at a time with tree depth of 4. Moreover, the results show that asthe depth of tree increases, the classification results are poorer due to over-fitting.We performed a similar test with a 160 tree forest, and found similar results80Figure 4.2: Classification rate of original dataset as the number of featuresare changed for forest of 160 trees for y range 80 to 96 percentto the 10-Tree validation set. The results are shown in Fig. 4.4. The highest de-tection rate was a value of 81.25 observed with 4-feature comparison at a depth of8. Moreover, with 160 trees, there were a total of 3 tests that passed 80 percentdetection. There was only one such case with 10 Trees.As shown in Fig. 4.5, we performed a test where the model was generated ona separate training set, and then tested on a separate test set as mentioned in ourdataset description. In this test we had synthetically generated feature vectors ofthe under sampled class using the SMOTE algorithm in its default setting. Thehighest correct classification rate achieved was 81.64 percent with a setting of 160trees, depth of 2, with 16 random features at a time. The performance of SMOTE81Figure 4.3: Classification rate of original dataset when tested on validationset for forests of 10 trees. The results show that as the depth of treeincreases, the classification results are poorer due to over-fitting.can be compared to the original dataset of Amos for 160 Trees on a validation setas was done in Fig. 4.4. There were 6 tests where the correct classification passedthe 80 percent detection. They were all achieved at a depth of 2 for 4, 6, 8, 16, 32features. However, the original dataset performed better when the tree depth was 4or greater in general.As shown in Fig. 4.6, we also performed a 10 fold cross validation test onSMOTE generated instances. The detection rate was over 91 percent for tree depthof 8 or more. The highest classification rate obtained was a value of 96.40 percentfor trees with 8 features compared at 32 depth.82Figure 4.4: Classification rate of original dataset when tested on validationset for forests of 160 treesTable 4.2: Amount of space required to store Random Forest model files asdepth of trees is increased for a forest of 160 TreesTrees Features Depth Model Size(MB)160 32 32 7.9160 32 16 7.5160 32 8 3.4160 32 4 1.9160 32 2 1.7160 32 1 1.783Figure 4.5: Classification rate on model generated by SMOTE with testingon a validation set with forest of 160 trees. This graph shows the per-formance of the Random Forest algorithm on a balanced dataset.In order to examine if storage of Random Forest models are feasible on mobiledevices, we measured the amount of space occupied by such models. This is shownin Table 4.2. As can be seen, the amount of space required increases as the depth ofthe tree increases. Random Forest models with 160 Trees, 32 Features comparedat a time (with replacement), with tree depth of 16 would require 7.5 Megabytes ofstorage.As shown in Table 4.3, the amount of space required to store a Random Forestmodel decreases as the number of features compared increases.84Figure 4.6: Classification rate on model generated by SMOTE with 10 Foldcross validation testing with forest of 160 treesTable 4.3: Amount of space required to store Random Forest model files asnumber of features measured is increased for a forest of 160 TreesTrees Features Depth Model Size(MB)160 4 32 15.1160 6 32 12.7160 8 32 11.4160 16 32 9.2160 32 32 7.9854.3.7 Experiment results with a 5-fold cross validationAs mentioned previously, we had also performed a 5-fold cross validation experi-ment in our previous work [5] based on a different dataset provided by the authors.Using a lower number of folds (using 5 instead of using 10) means a higher biastowards overestimating the true expected error. This however causes lower vari-ance and lower running time. The following were the results during our 5-foldexperimentation. The results here are based on applying the SMOTE algorithm toremove class imbalance on the original dataset.Table 4.4 shows the results when each tree is allowed to grow to maximumdepth. We performed 5-fold cross validation for each experiment.Following are the parameters that we measured as shown in Table 4.4:• OOB ErrorThis is the Out-Of-Bag error explained in section 4.2.2.• Root MSEThe square root of the mean squared error based on 5-fold cross validation.• % True ClassThis value shows the percentage of the samples that were classified correctly.We evaluate this number to show the minor variations that happen as thenumber of trees and random features selected change. This was not reportedin 10-fold cross validation as the variation is more obvious.• # IncorrectThis number shows the total number of the 48,919 samples that were mis-classified. We evaluate this number to show the minor variations that happen86Table 4.4: Experimental Results for varying number of trees and number ofrandom features with Trees allowed to grow to maximum depthTrees Features OOB Err Root MSE % True Class #Incorrect10 4 0.0067 0.0291 99.9469 2610 6 0.0064 0.0245 99.9407 2910 8 0.0058 0.0221 99.9600 1910 16 0.0056 0.0206 99.9600 1910 32 0.0056 0.0200 99.9600 1920 4 0.0008 0.0259 99.9670 1620 6 0.0006 0.0223 99.9632 1820 8 0.0005 0.0208 99.9693 1520 16 0.0004 0.0191 99.9652 1720 32 0.0006 0.0184 99.9693 1540 4 0.0003 0.0242 99.9693 1540 6 0.0004 0.0210 99.9734 1340 8 0.0002 0.0197 99.9755 1240 16 0.0003 0.0178 99.9612 1940 32 0.0003 0.0178 99.9714 1480 4 0.0004 0.0239 99.9734 1380 6 0.0002 0.0203 99.9775 1180 8 0.0002 0.0187 99.9836 880 16 0.0002 0.0175 99.9734 1380 32 0.0003 0.0178 99.9673 16160 4 0.0003 0.0233 99.9775 11160 6 0.0002 0.0201 99.9755 12160 8 0.0002 0.0183 99.9857 7160 16 0.0002 0.0171 99.9734 13160 32 0.0002 0.0175 99.9693 14as the number of trees and random features selected change.As shown in Table 4.4, the best Root Mean Squared Error value of 0.0171is achieved with 160 trees and 16 features. The best setting based on the lowestnumber of misclassifications (7 out of 48,919) was achieved with 160 trees and 8features selected. These have been highlighted in Table 4.4.87Figure 4.7: Misclassification comparison with 20 trees as depth of tree is var-iedFig. 4.7 provides comparison of how the depth of tree impacts the number ofinaccurate classifications. In this figure we show results of a Random Forest with20 trees. As can be seen, regardless of the number of features selected, the numberof incorrect classifications stabilizes at a tree depth of 16. Similar behavior isobserved for other size of forests, i.e. forests with 10, 40, 80 and 160 trees. Weomit them here for brevity.Fig. 4.8 provides comparison of how the depth of the tree impacts the out-of-bag error rate for Random Forest with 40 trees. As can be seen from the figure,low error rates are achieved quickly if 16 and 32 features are selected at tree depthof 8. If lower number of features are selected, then a tree depth of 16 is required88Figure 4.8: Out Of Bag error rate comparison with 40 trees as depth of treeis variedbefore the error rate stabilizes. Similar behavior is observed for other forest sizesfor the given tree depth and number of random features combination.Fig. 4.9 provides observed root mean squared error rates as the depth of the treeis observed at 1, 2, 4, 8, 16 and 32 for a Random Forest with 80 trees. Stable valueof the error rate is observed at a tree depth of 8 when 32 features are observed. Adepth of 16 is required for all other observed feature counts. We observe similarpattern for other tree sizes.In order to compare the results obtained by applying the Random Forest al-gorithm to other classification techniques, we perform preliminary classificationtests on our dataset with default settings for classifiers in Weka. The number of89Figure 4.9: Root Mean Squared error rate comparison with 80 trees as depthof tree is variedmisclassified instances of the 48919 points are as shown in Table 4.5. It should bepointed out that all the algorithms listed have associated free parameters which canpossibly be tuned to obtain better results. Similarly we have not computed valuesfor other existing classification algorithms such as Support Vector Machines. Weconsider it outside the scope of this research work as our focus is on testing theparameters of Random Forest for our dataset.4.4 DiscussionBased on our experimental results on 10 fold cross validation and separate valida-tion set test we make the following observations:90Table 4.5: Misclassification Comparison of Different classifiersAlgorithm MisclassificationBayesNet 342NaiveBayes 2361MultilayerPerceptron 38J48 47Decision Stump 2532Logistic Regression 323Random Forest 7• Random forest sensitive to parameter settings In our tests, we observethat using the default settings of an algorithm does not yield the best resultsas is done in all literary work. For 10 fold cross validation a default settingof 10 tree and 6 features compared with maximum depth yields 93 percenttrue classification. But a 95.74 percent true classification was obtained with160 trees with 32 features at depth 32.• Cross validation results higher than validation set test Whereas in cross-validation tests, results show true classification at over 90 percent at treedepth greater than 8 as shown in Fig. 4.6, in case of validation set tests,they rarely are higher than 80 percent true classification in general as shownin Fig. 4.5. This difference in result is primarily because there are featurevectors of an application in the validation set, that was not observed in thetraining set.• Class imbalance Based on comparing classification results provided in Fig. 4.5that shows performance on a class balanced dataset generated by SMOTE91vs Fig. 4.4 that shows performance with a class imbalance of the originaldataset, we observe that the SMOTE generated classifier performed betterat tree depth of 4. Thus, using a class balanced dataset would yield resultsfaster. The balanced dataset performed worser than the imbalanced datasetat higher tree depths due to over fitting the model to the training set.In our experiments, based on a 5-fold cross validation, Random Forest provided anexceptionally high accuracy of over 99.9 percent of the samples correctly classified(see table 4.4). This is is comparison to the 10-fold cross validation tests shown inFig. 4.6 the highest accuracy obtained was 96.40 percent for trees with 8 featurescompared at a decision point, at a tree depth of 32. The optimal square-root ofthe mean-squared-error achieved was 0.0171. The optimal out-of-bag error rateobtained was 0.0002 with a minimum forest size of 40 trees. Based on experimentalresults on 5-fold cross validation on a previous larger dataset, we can make thefollowing observations for the Android features evaluated:• High accuracy of random forest:Random Forest provides an exceptionally high accuracy with over 99.9 per-cent of the samples correctly classified when trees are allowed to grow tomaximum depth. The square-root of the mean-squared-error is 0.0291 orless. The out-of-bag error estimate of Random Forest is acceptably low with40 trees or higher. It varies between 0.0002 and 0.0004. The best settingbased on root MSE value was using 160 trees and 16 random features se-lected with a Root MSE value of 0.0171. The best setting based on numberof incorrect classifications was 160 trees with 8 random features selectedwith a score of 7 incorrect classifications.92• More trees are better: The overall trend shows that the out-of-bag errorreduces on average as the number of trees increase. For our data sample,we observe significant better out-of-bag error rates when we have at least 20trees for the varying random features selected from 4 to 32.• Depth of tree required: Based on experimentation, we observe that for ourdataset, we need to construct trees of depth 16. Lower depth than this causeshigher number of inaccurate classifications. Measuring trees of depth greaterthan 16 does not cause a statistically significant change for a given numberof trees in the Random Forest algorithm for our dataset. Random Forestprovides an accuracy of over 91 percent with a tree depth of 1. With 4 fea-tures selected, Random Forest provides greater than 99 percent classificationwith a depth of 8. With 6 or more features selected, a 99 percent correctclassification can be achieved with a depth of 4 for each tree.• Lower features per tree better: For a given forest size, after a certain point,we see that as the number of features are increased for a given tree, the num-ber of incorrect classifications increase. The author in [22] had mentionedthat ideally choosing log M features (where M is the size of the total at-tributes) would yield a good result. In our case, choosing 6 or 8 attributes fora forest gives ideal results for a particular forest size.• Misclassified malicious samples:Even though we do not show it in our results table, for all experiments, mostof the misclassified cases were due to the malicious class samples misclas-sified as being of the benign class i.e. there were more false negatives than93false positives. For example the experimental setting yielding the best resultwith a forest with 160 trees, 8 random features, and depth of 16 for eachtree, we observed 5 false negatives and 2 false positives. This is based onobserving the generated confusion matrix for each experiment case.4.5 SummaryThe results of these experiments show that the Random Forest algorithm providestrue classification results at over 90 percent if we are to observe cross validationresults. We also observed that the algorithm is highly sensitive to the parametervalues that are chosen. The parameters that we experimented with included thenumber of decision trees in the Random Forest, the number of random featurescompared at a decision node for each decision tree, and the depth of each treein the forest. We observed that choosing the default values of the algorithm, asis done in all research work that have tested with the Random Forest algorithmprovide results that are not optimal. We also observed that having good resultsin cross-validation tests, does not necessarily translate to having good results witha separate validation-set test. Moreover, training a Random Forest classifier on abalanced dataset allows to find better results at lower tree depths. This is beneficialas models of lower depth are smaller in size as shown in Table. 4.2 and take lesstime to compute.94Chapter 5Conclusion And Future Work5.1 Thesis summaryThis thesis studies the use of a Java based multi agent system framework based onthe JADE platform on Android mobile devices for malware detection. The agentbased framework is context aware in order to facilitate better conservation of re-sources on mobile devices. The framework defines multiple client based agentsthat reside on the Android device for data gathering and reporting classificationreports to the user. Server side agents in the framework are responsible for analy-sis of features by comparing to pre computed models that have been saved in thesystem. This client-server approach was taken due to resource limitations on mo-bile devices in terms of system memory, disk and battery constraints. Moreover,the server side agents can be distributed among multiple servers in the cloud forscalability as they communicate with each other using ACL.In order to measure the scalability of the multi-agent platform, we have com-puted the amount of CPU resources used by the agent platform on Android devices.95We also measured the memory requirements to maintain such an active agent sys-tem on the Android devices using Android’s Dalvik Debug Monitoring Service.Given that many mobile services have restrictions on the amount of data used,we have measured the network resources that are utilized in order to transfer databetween the agents on the client and the agents on the server for analysis. Allof these measurements are required as there is no clear methodology to measurethe resource utilization pattern on mobile devices, since battery usage depends onmany external factors, such as external temperature, how long the battery has beenused, and the capacity of the battery.We performed context aware testing by activating Action agents on the Androidmobile device based on context. For context based testing we mocked the GPSinformation used to activate one, or another agent. Similarly we used the networkthat the Android device was connected to in order to make context aware decisionsbased on network connection. We launched different agents based on if deviceswere rooted, and the kind of applications that were installed on the device. For thispurpose we installed tools such as RootTools.In order to detect if Android devices have been infected with malware, theagent framework relies on the use of machine learning classifiers that use pre-builtmodels to make decisions. The pre-built model used for comparison has to berelevant in terms of the features observed. This is because, not all system resourcesthat can be observed on one Android mobile system can be detected on another.This could be caused by the API level of the operating system used by the device,and also the presence of third party analysis tools used to build features.For this thesis we studied the performance of the Random Forest algorithmon a balanced dataset with a 50-50 split between goodware and malware for the96feature vectors. We started with making a 5-fold cross validation study on ourlabeled dataset. The study revealed results of over 90 percent true classificationrates. Later we revised our experimentation to use 10-fold cross validation onthe labeled dataset and also performed a training-validation set study. For thisstudy we performed three runs with random seeding for each combination of thefree parameters of the Random Forest algorithm. We observed that whereas crossvalidation causes results to be over 90 percent true detection, validation set testsrarely cross 80 percent true classification rates. We observed that classificationrates vary widely as the free parameters of the algorithm are modified, and that thedefault setting of algorithm do not yield optimal results.In our experimentation, we also measured the amount of disk space that willbe required to store these pre-built models. We made use of pre-built models fortwo purposes. One is because once the models are generated, the cost to comparefeature vectors is very quick. We measured the cost associated for one featurevector comparison, vs multiple comparisons made from a single call to reach ourclassification decision. In our experimentation, we could compare against 1350stored machine learning models in 24.3 seconds for a single feature vector; vs28.0 seconds for 256 feature vectors. The second reason was that this would allowus to better understand the size of the models generated on Android devices ifcreated with portable versions of Weka, such as the one with Weka for Androiddevices [53]. The size of our models were between 76 KB and 15.2 MB.5.2 Future workThe future work related to this thesis can be broken down into two parts. The first isrelated to the use of machine learning approaches and its potential weaknesses. The97second, is related to the architecture of using multi-agent systems as a detectionframework. We now discuss each in the next two sections.5.2.1 Application of machine learningAs malware in the Android mobile setting is constantly adapting to detection tech-niques, many of the detection models described here and in the referenced literaturehave to be tuned to observe new behavior patterns. As mentioned by Allix et al. in[7], [8], and [6], the performance of machine learning classifiers on Android sufferin performance when the test dataset does not exhibit features that the classifiershave not been trained on previously. We now list some future directions that canbe taken to refine this work further.Bayesian optimization for parameter selectionBayesian optimization [72, 78] is a promising approach for automatically adjustingfree parameters in any given algorithm. This optimization methodology throughrandom embedding was developed parallel to when we were developing our ap-proach, and could handle up to a billion dimensions. In the case of Random Forest,the free parameters include: the number of trees in the forest, the number of randomfeatures selected at each decision node of a tree, and the maximum depth of eachtree. We envision using an objective function that uses the out-of-bag error estimateto guide the Bayesian Optimization algorithm into selecting the right combinationof parameters that provide us acceptable settings based on our required threshold.Due to the reason mentioned above, and as the number of free parameters in theRandom Forest algorithm are not too many; we did not make use of this approachas we had determined that our accuracies followed a particular pattern and using98this method would not contribute to our results significantly.Observing more featuresThe dataset we used primarily focused on the binder API of Android, CPU usagepattern, and memory usage pattern on an Android device emulator. Many paperslisted in the related work section used system call tracking as features. RandomForest is relatively immune to increase in the number of features of a feature vectoras it requires to observe only log m features of the available m features. Thus,monitoring system call features and more fine grained network level behaviourwould allow us to create better detection models. For example, Allix et al. [7]created a set of 2.5 million features constructed from static features gathered from.dex byte code files of Android Executables. Our approach to testing with theparameters of the Random Forest algorithm could be tested on this data. The reasonwhy we have not tested this dataset is because of its size and the limitations ofthe weka library used for our analysis. The Java Weka library requires that theentire dataset be first copied into memory before a model can be built. Given thatthe dataset was approximately 250 gigabytes in size, the dataset would requirepre-processing to remove unnecessary static features to minimize its size to avoidrunning out of memory.Ensemble learningEnsemble learning creates a learning model by integrating the results of multiplemodels. Though the Random Forest algorithm is an ensemble learning method thataverages the results of multiple models (decision trees), we could create anotherlevel of ensemble learners, some of which monitor device at the user level and99others that monitor features at the kernel level. For example, we could create alearning model for tcpdump data to monitor network traffic and another to monitorsystem call data using strace. A foreseeable challenge in this case would be tosee how good a classification technique would be in the absence of observed dataduring testing time. This would be the case if some of the features cannot beobserved if a device is unrooted; or a tool for capturing the behaviour is missingin a rooted device. Similar issues will occur if Google decides to remove access toAPI used for observing behaviour at user level.Fine grained inspectionThe features observed in our dataset are global in nature i.e. all concurrently run-ning applications together impact the features observed. This would cause the datafeatures measured to be very noisy at best without being able to individually breakdown the impact of each application on the measured features. Similar issues canbe identified with [71] as feature vectors were collected by running a single An-droid application at a time on a real device. One approach we envision would beto normalize the measured feature changes by fine grained inspection of currentlyrunning applications. This information was allowed to be queried using the Ac-tivityManager class using the getRunningTasks method in Android API but wasremoved in API level 21 (Android Lollipop). This approach would however bechallenging as it would require first building the feature vector of each of the indi-vidual applications available on the system before being of use.1005.2.2 Use of multi-agent systemsDynamic loading of agentsCurrently, our system requires that all Action agents dynamically launched by theProfile agent reside on the Android device. This requires us to develop a newAndroid package file every time we create a new agent. The LoaderBehaviour classof JADE currently does not support loading Dalvik Bytecode (DEX) bytecode usedin Android systems. If DEX bytecode loading is supported by the LoaderBehaviourclass, it would allow to load agents not stored on the device.Using other types of communication frameworkThere are alternative solutions that can be used instead of agent-based systems.Given that one of the primary reasons for using the agent-based system was tocommunicate data between clients and servers, this could be handled by usingREpresentational State Transfer (REST) web services [64] by passing ExtensibleMarkup Language (XML) or JSON data describing the fields instead of using AgentCommunication Language (ACL). In that case, the Android devices would behaveas REST clients communicating with the servers for the information. However,given that RESTful services require clients to maintain state instead of servers, theAndroid clients would have to periodically query the server to see if a classifica-tion result was available, causing more network communication and hence batteryusage.101Bibliography[1] C. Aart. Ontology Bean Generator, 2015 (accessed 31 Jan, 2015). URLhttp://protegewiki.stanford.edu/wiki/OntologyBeanGenerator. → pages 35[2] M. Alam and S. T. Vuong. An intelligent multi-agent based detectionframework for classification of android malware. In Active MediaTechnology, pages 226–237. Springer, 2014. → pages iv, v[3] M. Alam and S. T. Vuong. Performance of malware classifier for android. In6th IEEE Annual Information Technology, Electronics and MobileCommunication Conference. IEEE, 2015. → pages iv, v, 4[4] M. Alam, Z. Cheng, and S. Vuong. Context-aware multi-agent basedframework for securing android. In Multimedia Computing and Systems(ICMCS), 2014 International Conference on, pages 961–966. IEEE, 2014.→ pages iv, v, xii, 42, 43[5] M. S. Alam and S. T. Vuong. Random forest classification for detectingandroid malware. In Green Computing and Communications (GreenCom),2013 IEEE and Internet of Things (iThings/CPSCom), IEEE InternationalConference on and IEEE Cyber, Physical and Social Computing, pages663–669. IEEE, 2013. → pages iv, v, xi, 4, 18, 31, 34, 48, 73, 75, 86[6] K. Allix, T. F. Bissyande´, Q. Je´rome, J. Klein, and Y. Le Traon. Empiricalassessment of machine learning-based malware detectors for android.Empirical Software Engineering, pages 1–29, 2014. → pages 13, 98[7] K. Allix, T. F. D. A. Bissyande, J. Klein, and Y. Le Traon. Machinelearning-based malware detection for android applications: History matters!2014. → pages 98, 99[8] K. Allix, Q. Jerome, T. F. Bissyande, J. Klein, R. State, and Y. L. Traon. Aforensic analysis of android malware–how is malware written and how it102could be detected? In Computer Software and Applications Conference(COMPSAC), 2014 IEEE 38th Annual, pages 384–393. IEEE, 2014. →pages 98[9] B. Amos. Antimalware, 2013 (Last Accessed May 15, 2013). URLhttps://github.com/VT-Magnum-Research/antimalware. → pages 66, 67, 69[10] B. Amos, H. Turner, and J. White. Applying machine learning classifiers todynamic android malware detection at scale. In IWCMC13 Security, Trustand Privacy Symposium, 2013. → pages 15, 16, 72, 73, 74, 75, 76[11] E. Andersen. Busy Box, 2013 (Last Accessed May 15, 2013). URLhttps://busybox.net/. → pages 36[12] Android Su. Android SuperUser Tools, 2013 (Last Accessed May 15, 2013).URL http://androidsu.com/superuser/. → pages 36[13] Android TCPdump. Android TCP Dump, 2013 (Last Accessed May 15,2013). URL http://www.androidtcpdump.com/. → pages 36[14] Anti Spy Mobile. 2013 (Last Accessed: Aug 14, 2016). URLplay.google.com/store/apps/details?id=com.antispycell.connmonitor. →pages 62[15] Apple. Apple Store, 2013 (Last Accessed May 15, 2013). URLhttp://store.apple.com. → pages 2[16] M. Asaka, A. Taguchi, and S. Goto. The implementation of ida: Anintrusion detection agent system. In Proceedings of the 11th FIRSTConference, volume 6. Citeseer, 1999. → pages 11[17] Z. Aung and W. Zaw. Permission-based android malware detection.International Journal Of Scientific & Technology Research, 2(3), 2013. →pages 16[18] G. Bai, L. Gu, T. Feng, Y. Guo, and X. Chen. Context-aware usage controlfor android. In Security and Privacy in Communication Networks, pages326–343. Springer, 2010. → pages 19[19] J. S. Balasubramaniyan, J. O. Garcia-Fernandez, D. Isacoff, E. Spafford, andD. Zamboni. An architecture for intrusion detection using autonomousagents. In Computer Security Applications Conference, 1998. Proceedings.14th Annual, pages 13–24. IEEE, 1998. → pages 10103[20] F. L. Bellifemine, G. Caire, and D. Greenwood. Developing multi-agentsystems with JADE, volume 7. John Wiley & Sons, 2007. → pages 22[21] A. Bieszczad, B. Pagurek, and T. White. Mobile agents for networkmanagement. Communications Surveys & Tutorials, IEEE, 1(1):2–9, 1998.→ pages 9[22] L. Breiman. Random forests. Machine learning, 45(1):5–32, 2001. → pages3, 59, 66, 70, 93[23] L. Breiman and A. Cutler. Random Forests, 2013 (Last Accessed May 15,2013). URLhttp://www.stat.berkeley.edu/∼breiman/RandomForests/cc home.htm. →pages 71[24] I. Burguera, U. Zurutuza, and S. Nadjm-Tehrani. Crowdroid: behavior-basedmalware detection system for android. In Proceedings of the 1st ACMworkshop on Security and privacy in smartphones and mobile devices, pages15–26. ACM, 2011. → pages 14, 69[25] G. Caire, G. Iavarone, M. Izzo, and K. Heffner. JADE Tutorial: JADEprogramming for Android, 2012 (accessed 25 Jan, 2015). URLhttp://jade.tilab.com/doc/tutorials/JadeAndroid-Programming-Tutorial.pdf.→ pages 34[26] N. V. Chawla, K. W. Bowyer, L. O. Hall, and W. P. Kegelmeyer. Smote:synthetic minority over-sampling technique. Journal of artificial intelligenceresearch, 16:321–357, 2002. → pages 68, 77[27] V. Chebyshev and R. Unuchek. Mobile Malware Evolution 2013, 2013(accessed 31 Jan, 2015). URL http://securelist.com/analysis/kaspersky-security-bulletin/58335/mobile-malware-evolution-2013/. →pages 2[28] Z. Cheng. A multi-agent security system for android platform. MastersThesis, University of British Columbia, 2012. → pages iv, xii, 33, 36, 42, 43[29] M. Crosbie and E. H. Spafford. Defending a computer system usingautonomous agents. 8th National Information Systems Security Conference,1995. → pages 10[30] N. De Freitas. Machine Learning, 2013 (Last Accessed 31 Jan, 2015). URLhttp://www.cs.ubc.ca/∼nando/540-2013/lectures/l1.pdf. → pages 12104[31] J. D. De Queiroz, L. F. R. da Costa Carmo, and L. Pirmez. Micael: Anautonomous mobile agent system to protect new generation networkedapplications. In Recent Advances in Intrusion Detection. Citeseer, 1999. →pages 11[32] A. Desnos. Androguard: Reverse engineering, Malware and goodwareanalysis of Android applications, 2015 (accessed 31 Jan, 2015). URLhttps://code.google.com/p/androguard/. → pages 8[33] S. G. Dewan and L. Chen. Mobile payment adoption in the usa: across-industry, cross-platform solution. Journal of Information Privacy &Security, 1(2):4–28, 2005. → pages 1[34] G. Dini, F. Martinelli, A. Saracino, and D. Sgandurra. Madam: a multi-levelanomaly detector for android malware. In Computer Network Security,pages 240–253. Springer, 2012. → pages 14, 69[35] A. Dmitrienko, C. Liebchen, C. Rossow, and A. R. Sadeghi. Securityanalysis of mobile two-factor authentication schemes. Intel R© TechnologyJournal, 18(4), 2014. → pages 3[36] Elinux. Procrank Memory Usage Measurement, 2013 (Last Accessed May15, 2013). URL http://elinux.org/Android Memory Usage#smem tool. →pages 45[37] W. Enck, P. Gilbert, B. G. Chun, L. P. Cox, J. Jung, P. McDaniel, and A. N.Sheth. Taintdroid: an information flow tracking system for real-time privacymonitoring on smartphones. Communications of the ACM, 57(3):99–106,2014. → pages 8[38] S. Erickson. Root Tools, 2013 (Last Accessed May 15, 2013). URLhttps://github.com/Stericson/RootTools. → pages 36[39] N. Foukia, D. Billard, and P. J. Harms. Computer system immunity usingmobile agents. In HP Openview University Association 8th AnnualWorkshop, 2001. → pages 12[40] N. Foukia, S. Hassas, S. Fenet, and P. Albuquerque. Combining immunesystems and social insect metaphors: a paradigm for distributed intrusiondetection and response system. In Mobile Agents for TelecommunicationApplications, pages 251–264. Springer, 2003. → pages 12105[41] W. Glodek and R. Harang. Rapid permissions-based detection and analysisof mobile malware using random decision forests. In MilitaryCommunications Conference, MILCOM 2013-2013 IEEE, pages 980–985.IEEE, 2013. → pages 13[42] Google. Google android security overview. Technical report,http://source.android.com/tech/security, May 2013. → pages 69[43] Google. Google Play Store, 2013 (Last Accessed May 15, 2013). URLhttp://play.google.com. → pages 2[44] Google. UI/Application Exerciser Monkey, 2013 (Last Accessed May 15,2013). URL http://developer.android.com/tools/help/monkey.html. → pages66, 72[45] Google. Dalvik Debug Monitoring Server, 2013 (Last Accessed May 15,2015). URL https://developer.android.com/studio/profile/ddms.html. →pages 41[46] M. Hall, E. Frank, G. Holmes, B. Pfahringer, P. Reutemann, and I. H. Witten.The weka data mining software: An update. SIGKDD Explor. Newsl., 11(1):10–18, Nov. 2009. ISSN 1931-0145. doi:10.1145/1656274.1656278. URLhttp://doi.acm.org/10.1145/1656274.1656278. → pages 48, 70[47] R. Hasan, N. Saxena, T. Haleviz, S. Zawoad, and D. Rinehart.Sensing-enabled channels for hard-to-detect command and control of mobiledevices. In Proceedings of the 8th ACM SIGSAC symposium on Information,computer and communications security, pages 469–480. ACM, 2013. →pages 3[48] G. G. Helmer, J. S. Wong, V. Honavar, and L. Miller. Intelligent agents forintrusion detection. In Information Technology Conference, 1998. IEEE,pages 121–124. IEEE, 1998. → pages 10[49] D. Kim, J. Kim, and S. Kim. A malicious application detection frameworkusing automatic feature extraction tool on android market. In 3rdInternational Conference on Computer Science and Information Technology(ICCSIT’2013), pages 4–5, 2013. → pages 13, 69[50] C. Kru¨gel and T. Toth. Flexible, mobile agent based intrusion detection fordynamic networks. European Wireless, 2002. → pages 11106[51] C. Kru¨gel, T. Toth, and E. Kirda. Sparta. In Advances in Network andDistributed Systems Security, pages 187–198. Springer US, 2002. → pages11[52] C. Li, Q. Song, and C. Zhang. Ma-ids architecture for distributed intrusiondetection using mobile agents. In Proceedings of the 2nd InternationalConference on Information Technology for Application (ICITA 2004), pages451–455, 2004. → pages 11[53] P. Liu, Y. Chen, W. Tang, and Q. Yue. Mobile WEKA as Data Mining Toolon Android, pages 75–80. Springer Berlin Heidelberg, Berlin, Heidelberg,2012. ISBN 978-3-642-27951-5. doi:10.1007/978-3-642-27951-5 11. URLhttp://dx.doi.org/10.1007/978-3-642-27951-5 11. → pages 97[54] F. Maggi, A. Valdi, and S. Zanero. Andrototal: A flexible, scalable toolboxand service for testing mobile malware detectors. In Proceedings of theThird ACM workshop on Security and privacy in smartphones & mobiledevices, pages 49–54. ACM, 2013. → pages 17[55] P. Mell and M. McLarnon. Mobile agent attack resistant distributedhierarchical intrusion detection systems. Technical report, DTIC Document,1999. → pages 11[56] M.Nikraz, G. Caire, and P.A.Bahri. A methodology for the development ofmultiagent systems using the jade platform. In International Journal ofComputer Systems Science and Engineering, volume 21, pages 99–116,2006. → pages 25[57] A. Moreno, A. Valls, and A. Viejo. Using JADE-LEAP implement agents inmobile devices. Universitat Rovira i Virgili. Departament d’EnginyeriaInforma`tica, 2003. → pages 19[58] K. P. Murphy. Machine learning: a probabilistic perspective. 2012. →pages 12[59] M. Musen. The Protege project: A look back and a look forward. AIMatters., volume 4. Association of Computing Machinery Specific InterestGroup in Artificial Intelligence, June 2015.doi:10.1145/2557001.25757003. → pages 35[60] M. Nauman, S. Khan, and X. Zhang. Apex: extending android permissionmodel and enforcement with user-defined runtime constraints. InProceedings of the 5th ACM Symposium on Information, Computer andCommunications Security, pages 328–332. ACM, 2010. → pages 8107[61] PayByPhone. 2013 (Last Accessed May 15, 2013). URLhttp://www.paybyphone.com/. → pages 1[62] S. Poeplau, Y. Fratantonio, A. Bianchi, C. Kruegel, and G. Vigna. Executethis! analyzing unsafe and malicious dynamic code loading in androidapplications. In 21st Annual Network and Distributed System SecuritySymposium, NDSS 2014, San Diego, California, USA, February 23-26,2013, 2014. URL http://www.internetsociety.org/doc/execute-analyzing-unsafe-and-malicious-dynamic-code-loading-android-applications.→ pages 2[63] G. Ramachandran and D. Hart. A p2p intrusion detection system based onmobile agents. In Proceedings of the 42nd annual Southeast regionalconference, pages 185–190. ACM, 2004. → pages 11[64] L. Richardson and S. Ruby. RESTful web services. ” O’Reilly Media, Inc.”,2008. → pages 101[65] D. Rosenberg. It’s Bugs All the Way Down, 12 2011 (Last Accessed: Sep 11,2015). URL http://vulnfactory.org/blog/2011/12/05/carrieriq-the-real-story/.→ pages 3[66] A. Santi, M. Guidi, and A. Ricci. Jaca-android: an agent-based platform forbuilding smart mobile applications. In Languages, Methodologies, andDevelopment Tools for Multi-Agent Systems, pages 95–114. Springer, 2011.→ pages 10[67] A. D. Schmidt, H. G. Schmidt, J. Clausen, K. A. Yuksel, O. Kiraz,A. Camtepe, and S. Albayrak. Enhancing security of linux-based androiddevices. In in Proceedings of 15th International Linux Kongress. Lehmann,2008. → pages 8[68] D. Schreckling, J. Ko¨stler, and M. Schaff. Kynoid: real-time enforcement offine-grained, user-defined, and data-centric security policies for android.Information Security Technical Report, 17(3):71–80, 2013. → pages 8[69] A. Shabtai, Y. Fledel, and Y. Elovici. Securing android-powered mobiledevices using selinux. IEEE Security & Privacy, 8(3):36–44, 2010. → pages8[70] A. Shabtai, Y. Fledel, U. Kanonov, Y. Elovici, S. Dolev, and C. Glezer.Google android: A comprehensive security assessment. IEEE Security andPrivacy, 8(2):35–44, 2010. → pages 8108[71] A. Shabtai, U. Kanonov, Y. Elovici, C. Glezer, and Y. Weiss. “andromaly”: abehavioral malware detection framework for android devices. Journal ofIntelligent Information Systems, 38(1):161–190, 2012. → pages 15, 69, 100[72] J. Snoek, H. Larochelle, and R. P. Adams. Practical bayesian optimization ofmachine learning algorithms. In Advances in neural information processingsystems, pages 2951–2959, 2012. → pages 98[73] S. J. Stolfo, A. L. Prodromidis, S. Tselepis, W. Lee, D. W. Fan, and P. K.Chan. Jam: Java agents for meta-learning over distributed databases. InKDD, volume 97, pages 74–81, 1997. → pages 11[74] Telecom Italia Lab. Jave Agent Development Framework, 2013 (LastAccessed May 15, 2013). URL http://jade.tilab.com. → pages 18[75] Trend Micro. Android Malware Believe the hype, 2013 (Last Accessed May15, 2013). URLhttp://countermeasures.trendmicro.eu/android-malware-believe-the-hype.→ pages 2[76] TrustGo Security. New Virus SMSZombie.A Discovered by TrustGO SecurityLabs, 2012 (Last Accessed: Sep 15, 2015). URLhttp://blog.trustgo.com/SMSZombie/. → pages 2[77] S. T. Vuong and M. S. Alam. Advanced methods for botnet intrusiondetection systems. In Intrusion Detection Systems. InTech, 2011.doi:10.5772/15401. URLhttp://www.intechopen.com/books/intrusion-detection-systems/advanced-methods-for-botnet-intrusion-detection-systems. → pages iv, vi[78] Z. Wang, M. Zoghi, F. Hutter, D. Matheson, and N. De Freitas. Bayesianoptimization in high dimensions via random embeddings. In Proceedings ofthe Twenty-Third international joint conference on Artificial Intelligence,pages 1778–1784. AAAI Press, 2013. → pages 98[79] C. Xiang, F. Binxing, Y. Lihua, L. Xiaoyi, and Z. Tianning. Andbot: towardsadvanced mobile botnets. In Proceedings of the 4th USENIX conference onLarge-scale exploits and emergent threats, pages 11–11. USENIXAssociation, 2011. → pages 3[80] Y. Zhauniarovich, G. Russello, M. Conti, B. Crispo, and E. Fernandes.Moses: supporting and enforcing security profiles on smartphones. IEEETransactions on Dependable and Secure Computing, 11(3):211–223, 2014.→ pages 19109[81] Y. Zhauniarovich, M. Ahmad, O. Gadyatskaya, B. Crispo, and F. Massacci.StaDynA: Addressing the Problem of Dynamic Code Updates in theSecurity Analysis of Android Applications. In Proceedings of the 5th ACMConference on Data and Application Security and Privacy, CODASPY ’15,2015. to appear. → pages 13[82] Y. Zhou and X. Jiang. Dissecting android malware: Characterization andevolution. In Security and Privacy (SP), 2012 IEEE Symposium on, pages95–109. IEEE, 2012. → pages 3, 13110


Citation Scheme:


Citations by CSL (citeproc-js)

Usage Statistics



Customize your widget with the following options, then copy and paste the code below into the HTML of your page to embed this item in your website.
                            <div id="ubcOpenCollectionsWidgetDisplay">
                            <script id="ubcOpenCollectionsWidget"
                            async >
IIIF logo Our image viewer uses the IIIF 2.0 standard. To load this item in other compatible viewers, use this url:


Related Items