Bypassing AirWatch Root Restriction

Mobile devices are becoming more common in corporate environments. As a result, mobile device management solutions (MDM) have cropped up so that employers can remotely manage and wipe devices if necessary along with setting certain requirements that employees must comply with, such as setting a passcode, encrypting the device, and not jailbreaking or rooting the device. It’s certainly not a bad idea to enforce restrictions on devices that may contain sensitive information. However, bypassing some of the restrictions that an employer may put in place it not difficult. This is especially true if someone wants to keep their device rooted.  There are many contenders in the sphere of MDM software. For this blog I will be looking at AirWatch for Android. The device I will be using is a rooted Nexus 4 running Android 4.2.2.

[Note Update at End of Post - 09.13.13]


AirWatch is an MDM solution that provides employers with the ability to manage mobile devices and enforce policies. An agent is installed on the device and monitors whether the device is compliant or not for specific policies. If a device is found to be non-compliant, the agent phones home to a server, notifying the employer of a non-compliant device.

Here is the default web interface for an AirWatch enrolled device. As you can see, my Nexus 4 is enrolled, is encrypted, and requires a passcode. However, it is still not compliant because my device has been “compromised,” i.e. rooted by myself. A poor word choice in my opinion. The same can be seen on the AirWatch agent.

If we navigate to the compliance section, we can see why we are not compliant.

Again, the agent shows that we are encrypted, but our device is “compromised.”

Digging Deeper

At this point I want to know how AirWatch is detecting that my phone is rooted. I tried removing the su binary and any superuser applications, but that didn’t seem to work. As a rooted phone, we can certainly grab the apk of the agent and tear it apart. That only revealed obfuscated java classes that would take a while to decipher. Next, I tried running strace against the agent process to get an idea of the calls that it is making, hoping that there would be something there that reveals what it is doing to detect root. Again, there weren’t any answers that I could find.

I decided to shelve looking for how AirWatch was detecting root for another day and instead I started focusing on the HTTP request and responses that the agent was sending and receiving. I started burp and setup a proxy on my Nexus 4. There is a fair amount of traffic that goes between the AirWatch agent and the server it’s talking to. One request in particular caught my eye.

This AirWatchBeacon checkin request. I omitted some of the more sensitive information in the request. As you can see there is an “IsCompromised” field in the request that is set as true. So I change that to false and sent the request off. After refreshing the web interface, my device is no longer compromised.

The agent also shows that my device is no longer compromised.

So now we know how the agent is checking into the server and whether or not your device is compromised. By changing a simple flag, we now control that. Furthermore, there doesn't seem to be any type of session information related with the request. We can replay the same request hours, even days later, and the server will accept it. The only downside now is that the agent will periodically do a check-in request with the server and report that the device is compromised. It’s a hassle to send a non-compromised request every time we want to be compliant. The first step I took in resolving this issue was to look at the AirWatch configuration options in its SQLite database.

Using the SQLite Editor app from the Android market, I open up the AirWatch database with root access.

Selecting the AirWatch database reveals a number of interesting tables.

The profileGroupSetting table is where most of the AirWatch configurations are stored.

There are a few rows that look interesting. The ones that contain interval in the name seem to set how often the AirWatch requests are sent. I tried changing the BeaconInterval to large values to see if it would take longer for the check in requests to be sent. That didn't seem to work. Neither did setting the value to zero or a negative value. For the most part, setting the interval values do not seem to do anything in my testing.

There is, however, another way to stop AirWatch from sending out request. Modifying the Android hosts file to block the host that the requests are being sent to. The Android hosts file is located in /system/etc/. Again, you have to be root to be able to modify the hosts file. I modified the hosts file to redirect the requested host to my localhost. The requested host is going to be different for every company, so I won’t be showing that. It’s been well over a week and my device has still not checked in and still shows that I’m compliant.

The only downside to not checking in often is that your device will show as not being seen for sometime. You employer may have a policy in place to remove devices that AirWatch shows as being inactive. One way to mitigate this is to periodically send out the checkin request yourself. Simply setting up a cronjob with curl to send out the checkin request work very well.

Here is the json POST request data the curl command uses for –d @request:

Finally add the bash script to your crontab by running “crontab –e” to edit the crontab and add the following at the end of the file:

This will cause the script to run every two hours.


MDM solutions are great for employers to manage mobile devices. However, they are not without their problems. Not only was I able to bypass compliance for having a rooted device, but I was also able to bypass the need to encrypt my device from the profileGroupSetting table. Bypassing compliance restrictions for AirWatch is relatively trivial after a few hours and I’m sure it is probably similar with many others MDM solutions.


Update - 09.13.13

