My Hero Adventure (II) – How ‘to root’ your Android phone
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 2.6.30.4. 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 (<= 2.6.30.4) 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.
Rooter
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)
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...
Status update
This is a quick note to give an update on my personal life and that kind of things ;-).
As some of you already know, I'll continue working in The Netherlands for one more year, until September 2010. The workplace will be the same, so I'll be working on smart cards and embedded devices, a little bit of Java programming and playing with interesting things such as fault injection (voltage/clock manipulation or laser radiation injection) and side channel analysis.
On the personal side (i.e. not work-related), at the end of June / beginning of July I went to Valencia for my summer holidays. I was at Campus Party, where I gave a presentation on smart card security and I worked together with Javi and Amin to achieve the first position of the security wargame organized by SbD.
Since then, I've been playing soccer quite a bit with the new team as well as going out more than I expected (partly due to the soccer team), being the case that most of my friends from last year did go back to Spain or were still on holiday.
On the other hand, I've both an HTC Hero smartphone, which is something I've been wanting to do for a while now. Actually, it's a quite nice device and I've been tinkering with it and trying to discover how it all works. This means you can expect a related post in a few days... but for now a small preview:
$ adb shell
$ rootsh
#
Yes, I already got root on the device based on some information I found out there ;-).
Finally, at the end of this week I'm going back home. First I'll go to Madrid, where I expect to gather with some of my Erasmus friends, some people from Wadalbertia and where I'll have my cousin's bachelor party. After this, I'll go to my village for the whole week... I'll try to schedule some post for you guys.
Back to life!
After being offline for almost the whole month of August, the server where this blog is hosted has misteriously become live today. I'm saying misteriously 'cause according to Javi it seems no one has powered it on, but it was just that the switches it's connected to were not online.
I'm sorry for the absence, you can expect to see new content from my side in a couple of days or so.
Crypto Series: DES and AES Visualization
Thanks to previous posts in this series we already know how the DES and AES ciphers work. Now we'll use ryptool to get a better understanding of these algorithms and see how every one of the described steps works.
To this end, we first launch Cryptool and then go to Indiv. Procedures > Visualization of Algorithms > DES to see the DES algorithm. We'll get a window which will show the different steps in the algorightm, together with navigation controls that we can move somewhere else if they are placed on top of part of the animation due to our screen resolution.
This image shows one of the steps in the DES visualization:
DES Visualization
For AES we have two options. The first of them, which can be found in Indiv. Procedures > Visualization of Algorithms > AES > Rijndael animation, provides a Flash animation explaining every step in the AES cipher.
AES Visualization
The second one, accessible through Indiv. Procedures > Visualization of Algorithms > AES > Rijndael Inspector, allows us to see the AES state in every intermediate step throughout the algorithm. This would allow us to check an hypothetical AES implementation:
AES Inspector
As you can see, once again Cryptool proves itself as a valuable educational tool for Cryptography, both classical and modern algorithms.
Understanding RHUL’s SSH attack
Last week a rumor about a 0 day exploit on OpenSSH being actively exploited arose. In some places I found links to Bugtraq's note about the OpenSSH attack published in a paper of the Royal Holloway University of London back in November 2008.
The paper, Plaintext Recovery Attacks Against SSH, describes an attack which provides knowledge of 32 bits from an arbitrary ciphertext block from an SSH connection when CBC mode is used. Personally, I didn't read the paper when it was published, I just took a quick look at it and I didn't feel like reading it completely.
However, when I saw the generated stir around this issue I thought it was time to take it again. And this post is the result: an attempt to explain how the attack described in this paper works.
SSH Binary Packet Protocol
SSH BPP is the protocol in charge of defining the binary packet structure of SSH, which supports the encrypted packets that conform an SSH connection. A data packet in an SSH connection is encoded as follows:
BPP Message
The Length field ( 4 bytes) indicates the size of the remainder of the packet. The Padding length field (1 byte) encodes the length of the final padding, which makes the packet a multiple of the block size. After this field, the message is added, and finally the padding, which has to be between 4 and 255 bytes of random data.
Two cryptographic operations are applied to this message: an encryption and a MAC. The MAC is computed over a sequence number which is never transmitted (it is kept by the two ends of the communication) concatenated with the original message depicted above. The encryption is applied to the original message only.
Therefore, when SSH recieves a packet, the first thing it has to do is decrypting the first ciphertext block to obtain the message length. Then, it waits to decrypt as many bytes as the packet indicates, in order to decrypt them and check its integrity with the MAC, which provides message authentication and protects your SSH sessions against modification while they are traveling from client to server.
SSH BPP's problem
The problem with SSH BPP described in the paper is a consequence of the combination of several factors. On one side, we have that OpenSSH returns different error messages for different situations: when the decrypted length does not pass some sanity checks (e.g. it is not a multiple of the block size) and when the computed MAC does not match with the valid one. Therefore, observing the error messages one can obtain information on what caused the interruption of the connection.
On the other hand, we have that the first block indicates how many bytes the server waits for before calculating the complete MAC. Therefore, assuming the sanity checks over the message length are passed, an attacker could inject a data block, and then inject block by block until the server says "Hey, wait, the MAC does not match!".
At that point, the attacker knows that after decrypting the injected block with the server's key, the result contains in its right-most 32 bits a value equal to the number of blocks injected in the connection.
But now the complicated part starts, because the attacker needs to link these obtained 32 bits with the 32 bits that the original packet held. If the packet was encrypted with a completely unrelated key, then knowing that decrypting it under a different key gives a certain value provides basically no information on the original message.
But here CBC mode comes to play. We already know from our previous block ciphers post that this mode performs an XOR of the previous encrypted block with the current plaintext block before encrypting it with a fixed key.
Let's assume we want to obtain data from a previous packet 
But when we inject it into the connection, assuming the previous ciphertext block is known, 
So, it will decrypt the injected block, and will XOR it with the previous block. This result will be regarded as the first block of a packet, and therefore its initial 32 bits will tell the server the packet length.
Thus, we can start injecting new blocks and observing the reaction of the SSH server. Once it returns a MAC error, this means that the initial 32 bits of 
Further, from the previous two equations we can obtain the following relation:
Where the left-most 32 bits of all values at the right side of the equation are known, and the value at the left side of the equation is what we wanted to obtain. In this way we can get to know the left-most 32 bits of the target block.
Implications of this attack
So, we know how the attack works... now it's time for asking ourselves whether we should be worried about it or not. In principle, the attack is not too complex and allows the retrieval of 32 arbitrary bites of an SSH connection with a probability of 
This means that, on average, an attacker would succeed one out of 262.000 times, forcing the client to reconnect so many times to the server. I'm pretty sure anyone would be tired after 3 consecutive attemps and would think that something is wrong ;-).
Further, the attacker needs to perform a man in the middle to be able to inject data into the connection. In local area networks it's not a big deal, but over the Internet it gets more complicated.
And even then, an attacker would have 32 bits of data, 4 ASCII characters of your password... which I hope has some more than that :D. Therefore, in my opinion the attack does not have practical implications, although it's always good to update to a patched version and/or use a mode different than CBC.
What this attack actually does is contributing as an interesting example of how important details are in crypto applications and protocols. If the protocol would not depend on a length field which needs to be decrypted for waiting such a number of bytes, or would not use CBC mode or simply would not return additional information about errors (simply closing the connection indicating that something was wrong, regardless of what this something is), none of this would be possible.
Requirements for (secure) Electronic Voting
Some time ago kuasar told me about an initiative named Partido de Internet (PdI for short). The idea is to create a political party which would vote every law proposition and every initiative in the parliament depending on the results of an individual electronic election. So, affilates would vote in a per-initiative basis through the Internet, and the representatives of the PdI in the parliament would vote according to the results.
Setting aside the political implications, whether I (or you) think this is a good idea or not, I want to talk here about electronic voting. As soon as she mentioned it to me, I started thinking "Wait... this is not so easy. You know, we want elections to be secure, one doesn't want everyone to know what he voted, but he wants his vote to be counted in the right way... there are several requirements which are not so easy to meet".
So I asked her about how would they implement it... and the answer was that probably using the e-DNI, the spanish electronic id card, which of course provides digital signatures. Yeah, that's right, you could use such a device to implement an electronic voting scheme... but there is quite a lot of thinking involved in order to make it right!
Let's start here a series of posts for brainstorming about e-voting. I'll start setting up what I (and the literature I have from last year's subjects about crypto protocols 😉 ) think an electronic voting scheme needs to provide. These are the requirements I can see, but maybe you can think of some other so feel free to comment on it!
- Privacy or Anonymity: A voter wants his vote to remain anonymous. There should be absolutely no way to link a voter with its vote, neither by other voters or by the election authorities.
- Eligibility: Only voters who are eligible for voting should be able to vote, and only once. A legitimate voter should not be able to cast two different votes, and of course a non-legitimate voter should not be able to vote.
- Fariness: The results can only be obtained at the end of the elections... so that other voters cannot be influenced.
- Verifiability: The outcome of the elections needs to be fair, i.e. the results have to be equal to the votes casted by the voters.
- Individual verifiability: An individual voter can verify that his vote was actually counted.
- Receipt free: A voter cannot prove that he voted for a given party. This way one cannot be coerced to vote for a given party.
Some of these requirements are more important than others, some of them are really required for any fair electronic voting system that one can think of, and others are just desirable. In subsequent posts we will look at some electronic voting protocols and try to see which requirements they meet.
Before finishing, one thing is clear: meeting the requirements is not trivial. For instance, vote privacy and verifiability seem to pose a contradiction... how come one can only vote if he is eligible to it, but a vote cannot be revealed to anyone? We'll see some ways of doing it in some time ;-).
Crypto Series: Introduction to modern cryptography
Let's leave aside our paper and pencil algorithms and get into modern cryptography. As most of you already know, modern cryptography is divided into two big blocks, according to the type of keys used.
On one hand, we have symmetric (key) cryptography. As you can imagine, it uses a symmetric key, shared between transmitter and receiver. This means that for each pair of entities communicating in a system, a different secret key is needed.
In this group we have block ciphers like DES/3DES and AES, as well as stream ciphers (for instance, RC4). The former divide the text into several blocks of fixed length, and encrypt block by block. The latter generally start from a key and generate a sequence of bits or bytes (key stream) from it, which will be XORed with the plaintext.
Further, there are the so-called modes of operating of block ciphers, which allow us to convert a block cipher into a stream cipher. These modes exist because for a given block cipher in its elementary mode, two identical blocks would give the same ciphertext under the same key, thus revealing part of the text structure. Later in this series we'll devote a post to these modes of operation.
However, the main problem of symmetric crypto resides in the key management. As I said, for each pair of users a secret key shared between them is needed. This means that for 3 users we would need 3 keys, for 4 users 6 keys, and in general, for n users we'd need n·(n-1)/2 keys.
As can be seen, the number of keys to be managed follows a quadratic order with the number of users to be intercommunicated. Therefore, with as few as 100 users we would need as much as 4950 different keys!
But Asymmetric or Public key Cryptography comes to help and solve this problem. This kind of cryptography works by having a key pair for each user. Each user keeps its private key secret, while its public key is known to the rest of the users ( hence the name 😉 ).
When user A wants to send a message to user B, A simply has to find B's public key, 
So far, this seems secure. Further, we just have n public keys, one per user. However, key management is still a problem: how do we make sure that a given public key pertains to a given user? In a closed environment that's easy, we just need to exchange keys in person and we're done. But... what about the Internet?
The solution is a system to determine the trust on public keys. One of the approaches is based on digital certificates, implementing what is known as a Public Key Infrastructure (PKI). Another approach is the one adoptet by PGP, based on so called trust rings. Or in other words, friends of my friends are my friends.
Finally, note that using these concepts (symmetric and asymmetric crypto), mechanisms to protect message authenticity and/or integrity can be implemented: the so called Message Authentication Codes (MAC) use symmetric crypto, while digital signatures are possible thanks to asymmetric crypto.
We'll also devote posts to all these questions in the future.
Timing attack in Google Keyczar library
Javi mailed it to me last week, and now I came across it again while reading my feeds. Nate Lawson found and described on his blog a timing (side channel) attack in Google Keyzcar library.
Take a look at his post, it's a typical problem found in string/array comparisons, and you should take it into account when programming embedded devices and any other security-related code in general.
PD: I said very soon, didn't I? 😛
Conferences, slides and documents
Yes, I know. I've been idle a looong time. I'm sorry, but I've been busy with friends and family visits, moving to a new room and other stuff. Today I bring you some links to documents of conferences, and I promise to be back very soon.
Archives Black Hat Europe 2009
Malware analysis course from F-Secure at the Helsinki University of Technology. The slides from the course are freely available for everyone.
Enjoy!