Terms of Use

I have created a tool that may be used to unlock your bootloader. It requires that your device has been rooted and that the “su” binary has been properly installed. By using this tool, you agree to the following conditions:

1. 1. You understand that using this tool will permanently, irreversibly void your device’s warranty.
2. 2. You understand that it may not be possible to “relock” your device’s bootloader after unlocking using this tool. A side effect of this is that if you lose your device and you are not using disk encryption, a malicious party who acquires your phone may be able to extract all personal data from the device regardless of any lock screen.
3. 3. You agree that I am in no way responsible for any damage to your device as a result of using this tool.

Instructions

The tool may be downloaded here. It may be used as follows:

1. 1. Extract the entire contents of the zip file.
2. 2. If you are using Windows, ensure you have installed the latest Motorola USB drivers available for your phone.
3. 3. Ensure your device has been rooted and you have a working installation of “su”.
4. 4. Ensure USB Debugging mode is enabled on your device.
5. 5. If you are using Windows, navigate to the extracted directory and execute “run.bat”. If you are using Linux or OS X, navigate to the extracted directory in a terminal and execute “./run.sh”.

Frequently Asked Questions

Will this support _____?

This tool supports the Razr HD, Razr Maxx HD, Razr M, and Atrix HD. No other models are supported. In particular, earlier OMAP-based Motorola phones will not be unlockable using this approach. Attempting to use this tool on unsupported devices may result in irreparable damage.

Can I re-package this tool and put my name on it?

No.

Can this be patched by Motorola or my carrier?

Absolutely. As always, if you’re interested in keeping your root access or unlocked bootloader, approach all OTA updates with caution. Be aware that failing to install OTA updates may deprive your device of important security and stability fixes and new features.

The top-level page fault handler on x86 is do_page_fault(), found in arch/x86/mm/fault.c. When the CPU fires a page fault exception, it pushes an error code onto the stack, which is accessible as an argument to the page fault handler.

When a userland process attempts to access unmapped memory or memory whose page permissions do not allow the desired type of access, the following code path is invoked:

do_page_fault()
__do_page_fault()
bad_area_nosemaphore()
__bad_area_nosemaphore()
show_signal_msg()


This last function prints a message to the kernel syslog with information about the uncaught SIGSEGV that is thrown as a result of the invalid memory access:

static inline void
show_signal_msg(struct pt_regs *regs, unsigned long error_code,
        unsigned long address, struct task_struct *tsk)
{
    if (!unhandled_signal(tsk, SIGSEGV))
        return;
        
    if (!printk_ratelimit())
        return;
        
    printk("%s%s[%d]: segfault at %lx ip %p sp %p error %lx",
        task_pid_nr(tsk) > 1 ? KERN_INFO : KERN_EMERG,
        tsk->comm, task_pid_nr(tsk), address,
        (void *)regs->ip, (void *)regs->sp, error_code);
    
    print_vma_addr(KERN_CONT " in ", regs->ip);

    printk(KERN_CONT "\n");
}

Note that the error_code printed to the syslog has been passed down all the way from the top-level page fault handler. It’s worth taking a look at what the bits of this error code correspond to. Most importantly, bit 0 is the Present flag, indicating whether or not the page the process was trying to access is present at all. Bit 1 is the Read/Write flag, indicating whether this was a read or write fault, and bit 2 is the User/Supervisor flag, which is 0 when the fault was caused by a supervisory process, and 1 if the fault was caused by a user process.

In other words, regardless of whether the attempted access resides in user or kernel space, the error code logged to the syslog indicates whether the address corresponds to a present or absent page. This can be verified as follows:

$ cat trick.c
#include <stdlib.h>

int main(int argc, char **argv)
{
    int *ptr, foo;
    ptr = (int *)strtoul(argv[1], NULL, 16);
    foo = *ptr;
}

$ ./trick ffffffff81aa3690
Segmentation fault (core dumped)
$ ./trick ffffffffc1aa3690
Segmentation fault (core dumped)
$ dmesg | grep segfault
[391396.756467] trick[31865]: segfault at ffffffff81aa3690 ip 0000000000400528 sp 00007fff7c026ba0 error 5 in trick[400000+1000]
[391404.736606] trick[31872]: segfault at ffffffffc1aa3690 ip 0000000000400528 sp 00007fff170fac60 error 4 in trick[400000+1000]

The first invocation deliberately causes an access violation on a mapped kernel address, resulting in an error code of 5 (a read violation from user mode on a present page). The second invocation causes an access violation on an unmapped kernel address, resulting in an error code of 4 (a read violation from user mode on a non-present page).

This trick is only possible if you can read the syslog in the first place, so the dmesg_restrict sysctl must be disabled.

