HTC launches htcdev.com

Yesterday HTC launched a new developer portal at www.htcdev.com.

HTC announced the following: "Our developer portal went live today! Currently on HTCdev.com you can check out an early access version of the OpenSense SDK for the 3D display on Evo 3D, the Tablet Pen used with HTC Flyer and also download kernel source code for HTC Android devices with even more to come. The site is also the future home of bootloader unlock process. Check it out!"

This means that the kernel sources for the HTC Evo 4G running Android 2.3.3 are now available for download and the workaround in my previous post is no longer needed.  Hopefully HTC keeps their kernel sources up-to-date with this new site.

The other intriguing part of the announcement is the HTC promises a web tool that will unlock the bootloader on HTC devices. So how will this work? "The Web tool, which will launch this month, requires that you register an account with a valid e-mail address and accept legal disclaimers that unlocking may void all or parts of your warranty. Then plug in your phone to a computer with the Android SDK loaded to retrieve a device identifier token, which you can then enter into the Web tool to receive a unique unlock key via e-mail. Finally, apply the key to your device and unlocking will be initiated on your phone."

While I applaud HTC for making it easier for anyone to unlock their bootloaders (which means trivial rooting, custom kernels, and awesomeness), I think it's pretty lame that HTC will require disclosure of personal identifiable information and a voided warranty to use the tool.  I'll be interested in seeing exactly what information HTC collects.

Compiling custom kernel modules for HTC Evo 2.3.3 Gingerbread

Some of my current research on Android forensics and security requires the loading of custom kernel modules.  In my previous post I detailed the steps required to compile and load custom modules on a rooted phone.  I recently updated my rooted Evo to Android 2.3.3 Gingerbread and was frustrated to see that HTC has yet to release the updated kernel source code.

Using an adb shell I can see that the phone is running linux kernel 2.6.35.10.

joe@zuul:~$ adb shell
# uname -a
Linux localhost 2.6.35.10-gc0a661b #1 PREEMPT Tue Jun 14 23:58:32 CST 2011 armv7l GNU/Linux

Luckily, HTC has released the Gingerbread kernel source for another phone, the Desire HD, which runs the same kernel version.  Assuming that the the kernels from the two phones would be very similar, I tried my hand at compiling the module for my Evo with the Desire HD source.  It worked!

To compile a kernel module for the Evo with the Desire HD kernel source requires a few extra steps:

• Download and unpack the Desire HD source code.
• Modify Makefile at the root of the source.  Change line 4 to read: EXTRAVERSION = .10-gc0a661b
• Follow the steps outlined in my previous post to export the config from the Evo, prepare the kernel sources, and compile the custom module

These steps worked for my phone and my module, but your mileage may vary.  It is unlikely that the kernels running on the two phones are identical, but hopefully the sources are similar enough to allow the functionality of your custom modules to work.  Of course HTC will eventually release the official kernel sources for the Evo 4G, but it's anyone's guess when that will be.

UPDATE (8/9/11):// HTC has released the EVO 2.3.3 GB Kernel sources.  See this post for details.

Phishing Web-Based Email Services with HTML5

Abstract: This paper presents a novel approach to phishing using the programmable session history stack introduced in HTML 5. The technique is implemented and tested against a sample of 100 Gmail users and 100 Yahoo Mail users. In this preliminary testing the technique has shown to be effective against approximately 9.5% of recipients.

Introduction

As the internet is becoming more ubiquitous and browsers are becoming more powerful, more and more people are moving away from traditional native applications and are doing most of their computing in the web browser.  Google recently released its CR-48 Chrome notebook, a laptop whose only operating system is the browser itself and which has no native applications.

Web-based email applications are also increasing in popularity.  Many are moving away from applications, such as Microsoft Outlook and towards web services such as Google's Gmail, Microsoft's Hotmail, and Yahoo's Mail.  Most websites utilize email as a means of identity control, allowing users to reset their passwords by clicking on a reset link that is sent to them in email.  This makes access to a user's email address desirable for hackers and identity thieves.

HTML 5 is the latest standard (in progress) for the markup language most commonly used for building content on the web.  HTML 5 introduces many powerful new features, which allows developers to build more powerful and useful web-based applications.  One of the new features in HTML 5 is the addition of a History Interface, which allows programmatic manipulation of the session navigation history.

In this paper I present a new phishing technique, which uses the HTML 5 History Interface to trick users into giving an attacker their email credentials.  Users will receive a link in their email to a harmless looking website.  When the website loads, a fake entry will be added to the session history.  If the user clicks the "Back" button in the browser they will be given a fake version of their web-based email application asking them to re-enter their password.  This attack will take advantage of the fact that, since the link was sent to a web-based email service, the attacker can guess what the previous page looks like.  It also takes advantage of the fact that users may implicitly trust a website that appears to be the page the navigated from, after clicking the back button.

