# Detecting Colluding Inter-App Communication in Mobile Environment
## 1 Introduction  
The growing technological development of recent years and the evolution of communication devices have changed our daily habits. The introduction of smartphones and tablets in our lives has allowed greater globalization, in fact, anyone can access the same information at the same time, thus reducing cultural differences and barriers. However, the technology spread too fast due to the possibility of buying models of smartphones (or tablets) of medium-high quality at affordable prices but also allowing users to download many applications freely. As result of this rapid spread, users have not had adequate \"training\" for the correct use of devices. People use smartphones without thinking about the problems related to their use, because these devices handle data of different types everyday, among which, we have personal information, the principal target of cybercriminals [1; 2]. Among the various operating systems for the mobile environment, the most popular is Android. Android is widespread and has an \"open nature\", allowing attackers to hit a significant amount of users quite easily [3; 4]. On mobile devices powered by the Android operating system, it is possible to download applications of various kinds and with different functionalities. Usually, people consider the official marketplace (for instance, Google Play in the Android environment) when attempting to download desired applications, but sometimes, they use unofficial markets (for instance, AppChina) to obtain applications for free, which usually require payment on the official store, or users will install applications not available on the official Android market [5]. In most cases, third-party markets turn out to be untrustworthy [6]; however, we can find infected applications even in official markets [7]. In this scenario, there are two main actors: the _attackers_, characterized by cybercriminals who implement malicious code to attack users and steal their information, and the _defenders_, characterized instead by creating tools, usually called anti-malware, that are able to detect the presence of threats [8]. Anti-malware applications, however, are unable to identify new threats, since recognition can only take place if the information about the threat is already known and stored in their repository [9]. In order to increase the complexity of the malicious payloads (i.e., the code aimed to perform the harmful action) and thus be capable of evading anti-malware programs, the malware writers developed a new threat called _Colluding Attack_. A colluding attack consists of dividing the malicious action between two or more applications. In this way, the anti-malware, analyzing any single application will not able to identify the potential threat, since it is the communication between these applications that will launch the attack. The attack occurs in the following way: we have two infected applications that communicate with each other when the user performs a certain action or when an event occurs in the system. The first application reads the user's sensitive data and then sends them to the second one, which then transmits them to a 3 rd party. We can deduce that the first application has the permission to read the data, while the second one has the permission to connect to a network, thus sharing the information. In the Android environment, the applications may communicate through the Inter-Component Communication (ICC): this mechanism is useful for the developer by allowing functionality reuse [10]. The presence of this mechanism means that applications are not always independent from each other, because the inter-application collaboration expects an information exchange between components belonging to the same application or to different applications [11]. The second possibility mentioned can be used by malicious applications to attack users' data [12; 13]. To detect and verify the presence of colluding applications on Android, we developed a method based on the use of model checking techniques [9].