Resources

People often ask me "How did you learn how to hack?" The answer: by reading. This page is a collection of the blog posts and other articles that I have accumulated over the years of my journey. Enjoy!

There are a seemingly endless amount of cellular protocols and specifications. How do our phones handle this? The baseband controller chip. Since these chips are closed source and are insanely complicated, security research on these is difficult.

The authors of this paper (who presented at CanSecWest as well), built an emulation platform for Baseband controllers called FirmWire. They wanted to be able to fuzz and statically analyze these platforms with a debugging environment.

The custom items for each vendor are how the program is loaded into memory (loader), peripherals and hooks to interface with the device. At the heart of it, is QEMU though. Besides the emulation, they created hooking and many great debugging plugins.

For the vendors, they chose to implement Samsung and MediaTek. Unfortunately, the biggest player Qualcomm has a proprietary architecture without QEMU support. They had to manually reverse engineering both images in order to understand how it worked, before the emulation was possible.

The images are Real Time Operating System (RTOS). Unlike regular operating systems, these are based upon launched tasks. So, to build a fuzzing harness, it is all about calling these tasks correctly from Python. The fuzzing is coverage based but must rely on black-box instrumentation.

Initially, they decided to fuzz three components: LTE Radio Resource Control (RRC), GSM Session Management (SM) and GSM Call Control (CC). They ended up finding 7 unique vulnerabilities this way.

Four vulnerabilities were found in RRC. The first one is in the parsing of data pre-auth. The parsing calculates an invalid length for a buffer on the stack, leading to a buffer overflow that can overflow the instruction pointer. This vulnerability existed in the reencoding, which demonstrates why full emulation allows for better bugs to be found. Two other similar re-encoding bug was found on the heap, which crashes since the boundaries have a static canary of (0xAA).

A double free was found in MediaTek's baseband image for RRC. This occurs when something is freed, an error path is taken, leading to a double free. This is dedicated by the heap allocator itself, which is cool.

In CC, they found a buffer overflow from an unsafe memcpy. The OTA length field is trusted, even though the size should never be larger than 16 bytes. The final bug is caused from an error case still attempts to decode data, resulting in a buffer overflow on the stack.

They eventually reproduced the vulnerabilities over the air using a USRP software defined radio. From talking to them at the conference, sending the bad bytes was the easy part of it. But, setting up a fake base station to connect to the phone is the complicated part. Overall, real amazing research!