The full paper can be found here.


Keywords: phishing yahoo mail, phishing gmail, html5, html 5 history interface

Linux CAP_SYS_ADMIN to root exploit 2

I've released my first Linux kernel exploit.

Guide to Compiling Custom Kernel Modules in Android

I've spent the better part of today trying to figure out how to compile and load a custom kernel modules in android to aid me in my research.  It has been in entirely frustrating experience, as there is almost no documentation on the topic that I can find.  Below you will find my attempt at a guide.  Hopefully this will help save someone else the hassle.

PREREQUISITES

Disclaimer:  This list may be incomplete, since I've not tried it on a fresh install. Please let me know if I've missed anything.

• Install the general android prereqs found here. 
• Download and un(zip|tar) the android NDK found here.
• Download and un(zip|tar) the android SDK found here.
• Download and untar the kernel source for your device.  This can usually be found on the website of your device manufacturer or by a quick Google search.
• Root your phone.  In order to run custom kernel modules, you must have a rooted phone.
• Plug your phone into your computer.

PREPARING YOUR KERNEL SOURCE

First we must retrieve and copy the kernel config from our device.

$ cd /path/to/android-sdk/tools
$ ./adk pull /proc/config.gz
$ gunzip ./config.gz
$ cp config /path/to/kernel/.config

Next we have to prepare our kernel source for our module.

$ cd /path/to/kernel
$ make ARCH=arm CROSS_COMPILE=/path/to/android-ndk/toolchains/arm-eabi-4.4.0/prebuilt/linux-x86/bin/arm-eabi- modules_prepare

PREPARING YOUR MODULE FOR COMPILATION

We need to create a Makefile to cross-compile our kernel module.  The contents of your Makefile should be similar to the following:

obj-m := modulename.o
KDIR := /path/to/kernel
PWD := $(shell pwd)
CCPATH := /path/to/android-ndk/toolchains/arm-eabi-4.4.0/prebuilt/linux-x86/bin
default:
$(MAKE) ARCH=arm CROSS_COMPILE=$(CCPATH)/arm-eabi- -C $(KDIR) M=$(PWD) modules

COMPILING AND INSTALLING YOUR MODULE

$ cd /path/to/module/src
$ make
$ cd /path/to/android-sdk/tools/
$ ./adb push /path/to/module/src/modulename.ko /sdcard/modulename.ko

RUNNING YOUR MODULE

$ cd /path/to/android-sdk/
$ ./adb shell
$ su
# insmod /sdcard/modulename.ko

CONCLUSION

Ineviditibly you'll run into some errors that you will need to sort out, as I did with both my droid 2 and evo devices.  Feel free to post in the comments if you run into any major problems, and I'll try my best to help you out.

FrozenCache Woes

There was a talk given very recently at 27c3 that I was very much looking forward to.  Juergen Pabel gave a talk about his ideas on mitigating cold boot attacks on cryptographic keys.  Since cold boot attacks are possible due to flaws properties of physical hardware they remain a largely unsolved problem.

Pabel's idea is that you can store sensitive data, such as keys, in the CPU's cache, disable cacheing, and zero the data from memory.  This should leave us with the key stored in a usable state in the CPU.  It's a good concept, but unfortunately it doesn't seem to be much more than a concept at this point.

Not surprisingly, CPUs have caches for a reason and when they are disabled, performance suffers.  In Pabel's demo, he was running what seemed like nothing more than a terminal to enable and disable his proof-of-concept and even that was painfully slow.  I realize that Pabel was not presenting a full solution, and I know how far from complete many POCs are, but I'm not sure how much optimization can actually be done.

x86 processor's simply weren't designed for this sort of cache abuse.  They don't offer enough control over the cache for this method to really be feasible.  There are no obvious ways to disable only the parts of the cache of our choosing, and no way to prevent others from flushing the cache and either destroying our sensitive data or dumping it to RAM.

What we really need is a hardware-tailored solution to this problem.  I think there is a need for a dedicated piece of hardware, either built into the CPU or with fast access to it, that could be used as forensically secure storage for sensitive data.  Similar solutions seem to work reasonably well in consoles (unless you are into epic math fails like Sony).

Overall, cold boot attacks aren't a huge problem, since they require physical access to pull off, but with an increase in government asshat-ery at airports it would be nice to have a solution.

UPDATE:// Juergen was kind enough to address my concerns in the comments.  Read on.