I am working on ensuring security of my company's product. We have a mobile version of the product. This question is for the Android version

Background - Our product is a SaaS-based product and the app is meant to be used by different salespeople of tenant organisation. We have implemented different layers of control for ensuring secure (or more like safe) environment for our app -

  • We check for root detection - (OS level check)
  • Implemented SSL pinning - (Transport layer level check)
  • Storing secrets in Android key chain
  • Minimal local data storage. Encrypt local data (that needs to be stored)

and the list goes on. In short, right from the device to the communication layer to the server layer we are in the process of covering every corner.

The problem is we got one issue reported by one of the security researchers that says that as our app can be downloaded from the Android play store thus it can run on an emulator, and on an emulator, it is possible to bypass root detection. So it adds a huge threat and should be fixed immediately.

I searched, but I cannot find security implication that could be possible if app can be installed on the emulator. Also I checked if I might have to fix it, what could be the possible solution. There are checks like looking if the running environment is an SDK, check if features like camera or sensors are working, but all those checks can be bypassed in emulator also.

It is kind of critical for me because if I accept this issue our client will see it in report and insist on getting it fix. I'm coming up blank for the implication that I would have to explain to Management and developers (if I accept) and fix (that might be required later)

Update -

  1. I want to clarify one thing that we never advocate root detection or any other client side security controls as a plus point of our app because we believe all client side protection can be bypassed at one point or the other
  2. We keep on trying to build more secure architecture at the server level. But since client side also forms the part of eco-system so we cannot leave it unguarded.
  3. We even try to implement controls at the communication layer (other than TLS) to ensure just by tapping in you cannot get everything

Whole idea is if we cannot control certain things we can at least make it difficult for malicious parties. Our primary focus is to secure our users data and controls are in place and in progress.

Also update from Pentester - After discussion with him, he said that he didn't understand the application security requirement. As per him all app should have root detection. We explained him that those things means secondary to us but if any client specific data is lying in plain sight or can be compromised because of misconfiguration in app or any vulnerability in app (like hard coded secrets) then that it is primary.

Based on input provided you guys I was able to make this distinction clear and help in closing down the issue. Earlier it was all noise because of this issue. Thanks to all

  • 73
    If a user has root access then they can bypass your root check detection anyways. Rootkits can even hide their existence from root users, so hiding from a user application would be much easier.
    – user
    Commented Dec 16, 2019 at 14:18
  • 57
    Your security researcher says it's a problem that your app is available in the Play Store? That sounds like something this guy would say. Commented Dec 16, 2019 at 20:56
  • 73
    Your application is simply designed wrong - "Your backend is the product, the frontend is just you being nice enough to build a client for your users".
    – Luke Park
    Commented Dec 16, 2019 at 22:01
  • 93
    Additionally, it's the user's business whether to root a device. I've given 1-star reviews to apps that complained about root when they have no business worrying about it. Commented Dec 16, 2019 at 22:28
  • 31
    Why is your app trying to detect root and what are the secrets stored in the keychain?
    – Frank
    Commented Dec 17, 2019 at 6:27

9 Answers 9


It is unclear what kind of security requirements you have in the first place and thus it is unclear if your security measures are sufficient or not.

Fully protecting against a malicious user using your application is not possible as long as you are not able to fully control the device of the user. This risk includes running the application on emulators but also includes running it on rooted or otherwise tampered device - and not all of this will be detected by whatever root detection method you use.

Instead you need to design your application so that a malicious user cannot do any harm to you or to other users but only to himself. This for example means having user specific secrets in the application and not using global secrets. This also means that you should not trust anything the application reports but instead verify if this make sense (i.e. not trust any self-reported high score in games or similar).

  • 46
    In addition to the above methods of malicious use, it is possible to reverse engineer the apk and remove any protections you include. Commented Dec 16, 2019 at 14:19
  • 37
    @Lexichamp: The real question is not if it is a problem that your root checks can be bypassed in an emulator. The real question is if an attacker is able to access data of other users by somehow fiddling with your application (i.e. reverse engineering, rooting ...). It does not matter if an attacker can bypass your root detection if the attacker cannot gain anything from this bypass, i.e. if he is not able the other customers data. Commented Dec 17, 2019 at 7:48
  • 11
    Attacker might not even need to reverse engineer the app, they could just as well just use wireshark and tamper with the communication directly. Commented Dec 17, 2019 at 10:05
  • 20
    "it is very critical that a user cannot access data of any other user" - This needs to be implemented server side, most commonly using username and password login. A modified app will not be able to bypass a correctly implemented server-side login system. @Tomáš , That's why you have SSL cert pinning, so the user will need to dissemble the app or root the device to be able to view traffic in wireshark Commented Dec 17, 2019 at 12:35
  • 4
    @Lexichamp The most used root method at the moment is Magisk. This is thus far undetectable so good luck with blocking root. You already failed, root is always 1 step ahead of detection. And if a rooted user could access data of another user that means your security is bad, don't block root, make sure people can't access other people's data no matter what.
    – EpicKip
    Commented Dec 18, 2019 at 8:46

