Exploring Qualcomm's TrustZone Implementation | Hacker News Reader

Exploring Qualcomm's TrustZone Implementation

bits-please.blogspot.com

48 pointslaginimaineb15 comments

(Disclaimer: I'm the author of this blog)

In this post I describe an (initial) analysis of Qualcomm's TrustZone implementation, and a vulnerability that I've discovered which allowed complete arbitrary code execution within TrustZone (which I've responsibly disclosed to Qualcomm).

This is the first in a series of posts describing various kinds of vulnerabilities, so stick around if this interests you in any way!

In the following months, I'll be submitting detailed vulnerability write-ups and exploits for Android related vulnerabilities that I've discovered in the last year (but have been too busy to write about because of the academic year).

Please let me know if you have any questions/comments! I'll be more than happy to answer.

Thanks for this. Really interesting.

Might be a longshot, but you seem like a person that might know :) Do you know of anyone that has taken a MediaTek chip and customized the OS for a simple phone implementation?

Thanks for reading!

I haven't heard of such a project, but I'm not 100% sure I understand what you mean; are you asking if there are non-Android implementations on mediatek chips?

Exactly. Non-Android. So either bring up an RTOS or something else on the chip or simply customize their UX layer to make it seem like a different OS. No worries! Thanks for responding :)

There was a 5 month gap between the first blog post and this one. Was it 5 months of work that culminated in this latest blog post? And how long do you think it will take to get to your endgame of showing the full exploit?

Actually, I haven't been able to write posts these five months because of the ongoing semester. The whole discovery to exploitation didn't take more than a week, AFAIR.

As for the next post (with full exploit code!), you can expect it within 3-4 days tops.

Have you looked at any of the files under the N5's /vendor/firmware directory? Specifically, I believe the .bXX and .mdt files are modules that can be runtime-loaded into the secure element. .b00 and .mdt always seem to be some ELF wrapped file. They look to contain X.509 certificates so I'm guessing you can't just ask qseecom to load arbitrary files... without an exploit in the TZ. ;-) /vendor/firmware/discretix/dxhdcp2.b02 is interesting because it has many strings in plaintext and other bytes that seem to disassemble to valid Thumb-2 code. Is TZ code all Thumb or can you mix Thumb and ARM like in regular context?

I've reversed those files in the past as well, and you're correct, they are TrustZone applications (like Widevine, DxDHCP, Keymaster and more). I have a script which can be used to reunite these pieces of code into an ELF file which can be loaded into IDA (more about this in about a month!)

Anyway, if you're looking to load arbitrary code into TZ, wait for the next blog post (approx. 2-3 days)!

Awesome, thanks!

This is a pretty awesome piece of reverse engineering. laginimaineb++

Please change your Blogger theme to do "Month Dayth, Year", because Euro-style 4/8/15 for Aug 4th is confusing to over half of the English speaking world.

Other than that, very interesting write up.

There's a standardized date format that's unambiguous and universally understood: https://xkcd.com/1179/

Only confusing to Americans...

Rather "only confusing to US citizens" (there are more states in (even north) america than the United States):

> https://en.wikipedia.org/wiki/Date_format_by_country#Map

You are right.

Reply on news.ycombinator.com