Is the Device Emulated ?

Part 2 - Secure Android App Development

Stop App running on Emulator or a Rooted Device

To reverse engineer a production build of a mobile application it is mostly run on an emulator or a rooted device.

Preventing our production app from running on an emulator will increase difficulty of the malicious user to use emulator and easily access and analyse the device and application state.

There are several build properties that indicate if the device in question is an emulator . Although all these API calls can be hooked, these indicators provide a modest first line of defense.

• Build.MANUFACTURER
• Build.MODEL
• Build.HARDWARE
• Build.FINGERPRINT
• Build.BOARD
• Build.PRODUCT

Example 1 — Check build hardware properties

 fun doesHardwareSuggestEmultaor(): Boolean {
    return Build.HARDWARE.contains("goldfish")
            || Build.HARDWARE.contains("ranchu")
            || Build.HARDWARE.contains("vbox86")
            || Build.HARDWARE.lowercase(Locale.getDefault()).contains("nox")
}

Example 2 Check build Model properties

fun doesModelSuggestEmulator(): Boolean {
    return Build.MODEL.contains("google_sdk")
            || Build.MODEL.contains("Emulator")
            || Build.MODEL.contains("Android SDK built for x86")
            || Build.MODEL.contains("sdk_gphone_x86_64")
            || Build.MODEL.contains("sdk_gphone")
            || Build.MODEL.lowercase(Locale.getDefault()).contains("droid4x")


}

and so on for the above list of build properties.

Note that this is not a exhaustive list, nor is it foolproof. These property values need to be revised and updated as new information because available. It is also important to point out that these build properties can be edited in the build.prop file on a rooted Android device or modify it while compiling AOSP from source.

Client side vulnerability prevention cannot be foolproof. These are measure to increase the resilience of the app in case of an attach and increase the the difficulty level for the reverse engineer trying to get access to the app data or code.

Root Access

Rooted Android devices can pose significant security threats due to the elevated privileges and capabilities they grant to users and potentially malicious applications. When a device is rooted, the user gains administrative access, which allows them to modify system files, bypass security restrictions, and install apps that have deep access to the device’s resources. While rooting can provide advanced customization options and access to features not available on stock devices, it also opens the door to various security risks. To prevent use of your app on a rooted device, we can provide a check.. there are open source libraries like

https://github.com/scottyab/rootbeer or https://github.com/DimaKoz/meat-grinder

There is also https://developer.android.com/google/play/integrity API by google that helps with “check that interactions and server requests are coming from your genuine app binary running on a genuine Android device.”

We will explore the Play Integrity API in details in upcoming chapters of this series.

Source —

Android Anti-Reversing Defenses - OWASP Mobile Application Security

Testing Emulator Detection

Gihub Link -

https://github.com/ChaitanyaDuse/SecureAndroidApp/tree/emulator-check