Whose security are you concerned for here, and what are you trying to protect? Are you trying to protect the users from having other people access their data, or are you trying to protect the company from reverse engineers attempting to look at how the app works because your API is insecure?

If you are purely attempting to protect the users' security, then there is no issue at all with having the app run in a VM unless you think users will run the app in a poorly secured VM and have their data stolen, which is both very unlikely and is their problem, not yours.

If you are attempting to prevent people from reverse engineering the app, then you are fighting a difficult battle because root checkers are easily bypassed. This is also almost always a pointless effort since the app should have nothing useful for an attacker if it was designed securely.

Also, keep in mind that sometimes security testing people will sometimes just make up non-issues if they fail to find any real issues since a blank report makes it hard to justify the money spent. If possible, challenge them on this statement and ask them to give a real world example of how this is actually an issue.

  • We are focused on securing our user data that might reside on the device. We have implemented certain measures to make it difficult to reverse engineer APK but that is not a prime concern for us. Its just another layer of defence-in-depth approach we are trying to implement. We just wants to make it difficult (as much as possible) to run our app on rooted device. I know we cannot do it 100% but we want to avoid as much as possible. The researcher tried to run our app on rooted device but when that didn't worked, he run it on rooted image running on emulator. App was working on later
    – Lexi champ
    Commented Dec 17, 2019 at 7:33
  • 2
    We are still waiting to hear security implication of app running on emulator from him. My gut says you are right and it could just an issue to increase the count
    – Lexi champ
    Commented Dec 17, 2019 at 7:39
  • 33
    @Lexichamp But why are you protecting the user's data from the user? Who cares if the user can "steal" their own data? As long as they can't steal someone else's data. Commented Dec 17, 2019 at 11:34
  • 3
    @user253751 Thats another big point. Root checking is for when you don't trust the user for some reason. Mainly to implement DRM or prevent cheating in games. I suspect part of the reason the VM issue has come up is because it shows that the root checker was pretty much pointless.
    – Qwertie
    Commented Dec 18, 2019 at 0:30

The classic and correct answer to your client is NOTANISSUE.

No client side software * * should ever be considered to be designed as secure, in the sense your question asks. They can't be. The client side software - be it web or app - is totally under the clients control, as is its environment, as is the total ability to rewrite/mod the software, or run it on an undetectably insecure or modified environment. That isn't a bug. That's inherent in the model * *.

The purpose of your various checks is to reduce the risks and raise the bar, as so often with security. It is not done to make the client secure or ensure client side security, and your client is incorrect in assuming that aim.

  • * * With perhaps the sole exclusion of client side software where the entire client side software and its environment is designed and controlled with the purpose of creating a highly tamper-resistant and verifiable environment, such as Trusted Execution, or the firmware of some YubiKeys (that can't easily at all be downloaded or modified once flashed), or when the client is a remote system with its own security in place, such as well-secured failover servers syncing to each other over SSH.

    Even then, perhaps the specific module may be considered secure (for a certain threat model) but that still doesn't mean that anything else, such as a local app checking the dongle's response, is in any way secured.
  • No client side software * * should ever be considered to be designed as secure. Well. Client side software can absolutely be insecure regardless of the backend design. Storing passwords in the wrong place, for example.
    – Cruncher
    Commented Dec 17, 2019 at 16:26

I'm readign between the lines here, but I think I see where the researcher is coming from.

Your app has no business storing (or using) any secrets that could expose the data of other customers.

design your backend so that the secrets given to the frontend only give compartmented access to the backend services. then if a user roots their device they can only hack their own account.

  • 11
    I would agree with that, but hearing that the same person suggested publishing the app on the Play Store is a vulnerability makes me question the credibility of said researcher.
    – user163495
    Commented Dec 17, 2019 at 13:06
  • 1
    @MechMK1 Unless the conversation went something like: "No you see, our app is secure because you can't run it with a rooted device!", to which the researcher responded with "I can run it in an emulator"
    – Cruncher
    Commented Dec 17, 2019 at 16:30
  • 3
    @MechMK1 I think you are giving too much weight to the way OP worded that sentence. A) "Root detection adds security to our app" B) "Your app is on the public store, not in a corporate managed environment, root detection is impossible, if you need it you have a problem" would be an entirely reasonable exchange that OP could have restated. Publishing the app to the play store is a vulnerability if it's a badly designed app that was intended only for sandboxed use. They may have implied that to the tester.
    – Affe
    Commented Dec 17, 2019 at 17:05
  • @Cruncher see my answer below - the researcher's supposed response is plain wrong.
    – user171968
    Commented Dec 18, 2019 at 1:22

