# Detecting Colluding Inter-App Communication in Mobile Environment
## 1 Introduction
We propose an heuristic function that reduces the number of candidate applications to the analysis. The function is defined based on the \(\mu\)-calculus temporal logic and model checking. In this work, we focus our attention on different ICC, in particular: _SharedPreferences_, _ExternalStorage_, _BroadcastReceiver_, and _Remote Procedure Calls_ (RPC). This kind of communications can be used to launch an attack, as follows:  
* with the _SharedPreferences_, it is possible to store key-value pairs of data, configuration, and preferences. So an application can save some settings (containing data information) into a shared preference file, which could be read by the receiving application;
* with the _ExternalStorage_, we consider the ability to store the information in a file. In this case, for example, an application can read data and send them to a second application via an intent. The second application, using the external storage, can send the data though an external network (for instance, Internet);
* with the _BroadcastReceiver_, it is possible to be notified of an event occurrence at the system level (e.g., receiving an SMS). It is useful for the instant management of special events. Broadcast receivers respond to broadcast messages sent using Intent objects, which can come from the same application or from others applications installed on the device. So, with this component, it is possible to have applications that receive data both via broadcast receivers and SMS messages [10];
* with the _RPC_, it is possible for an Android application to call a method to execute in a different address space (typically on another Android application), which is coded as if it were a normal (i.e., local) procedure call, without the developer explicitly coding the implementations for the remote interaction: the developer writes the same code whether the subroutine is local to the executing application or remote. Android provides several distinctive components, for instance, Activity and Service, which are able to perform this kind of communication by also sharing data between these components. In this attack, the collusion happens when an Android component (for instance an Activity) starts a component in another application (by invoking a Service in the second application) by also sharing data between the Activity and the Service components. We chose ICC attacks since they are the most common ones used to launch colluding interactions, as demonstrated in [14; 15; 16; 17]. The detection of colluding behavior in the Android environment, by exploiting model checking, was already explored by the authors of [18]. Below, we itemize the main points introduced in this paper with respect to the work in [18]:  
* in this paper, we consider the detection of four colluding attacks (i.e., _SharedPreferences_, _ExternalStorage_, _BroadcastReceiver_, and _RPC_) whereas the work in [18] focused only on the _SharedPreferences_ colluding attack. This represents the main contribution of the work and, at the best of knowledge authors, this is the first contribution devoted to the detection of these four different harmful colluding attacks;
* we propose an algorithm for the automatic detection of collusion. The authors in [18] propose a set of manually designed properties for the detection of _SharedPreferences_ collusion. In this work, we propose an algorithm for the automatic generation of properties for the detection of whether two or more applications are performing a colluding attack through _SharedPreferences_, _ExternalStorage_, _BroadcastReceiver_, or _RPC_;
* the proposed method can also detect colluding attacks performed by more than two applications, whereas the method in [18] can detect collusion between only two applications.