Do not jail my app: Detecting the Android plugin environments by time lag contradiction

Android apps typically contain many components such as Activity, Service, Broadcast Receiver and Content Provider, and run on top of the Android framework [3]. When an Android app (or an APK file) is installed on a device, the Android system maintains some records about the app and the registered components defined in AndroidManifest.xml. Such records are useful when the framework launches the app or one of its component, for instance, starting a new activity for editing emails in a mail app. Without installing an app means the corresponding records are missing and the Android framework is not able to discover the components within the app as they are not registered. The plugin technology addresses this issue, making it possible to run the apps not installed on the Android system, even if the Android framework does not know the existence of the guest app.

We examined the two open-source Android plugin frameworks, DroidPlugin [13] and VirtualApp [39], to figure out how they play tricks on the Android system and successfully execute guest apps. Figure 1 demonstrates the overview of the plugin technology. In general, the host app, which embeds a plugin framework, is installed on a device as a normal app. The embedded plugin framework provides the ability to manage the plugin apps and hook necessary API invocations. Besides, the plugin framework contains a special AndroidManifest.xml, which defines lots of stub components. The stub components are registered to the system as the host app installation. When launching an app or a component, the plugin framework hooks the interactions between the guest app and the Android framework, requesting the system to launch a stub component instead. The system checks succeed as the stub component has been registered, but subsequent operations are interfered by the plugin framework via hooking, replacing the stub component with the target component.

OPEN IN VIEWER

Fig. 2.

Launching an activity in Android.

For example, as shown in Fig. 1, when an activity A in the plugin app is trying to start another activity B via startActivity(), the invocation falls into the hooking module, which requests the Android framework to launch a stub activity S. The Android framework performs some checks and then notifies the plugin process to instantiate and start S. The hooking module hijacks the response, and launches the original target activity B through the reflection mechanism. The Android framework does not interact with the plugin app directly, but with the help of the plugin framework, the graphical user interface associated with A is successfully transited to that for B.

In order to avoid the interference among different guest apps, the host app and each guest app usually run in different processes. However, since the Android sandbox mechanism prevents users – in most cases, each app is assigned an unique uid – from accessing resources of other users [4], in order for the plugin framework to interleave the execution of a guest app, they share the same uid. Hence, the sandbox mechanism is evaded and this allows the host app to access all resources and information associated with the guest apps, either public or private. Risks appear as adversaries can leverage this feature to steal the user’s privacy data, as done in DualTwitter [35], or perform many other unexpected behaviors [45].

We omit the implementation details of how the plugin environment loads specific classes and resources from a plugin app [23]. For our paper, we describe the conceptual workflow of launching an activity, which motivates our solution for detecting the plugin environments.

Figure 2 illustrates the normal flow of launching an activity in Android. When an activity A tries to launch another activity B, it invokes an API like startActivity() and sends an Intent message to Activity Manager Service (a.k.a., AMS) via Binder, the Android-specific inter-process communication mechanism [2]. Once the request arrives, AMS, running in the process system_server, performs a series of checks, for example, checking whether the target activity B has been registered to the system. AMS also deals with the management of activity stacks and tasks. Typically, after pausing the top activity A, AMS sends a LAUNCH_ACTIVITY message to the app process. A callback handleLaunchActivity() responds the message. The app process instantiates the target activity B and executes the corresponding functions, switching the user interface. It is notable that, if B is declared to be launched in a new process (with “android:process” property in its declaration), AMS notifies the system to fork a new process. The app’s Application is then initialized within the new process, and afterwards, similar activity instantiation and execution are done.

The above workflow fails when the app is indeed a guest app running in a plugin environment as the app is not installed and the target activity B is not known to the system. AMS checks fail if the Intent message is directly sent to AMS. The plugin technology introduces “component replacement” to bypass the AMS checks. As mentioned earlier, the plugin environment defines many stub components in AndroidManifest.xml and registers them to the system when installing the host app. When a plugin component is about to be launched, the host app creates a new Intent wrapping a stub component, which is sent to AMS. Without loss of generality, we depict below how a host app launches an activity in the plugin app.

OPEN IN VIEWER

Fig. 3.

