Threats / 03 Emulators and Virtualization Apps

An emulator is a program that provides a virtual environment replicating the hardware and software environment of a certain platform, enabling software designed for that platform to be run on a different one that it was not originally designed for. For example, Android Emulator allows you to run Android applications directly on a PC or Mac, by creating virtualized versions of Android systems and hardware devices.

Virtualization apps - typically marketed as Cloner Apps or Sandbox Apps - are applications that load and execute other applications within their sandbox. As a form of app wrapper performing Dynamic Code Loading (DCL), they extract code files, metadata, and resources from the loaded application and add them to their own runtime environment. The loaded application does not even need to be present or installed elsewhere on the device.

You might be wondering how this is different from certain platform offerings, such as Android for Work, multi-user devices, and the App Cloning feature introduced in Android 14. Well, there are some important technical differences which have security implications.

First, virtualization apps actually load other mobile apps into their memory space. This means that the ‘wrapped’ app doesn’t have its own sandbox and associated security offered by the operating system. And there’s also no need for any other version of the app to be installed on the device.

Android platform features which allow for multiple installations of the same app on a single device, on the other hand, ensure that each version of the app is subject to standard OS restrictions regarding signing certificates, installation method, and app scanning. And they do run in their own isolated sandbox. From a security perspective, each separate installation of the app is therefore equivalent to a single installation.

There are a substantial number of apps which offer such functionality available. Well-known examples are VirtualXposed and Parallel Space.

The fundamental goal of virtualized environments is having control over the execution environment (runtime). Having this control basically allows an attacker to do whatever they like in it.

Both emulators and virtualization apps are software based which allows the attackers to easily configure or customize them as much as they like. The Android Emulator or Virtual Device (AVD), for example, allows an attacker to load a self-built or customized kernel that contains patched system call instructions. With this, they can then intercept and spoof any kernel space information requested by the applications, such as when an application attempts to detect root by checking the presence of particular files on the device or system properties.

An emulator usually provides debugging capabilities and root privileges by default, too. And this makes it possible for the attacker to analyze every application or process with ease.

Virtualization apps may not seem as powerful as emulators, but they too can be potent tools for an attacker. There are no boundaries between the virtualization app and apps loaded in it, so an attacker or malware with control over the virtualization app can easily inspect its memory layout, which also includes everything from the loaded ‘wrapped’ apps: their code, and resources, and any data they process. 

And since the virtualization app acts as the only bridge between the wrapped applications and the underlying OS functionalities and hardware, attackers can easily manipulate every bit of information flowing in and out without needing to customize or control the system itself.

If an attacker wants to debug a target app, for example, he can load it to a virtualization app which has been configured as debuggable and simply attach the debugger to the virtualization app. No need to modify the app, or to override the system properties.

And there’s a key advantage for attackers to using virtualization apps over emulators: they’re harder to detect.

Attackers can use virtualized environments to steal sensitive information from your mobile application. Virtualization apps, as previously explained, allow the attacker to load and execute your mobile app within its own sandbox or runtime. Every bit of code, data, and resources will be visible to the host app. Not only that, but if your mobile app tries to emit and store some data on the device it will be placed within the host app’s private directory. Your mobile app’s network traffic can be easily intercepted and analyzed, too. As it’s loaded and executed in a virtualization app, your mobile application isn’t protected by a sandboxing system that the OS provides for installed applications on the device. That means that the host app can freely access - and do whatever it likes with - your app.

Virtualized environments are an attacker’s playground to spoof and hack mobile apps.

Let’s consider a scenario where you develop a mobile game. Those who don’t intend to play fairly might use emulators on their computer to play the game and easily defeat their opponents playing on physical devices. The best case scenario here is that this creates an unhealthy, resentful gaming experience among your end users. But there can be other, even more damaging ramifications. Because emulators are software-based and can be modified while also providing root privileges and debugging capabilities, bad actors can easily use them to inspect and hack your mobile game. Alternatively, they can also use a virtualization app (as demonstrated by this tool) to achieve the same goal because every part of your mobile game would be visible to it.

Another real-world scenario is a mobile ad fraud attack. Imagine you develop a marketplace app that offers promo codes for first-time users. An attacker discovers that your app’s backend will first check whether there’s any user account associated with a particular device ID. If there isn’t one, your app’s backend will grant the user access to the promo codes. To cheat this system, the attacker can use a virtualization app to load your app and easily spoof the result of the API that your app used to obtain the device ID. Your app’s backend will then fail to identify this attempt and the attacker will be able to abuse the promo codes.

Here’s another scenario. You develop a messaging app and set a rule that users can only be signed in with one account at a time. One user wants to use a second account so she looks into possible solutions and discovers that by using cloner apps that are freely available on the market - often dubbed as multi-account apps - she can set one up easily.

Attackers are aware of the demand for cloner apps and sandbox apps - and they see it as a golden opportunity to target your end users. By creating and distributing such an app, an attacker is in a position to observe all activity within all ‘wrapped’ apps. If your end user is looking for an app that will allow them to operate multiple accounts on their device, for example, installs this malicious app, and runs your application within it, the host app can report back all data - credentials, session tokens, personal identifying information, etc. - to the developer’s command & control server.

No matter how emulators are developed, they’ll not be able to perfectly simulate or mimic a real mobile device. For instance, emulators aren’t able to reproduce the behavior of a hardware component that exists in a real mobile device. You can take advantage of this fact to detect emulator usage via platform-official solutions like Play Integrity API and Apple DeviceCheck. Emulators will not pass this attestation process.

As previously stated, attackers can run your mobile application inside a virtualization app without actually installing it. This means that your mobile app doesn’t have a proper sandbox or isolation system provided by the OS such as app-specific storage. The host app would control the file system activities of your mobile application within its own sandbox.

Acting as a wrapper, such apps act like a bridge between your mobile application and the underlying OS and hardware. On a technical level, that means virtualization apps must hook some system libraries or platform APIs to ensure that your application can function properly. For example, hooking filesystem APIs to perform path redirection when your application wants to store or access its private files because your application doesn’t have its own sandbox like most installed apps do.

Depending on what you’ve decided in your threat model and the sophistication of the protection mechanisms that you have implemented, you can choose to crash the application upon detection of virtualized environments. Alternatively you can block app functionality, display a warning to your end users that the environment is not secure and their data may be at risk, and / or report the detection results to the backend.