# Detecting Colluding Inter-App Communication in Mobile Environment
## 4 Experimental Analysis
### The Real-World Android Data-Set
We chose 10 malware belonging to the top 10 malicious families in the data-set for a total of 100 non-colluding malware, as shown in Table 8.  
We also considered, as malicious samples, a set of 50 ransomware samples, obtained from the Android Malware Dataset (AMD) ([[http://amd.arguslab.org/](http://amd.arguslab.org/)]([http://amd.arguslab.org/](http://amd.arguslab.org/))) repository: in detail, we considered samples belonging to the Simpelocker malicious family, whose payload is able to encrypt files with several extensions on the device external storage and then demand a ransom (usually in bitcoin) to decrypt the data. We also considered a set of 300 trusted applications obtained from the official store of Google i.e., the _Play_ store. These applications were automatically collected from Google Play ([[https://play.google.com/store](https://play.google.com/store)]([https://play.google.com/store](https://play.google.com/store))), by using a script to query and to download applications from Android official market. In order to confirm the trustworthiness of these 260 applications, we analyzed the data-set by exploiting the VirusTotal service ([[https://www.virustotal.com/](https://www.virustotal.com/)]([https://www.virustotal.com/](https://www.virustotal.com/))). This service runs 60 different antivirus software (e.g., Symantec, Avast, Kasperky, McAfee, Panda, and others) on each application: the output confirmed that the trusted applications included in the legitimate data-set did not contain malicious payload. To summarize, we consider a total of 1092 applications, 792 (colluding and non-colluding) malicious applications and 300 legitimate applications. The data-sets considered are composed of different types of attacks analyzed in this paper, these attacks can be colluding or non-colluding. The applications were analyzed in pairs: an application with properties of PUT was analyzed with an application with properties of GET, by going to check whether there is a collusion. In Table 9, we can see how the applications that communicate with each other through the use of Android resources were divided, so as to have a clearer picture of which applications our Model Checker has classified as colluding. \begin{table}
\begin{tabular}{c c c c} \hline \hline
**Family** & **Inst.** & **Attack** & **Activation** \\ \hline Fakelnstaller & s & t,b & \\ DroidKungFu & r & t & boot,batt,sys \\ Plankton & s,u & t,b & \\ Opfake & r & t & \\ GinMaster & r & t & boot \\ BaseBridge & r,u & t & boot,sms,net,batt \\ Kmin & s & t & boot \\ Geinimi & r & t & boot,sms \\ Adrd & r & t & net,call \\ DroidDream & r & b & main \\ \hline \hline \end{tabular}
\end{table} 
Table 8: Malware families in the _Drebin_ data-set. We selected the 10 most populous families in this repository, for a total of 100 non-colluding malware (10 samples for family). We indicate in the _Inst_. column the payload delivering (standalone, repackaging, and update), in the _attack_ column the kind of attack (trojan and botnet) and in the _Activation_ column the operating system events triggering the malicious payload. \begin{table}
\begin{tabular}{l c c} \hline \hline
**Type of Attack** & **PUT** & **GET** \\ \hline _SharedPreferences_ & 90 (80 String, 5 Int, 5 Float) & 90 (80 String, 5 Int, 5 Float) \\ _ExternalStorage_ & 80 & 80 \\ _BroadcastReceiver_ & 81 & 81 \\ _RemoteProcedureCall_ & 10 & 10 \\ \hline \hline \end{tabular}
\end{table} 
Table 9: We find the three types of attack treated in this work, and for each of them we have the number of PUT applications and the number of GET applications. In particular, for the _SharedPreferences_, we report the division of the application number by type of resource.