Launching an activity in the same process (extra code in grey).

OPEN IN VIEWER

Fig. 4.

Launching an activity in a new process (extra code in grey).

In real-world Android apps, most activities are launched in the same process. Figure 3 illustrates how to launch a plugin activity B within the same process. We aggregate the injected operations into two grey areas ( 1 and 2). The hooking module, once receiving a request for launching an activity, replaces B with a stub one, say Stub01, which is defined in AndroidManifest.xml of the host app, and wraps a new Intent to AMS. After AMS checks succeed, the hijacked callback provided by the plugin environment replaces the wrapped Intent with the original one and launches B.

Figure 4 shows the flow of launching a plugin activity C in a new process. The procedure before AMS responds is nearly the same as that in Fig. 3. But when AMS checks succeed, a new process (pid_3) is created, within which the guest app’s application needs to be initialized. However, as the system cannot see the plugin app, it initializes the host app’s application, which prepares the plugin environment for the new process. Then the plugin environment initializes the guest application, unwraps the replaced Intent and uses the original one to start the actual target C. Essentially, three extra phases are injected to the flow ( 3, 4 and 5).

Luo et al. present Plugin-Killer [23], a lightweight defense mechanism, to prevent Android apps from being launched as plugin apps. Embedded within normal apps, it can detect the existence of plugin environments and terminate the enclosing apps if needed. The intuition behind Plugin-Killer is that, when an app is running as a plugin, there are definitely some differences in the running environment with the one created by system. Hence, Plugin-Killer collects and compares certain information with the counterpart under system environment. Any inconsistency indicates that the app is running in plugin environments. Below we will discuss the methods proposed by Plugin-Killer and show why they are not resistant to attacks.

By introspecting the code of Plugin-Killer, we find four types of information are collected in detection, the process name, the component name, the private directory path and the permission information (see the first column in Table 1).

For the process name, Plugin-Killer obtains all the running processes that share the same uid with itself, and checks their names. Generally, a process’s name contains the package name of the corresponding app. However, in plugin environment, the host app process is also running with the same uid, so Plugin-Killer can detect the existence of the host app that has a different process name. The component name checking is conducted in a similar way. In plugin environments, the name of a plugin component will be the stub component name defined in the host app. For example, a service AntiCheckMainService launched by Plugin-Killer will have a name of ServiceStub$StubP01$P00 due to the “component replacement” introduced by the DroidPlugin framework. Plugin-Killer considers the running environment as a plugin environment if it finds a wrong name of a component. In addition, since a plugin app is not installed by the system, it does not have its own private directory which is generally located in /data/data/{package_name}/. All the file accesses will be redirected to another directory owned by the host app. For example, DroidPlugin creates a separate directory located in /data/data/{host_app_package_name}/Plugin/{plugin_app_package_name}/data/ as the private directory of each plugin app. If the private file path does not start with “/data/data/{package_name}/”, Plugin-Killer terminates the app’s running. Moreover, in Android, apps need to declare specific permissions to do some sensitive operations, such as sending SMS. To successfully execute arbitrary guest apps, host apps tend to declare quite a lot of permissions, generally much more than what a plugin app requires. To detect plugin environments, Plugin-Killer checks if an undeclared permission is granted at runtime. If so, it indicates that the app is running as a guest because the host app have declared the unexpected permission.

While the proposed approaches can be effective to some extent, they can be easily bypassed by the plugin environments. To collect such running environment information, some specific Android APIs are invoked by Plugin-Killer. Table 1 lists the APIs to obtain the information under the system environment and the DroidPlugin environment. Suppose the package name of the host app and the plugin app are com.example.hostapp and com.example.testapp, respectively. As described in Section 2.2, the startActivity() API is hijacked by the plugin environment to launch the plugin’s activity. Similarly, the APIs in Table 1 can also be hijacked. When Plugin-Killer invokes these APIs, the plugin environment modifies their return values and replays them with the values under the system environment. Take the component name as an example. After the plugin environment gets the actual return value of ActivityManager.getRunningServices(), it extracts the stub component name and finds the original target component of the plugin app. Then, the plugin environment initializes a new object based on the target component and returns it to the plugin app. Plugin-Killer cannot distinguish the system environment and the plugin environment if all the information in Table 1 are replayed in such ways. In other words, Plugin-Killer is not robust enough to defend the real-world plugin technology. We also empirically evaluated the attacks with an implementation on top of DroidPlugin and all of the defense techniques provided by Plugin-Killer are successfully bypassed.