I feel the need to advocate for the poor maligned pen-tester here.

What was this tester hired to do and with what scope?

If the app developer provided a white paper or security strategy etc. that claims root detection is part of their security strategy, then it is absolutely appropriate to point out root detection is a fiction for publicly available apks. It is not generally the tester's problem to figure out if the overall architecture is actually vulnerable on the client side and should only be run on controlled devices, or management just wanted the biggest possible list of "security features." He or she just reports it failed against the claims provided (that root detection is improving security.)

The "fix" is stop making claims that client side environment checks does anything for security so that you can have a bigger list of "security features".

The wording that implies this person said "being on playstore is a vulnerability" is OP's not theirs. (having had things I said restated incorrectly in a way that makes it wrong enough times in my own career...!)

  • Exactly. If the claim is that the root detection provides some protection against a scenario involving users intentionally running the app on a device that they have root access to, then the tester found that the root detection only prevents against a user who is not determined to run the app on a device they have root privileges on. Commented Dec 18, 2019 at 18:51

I would not consider any of client-side or web applications as sufficiently safe stand-alone, i.e. without securing the solution server-side independently on the OS.

All security layers, validations and checks implemented inside the client-side application should be at least repeated with corresponding or stronger validations within your application server-side components.

What is more, using emulator to run the application means the emulator own vulnerabilities can harm the user's security, for example some vulnerabilities allowed attackers to perform remote code execution, information disclosure, steal backups and data, as well as gain access to emulator's inter-process communication functions*.

*Source: https://www.bleepingcomputer.com/news/security/bluestacks-flaw-lets-attackers-remotely-control-android-emulator/


There is little difference in between a JVM running on a hardware device or an emulator. Of course one could see if the OS build string has "generic" (which only the emulator has) and then exit the application, when it is a release build - but this provides zero improvement of the overall security (since the bytecode can easily be decompiled - and only the code-signing prevents changes to functionality to some degree). Besides, release builds are not configured as debuggable.

The point is, that when it cannot run on a rooted device - then it will not run on an (rooted) emulator.


Reliable root detection is impossible, due to obvious logical pen testing holes.

If the user has access to the apk, the user can also just analyze the apk and then call your server api's directly quite easily and bypass the application entirely or port the application to a different system. You need to rethink your overall approach to security if it's part of the strategy to protect your systems to detect if it's being ran on a rooted device - since you cannot even reliably know what is being ran.

The user can if they want decompile your application and just strip all the detection parts out of the application in the first place. The process would be just same as "cracking" software would be.

What you can do with the root detection is to just let an user know that you think their phone is rooted, as a security caution to the user - maybe the phone is rooted without the user knowing it? but even in such case you cannot rely on it. you can't know if it's actual hardware or not that you're running on. You cannot know if it's running on some system like knox where you can pay samsung to gain essentially root powers in the system(through the enterprise functionality - and yes it basically can grant you almost root like powers to mess with other applications and other applications components - the phone will appear as knox secure even then and unrooted).

Root detection and such usually end up in an application to deter hacking, but it's 100% the wrong approach to combating the problem. Sorry, but what you need is a cultural thinking change in the organization in regards of the security: you can't trust software that runs elsewhere to be what you think it is so pentesting for that is pointless.

edit: If you need some way to explain it to your superiors, you could try this: "If we could do this then that bit of code would be worth more than the entire company is ever going to be worth" - and that quote would still apply to your company even if you worked for Google.


The security researcher warning is right, but you must put this warning on the context of your application to know if it is relevant.

You listed the "root detection" as an important security feature of your app.

