# Detecting Colluding Inter-App Communication in Mobile Environment
## 3 Colluding Inter-App Communication Detection  
In this section, we present the proposed method for the detection of Android-based colluding applications. We remark that our proposal represents the first method designed for the detection of different kinds of colluding attacks: _ExternalStorage_, _SharedPreferences_, _BroadcastReceiver_, and _RPC_. Figure 1 shows an overview about the proposed approach. We began our investigation with an Android _Device_, where the installed applications are gathered by obtaining the APKs at the _/data/app_ url in the device internal memory that is possible to read without root permission [23]: the permissions on that directory are _rwxrwx-x_. The APK extension indicates an Android Package file. This file format, basically a variant of the JAR file, is considered for the distribution and installation of bundled components on the Android mobile platform [24]. The APK contains all the resources for the application running, for instance, external libraries, images, audio, and the set of.class files of the application, stored in the _classes.dex_ file, in a format translated for Dalvik, the Android virtual machine. Once we obtain the APKs of the _Installed Applications_, through a reverse engineering process, we obtain the Java bytecode for each APK. We obtain the Java bytecode representation for each method of Android applications by invoking the _dex2 jar_ ([[https://github.com/pxb1988/dex2](https://github.com/pxb1988/dex2) jar]([https://github.com/pxb1988/dex2](https://github.com/pxb1988/dex2) jar)) tool to obtain from the classes.dex file (the executable file targeting the Android virtual machine) the jar one (the executable targeting the Java virtual machine), and the Byte Code Engineering Library (BCEL) ([[https://commons.apache.org/proper/commons-bcel/](https://commons.apache.org/proper/commons-bcel/)]([https://commons.apache.org/proper/commons-bcel/](https://commons.apache.org/proper/commons-bcel/))), to obtain the classes stored in the.jar file their Java bytecode representations. We consider the Java bytecode because is already possible to obtain even the APKs were obfuscated [25; 26; 27; 28], for instance, using the R8 compiler built-in in the last Android studio release ([[https://developer.android.com/studio/build/shrink-code](https://developer.android.com/studio/build/shrink-code)]([https://developer.android.com/studio/build/shrink-code](https://developer.android.com/studio/build/shrink-code))), providing a kind of obfuscation to shorten the names of the classes and methods, but also optimization techniques that can make the code more difficult to read, applying aggressive strategies to reduce the size of the developed application. Once we obtained the Java bytecode related to the installed APKs, we generated a model for each application (i.e., _Automata Generation_ step in Figure 1). In the following, we explain how we generate the automata. We considered a CCS model for each method of the APK. This is obtained by translating each Java bytecode instruction in a CCS process. The precise definition of the translation can be found in [6; 7]. With regard to the sequential Java bytecode instructions, the translation is the following:  
\[proc\ x_{current}=opcode.x_{next}\]  
where \(x_{current}\) represents the current instruction under analysis, whereas \(x_{next}\) is the process representing the successive instruction and finally, \(opcode\) is the name of the Java bytecode instruction. Note that to express constant definitions we use the syntax of the Concurrency Workbench of New Century [20], the formal verification environment used for the experimentation. Thus, instead of \(x\stackrel{{\text{def}}}{{=}}p\) we write \(proc\ x\ =\ p\). An example of CCS translation from the translation of sequential op-code instructions is shown in Listings 1 and 2. Figure 1: The proposed approach for colluding application detection. ```
procP1=store.M2 procP2=load.M3 procP3=return.nil
```  
Listing 2 CCS process for Listing 2.