Exploitation

The vulnerability in this case allowed me to chmod an arbitrary file or directory 0777 (world-writable). Normally I’d go for /data/local.prop (if it already exists) or /data itself (if it doesn’t). However, on this particular device, setting the ro.kernel.qemu property (to cause ADB to give a root shell) caused the device to bootloop before ADBD started.

My second go-to for these types of bugs is /proc/sys/kernel/modprobe or /proc/sys/kernel/hotplug, since writing the path of a user-controlled executable and triggering a module load or hotplug event would be a win. For some reason, changing the permissions on these files with this particular bug didn’t work – I suspect either /proc wasn’t mounted at the time of the chmod or a later init script restored the permissions of these files. Either way, these options were out.

As yet another vector, I chose to make the block device corresponding to the /system partition world-writable. I pulled the setuid-root “run-as” application from the device, opened it up in IDA, and found a good place to patch it to cause it to fail to drop privileges, so that rather than allowing me to run with a particular application’s privileges, it would grant me a root shell. I then patched these bytes by writing directly to the block device. It’s ugly, but it works.

Download

Download the Windows version here. To root your phone, install LG ADB drivers, put the device in USB debugging mode, connect via USB, extract the zip file, and execute “run.bat”.

This exploit is not guaranteed to be 100% effective or stable. In a worst-case scenario, you may need to reflash your build and try again.

I encourage anyone thinking of donating in thanks to direct your donation to the American Red Cross or another reputable charitable organization. If you absolutely insist on throwing money at me instead, you can donate below.

Download the Windows version here, or the Linux/OSX version here. To root your phone, install LG ADB drivers if on Windows, put the device in USB debugging mode, connect via USB, extract the zip file, and execute “run.bat” (on Windows) or “run.sh” from a terminal (on Linux/OSX).

I encourage anyone thinking of donating in thanks to direct your donation to the American Red Cross or another reputable charitable organization. If you absolutely insist on throwing money at me instead, you can donate below.

Plagiarism for Profit

After doing some research on what’s been done on this device in the past, I found that it has apparently been rooted before, prior to the most recent OTA update. Someone by the name of “Evil_DevNull” published a root exploit here, that appeared to take advantage of a command injection vulnerability in a utility called “cmdclient”. He then proceeded to repeatedly request and receive monetary donations. This would all be fine (donating to developers is a good way to support their otherwise unpaid work), except Evil_DevNull seems to have ripped off the exploit used here to root the Acer Iconia A100, which is just a variation on an exploit published as “iconiaroot” here, authored by “sc2k”. Congratulations, Evil_DevNull, you’ve managed to profit by ripping off someone else’s exploit without credit!

Stupidest Root Ever?

Anyway, back to the fun stuff. After confirming that cmdclient is installed setuid root, I pulled up IDA and took a look at what it does. What I saw was so broken it was hard to believe.