3.1. Threat model

PluginAssassin is designed to detect whether an app is running in a plugin environment. Considering the nature of attack-defense countermeasures, we cannot expect to solve the problem once and for all. Therefore, we assume the plugin environment has the following capabilities:

The first requirement relaxes the restriction, which invalidates the Plugin-Killer solutions as we discussed in Section 2.3. Though it gives the plugin environments the best ability to interfere the guest app, we think the major purpose of a plugin environment is to run Android apps as usual instead of running into crashes or malfunction. As a consequence, in this paper, we require the plugin environments to preserve the utilities of guest apps. The second assumption limits the ability of the host app to interpose other apps and the kernel’s running.

3.2. Road to success

Recall the flow of launching a plugin activity in Fig. 3 and Fig. 4. Apparently, the extra embedded functionalities, such as component replacement for both scenarios ( 1, 3, 4 and 5) and plugin environment preparation for inter-process launching ( 2) cost additional time compared with the normal flows of launching an activity. The keyword in our observation is “time” – the time is a potential property to distinguish the system environment and the plugin environment.

At first, we try to get clues from the absolute time an interesting operation consumes. We represent the time period from invoking startActivity() to entering onCreate() in the target activity as T s p and T n p , respectively for intra-process and inter-process scenarios. We use T i ( 1 ⩽ i ⩽ 5 ) to denote the time cost of the ith numbered block in Fig. 3 and Fig. 4. Moreover, T S and T N , separately for the two types of activity launching, express the sum of the time required by all other events than the embedded code, such as executing the plugin app’s own code, process scheduling, and so on. We have the following equations: (1) T s p = ∑ 1 ⩽ i ⩽ 2 T i + T S , T n p = ∑ 3 ⩽ i ⩽ 5 T i + T N .

We are able to measure T s p and T n p via APIs like currentTimeMillis(). However, we do not have oracles about the precise and tight ranges of T S and T N . Many factors can affect their values, for example, different hardwares, different Android releases, and even different system states at runtime. The uncertainty of time measurements makes it impossible to devise a technique utilizing the absolutely elapsed time of the procedures.

Later, we discovered that APIs like clock_gettime() allow apps to obtain the real CPU time for current process (e.g., the new process) or even a thread in the current process (e.g., the main thread launching an activity). Even though scheduling, AMS and any other out-of-process effects are excluded, the problem still exists as we cannot determine a proper threshold which limits how long a target operation or procedure can take at most. We know that even the same piece of code can cost different time in different situations. One threshold does not support the detection in arbitrary devices but app developers are unable to learn many thresholds for all situations.

While the absolute time doesn’t help, we turn our mind to the relative time. Our research question emits: “Can we compute such a time ratio of two procedures, satisfying that: (1) at least one procedure involves the code injected by the host apps in plugin environments, i.e., activity launching, and (2) the ratios for different situations are well distributed such that a simple threshold can easily separate those for system environments and plugin environments?”

To answer the question, we conducted some pilot studies and collected amounts of data, which shed some light on the situation, enlightening us to propose an approach based on the observation of the time lag contradiction.

3.3. Time lag contradiction

As we discussed previously, the plugin environment introduces extra code for both intra-process and inter-process activity launching during the guest app’s execution, which prolongs the time consumption. We observed that the plugin environments do not impose proportional time overhead on the two activity launching scenarios. Formally, we have: (2) T s p ( plugin environment ) T s p ( system environment ) ≉ T n p ( plugin environment ) T n p ( system environment ) . We call it the time lag contradiction, which can be used as an indicator of the environment identification. Given the fact that an app cannot measure the time for both system environment and plugin environment in the meantime, we convert the inequation to: (3) T n p ( system environment ) T s p ( system environment ) ≉ T n p ( plugin environment ) T s p ( plugin environment ) . Now, either side denotes a time ratio and is measurable during one execution.

