Comment by gruez
8 years ago
>Qualcomm IZat location services
did a quick check, it's not on my phone (SD 820 SoC).
>other location-based trustzone applets remain running even on custom ROMs.
I have no doubt some proprietary blobs still remain on custom ROMs, but do those actually send back location data to the OEM?
You have a Qualcomm Snapdragon 820? Oh yes, IZat is definitively there, along with other interesting trustzone applets :)
It is running under QSEE (Qualcomm) and/or MobiCore (Trustonic) OS, which is separate from your Android OS. It is left untouched by custom ROMs.
While most of the terms there aren't Google-able (QSEE, MobiCore, trustzone applets, etc) the IZat page seems to almost boast about the core argument:
https://www.qualcomm.com/products/izat
Scroll down to "Cloud-Based Assistance" and "Built Right In."
I do not understand.
Even if there was a separate OS running in parallel with Android, how could it access the wireless-networks-based and satellite-based location data? I thought that access to these things is controlled by Android.
In other words, when I turn off e.g. satellite location data in Android, can IZat (which, according to your post, runs outside of Android) or other similar spyware keep secretly using it anyway? That would be quite worrying.
I suppose that the location data can be collected by sniffing the low-level communication between the radio device and Android kernel, provided that it has been enabled in Android first. But even then, how could this location data be transferred out of the device? Are these "parallel-running" OSs also able to somehow "tap into" Android's network layer and send the collected data out?
Oh, sweet summer child ...
"Even if there was a separate OS running in parallel with Android, how could it access the wireless-networks-based and satellite-based location data? I thought that access to these things is controlled by Android."
There is a separate OS running in parallel with Android and it is running on the very hardware that makes the network connections to the cellular network that you are speaking of.
In fact there are two - the OS and software stack that run on the baseband processor and the OS and software (java apps) that run on your SIM card, which is a full blown computer with its own memory and processor, etc. In fact, your carrier can upload new java programs to your SIM card without your knowledge at any time.
Your final question is a good one - many (most ?) implementations give the baseband processor DMA to the main, application processor. So you are hopelessly owned. Deeply, profoundly, hopelessly owned.
6 replies →
You seem flabbergasted so I wanted to directly answer your questions.
> how could it access the wireless-networks-based and satellite-based location data?
The OS is either running on the same hardware as Android or has the same direct hardware connections.
> I thought that access to these things is controlled by Android.
Only for things executing within Android. This is just a fancy UI - Android doesn't actually control the hardware.
> In other words, when I turn off e.g. satellite location data in Android, can IZat (which, according to your post, runs outside of Android) or other similar spyware keep secretly using it anyway?
Yes.
> I suppose that the location data can be collected by sniffing the low-level communication between the radio device and Android kernel, provided that it has been enabled in Android first.
You shouldn't think of it as between the radio device and Android but rather between the radio device and the CPU. A CPU that another OS can and is running on. Android is not special here.
> But even then, how could this location data be transferred out of the device?
The same way Android sends data out of the device. The OS asks the CPU asks the radio to transmit some data. Bog standard.
> Are these "parallel-running" OSs also able to somehow "tap into" Android's network layer and send the collected data out?
Yeah but like I said its not Android's network layer. Android is a guest on top of the system just like any other OS running.
Most cellular devices have a Baseband processor with RTOS or run a hypervisor that runs a RTOS and your phone's operating system.
These OS images are untouched by your custom ROM because they're black box.
https://en.wikipedia.org/wiki/Baseband_processor
The SIM card is a separate OS that gets underneath the SOC's OS. It can run its own applets without the knowledge or permission of the SOC OS.
https://www.youtube.com/watch?v=31D94QOo2gY
The baseband is a completely different RTOS as well. And then there's also TrustZone running in the SOC as well.
Are you sure? According to https://forum.xda-developers.com/android/software-hacking/ar..., they have corresponding apps running in the main OS as well.
what about exynos chips?
It uses these domains:
http://xtrapath1.izatcloud.net
http://xtrapath2.izatcloud.net
http://xtrapath3.izatcloud.net
I'm not sure what part of the OS is sending it, but it's definitely happening (and is block-able!)
> did a quick check
How? Thanks.
searched up the package name, and according to https://forum.xda-developers.com/android/software-hacking/ar..., it's installed at /system/priv-app/xtra_t_app, which was not on my phone.
Also noticed that most posts had mentions of IZat in their location settings, which my phone did not have (in lineageos or stock)
You're looking in the wrong place.
TrustZone OS is started during SBL2 (secureboot level 2), running in hypervisor mode, while you're looking at the Android OS started during SBL3 (secureboot level 3). You cannot see hypervisor processes & apps from your vantage point (the android kernel).
The trustzone OS is usually located in TZ partition, and it uses some additional partitions for custom TZ apps and data persistence.
The hypervisor has independent access to the internet, the wifi card (for indoor location), and more.
Qualcom boot process, showing SBL1, SBL2 and SBL3 stages:
https://forum.xda-developers.com/showthread.php?t=1769411&pa...
It goes without saying that without TrustZone OS, the phone won't boot to Android OS (won't proceed to SBL3).
You don't seem to appreciate the fact that the OS you interact with on a modern smartphone is essentially a guest.
There's a world of proprietary complexity you have zero visibility into, and much of it is running with direct access to hardware the application OS you interact with can only partially make use of.