Being a security expert myself, I would point out that root detection can be easily bypassed. Not only on virtual machines: but in physical devices as well. Many frameworks that claim to do root detection do not detect many rooted devices and detect some normal ones as rooted. Even if was the case, the client-side of any application can be easily reverse-engineered. A motivated attacker will be able to access your back-end interface bypassing the client-side app altogether. This means that any checks on the client-side can be bypassed and any calculation messed with. No client-side check or calculation can be trusted.

It is possible to create a trusted client, but it requires proprietary hardware, proprietary operating system and software. Game consoles and cable networks do that, but still suffers a lot with piracy which should count as a good example of how difficult is to tamper-proof a device. This strategy is theoretically possible, but fails on practice because it is too expensive, steal and prevent investments on the product functionality that becomes weak and obsolete in front of its competition.

How secure does it need to be?

There is no such thing as a secure/safe app. Security is about understanding the risks, the likelihood and size of the losses it can cause and identify contingencies and mitigation strategies to keep a healthy profit margin. The questions you should be asking are:

  • what happens when the "root detection" fails?
  • what kinds of attacks the "root detection" is supposed to protect against?
  • what is the likelihood of that to happen?
  • what kinds of losses can a "root detection" fail cause?
  • are there other protections against that?
  • is it possible to detect those kinds of violations fast?
  • is it possible to trigger contingencies that reduce or eliminate the losses?
  • will the company still be profitable with those losses?

All important logic must be server-side

You seem bothered with the possibility of an attacker being able to install your app in a virtual environment. I suspect that many of the security checks and important calculations are on the client-side. If it is the case, you really need to redesign your app to move all controls to the server-side:

  • The back-end interface APIs exposed to the user networks must require authentication of the user.

  • The back-end interface APIs must limit what the user can see and do. The access limits should be imposed by the server-side, never by the client-side. With the exception, of course, of services that do not include sensitive information and commands;

  • The back-end interface APIs must account for the possibility of brute-force attacks. An attacker can download huge portions of your database and guess weak passwords and confirmation codes by attempting them all.

  • The internal APIs - those used by the back-end and not exposed to the user networks - compose an inner service layer that should use service users or client certificates to authentication. The information of the real user should be propagated to those services for logging purposes.

I know that this is very disappointing. With those restrictions, the back-end interface APIs must be very specific to the app workflows and therefore less reusable. Unfortunately, only internal APIs can be reusable. This also means the back-end developers will need to understand very well the user experience, the designed workflows and work closely with the front-end teams which are things most developers do not like or are prepared to do.

Even with all the important logic on the server, it is necessary to design the workflows to account for other risks

If the app follows the guidelines mentioned above, it does not matter if the client-side app is tampered with on an attacker's device. He or she will not be able to do anything other than what the user credentials they have would allow them to do via the official client-side app.

But if a real user device is rooted, malware will be able to:

  • bypass rooted device detection;
  • capture user credentials;
  • redirect the user to a false page;
  • redirect the user to a false app;
  • remote control the device;

Those attacks are not very common. Those are difficult because usually require the user to do complicated procedures. But if the product is expensive or the information is too sensitive, those attacks must be taken seriously.

If your concern is because your "salespeople" deal with expensive products in which losses are large and not easily recoverable, you must consider secondary barriers such as:

  • supervisor validation on larger operations;
  • validate the delivery address with several external databases;
  • improve tracking of the deliveries;
  • impose time constraints on deliveries according to the risk.

If this still not enough, you may choose to provide a company-owned device that is locked to prevent external app installation and have the USB locked only to charge. I know a few people that walk around with three corporate phones of different companies all the time: it is still a thing.

Develop good logs and monitor them

Monitoring is also a good strategy to avoid many losses. Backtracking the losses on the logs allows better understanding on how they happen and what have failed, propose changes to the products or at least monitor that situations to get early warnings of similar situations on the future.

If the logs are detailed enough, there are techniques of behavior biometry that are easy to implement and can detect many kinds of intrusions and some kinds of operational mistakes early enough to prevent losses.

You have a desktop version?

When you said "We have a mobile version of the product", it sounded like you have another. Do you have a desktop version? Desktop operating systems are rooted by default and there is no app isolation. If you can live with a desktop version, you probably do not even need root detection in the first place.

It is a good thing to continuously improve security, and you should do it, but you can expect the mobile version to be safer than the desktop one unless you make a horrible mistake in the new development.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .