it’s clear that their hardware level enhancements include some profiling ability to figure out what other software - on app but also on lower level - is doing.
I have zero insight, so this is educated guessing, but this is how I would implement it:
Qualcomm controls the primary boot loader (the one in ROM, which loads the SBL) - so this could already set up some virtualization stuff to hide parts of memory from anything that loads later, and for example load a cryptographic key flashed into the device in factory.
Using QSECOM or similar, instead of just loading signed code into the chip, why not load encrypted code. No one can reverse engineer it. You can compile it with the right public key, but not decompile. Only within the secure environment where the kernel can’t see, can that code be decrypted and executed. Only from there one has access to lowest level hardware features (such as updating the keys)
While we talk about profiling other stuff, of course the code in that zero tier execution environment should have full access to the whole memory. Inspect any address, and make some changes if ever needed.
And also undocumented trap registers the rest of the code doesn’t even have the opcodes for. Just like the nifty stuff you set in gdb: When a certain memory address is read or written, or some hardware device utilized, the secure code jumps in and has a closer look. usually just statistics, to fingerprint whatever activity is running and run a heuristics if that is something ‘interesting’ (access to eeprim/flashing, malware activity, network handshakes, some process sets up protected memory to store crypto keys… )
in effect the entire operating system - SBL, fastboot, linux, selinux android, … effectively runs in a virtual machine, while qualcom controls the hypervisor to monitor whats going on.
As we’ve previously discussed, QSEE is extremely privileged - not only can it interact directly with the TrustZone kernel and access the hardware-secured TrustZone file-system (SFS), but it also has some direct form of access to the system’s memory.
In this blog post we’ll see how we can make use of this direct memory access in the “Secure World” in order to hijack the Linux Kernel running in the “Normal World”, without even requiring a kernel vulnerability.
Why am I not surprised. As I said, by bypassing the kernel’s security layer to offer “security features”, security is indeed getting compromised…
Edit:
Unfortunately we do. That’s exactly what QSEE does
So … if we were to disable the QSECOM kernel driver, then the userspace qsecom library would no longer be able to load, or talk to any of the “trustlets” - preventing kernel hijacking from an app. But it would also interfere with userdata encryption, as this security enclave is used to calculate the decryption key from the password.
That being said, their architecture isn’t secure to begin with, so the loss of security by relying on regular linux kernel space crypto-features (and a strong encryption pin/password to prevent bruteforcing) would be acceptable.
This would break DRM features, but it might be an interesting exercise to figure out which of the vendor extensions rely an QSEE and why. Would android still boot? would the modem work?
Not everyone has “NSA and such” in their threat assessment. IMO, the correct way to deal with this is assume your device is compromised by said state actors. (I’d rather assume the threat comes via zero days in Android/AOSP though.)
Not everyone has “NSA and such” in their threat assessment
which is why I don’t worry that much about the Qualcomm stuff, besides doing what I can to block their trackers.
I’m much more worried about the fact that German banking apps don’t work with MicroG, and thus force me to install a heap of code which I don’t need, much less want, on my phone. But that’s a separate problem.
I think if you read post #2 in that same XDA thread. They don’t want to give any new phones separate sections anymore but only so called “extended tags”. Caveat, you need to start a thread about that phone in a general section, and tag it FP3, and their modrators can then elevate that tag into an extended tag. But it’s stupid, it would mean FP1 and FP2 will have prominent sections of their own, while FP3 - which will likely be more significant would not. See https://forum.xda-developers.com/showthread.php?t=1660354 (post 1 + 2) for details
The Extended Tag stuff is just temporary, it seems.
When an ET grows to the point a discussion page becomes un-manageable and cumbersome for members to navigate, we will add the sub-forums and give the device full forum status.
“Cumbersome” translates to “longer than three pages”, which we’re lkely to reach in half a day or so.
Yeah, for the majority of users, Qualcomm’s spying is a privacy nuisance which can be mitigated by simply disabling their apps and preventing the network traffic. The default installation will (most hopefully) not include “trustlets” that directly send user data to third parties.
The main security risk comes from the way QSEEOS is implemented.
It sits above the kernel with elevated privileges.
It, itself is a proprietary security nightmare which - unlike the Linux kernel - doesn’t get regular audits, which makes exploiting much more easy. (See linked blog series about the complete lack of security in 2016. Knowing proprietary security approaches, they will have applied the minimum patches to render the proof of concepts non-working without fixing the underlying architectural issues.)
The issue is as such not so much zero-days in Adroid/AOSP, but zero-days in the proprietary QSEE environment, as they are much more obscure which translates to “will remain open for a much longer time” - and will affect any phone with qualcomm hardware regardless of android version and patchlevel. In fact, because of the CPU-level privilege escalation there is no kernel level mitigation (other than disabling QSEECOM drivers, which as @k4y0z noted will render the modem inoperational)
We practically all use proprietary firmware somewhere though, sometimes on ring 0 or lower. If it isn’t an implementation of TrustZone or SGX, it is Intel ME or AMD PSP or a WLAN driver. Practically everyone with a LTE or 5G modem suffers the same fate. The way I see it, if you don’t want to be vulnerable, stick to wired and ensure physical security. You can lower your attack surface by using less radios. For example, not use LTE/5G, or avoid using Bluetooth for anything serious.
Another alternative is using audited, FOSS implementations such as i.MX series, Talos II, RISC-V, etc. Do come with either less performance, less compatibility, or higher price tag. AFAIK there are no reproducible builds for such firmware though.
where should we upload/share stock ROM images and in which format? I have orig images of the phones partitions for A.0101 from November, A.0105 from December and the latest A.0110 from Jan 2020
Edit: as I understood some additional work is needed to change the raw image into correctly formatted .zip for sideloading
Ah by the way the image @Claymore1297 ( uploaded by @k4y0z ) provided above for A.0105 is corrupt. When I compared them to mine, I noticed a mismatch in the “dsp” partition.
So I tried to manually apply the January 2020 update to the full image, with active checksum tests using the checksums in the signed payload.bin turned out my image for A.0105 was correct, while the one from the zipfile fails its Sha256 check.
The over the air update expects dsp partition to be
/qoVpCy2O8gf/+k+eeqpJiyMGBir5A9DunE8UYSsWDk=
the one in
Interesting note: Applying the payload.bin via bindiff is not enough to get from an old full image to a new valid image. The update procedure on the phone does some funky stuff on the phone after applying the bindiff. So while the checksum tests integrated in the payload applier succeed, the resulting images are not identical to the full image after the update has been fully completed (including booting from the new version) <-<-that ended up being just padding zeroes. Manually patched image files are correct.
Edit: I updated GitHub - CorvusCorax/payload_dumper: Android OTA payload dumper to correctly patch and print checksums (both before and after patch) This allows verification of a system image if you have an OTA update that is based on it, since this includes signed checksums of each partition.
Edit: I requested dev access to androidfilehost, lets see if they approve it
In the meantime here is the correct dsp.img for A.105 dsp.img.zip.not_a.pdf (3.2 MB) (zipped and renamed to pdf to allow upload here)
