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!

MediaTek chips are in 37% of all smart phone and IoT devices in the world. Modern chips contain AI processing unit (APU) and digital signal processing as well. The APU and the DSP have a custom architecture called Xtensa, where MediaTek even has their own custom instructions. How did they find all of this out? By a whole lot of reverse engineering!

First, they rooted a Xiaomi Android phone. The host operating system must communicate to the chip somehow; this was done via the audio_ipi at vendor/lib/hw/audio.primary.mt6853.so. This library has a single export: AudioMessengerAPI, which is responsible for Inter-processor interrupt (IPI) messages to the audio DSP. The driver has 6 ioctls, which the authors interact with directly during the later proof of concept.

The authors of the article got the firmware by stealing the factory update image file audio_dsp.img. However, this also could have been done by reading the /dev/block/platform/bootdevice/by-name/audio_dsp on a root device. The article dives into the format of this img as well but they do find out it runs a custom version of FreeRTOS. Here is the interesting part though: IDA has no idea how to process a large part of this code.

IDA Pro 7.6 supports the Tensilica Xtensa architecture. But, not well and there are many customized instructions, which can be variable length as well. Using the Xtensa SDK many more of the instructions can be decoded. Additionally, MediaTek had very helpful logging that made it easy to find functions and their usage. Not everything was perfectly decoded but it was good enough for this research.

The drivers, from the Android side, have to interact with the chip somehow. The authors reviewed this source to find the best possible entry points in the code for the DSP chip.

The first vulnerability they found was a classic heap overflow in one of the IPI message handlers (ID 6). When processing the input, the function copies the message payload into an object, with the amount of bytes being copied directly controllable by an attacker. There is no validation on this size, which leads to a memcpy out of bounds write on the heap. Sending more than 20 bytes triggers the bug.

A similar issue was found with an IPI ID of 7. A copy is performed with a user controlled size in a buffer of only 0x20 bytes. Even though there is a validation, it checks the wrong size value (0xE0). It is like somebody wrote the code with a hardcoded size but the eventually size of the buffer change, without the validation ever being changed.

The last vulnerability on the DSP processing is an out of bounds write via lack of validation of array indexing. Simply put, the user can provide an index but this index is never validated. By providing something outside of the expected range, a write can occur with a user controllable value.

These bugs are awesome but there is one problem: only specific processes are allowed to use these drivers. Some sort of privilege escalation would be required to hit these drivers! The authors noted that the Mediatek hardware abstraction layer (HAL) was controllable via standard function calls to the AudioManager. The authors believe that this was left over for testing purposes but gives us access to more things than we should!

Normally, the HAL configurations are set by the manufacturer and are not a source of malicious input. But, in this case, we can alter the HAL configuration to do whatever we want. Since this is not a normal location for input, the security was much weaker. On the Xiaomi device, they found a vulnerability that allowed for the calling of the DSP drivers from inside the library.

A few things that I took away from this:

• Hard to reverse targets tend to have easier bugs. The effort is just put into reversing instead of vulnerability hunting in this case.
• Sandboxes are quite useful! As we move more and more towards sandboxing, LPEs are going to become more common.
• Changes in unexpected places usually leads to security bugs.