For intra-process launching, we use T s p to denote the CPU time for merely the app’s main thread, from invoking startActivity() to entering onCreate(), covering both T 1 and T 2 . We are unable to intercept the procedure, as from the guest app’s point of view, only these two locations are visible for gathering the timestamps. For inter-process launching, startActivity() is invoked in process pid_2 while onCreate() is executed in process pid_3, as shown in Fig. 4. To simplify the time data collection, we record the elapsed CPU time when the app is initialized in the new process, namely, within the constructor of the app’s Application class, notated as T n p , merely T 4 for the embedded functionalities included. Only some process initialization and the plugin environment preparation affect the value. By this means, we exclude the influence of different app implementations, only taking into account the environmental part that the app developers cannot control. We compute the ratio R as follows: (4) R = T n p T s p which, according to our observations, shows significant difference under plugin environments compared to that under system environments.

Table 2 shows the experimental results of running a simple demo app in a system environment and two plugin environments powered by DroidPlugin and VirtualApp separately, three times for each. The experiments are all conducted on an OPPO A37m smartphone with Android 5.1 running. The observed results clearly satisfy our anticipation of the time lag contradiction. T s p in plugin environments exceeds that in system environment by at most 42%, and the optimization in VirtualApp makes the difference much smaller. However, T n p is at least seven times bigger in plugin environments than in system environment. Using T ◇ to represent the time in the plugin environments and T ⋆ to denote the time in the system environment, for all the observed ( T s p ◇ , T n p ◇ ) and ( T s p ⋆ , T n p ⋆ ) , the following formula always holds: (5) ∃ α ⩾ 6 , β ⩽ 0.5 , T n p ◇ > T n p ⋆ + α T n p ⋆ , T s p ◇ < T s p ⋆ + β T s p ⋆ ⇒ T n p ◇ T s p ◇ > T n p ⋆ + α T n p ⋆ T s p ⋆ + β T s p ⋆ > T n p ⋆ T s p ⋆ . Our goal is to choose a desirable threshold R b that satisfies: (6) ∀ ( T s p ◇ , T n p ◇ ) , ( T s p ⋆ , T n p ⋆ ) , T n p ◇ T s p ◇ > R b > T n p ⋆ T s p ⋆ . According to Table 2, we can simply set R b = 1 , which perfectly differentiates the system environment from two plugin environments. We will show in Section 4.3 how to scientifically determine R b for real-world Android apps and evaluate its effectiveness in other devices as well as in many other plugin environments.

While the preliminary results show the feasibility of our time lag contradiction approach, it suffers from a simple attack that can be easily implemented. Due to the hooking capability, the hooking module provided by plugin environment can modify the return value of time acquisition APIs after a hooked functionality is done, by subtracting the time consumed by the injected code from the actual value. The plugin environment developers are able to measure T i that stands for the increment of the execution time. We denote the corresponding increments as Δ T s p = T 1 + T 2 and Δ T n p = T 4 . If a plugin environment collects these values and interferes the APIs, we get in the plugin environment that: (7) R ′ = T n p ′ T s p ′ = T n p ◇ − Δ T n p T s p ◇ − Δ T s p ≈ T n p ⋆ T s p ⋆ , where T ′ denotes the intervened time value, T ◇ represents the actual time not modified in the plugin environment and T ⋆ expresses the corresponding time in the system environment. As a plugin activity launching consists of the normal launching procedure plus the injected behaviors, it is reasonable to presume that T ⋆ ≈ T ◇ − Δ T . As a result, the above formula indicates that with a simple interference, the plugin environments can bypass our detection because the ratio in plugin environments approximates that in system environments. We call this threat the Δ T attack. The left part of Fig. 5 conceptually shows how a Δ T attack is performed in a plugin environment.

OPEN IN VIEWER

Fig. 5.

Intra-process Δ T attack and detection.

To mitigate the Δ T attack, we adopt a probing strategy to verify the authenticity of T s p and T n p . If either is considered fabricated, we say a Δ T attack happens, which further infers that the app is currently running as a guest app and should be terminated immediately. Our Δ T mitigation mechanism assumes that each Δ T is only visible to the process that calculates it. Namely, it won’t be transferred to other processes. Otherwise, the Δ T attack can be devised elaborately and intricately to be more difficult to resist.

