Limited Entropy Dot Com Not so random thoughts on security featured by Eloi Sanfèlix

My Hero adventure (I)

So yes, I bought an HTC Hero a couple of weeks ago and I've been investigating it and looking around to see what's been happening in the android scene (let's call it this way 🙂 ). In this post I'm going to summarize what I discovered during my first days with the device... and will be followed by more updates because its edition is taking more time than I thought ;-).

First things first, the HTC Hero is a smartphone from HTC running a modified Android OS. It has a customized UI by HTC, multi-touch screen and browser with built-in flash support. Here is a small summary of the specifications:

• Processor: Qualcomm MSM7200A, 528 MHz
• Memory: 512 MB ROM and 288 MB RAM
• Quad-Band GSM/GPRS/EDGE and HSPA/WCDMA network connectivity
• GPS, Wi-Fi IEEE 802.11 b/g, Bluetooth
• Camera 5 Mpixel
• ...

Android development

Android provides a Java API for application development. Applications are normally implemented in Java, although it is possible to run ELF binaries compiled for ARM since it runs a Linux kernel. You can find all the documentation you need to start developing for the Android in http://developer.android.com/.

With the Hero, as with any other Android device I know of, you can enable USB debugging for development and use the tools in the Android SDK to connect to the device, upload applications and run them. Furthermore, the SDK provides an Eclipse plugin that makes it certainly easy to manage. You just press 'run as Android application' and it will run in your phone or in an emulator if no phone is connected.

However, the adb shell commands provides you a shell under the shell user and there is no way to get root.

Getting root shell access in my Hero

Didn't you say no way? Well... that's why it's written in italics ;-). Looking around I found references and howtos for rooting the Hero using the fastboot utility and flashing a recovery image into the phone. However I didn't have the sources used for creating this image so I decided to hold this for a while until I could actually look what was in there.

After some more reading, I also found the FlashRec utility which can be used to flash recovery images without having to reboot into flashboot mode and send it manually. And the source code was available! That sounds like a good oportunity to learn how things work in the Android world... so I downloaded the sources and started reading through them.

As it turns out, this FlashRec tool uses the sock_sendpage exploit for the Android, which sounds like fun ;-). So it includes an as_root binary which takes a template for a temporary file as its first argument, and then the command to be executed as root; when you press the 'flash' button, it just runs a flash_image binary included with Android but only executable for root.

But hey... do we really want to flash a recovery image? Well... it depends. In my case, I did because I wanted to install the new HTC Hero firmware update and I didn't have a handy Windows. But if that's not your case and you just want to obtain root, why don't you use this exploit to create a root shell?

You guessed it, that's what I did next :-). I just shrinked the FlashRec tool removing everything I didn't need, and made it execute a shell script that copied the /system/bin/sh shell into /system/bin/rootsh and gave it setuid root permissions. However, it took me quite a while to realize that there was no cp on this system! And it was because the ash shell it ships doesn't say Command not found when you type in cp as a non-privileged user, but Permission denied.

So my final script looked like this:


mount -o remount /dev/mtdblock3 /system
cat /system/bin/sh > /system/bin/rootsh
chmod 04755 /system/bin/rootsh
mount -o remount,ro /dev/mtdblock3 /system
exit 0

And after executing it I got the root shell waiting for me in /system/bin/rootsh. I only had to connect through adb and then run rootsh.


~ tuxed$ adb shell
* daemon not running. starting it now *
* daemon started successfully *
$ rootsh
#


Investigating the system structure

Well, we are in, now what? Let's take a look at the system structure: filesystems, shell, installed applications, etc. Let's start by running a mount to see what filesystems are there:

# mount
rootfs / rootfs ro 0 0
tmpfs /dev tmpfs rw,mode=755 0 0
devpts /dev/pts devpts rw,mode=600 0 0
proc /proc proc rw 0 0
sysfs /sys sysfs rw 0 0
tmpfs /sqlite_stmt_journals tmpfs rw,size=4096k 0 0
/dev/block/mtdblock3 /system yaffs2 ro 0 0
/dev/block/mtdblock5 /data yaffs2 rw,nosuid,nodev 0 0
/dev/block/mtdblock4 /cache yaffs2 rw,nosuid,nodev 0 0
/dev/block//vold/179:1 /sdcard vfat rw,dirsync,nosuid,nodev,noexec,uid=1000,gid=1000,fmask=0000,dmask=0000,allow_utime=0022,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8 0 0
#

Ok, we can see a read-only filesystem mounted in the root directory ( using rootfs ), the usual /dev and /proc stuff and three partitions of the NAND flash mounted over /system , /data and /cache. The first one of them is mounted read-only and the latter are mounted with read-write permissions but suid files and devices are forbidden in there. Finally, our SD card is mounted under /sdcard as a FAT partition with read-write permission, and suid, devices and execution of binaries is forbidden from that partition.

Now, you are probably wondering... what about the missing partitions in the flash? Honestly, I didn't know either... one of them is for sure the recovery partition, which is where the code for recovering the device in case of problems (i.e. reflashing it) is stored. It helps to avoid bricked devices ;-). But how do we find out what is what?

What I did is first rebooting my hero, because the device was started a while ago and I wanted to see the complete boot log doing a simple dmesg. Then I did it, and scrolled up to find this:


<5>[ 4.765655] Creating 6 MTD partitions on "msm_nand":
<5>[ 4.766082] 0x024c0000-0x02500000 : "misc"
<5>[ 4.767425] 0x026c0000-0x02bc0000 : "recovery"
<5>[ 4.768890] 0x02bc0000-0x02e40000 : "boot"
<5>[ 4.770355] 0x02e40000-0x0d840000 : "system"
<5>[ 4.771820] 0x0d840000-0x15a40000 : "cache"
<5>[ 4.773162] 0x15a40000-0x20000000 : "userdata"


So we have 6 partitions in the NAND flash: misc, recovery, boot, system, cache and userdata. That makes for a 512 MB NAND flash memory, which matches the advertised size. Now, we have 3 of them mounted, one of them is identified as the recovery image and another one presumably conatins the boot loader. What is the "misc" partition then? Honestly, right now I have no clue but I guess we'll find out in a later post.

That's it for today. I'm stopping here because I feel that it's taking forever and I want to post this and move on for something else.

To be continued...