# Detecting Colluding Inter-App Communication in Mobile Environment
## 4 Experimental Analysis
### The Real-World Android Data-Set  
We built a data-set by exploiting several well-known Android application repositories, composed by malicious and legitimate Android application. In particular, for the evaluation of the effectiveness of the proposed method we take into account a set of malicious applications able to perform the _SharedPreferences_, _ExternalStorage_, _BroadcastReceiver_, and the _RPC_ colluding attacks. We consider the repositories to built the evaluated data-set as follows: the first one is represented by the _ACE_ data-set, proposed by researchers in [10]. In this paper, the authors designed a framework to generate Android colluding applications. The ACE data-set is composed of 482 different colluding applications considering the _SharedPreferences_ (160 applications), the _ExternalStorage_ (160 applications), and _BroadcastReceiver_ attacks (162 applications). In particular, each colluding attack, composed of 160 (162 for _BroadcastReceiver_) applications, considering 80 (81 for _BroadcastReceiver_) applications that perform a write on the shared resource (i.e., the PUT) and the remaining 80 (81 for _BroadcastReceiver_) perform a read on the same resource (i.e., GET). The second repository we considered was composed of 20 applications and developed by authors in [18]. Considering that the ACE data-set considered _SharedPreferences_ colluding applications sharing only string variables, in this data-set, 10 applications exploit a collusion attack through an _Int_ value, whereas the other 10 applications consider the collusion attack through a _Float_ value. With regard to the _RPC_ colluding attack, we developed a set of 20 applications (10 to send data, and the remaining 10 to receive the data) by exploiting the Remote Method Procedure. As a matter of fact, Android integrates a lightweight mechanism for Remote Procedure Calls (RPCs), where a method is called locally (for instance in an Android Activity), but executed remotely (in another process, belonging for instance to an Android Service), with any result returned back to the caller. This entails decomposing the method call and all its attendant data to a level the operating system can understand, transmitting it from the local process and address space to the remote process and address space, and reassembling and reenacting the call there. Return values have to be transmitted in the opposite direction. Android provides all the code to do that work, and in this way, the developer can concentrate on defining and implementing the _RPC_ interface itself. In the apps we developed, we consider the exchange of resources through between an Activity (i.e., an application component that provides a screen with which users can interact in order to do something) and a Service (an application component that can perform long-running operations in the background, not to provide a user interface). For data exchanging, we consider Bundles, used for passing data between various Android activities and services. The 10 applications with the Activity were able to send data (by performing a _PUT_ operation on a Bundle object), whereas the 10 applications with the Service were to able to receive the data sent (by performing a _GET_ operation on a Bundle object). With regard to the non-colluding applications, we considered the _DroidBench_ 2.0 ([[https://github.com/secure-software-engineering/DroidBench](https://github.com/secure-software-engineering/DroidBench)]([https://github.com/secure-software-engineering/DroidBench](https://github.com/secure-software-engineering/DroidBench))) repository, composed of 120 applications. This data-set did not have colluding applications, but some applications use _SharedPreferences_. This data-set is usually considered for the evaluation of taint analysis tools. Moreover, in order to evaluate the effectiveness of the proposed method in the detection of colluding attacks only, we took into account the _Drebin_ malware repository, a repository of malicious Android applications [29; 30] that do not perform collusion attacks.