As shown in Fig. 5, a probe thread, is started before startActivity(), running along with the testing thread that launches an activity until the elapsed time is collected. The probe thread launches a series of requests to acquire the CPU time of the testing thread via clock_gettime(). The interval H between every two adjacent requests is smaller than a typical Δ T . Generally, we claim that (8) t i + 1 = t i + H , where t i denotes the ith time request. Once a Δ T attack occurs, i.e., the plugin environment camouflages the time value by subtracting Δ T from the actual time value, the following formula is satisfied given that H < Δ T : (9) ∃ j , t j + 1 ′ = t j + 1 − Δ T = t j + H − Δ T < t j in which t ′ represents the interfered time and t denotes the actual value. Both t j + 1 and t j are observed by the probe thread. Such a case violates the natural law in a timeline, so upon its occurrence, we can directly report the existence of a Δ T attack in intra-process launching and terminate the running app.

However, this time-probing method fails in the inter-process launching scenario, because the system call clock_gettime() does not support to acquire the CPU time of other processes. A feasible method to judge the validity of T n p is to compare T n p with the execution time collected from the proc file system. Given a process ID, a specific record file located at “/proc/{pid}/stat” provides two fields, utime and stime, illustrating the scheduled time of the process in user mode and kernel mode respectively. The sum of these two values approximates the execution time of the process. It is notable that utime and stime are measured in jiffies (or clock ticks), so before the comparison, we convert the tick numbers to general time values that are measured in nanoseconds using the following transforming relationship: (10) T proc = N user + N sys H Z × 1 000 000 000 , where T proc stands for estimated CPU time of the process, N user and N sys denote the clock ticks in utime and stime. Moreover, HZ is a constant value representing the number of ticks per second, which is 100 in Android.

The probe thread behaves differently to an inter-process scenario. It is created in the main process right after startActivity() and iteratively queries the system for the PID of the new process based on its process name that is predefined in AndroidManifest.xml. Although this phase involves some Android APIs that can also be hijacked, in order to preserve the utility of the guest app, the actual PID is returned generally. Once the PID is obtained, the estimated execution time T proc of the new process can be calculated based on the observed utime and stime. At this moment, the new process has not reached the point of collecting T n p , leading to a smaller T proc than T n p . However, it serves as a reasonable indicator to verify T n p as our experiments and inspection of the plugin environment implementations show that most jobs have been finished before the plugin environment replaces the stub activity process name with the target activity process name. The replacement lets the probe thread be able to query the PID with the process name and soon after that, the point of collecting T n p is reached. Thus, T proc is generally slightly smaller than an unmodified T n p .

Because of the invisibility of Δ T n p to the main process, the plugin environment cannot forge T proc into a rational value. If a plugin environment implements the Δ T attack in the new process, a huge increment (a.k.a. Δ T n p ) is subtracted from T n p , based on the observations of Table 2. A satisfiable relationship T n p ′ < T proc indicates the existence of a Δ T attack in the inter-process launching.

If neither Δ T attack is detected, we consider the collected time values, T s p and T n p , not counterfeited and then apply them for plugin environment detection.

So far, we have not found any plugin environment implementing the Δ T attack. To verify the validity of both the attack and defense approaches, we conducted two pilot experiments and present the results in Section 4.1.

We present PluginAssassin to implement the time lag contradiction detection technique, with the Δ T mitigation mechanism equipped. According to above discussions, we show the complete flow diagram in Fig. 6.

OPEN IN VIEWER

Fig. 6.

Flow of PluginAssassin.

Conceptually, the intra-process and inter-process procedures can run in parallel. To reduce the impact of any noise as much as possible, we choose to collect multiple time values and finally compute the ratio with their averages. We define in the diagram the iterations of collecting time data as N and the ratio threshold as R b . And at the beginning, we initialize two empty sets S s p and S n p for keeping the multiple records of time values, for intra-process and inter-process scenarios separately.