Eric Gruber: AirWatch states that it has addressed this issue by recommending that clients enabled a security configuration setting called "secure channel" which according to AirWatch protects against Man-In-The-Middle attacks by using mutual X.509 message-level certificate signing and encryption between the client and the server. For AirWatch hosted customers, this options is now enabled by default and cannot be disabled.


  • Not sure if i am missing something or need to be educated, but why would the device be enrolled in the first place when the device is rooted? Man in the middle comes later …

    • Your device is enrolled before root detection takes place. After Airwatch is installed and setup your company’s policies get pushed to your device. It’s these policies that dictate whether or not a rooted device is allowed, which is why you have to enroll first.

  • Understood, but the point being the detection happens after the damage is done partially, which is that the device has to be enrolled. On the contrary, if the jailbreak is detected during the device enrollment, then the enrollment should not even a continue. No company policies should be even pushed at this point to the device (which is what i call partial damage). And there are multiple MDM vendors who provide this feature. Zero tolerance for jail break devices, especially in the Govt, HIPPA compliance.

  • I’m experimenting airwatch on my device that’s rooted. It is a Samsung Galaxy Note 10.1 running Android 4.1.2
    How do you monitor HTTP traffic using Burp?
    Do you run Burp on your device or you run it on your computer to which the device is connected to?
    I’ve tried running Burp on the device but there’s no way I can run the burp.jar file from it.

  • @Eric – Pretty cool article. How does Airwatch install apps silently on device without user intervention. (Thats what their video says). Generally you need usb connection or supersu access to install app silently. How is air watch agent able to do that?

    • Vish,
      AirWatch can not push public apps to a device, but if the device is enrolled and you have the APK you can upload the APK to your console and then push it to any device in your environment.

  • nice article. wondering how to be able to see if my iphone is compliant or not without access to the AW console? I installed a JB detection bypass tweak, but have no way to test if my IT group can see the iphone as being compliant or not. Ideas?

  • This article is not correct when AirWatch security settings respect standards.
    You can only send handcrafted requests if the administrator disables secure communications on the server.
    In all secure environments, only the agent can send its compromission status to the server.

    • @Milo This is true now. However, The setting was disabled by default for hosted and non-hosted AirWatch customers when the blog was written. They have fixed this and the setting is enabled by default for hosted customers, but non-hosted customers still need to enabled it. I addressed this at the bottom of my blog back in September 2013.


  • Seems like when I set the proxy through Burp I cannot see any messages related to Airwatch. Other apps seem to show up but not Airwatch. Thoughts?.

    • Have you imported your Burp CA? If you have, then they are probably doing certificate pinning in the application.

    • Hi Isaiah,

      I read your blog and wanted to touch on one important thing. AirWatch is always watching for your device to check-in. This is what I ultimately wanted to bypass. Blocking all traffic from the device to the AirWatch server will work for only a while until AirWatch blocks the device for not checking in. I initially did the same thing when I was first playing around with AirWatch, but it’s not a stable solution that will work in the long run.

      • @Eric I actually did manage to get around that issue on an older version of AirWatch. They updated the app about a month after I published how to bypass it, I presume they saw what I published. Those who don’t run the newer versions of the app can still capture the request and then send it again. The reason this does not work anymore is that each beacon that is sent out now contains a random key to prevent the request from being reused.

        • I’m guessing you are using a self hosted AirWatch server with secure channel disabled then, because the body of the requests should be completely encrypted. I touched on the replayability of the requests in my blog, which is how I was able to send the same request out in my curl script. Also I spoke with AirWatch a little more than a year ago about the issue and they fixed it by September.

        • Also, I’m not sure if the iOS version of AirWatch works differently then the Android version. I have not looked at the iOS one, but essentially you were doing the exact same thing I was doing on the Android side. This includes modifying the hosts file and replaying the beacon which I explain in my blog.

  • Hi Eric. I have previously had Airwatch Agent installed on an android device, but recently changed devices. I set up and configured AW on the new device, but keep getting a prompt to go through encryption despite the encryption process already taking place upon initial set up. Is there a way to bypass this just as you bypassed the “compliant” check?

  • Just an FYI, I help manage our MDM side and when a device has been last seen over 60 days, it automatically blacklists the email entry to not receive anymore.
    I have a Galaxy S5 and I rooted it to remove some bloatware. Airwatch detected it, and removed my email settings. No big deal, I do what i need, unroot, re-enroll, all is good.
    I had done this 3 more times for random things, no problems.
    Last time it somehow glitched and did not remove the email profile. Thats how I learned about the 60 day inactivity. You can go into the console and white list the Email entry for your name/device and it will continue to work.
    Sadly today was day 121 and it stopped and I thought I hit another failsafe so I reenrolled and broke my special setup, only to find out email isnt working for many people and its actually an exchange issue internally.
    So sad, lost my rooted privaleges. At least I have a reason to upgrade to Lollipop now.

Leave a Reply

Your email address will not be published. Required fields are marked *