The first few arguments cmdclient supports are “ec_recovery”, “ec_btmac”, “ec_snid”, “ec_skunumber”, and “ec_imeiwithbarcode”. Each of these commands builds a command string using the second argument (such as “echo [arg] > /sys//EcControl/RecoveryMode”) and executes it using system(). These are all trivial command injection vulnerabilities: something like “cmdclient ec_skunumber ‘; [my cmd];'” works fine to execute arbitrary commands as root. Ok, device rooted, that was easy.

But one of the other cmdclient options was so ridiculous that it’s hard to believe it isn’t a deliberate backdoor. “cmdclient sys_open” will perform a “chmod 777 /data” and “chmod 777 /cache”, among a few other things, which obviously cripples the security of the device and allows gaining root yet again. They might as well rename the application “own_my_device_now”.

Download

If you’re a Xoom FE owner, you can download a Windows root script here or a Linux/OSX version here. Install the appropriate Motorola drivers, connect your device via USB, extract the appropriate zip, and execute “run.bat” (on Windows) or “run.sh” from a terminal (on Linux/OSX). Enjoy.

Download the Windows version here, or the Linux/OSX version here. To root your tablet, install Motorola ADB drivers if on Windows, put the device in USB debugging mode, connect via USB, extract the zip file, and execute “run.bat” (on Windows) or “run.sh” from a terminal (on Linux/OSX).

Is anyone else getting bored of this? I sure am. OEMs: unlock your bootloaders, you are not going to win this one.

Download the Windows version here, or the Linux/OSX version here. Same deal as always: install LG ADB drivers if on Windows, put device in USB debugging mode, connect via USB, extract zip file, and execute “run.bat” (on Windows) or “run.sh” from a terminal (on Linux/OSX).

Apparently this was considered unacceptable by the raging masses of Android fanboys, who not only believe they are entitled to exploits for free, but are also under the delusion that $200 total is a lot of money in exchange for this kind of work. I’m disappointed in the response by the community, but I’m going to turn it into a positive thing.

The bounty is now entirely for charity. 100% of proceeds will be donated to the American Red Cross. I will post donation receipts after donating. You can donate at https://www.wepay.com/donations/droid-4-root-bounty.

But Where’s the Root Exploit?

The Windows version of the exploit can be downloaded here. Make sure your device is in USB debugging mode, attach it to your PC, ensure you have the latest Motorola drivers installed, extract the entire zip file, and execute “run.bat”. Enjoy.

Update: a Linux/OSX version of the script is available here. Same deal: USB debugging mode, attach to PC, extract zip file, change into the zip directory, and invoke “./run.sh” from a shell.

The Bug

The Sony Tablet S has a logging service running as root named nfx_log_service. This service maintains on-disk backups of the Android logcat buffers in the /log directory. This directory is group-writable and group “log”, which is granted to the ADB shell, so we can modify files in this directory.

The logging service uses predictable filenames for its output. Specifically, “Kernel.txt”, “AndroidMain.txt”, “AndroidEvent.txt”, and “AndroidRadio.txt” are used. As you might expect, by replacing these files with symbolic links, it’s possible to cause the logging service to either create a new file containing the contents of the appropriate log buffer, or if the symlink is in place at boot time, append the appropriate log buffer to an existing file. These files are created as root:root 0644, so once they are created we do not have the ability to control their contents.

The Goal

Normally, I’d go straight for victory by creating a symlink at one of the logfile locations (I chose “/log/AndroidRadio.txt“) to /data/local.prop and writing “ro.kernel.qemu=1″ a whole bunch of times to the radio log. This would cause /data/local.prop to be created containing the ro.kernel.qemu property, so that when I reboot the device ADB runs as root and it’s game over.

Unfortunately, that doesn’t quite work here. The Sony Tablet S already has a /data/local.prop file, and worse, it’s actually a symlink to /configs/local.prop. Since /configs is a read-only mountpoint, we won’t be able to overwrite this file. However, if we could remove the existing /data/local.prop, we could create a new file there that sets the ro.kernel.qemu property and allows us to win. But how can we use our logger vulnerability to remove a file?

Trickiness

It turns out the Android package manager has an interesting behavior. Packages have data directories at /data/data/[package]/. Ordinary packages have a lib directory in the data directory for native libraries. However, system packages (like the ones installed by Google or the OEM, in this case Sony) are not expected to have libraries in this directory. If any system package has files in its /data/data/[package]/lib/ directory, those files are deleted on boot by the package manager. Interestingly, this includes following symlinks. So if we can somehow cause a system package’s data folder to contain a symlink at /data/data/[package]/lib that points to /data, then the /data directory will be erased on boot, wiping out /data/local.prop and allowing us to create a new one and gain root.

Android devices contain a program called “run-as” that allows the ADB shell to assume the privileges of any application that is marked as “debuggable”. This is determined by checking the /data/system/packages.list file, which contains a list of packages, their uids, the debuggable flag, and their data directories. For the exploit, we can pick any system application – I chose com.google.android.location.

We can use our logging vulnerability by creating a symlink at /log/AndroidRadio.txt that points to /data/system/packages.list, rebooting the device, and running a program that logs packages.list lines for a fake application that’s marked as debuggable with the same uid as this system application. For example, I used:

com.pwn.me 10026 1 /data/data/com.google.android.location

In this case, 10026 was the uid of com.google.android.location. This might vary based on device. At this point, the logging service appends this line to packages.list, and we can “run-as com.pwn.me”, at which point we have the privileges of our system package. We can then replace the system package’s lib directory with a symlink to /data, reboot the device, exploit the logger again to create a fresh /data/local.prop containing the line “ro.kernel.qemu=1″, and reboot again, at which point ADB is running as root and we can install su and Superuser.

The Final Product

A script that automates these steps on Windows is available here. To run it, ensure your device is in USB debugging mode, connect it via USB, extract the zip, and run “run.bat”. Enjoy!

If you were involved in raising a bounty for this exploit, donations can be made below.

Instructions

• 1. Make sure you have the latest ADB drivers installed on your PC, and that your device is in USB Debugging mode. More detailed instructions for this are available here.
• 2. Download the root exploit here.
• 3. Make sure your Thinkpad is connected to your PC via USB, is turned on, has the screen unlocked, and is connected to a wifi network.
• 4. Extract the entire zipfile, and run “run.bat”. Follow any directions given in the command prompt closely, and ignore any activity on the Thinkpad itself.

Enjoy!

If you were involved in raising a bounty for this exploit, donations can be made below.