For intra-process launching ( 2 ∽ 5 ), a probe thread is created, followed by the activity launching. After the activity is started, PluginAssassin calculates T s p i , the consumed time of the ith collection. If any Δ T attach is detected according to our defense mechanism, the app is directly terminated. Otherwise, PluginAssassin puts T s p i into S s p .

For inter-process launching ( 2 ′ ∽ 5 ′ ), we start a probe thread and try to start an activity in a new process. Within the probe thread, we iteratively query the PID of the new process, which allows PluginAssassin to obtain the jiffies of the new process and calculate T proc i . T n p i is collected in the new process and the probe thread is stopped. If no Δ T attack is found, T n p i is inserted into S n p .

The above steps are repeated for N rounds and the averages of S s p and S n p are computed as T s p and T n p respectively. Then PluginAssassin calculates the ratio R and compare it with the given threshold R b . A larger R indicates a plugin environment, so the app is terminated. Otherwise, we think the app is not running as a plugin app and thus the app continues running.

As mentioned in Section 3.4, we conducted two preliminary experiments on some demo apps with the OPPO smartphone to show the power of a Δ T attack and the effectiveness of the defense mechanism.

In the first experiment, we prepare two plugin environments. Both are powered by DroidPlugin, one unchanged and the other roughly instrumented with the Δ T attack technique. The demo app is equipped with the naive time lag contradiction detection but without the previously mentioned Δ T defense mechanism. From Table 4, we see that without the Δ T attack implemented in DroidPlugin, the system environment and the plugin environment can be easily differentiated with the ratio comparison (0.681 versus 4.205), similar with the results in Section 3.3. But when DroidPlugin is augmented with the Δ T bypassing mechanism, the demo app generates a relatively low ratio (0.765), close to that for the system environment (0.681) but far away from the one for the pure plugin environment (4.205). We are not confident to distinguish the plugin environment from the system environment in this case.

OPEN IN VIEWER

Fig. 7.

Preliminary Δ T attack results.

The second experiment tests whether the Δ T defense can be effective. We equip the demo app with the defense technique and run it in the instrumented DroidPlugin. For the intra-process scenario, we simulate the interval H with an empty 10 000-loop, about 50 microseconds in the experiment. Figure 7 shows the time values of the testing thread acquired by the probe thread. We see an obvious declining, more than 13 milliseconds, from t 1196 to t 1197 , indicating the existence of a Δ T attack. For inter-process activity launching, we dump T proc and T n p acquired in the main process and new process separately. In this experiment, when a Δ T attack happens in the new process, the fetched utime and stime are 32 and 7, meaning that the collected T n p should be around and in most cases at least 390 milliseconds. However, the obtained value in the new process is about 50 milliseconds, resulting in an apparent inconsistency between T proc and T n p .

By far, the effectiveness of the Δ T attack and the corresponding mitigation approach are well demonstrated.

To evaluate the capability of PluginAssassin to detect plugin environments, we chose five popular social apps, WeChat [41], Twitter [37], Instagram [18], WhatsApp [43], and LINE [22], to deploy PluginAssassin, and ran them in plugin environments. These social apps have hundreds of millions of downloads on Android app stores. However, because of the limitation of simultaneous login to multiple user accounts in one device, they become the first targets of multi-instance apps.

We repackaged the social apps with PluginAssassin. Figure 8 shows how PluginAssassin is integrated into social apps. First, for each social app, we obtain its original APK file and unpack it with ApkTool [5], generating smali files for all classes. We declare two additional activities SPActivity and NPActivity in its AndroidManifest.xml, for intra-process and inter-process launching separately. In addition, we inject a shared library file (libdetector.so) to implement the timestamp acquisition and time overhead calculation in native code. Because PluginAssassin requires N iterations to balance the collected time values (see Section 3.5), we disperse the operations of starting the testing activities into several existing activities of the social apps. We set the number N of iterations to 5 for all following experiments, as we have observed in earlier experiments on the demo app that, five iterations will not introduce high overhead but are enough to capture the timing characteristics of different types of activity launches, even after eliminating the outlier data.The app developers can choose an app-specific N when adopting our approach. During each test for a social app, for the reason that missed cache of the target activity can result in higher time cost for the first launch than the rest in the demo app experiments, we discard a pair of outliers, typically a maximum value and a minimum value, from S s p and S n p , individually, and then average the more balanced remaining values for T s p and T n p . In next section, we will discuss how to determine a practical threshold R b . In order not to affect the social app’s normal running, SPActivity and NPActivity are declared with transparent themes, making our detection operations invisible to users, and call finish() to explicitly terminate their instances after the time overhead is calculated. After we repack and resign all these files, an APK file equipped with PluginAssassin is generated.

