# Malware Collusion Attack against SVM: Issues and Countermeasures
## Background
### Android Background
#### 2.1.2 Inter-App Communication Channels  
Android OS allows Apps to communicate in a variety of ways. The article [18] has investigated the overt and covert channels that may be used in communication. The overt channels include _Unix Socket Communication_, _Internal/External Storage_, _Intent Communication_ and _Shared Preference_. The covert channels include _Processor Frequency_, _Threads Enumeration_, _Reading /proc/stat_, etc. In our work, we only focus on the overt channels and here we only briefly introduce the two main overt channels that we concern, namely _Intent Communication_ and _Shared Preference_. **Intent Communication** is the communication channel among components within the Android system. It is also called Inter-Component Communication--ICC for short. It means that the components could communicate with each other through _Intents_. _Intents_ are messages that are sent among the three other components. _Intents_ can be sent explicitly or implicitly, which are named _Explicit Intents_ and _Implicit Intents_ separately. An Intent being explicit means its target package name and class name are specified. When these kinds of Intents are issued, the targeted components will be launched by the system. Typically, _Explicit Intents_ are used to connect the component within an app. However, malware can abuse them by sending them to other applications. In this case, malware can directly launch other applications' exposed components. In the next section, we will present an example to express how it was abused by malware. Unlike _Explicit Intents_, _Implicit Intents_ do not name any specific components but instead declare the functionality that they desire for their target. The desired functionality is described by three items:* An _action_ string specifies the generic action to perform. Usually, an app specifies action constants defined by the system _Intent_ class or other framework classes. However, an app can also specify their own actions. In this case, malware could specify their own unique action string to launch a particular component. * A category string containing additional information about the kind of component that should handle the intent. For example, \(CATEGORY\_APP\_GALLERY\) category indicates that the intent should be delivered to a gallery application. The target activity should be able to view and manipulate image and video files stored on the device. * A set of data fields specifies data to be acted upon or the Multipurpose Internet Mail Extensions (MIME) type of that data. The type of data supplied is generally dictated by the intent's action. For example, if the action is \(ACTION\_EDIT\), the data should contain the URI of the document to edit. If a component wishes to receive implicit Intents, it has to declare _Intent Filters_, which describe the attributes of the Intents that they are willing to receive. Each component can declare one or more intent filters. Each intent filter specifies the type of intents it accepts based on the intent's action, data, and category. Components have an exported attribute. When this attribute is set to _True_, the component will become accessible by other applications through ICC. Components that are not exported are only accessible by the components within the same application. Matching Intents with their target is done by the operating system during an _Intent resolution_ process. In the next section, we will describe how to perform a malicious operation through ICC, which can not be detected by current detection methods easily. **Shared Preference** is built-in key-value storage in Android. If we have a relatively small collection of key-values that we would like to save, we should use the _SharedPreferences_ Application Programming Interfaces (APIs) [19]. We can create a new shared preference file or access an existing one by calling _getSharedPreferences()_; then the shared preference file will be created or opened.