Automated generation of colluding apps for experimental research
- 738 Downloads
Colluding apps bypass the security measures enforced by sandboxed operating systems such as Android. App collusion can be a real threat in cloud environments as well. Research in detecting and protecting against app collusion requires a variety of colluding apps for experimentation. Presently the number of (real or manually crafted) apps available to researchers is very limited. In this paper we propose a system called Application Collusion Engine (ACE) to automatically generate combinations of colluding and non-colluding Android apps to help researchers fairly evaluate different collusion detection and protection methods. Our initial implementation includes a variety of components that enable the system to create more than 5,000 different colluding and non-colluding app sets. ACE can be extended with more functional components to create even more colluding apps. To show the usefulness of our system, we have applied different risk evaluation and collusion detection methods to the created set of colluding apps.
KeywordsCollusion Android Malware Sandbox Benchmark
Modern mobile operating systems, such as Android, use sandboxing to prevent malicious apps from causing harmful effects by restricting each process from accessing resources outside its domain. In a sandboxed environment, access to sensitive system resources is mediated by the operating system and restricted by default. Apps requiring access must request the necessary permissions from the user at installation or execution time. Additionally, resources from other apps are outside of the boundaries of the sandbox and must be accessed through inter-application communication methods, if available in the operating system.
Colluding apps use covert and overt channels to jointly perform malicious operations . The origin of app collusion can be traced back to the confused deputy attack . Confused deputies expose protected resources through public interfaces. In Android, confused deputy attacks can happen in the form of permission re-delegation attacks [15, 19, 33]. A careless developer may unintentionally expose permission-protected resources by allowing the component that access those resources to communicate with other apps through IAC (inter-app communication). An attacker can take advantage of this component to access the protected resource without requesting the corresponding permission.
Colluding apps behave similarly to malicious apps taking advantage of confused deputies, but their actions are executed on purpose. Colluding apps can carry out information theft attacks but also can be used to misuse a device service or increase the impact of an attack inside a system. The main goal of collusion attacks is to avoid the restrictions imposed by sandboxed environments, like Android, to make an attack more difficult to detect. Users, security researchers and malware analysis services normally focus on the the access to resources given to an app to establish its risk level. If that access is split across several apps that collude, an app may not require to request access to a protected resource. It will only have to ask for it to a colluding app that already has access to it. It must be noted that, while Android requires the user to grant the permissions to be used by an app, it does not impose any control on how apps exchange information. Although app collusion is not a widespread problem today, there have been already some cases of malicious apps engaging in colluding behaviors. In  authors detected some samples from the VirusShare project  that were receiving data through broadcast receivers and sending it through SMS messages. More recently, researchers discovered a malicious version of the MoPlus SDK that was synchronizing the execution of the malicious payload through app collusion [2, 9]. All apps running on a device embedding the MoPlus SDK would talk to each other to determine which of these apps had the most privileges. The app with the most privileges would be the only one executing a local HTTP server to receive commands from a command and control server. This SDK was embedded in more than 5,000 versions of 20 apps. This synchronization strategy was used by the developers of the malicious SDK to avoid apps embedding the SDK but with not enough privileges to activate the malicious payload. In this way, only the payload within the app with the required permissions would execute, maximising the result of the attack.
Malware researchers have access to public datasets, predominantly for Android, that can be used to test their detection methods [4, 35]. This allows fair evaluation and comparison between proposed methods, which in the end fosters better quality research. Unfortunately, representative datasets do not presently exist for colluding apps because the very few examples of collusion happening in the wild, have been discovered very recently.
This paper aims to meet the need a practical set of colluding apps for research. Our system called Collusion Application Engine (ACE) is capable of automatically generating multiple colluding app sets with a variety depending on the configuration of app component templates and code snippets. ACE can be extended with new app components and code blocks to create a greater variety of new colluding app sets, if needed. In this way, it is easy to create substantial app sets (colluding and non colluding) for experimentation avoiding the need for a great deal of manual programming effort. The source code of ACE, as well as an initial set of 240 apps are available upon request from the authors.1
The remainder of this paper is structured as follows. Section 2 describes previous efforts of other researchers in exploring colluding apps. Section 3 describes the methodology underlying ACE and how it can generate thousands of different app sets. Section 4 shows the validation process followed to test the apps created by ACE. Finally, Sect. 5 presents our conclusions and future directions for research.
2 Related work
Android malware detection has been an attractive and active research area during the last few years. As a result, techniques for detecting Android malware are readily available [17, 30]. These can be categorised into two main groups: static and dynamic. In static analysis, certain features of the app binary are extracted and analysed using different approaches such as machine learning techniques. Examples of these are , using hardware components, requested permissions, critical and suspicious API calls, and network addresses or many others [11, 14]. Conversely, dynamic analysis detects malware at run-time. It deploys suitable monitors on Android systems to log traces and features that are used to look for malicious behaviours. Examples of these are , which keeps track of the network traffic or , which collects information about the usage of network usage, memory and CPU.
In contrast to malware detection, detecting colluding apps involves not only obtaining features that show if an app carries out a security threat, but also revealing whether communication between several apps occurs during the attack. As most of the existing malware detection techniques focus only on detecting whether single apps can carry the full extent of the threat and not on their communication channels, they are naturally constrained to detect collusion. Taint analysis based approaches like Amandroid  and FlowDroid  could be used for collusion detection. These are focused on analyzing single apps to detect information leaks through inter-component communications, ICC, (i.e. a location leaking from a service to an activity within the same app). This limits its usefulness against colluding apps. First, they are only able to analyse single apps. This means that, although they are able to detect leaks to other apps through inter-app communications,2 (i.e. and activity/service from one app sending information to an activity/service from another app), they are not able to tell the other app that is taking part in the collusion. In addition to this, colluding apps may use other communication channels for collusion (i.e. covert channels) rather than standard IAC channels.
To overcome this limitation, there are approaches like APKCombiner  that join two applications into a single APK. This enables information flow tools to analyze app pairs.
The other colluding apps available in the literature can be categorized into two groups: those developed to test detection and protection methods and those developed to explore the different covert channels available in Android.
A combination of Soundcomber, three proof-of-concept colluding app sets, and another three vulnerable apps from other works [15, 18, 26] were used to test an an operating system extension called XManDroid . The colluding apps were capable of stealing user contacts, SMS messages, and location, respectively. In a similar way,  describes 10 colluding apps developed to evaluate their static analysis detection methods. In this case, colluding app sets are not restricted to information theft. One of the developed sets is also able to send premium-rate SMS messages to numbers that are received from another app. Finally, the authors of  evaluated their proposal against 13 colluding apps that steal sensitive information and communicate through intents and DroidBench . DroidBench is the only public dataset that includes colluding apps. However, it only includes three colluding apps from 120, as it is intended for evaluating the effectiveness of taint-analysis tools (where collusion is a subset).
Overall, 36 different apps have been accounted as developed with the specific purpose of testing collusion detection methods. The development of mobile apps is a time consuming task that requires to gain knowledge of the app development environment and many hours of testing. An automated method to develop colluding apps could reduce the efforts researchers have to spend on these time consuming tasks, so they can focus on improving the actual detection methods. As an example of this, we use our automatic app generation method to generate 240 colluding app pairs that are tested with two different collusion detection methods.
Besides Soundcomber, several previous papers have investigated the usage of covert channels for app collusion. Covert channels in Android, as in other systems, are restricted by the amount of shared resources, side channels that can be found in the device, and human imagination [13, 34].  describes a collusion scenario where a ContactManager and PasswordManager app use overt and covert channels to extract information through another app that acts like a generic weather app. In , the authors enumerate and evaluate the bandwidth of different overt and covert channels in real devices. Covert channels tested include: intent type enumeration, settings modification, thread and socket enumeration and free disk space among others, which were used also in . An imaginative covert channel that uses the device actuators and sensors is described in . The vibration motor is used to transmit information while the accelerometer sensor is used to capture it from another app. More recently,  showed how repackaging can be used to inject colluding payloads into benign apps. Repackaged apps communicate through a covert channel based on process enumeration. ACE could be used to generate, with minimal effort, additional testing apps based on the specific features of these specifically developed colluding apps (covert channels and payloads). The rest of this sections describes in more detail each of the components of ACE.
3 Application collusion engine
ACE aims to fill the need for colluding app datasets for research experimentation. It can free up significant time for researchers so they can focus instead on efforts to develop collusion detection and protection methods. If a new covert channel or attack is found, ACE can be easily extended. In this section, we describe the system design and how it can generate colluding app sets.
3.1 General overview
Generating individual malicious apps is a relatively simple task. A malicious payload can be injected into a template or repackaged app, modifying the required permissions as needed. Generating colluding app sets is more complex because the creation of one app needs to take into account how the rest of the apps in the colluding set were generated.
3.2 Colluding set engine
The Colluding Set Engine tells the Application Engine how to generate apps in such a way that they end up colluding.
3.2.1 Collusion templates
A collusion template describes the different apps that take part in a colluding app set. This is, the threat they carry out and how they communicate. Colluding apps can carry out any attack similar to the ones posed by single apps : denial of service, service misuse, and information and money theft. Although the nature of each of these attacks is different, they are all based on executing a set of actions in a specific order.
Our colluding templates follow this philosophy. For each of the aforementioned threats, we have established a set of actions that are required to execute it. For example, an information theft attack will require (i) reading sensitive information and (ii) sending it outside to a remote server. In the same way, a ransomware attack will require (i) encrypting the personal files (ii) processing or facilitating the payment and (iii) decrypting back the files.
In our case, each defined action is implemented with a specific code snippet. In this way, creating a colluding app set to execute a threat requires to split, across different apps, the different code snippets (actions) required to execute it. The communication channel used to execute the attack is not relevant to the attack goal. As long as the selected code snippets allow apps to exchange information somehow, the generated set will be able to collude. This fact enables us to create many different colluding app sets for even the same threat by interchanging different communication code snippets. Additionally, this allows us to create colluding app sets of an arbitrary number of apps. If the number of apps in the set exceeds the number of actions, some of the apps will just forward messages from one app to another.
3.2.2 App templates
An app template includes all the initial files, organized in an Android project structure, that are required by the Android Development Kit to build and sign an app. This includes, among other things, an initial manifest file, build and signing scripts, a private key to sign the resulting apk, and all the other resources that may be required during the process. App templates can be customised to target specific Android versions or include other specific features such as loading images, etc.
3.3 Application engine
The Application Engine creates fully working apps by filling app component templates with code snippets. The Application Engine works as follows. First, it reads and processes the app description file. This retrieves the required component templates and code snippets and adds all the reference resource files to the app source. Then, the component templates are filled; the app manifest is generated; and the project is built and signed, producing an APK file that can be installed in a device.
3.3.1 Component templates
Activities represent screens of the user interface. Activities allow the user to interact with the app, giving back some feedback. Activities run only on the foreground. Apps are generally composed of a set of activities.
Services execute operations in the background. They are generally used by other components of the app to perform long-running tasks that must be executed in the background: listening to incoming connections, play music, download a file, and so on. Services can be configured so they can be accessed remotely by other processes.
Broadcast Receivers respond to broadcast messages that can be sent through Intent objects, by the same or other apps in the device.
Content Providers manage access of other apps to the app’s own shared data. Apps with content providers enable other apps to read and write data inside their sandbox.
3.3.2 Code snippets
Code snippets also enable inter-component and inter-app communication. If the snippet sends information to another component of the app (i.e. an intent that launches a service within the same app) it will allow inter-component communication. In this case, the app will also have to include the definition of the component that will receive the communication and a code snippet to process that information. If the snippet sends information to a component that belongs to another app (i.e. a broadcast intent) it will allow inter-component communication. Of course, an app can include both ICC and IAC snippets (depending on the application description file used to generated them).
In some cases, there might be synchronization issues. For example, if an app sends an intent and no app is registered to receive it, the information sent will be lost. In other cases, like when using external storage this problem does not happen. However, controlling this is not part of ACE, as execution order (or even installation) is controlled by the developer. When creating a pair of colluding apps, the Colluding Set Engine generates the app description files avoiding this, in such a way that the both apps can communicate.
General Snippets provide the general functionality to complete a fully working app. These include: string concatenation, encryption, variable initialization, logging, etc. These can be used to combine, for example, execution of an app that extracts information from the device and another that encrypts it before sending it through an inter-app communication channel.
3.3.3 App description files
3.4 Building app sets
Read the collusion template that specifies the actions to be executed in each colluding app.
Generate n apps where n is more than 1 and smaller than the number of actions in the template; assign at least one action to each app.
Determine if there is going to be forwarding apps; if so, create them.
Add pairs of communication snippets to enable communications between the apps in the set.
Generate the app description files for each app in the set.
Call the Application Engine to create the set.
3.5 Generating non-colluding apps
Create app sets that exchange information, but do not access sensitive resources.
Create app sets that access sensitive resources but exchange information that is not related to those sensitive resources.
Create apps that access sensitive resources and send information to non-colluding apps via standard Android communication channels (e.g. the generated app reads your location and allows sharing it via facebook).
The amount of colluding app sets that can be generated with ACE depends greatly on the number of available code snippets and templates. We have validated our tool by generating a set of colluding apps and measuring its risk with different methodologies available in the literature. This section describes this process.
4.1 Colluding app set generation
Resource code snippets used for the generation of colluding app sets executing information theft attacks
Returns device accounts information
Returns the browser bookmarks
Returns the call log
Returns the list of contacts
Returns the navigation history
Returns the device IMEI
Records audio for 5 seconds
List of WiFi SSID networks
List of processes being executed
Intents: an app launches a broadcast intent with a randomly generated action. The receiving app registers a broadcast receiver with the same action. Other intent based communication channels (e.g. explicit intents launching activities and services) could be easily added by incorporating the corresponding code snippets.
- Shared Preferences: are an Android feature that allows apps to store key-value pairs of data. configuration and preferences. Although it is not intended for inter-app communication, apps can use key-value pairs to exchange information if proper flags are defined ( or ) when accessing and storing data. In our sets, one of the apps saves the data into a world readable shared preference file. The receiving app accesses the same file to read the information.
4.2 Validation of collusion behavior
Install both apps.
Run the first installed app for five seconds (in the foreground).
Press the home button.
Run the second app for five seconds (in the foreground).
Press the home button.
Uninstall both apps.
4.3 Measuring collusion risk
Current App collusion detection techniques can be split in two groups: operating system extensions and taint analysis tools. The first group focuses on detecting and mitigating collusion during execution while the second group focuses on analysing the static features of the app code and resources without executing the apps. Unfortunately, we were unable to find any working version of an operating system extension, like XManDroid, to execute our experiments.
FlowDroid and Amandroid are two examples of taint analysis proposals [6, 32]. The focus of these tools is to detect sensitive information flows between components within the same application (ICC), but they are also capable of detecting, with certain limitations, when an app component leaks sensitive information to other apps through inter-app communication (IAC). Their limitation relies on the fact that the tools are only able to tell if sensitive information is being sent to other apps via IAC, without specifying the actual apps, as the analysis is only executed over one app. In order to identify if two apps communicate, the analysis must be performed over the two apps separately to check if the sources and sinks from both apps match. In our tests, neither FlowDroid or Amandroid were able to identify apps receiving sensitive information through intents or shared preferences. As both tools execute single app analysis, they have no information about the kind of information that can be received through those channels, and therefore not consider those as possible transmitters of sensitive information. This means that these tools are appropriate to identify apps leaking sensitive information, but not so good on identifying apps making use of that information.
In 2015, Li et al. proposed APKCombiner, a method to avoid this issue . APKCombiner combines two apps in such a way that IAC channels between the apps are transformed into ICC channels (as the components that communicate are now within the same app). In this way, tools like FlowDroid or Amandroid will be able to directly trace the sensitive information flowing through the two components (that are now together in the same app). It must be noted that the app resulting from the execution of APKCombiner may not correctly execute on a system. However, the resulting app is still valid for the purpose of static analysis and transforming inter-app communication channels into inter-component communication channels within the same combined app .
Amandroid is a static analysis tool for Android apps. It analyzes the usage of sensitive APIs in a flow and context-sensitive way across Android app components. In a nutshell, Amandroid analyzes the different information flows inside an app, checking if any sensitive API can be accessed through inter-component communication (ICC) calls. In addition, Amandroid conducts basic string analysis for inferring ICC call parameters such as the intent action. These allow Amandroid to precisely identify the ICC channels that can be used by other app components to access sensitive APIs.
In our experiments, we combine Amandroid with APKCombiner. Amandroid is focused on ICC communications. When analyzing a single colluding app, Amandroid will find all the ICC sensitive information flows between the app, including the one that is sending information outside the app. However, it will not match that available ICC channel with the other colluding app, as it is only analysing a single app. After the APKs are combined with APKCombiner, all IAC between components of the apps would become ICC (as the components are now within the same app). Analysing the combined app, Amandroid should be able to detect now the IAC as ICC within the combined APK file. If the components identified by Amandroid in this case belong to the original different apps (APKCombiner keeps the component packages and names), we can conclude that there was an IAC between the apps.
Amandroid includes rules to detect information leakage, information injection and API misuse attacks. As our colluding apps are restricted to information theft, we have restricted our analysis to information leakage. These information leakage flows could be flagged as other confused deputy attacks. However, in the context of our work and due to the nature of the generated apps, we consider them as evidence of collusion (app pairs have been generated to collude to steal sensitive information).
Results of executing Amandroid
Apps accessing sensitive data
Apps with ICC (Intents)
Apps with ICC (Sh. Prefs)
Apps that leak information
ACE allows researchers to quickly generate colluding app sets. In this way, they can focus on developing new detection methods, rather than spending their time implementing proof-of-concept colluding apps that have already been developed by other researchers.
However, as with other artificially crafted corpus, automatic generated apps should be used with care to avoid certain risks. For instance, let’s imagine such corpus is the only data used to train a machine learning algorithm. In this scenario, there is a non-negligible risk of generating a model that, instead of distinguishing colluding from non-colluding apps, is distinguishing ACE generated from non-ACE generated apps. This could be avoided in three ways: (i) by avoiding features too similar within the set of generated apps (size, number of activities, etc.); (ii) by increasing the variability of code snippets and templates used in ACE; and (iii) by including the few colluding applications that have already been found in the wild [2, 6, 9].
In this paper we have presented ACE (Application Collusion Engine), a system capable of easily generating colluding app datasets. The datasets generated by ACE can be used by researchers to validate and compare different collusion detection proposals.
We have tested ACE by generating 480 colluding apps (240 colluding app pairs) that execute different information theft attacks. All the generated colluding app pairs were executed to verify the collusion attack was possible. Although for experimentation we have generated colluding sets consisting of two apps, ACE is capable of generating app sets of an arbitrary number of apps. We have used two different approaches to measure the risk of the generated apps. First, we have compared the risk levels obtained by single and combined applications using Droidrisk. Results show that approaches that focus on single app analysis can underestimate the risk that an app poses to a system. Approaches that analyze sensitive information flows, like Amandroid, are better at detecting collusion attacks. However, as in most collusion detection research, these tools focus only on apps using the standard ICC communications provided by Android (Intents). Adversaries may take advantage of this fact by implementing their attacks through other well known, but not yet detectable, channels such as shared preferences (up to Android 4.3), external storage o covert channels.
Researchers working on new collusion detection methods (static and dynamic analysis and operating system extensions) can easily extend ACE to quickly generate fully working apps for testing. This will enable, not only a quick validation, but also fair comparison between different proposals. As an example,  recently proposed an energy consumption based method to detect the usage of several covert channels for app collusion. Authors provide the source code required to implement such covert channels. Their validation experiments were executed by transmitting simple messages after a random wait for each of the channels. By adapting the source code of those channels to ACE, validations could be executed on thousands of different colluding apps that transmit real colluding messages instead.
ACE is available by request (with its source code) from the authors. Due to the risk of misuse, it has not been uploaded to public repositories.
The dataset is available on http://personal.rhul.ac.uk/udai/003/colluding_apps.zip.
In Android, IAC and ICC are implemented through very similar APIs.
Risk values were obtained measuring the permissions being used in the combined APK files, and not the ones requested. This is due to a bug in the latest available version of APKCombiner.
This work was supported by the UK Engineering and Physical Sciences Research Council (EPSRC) through grant EP/L022699/1.
- 1.Virusshare (2013). http://www.virusshare.com. Accessed Jan 2017
- 2.McAfee Labs Threats ReportJune 2016. In: Technical Report, McAfee (Intel Security) (2016). http://www.mcafee.com/us/resources/reports/rp-quarterly-threats-may-2016.pdf
- 4.Arp, D., Spreitzenbarth, M., Hubner, M., Gascon, H., Rieck, K.: Drebin: effective and explainable detection of android malware in your pocket. In: NDSS (2014)Google Scholar
- 5.Arp, D., Spreitzenbarth, M., Hubner, M., Gascon, H., Rieck, K.: DREBIN: effective and explainable detection of android malware in your pocket. In: 21st Annual Network and Distributed System Security Symposium, NDSS 2014, San Diego, California, USA, February 23-26, 2014. The Internet Society (2014). http://www.internetsociety.org/doc/drebin-effective-and-explainable-detection-android-malware-your-pocket
- 7.Asavoae, I.M., Blasco, J., Chen, T.M., Kalutarage, H.K., Muttik, I., Nguyen, H.N., Roggenbach, M., Shaikh, S.A.: Towards automated android app collusion detection. Innov. Mob. Priv. Secur. 1575, 29–37 (2016)Google Scholar
- 8.Bhandari, S., Laxmi, V., Zemmari, A., Gaur, M.S.: Intersection automata based model for android application collusion. In: 2016 IEEE 30th International Conference on Advanced Information Networking and Applications (AINA), pp. 901–908. IEEE (2016)Google Scholar
- 9.Blasco, J., Muttik, I., Roggenbach, M., Chen, T.M.: Wild android collusions. In: VirusBulletin 2016. Virus Bulletin (2016)Google Scholar
- 10.Bugiel, S., Davi, L., Dmitrienko, A., Fischer, T., Sadeghi, A.R.: Xmandroid: a new android evolution to mitigate privilege escalation attacks. Technische Universität Darmstadt, Technical Report TR-2011-04 (2011)Google Scholar
- 11.Canfora, G., Lorenzo, A.D., Medvet, E., Mercaldo, F., Visaggio, C.A.: Effectiveness of opcode ngrams for detection of multi family android malware. In: 10th International Conference on Availability, Reliability and Security, ARES 2015, Toulouse, France, August 24–27, 2015, pp. 333–340 (2015). doi: 10.1109/ARES.2015.57
- 13.Chandra, S., Lin, Z., Kundu, A., Khan, L.: Towards a systematic study of the covert channel attacks in smartphones. In: International Conference on Security and Privacy in Communication Networks, pp. 427–435. Springer (2014)Google Scholar
- 14.Dai, G., Ge, J., Cai, M., Xu, D., Li, W.: Svm-based malware detection for android applications. In: Proceedings of the 8th ACM Conference on Security & Privacy in Wireless and Mobile Networks, New York, NY, USA, June 22–26, 2015, pp. 33:1–33:2 (2015). doi: 10.1145/2766498.2774991
- 15.Davi, L., Dmitrienko, A., Sadeghi, A.R., Winandy, M.: Privilege escalation attacks on android. In: Information Security, pp. 346–360. Springer (2011)Google Scholar
- 16.Dimitriadis, A., Efraimidis, P.S., Katos, V.: Malevolent app pairs: an android permission overpassing scheme. In: Proceedings of the ACM International Conference on Computing Frontiers, pp. 431–436. ACM (2016)Google Scholar
- 18.Enck, W., Ongtang, M., McDaniel, P.: Mitigating android software misuse before it happens. The Pennsylvania State University, Technical Report, NAS-TR-0094-2008 (2008)Google Scholar
- 19.Felt, A.P., Wang, H.J., Moshchuk, A., Hanna, S., Chin, E.: Permission re-delegation: attacks and defenses. In: USENIX Security Symposium (2011)Google Scholar
- 20.Fritz, C., Arzt, S., Rasthofer, S., Bodden, E., Bartel, A., Klein, J., le Traon, Y., Octeau, D., McDaniel, P.: Highly precise taint analysis for android applications. In: EC SPRIDE, TU Darmstadt, Technical Report (2013)Google Scholar
- 21.Han, H., Chen, Z., Yan, Q., Peng, L., Zhang, L.: A real-time android malware detection system based on network traffic analysis. In: Algorithms and Architectures for Parallel Processing—15th International Conference, ICA3PP 2015, Zhangjiajie, China, November 18–20, 2015. Proceedings, Part III, pp. 504–516 (2015). doi: 10.1007/978-3-319-27137-8_37
- 22.Hansen, M., Hill, R., Wimberly, S.: Detecting covert communication on android. In: Local Computer Networks (LCN), 2012 IEEE 37th Conference on, pp. 300–303. IEEE (2012)Google Scholar
- 24.Kim, K., Choi, M.: Android malware detection using multivariate time-series technique. In: 17th Asia-Pacific Network Operations and Management Symposium, APNOMS 2015, Busan, South Korea, August 19–21, 2015, pp. 198–202 (2015). doi: 10.1109/APNOMS.2015.7275426
- 25.Li, L., Bartel, A., Bissyandé, T.F., Klein, J., Le Traon, Y.: Apkcombiner: Combining multiple android apps to support inter-app analysis. In: ICT Systems Security and Privacy Protection, pp. 513–527. Springer (2015)Google Scholar
- 26.Lineberry, A., Richardson, D.L., Wyatt, T.: These arent the permissions youre looking for. DefCon 18, 2010 (2010)Google Scholar
- 27.Marforio, C., Francillon, A., Capkun, S., Capkun, S., Capkun, S.: Application collusion attack on the permission-based security model and its implications for modern smartphone systems (2011)Google Scholar
- 28.Marforio, C., Ritzdorf, H., Francillon, A., Capkun, S.: Analysis of the communication between colluding applications on modern smartphones. In: Proceedings of the 28th Annual Computer Security Applications Conference, pp. 51–60. ACM (2012)Google Scholar
- 29.Schlegel, R., Zhang, K., Zhou, X.y., Intwala, M., Kapadia, A., Wang, X.: Soundcomber: a stealthy and context-aware sound trojan for smartphones. In: NDSS, vol. 11, pp. 17–33 (2011)Google Scholar
- 31.Wang, Y., Zheng, J., Sun, C., Mukkamala, S.: Quantitative security risk assessment of android permissions and applications. In: Data and Applications Security and Privacy XXVII, pp. 226–241. Springer (2013)Google Scholar
- 32.Wei, F., Roy, S., Ou, X., et al.: Amandroid: a precise and general inter-component data flow analysis framework for security vetting of android apps. In: Proceedings of the 2014 ACM SIGSAC Conference on Computer and Communications Security, pp. 1329–1341. ACM (2014)Google Scholar
- 33.Wu, L., Du, X., Zhang, H.: An effective access control scheme for preventing permission leak in android. In: International Conference on Computing, Networking and Communications (ICNC), pp. 57–61. IEEE (2015)Google Scholar
- 34.Yue, M., Robinson, W.H., Watkins, L., Corbett, C.: Constructing timing-based covert channels in mobile networks by adjusting cpu frequency. In: Proceedings of the Third Workshop on Hardware and Architectural Support for Security and Privacy, p. 2. ACM (2014)Google Scholar
- 35.Zhou, Y., Jiang, X.: Android malware genome project (2012). http://www.malgenomeproject.org
Open AccessThis article is distributed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits unrestricted use, distribution, and reproduction in any medium, provided you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license, and indicate if changes were made.