OPEN IN VIEWER

Fig. 8.

Repacking social apps with PluginAssassin.

We collected 29 multi-instance apps from the Google Play store and 21 multi-instance apps from the YingYongBao store (a third party Android app store in China) by searching with the keywords such as “multiple accounts”. They provide the plugin environments in our experiments. In general, these apps scan the installed social apps in system and load the ones upon user’s choice. Some of them support to load external APK files on device. We also found that a number of the multi-instance apps display advertisements before launching guest apps. We installed these multi-instance apps in the testing smartphones as unprivileged host apps, which will load the five security-enhanced social apps as plugins to evaluate PluginAssassin.

OPEN IN VIEWER

Fig. 9.

Sample ratio distribution and threshold determination.

PluginAssassin collects T s p and T n p at runtime, computes the time ratio R and judges whether the running environment is a plugin environment or not based on the ratio. Thus, a predefined threshold R b is required to perform a comparison. We show in Section 3.3 that simply setting R b = 1 works well for the demo experiments to distinguish plugin environments from a system environment. In practice, distinctive hardware and software configurations can result in varying degrees of time cost for the same operations across devices. Probably the threshold we computed based on merely the experimental data on OPPO cannot differentiate the running environments on other smartphones. Moreover, the specific implementations of the plugin environment may also influence the value of R at runtime.

We propose a straightforward calculation for R b . Our experimental observations show that, given a number of collected time values (averages for each test), the ratio R ◇ for starting activities in a plugin environment is always greater than the ratio R ⋆ for launching activities within a system environment. Putting the time values in a two-dimensional coordinate system, X-axis for T s p and Y-axis for T n p , the slope of the line connecting a point and the origin O represents a time ratio R . We pick the point with the minimum slope R ˜ ◇ and the one with the maximum slope R ˜ ⋆ , corresponding to point S ( T ˜ s p ◇ , T ˜ n p ◇ ) and point P ( T ˜ s p ⋆ , T ˜ n p ⋆ ) , respectively. The angular bisector equally divides ∠ S O P . Hence, its slope is a good choice of the threshold. Mathematically, the slope of the angular bisector is computed as: (11) R b = T ˜ n p ◇ ( T ˜ s p ⋆ ) 2 + ( T ˜ n p ⋆ ) 2 + T ˜ n p ⋆ ( T ˜ s p ◇ ) 2 + ( T ˜ n p ◇ ) 2 T ˜ s p ◇ ( T ˜ s p ⋆ ) 2 + ( T ˜ n p ⋆ ) 2 + T ˜ s p ⋆ ( T ˜ s p ◇ ) 2 + ( T ˜ n p ◇ ) 2 .

We randomly selected five multi-instance apps and two social apps (WeChat and Instagram), ran them on two controlled devices, (i.e., the OPPO A37m and HUAWEI CRR-UL00 smartphones) and computed R b based on the obtained time values. Figure 9 shows the distribution of the points, four stars for the system environments and twenty diamonds for the plugin environments. R ˜ ◇ = 2.31 when WeChat ran as a guest app on the OPPO A37m smartphone, and R ˜ ⋆ = 1.21 corresponds to a test of Instagram on the HUAWEI CRR-UL00 smartphone. With Eq. (11), we get R b = 1.63 and draw the angular bisector in dashed and black. Notice that, the visual indistinctness of the equal division is caused due to more compact Y-axis compared to the X-axis. We use this R b for all following experiments.

4.4. Detection results and analysis

We conducted experiments for all the social apps and multi-instance apps, on all the three smartphones. We show the results in Table 5. We use the MD5 values of the multi-instance apps to represent the 50 plugin environments and the abbreviations, WX, IN, TW, WA and LI, to denote the five social apps, WeChat, Instagram, Twitter, WhatsApp and LINE, respectively. “∗” indicates the combination of a social app, a plugin environment and the smartphone is used in the threshold determination phase and the detection of plugin environments succeeds. “ ◯ ” means a successful detection as well, with R b = 1.63 . “–”, in contrast, corresponds to a failing test.

We unfold the failures as follows:

According to above discussions, none of the failures is induced by our modifications in the social apps or remarks the existence of indistinguishable time ratios, i.e., all computed R ◇ are greater than R b . In fact, the minimum R ◇ for plugin environments in all tests is 2.05, when Twitter runs in multi-instance app #9 on HUAWEI CRR-UL00. The maximum R ⋆ for the system environments is 1.35, introduced by LINE running directly on HUAWEI CRR-UL00. They both show sufficient gaps between the threshold and the real-world time ratios. We suspect the learned threshold 1.63 can be applied to more plugin environments and devices. So far, the research question presented in Section 3.2 is well answered.

Figure 10 shows all the R values obtained under system environments. As we can see, LINE produces close time ratios on all three devices, even if the actual time values differ a lot. For example, T s p and T n p collected in LINE on OPPO are 86.4 and 115.5 milliseconds, but on HUAWEI Mate 10 they are 44.9 and 58.9 milliseconds respectively. The other four apps have unstable ratios across devices. Potential causes are the optimizations in the system and framework by certain smartphone vendors, or those done by the app developers for specific smartphones. Noises would also affect the results. Nonetheless, they have little influence on the experiment results.

We also observed that, WhatsApp usually holds relatively small time ratios (typically smaller than 0.6) while the others may produce bigger ratios. Due to this fact and that we determine the threshold based on very few tests on only two controlled devices, we suggest the app developers to exercise their apps, with PluginAssassin augmented, on more available devices and make the decision with an app-specific threshold, instead of using one applicable for many different situations as done in our experiments. For example, WhatsApp may set a smaller threshold (e.g., one) and LINE might requires a bigger value.

OPEN IN VIEWER

Fig. 10.

Time ratios under system environments.

Considering the plugin technology has been applied to implement malicious purposes by real-word malwares, such as DualTwitter, we uploaded these 50 multi-instance apps to VirusTotal [40] to check whether they are malicious. Results show that 44 out of 50 are marked as malware or potential malware by the antivirus engines hosted by VirusTotal. According to the analysis reports, we found 10 multi-instance apps intend to execute the “su” shell command to check whether the device is rooted. Besides, 15 multi-instance apps are reported to use the Android packing technique. Antivirus engines label these samples as potential malware because they may hide malicious payloads and dynamically load them during running to evade analysis.

As we mentioned earlier, multi-instance apps with malicious behaviors may threaten the security of legitimate apps. Fortunately, PluginAssassin has a satisfactory performance on identifying the plugin environments by the time lag contradiction detection approach. From the experimental results, we can faithfully claim that PluginAssassin achieves zero false positive rate. For all cases where both the plugin environments and the guest apps do not crash, PluginAssassin doesn’t leave any multi-instance app unreported, namely, zero false negatives.

Since PluginAssassin injects code for extra activity launching, it inevitably introduces some runtime overhead and we will briefly discuss its upper bound in this section. According to our discussion in Section 2 and Section 3, it makes sense for us to simulate the runtime overhead with the observed T s p and T n p in the system environment. For a single pair of an intra-process launching and an inter-process launching, the overhead O is bounded as: (12) O ⩽ 2 × T s p + T n p . An app containing N pairs has the overall overhead bounded by ∑ 1 ⩽ i ⩽ N O i . In our experiments, N = 5 . We show all the estimated upper bounds of the overhead in Table 6. From the results, we can see that except the three cases on HUAWEI CRR-UL00, all other tests have the overall overhead lower than two seconds, while on HUAWEI Mate 10, a more powerful device, the overhead for four apps is even lower than one second. Though the running environments and test noise may affect the results, an individual pair of intra- and inter-process launching introduces the overhead of no more than 0.7 seconds on average. In our experiments, we disperse the operations into different activities along the app’s running, so we believe the low overhead will not influence the user experience.