IMHO if we can use GSI then we should.
There’s no point in re-inventing the wheel for each phone variant, which is IIUC why GSI exists in the first place.
5 Likes
GSI :
Pros:
- Easy to do, actually already available (we don’t have to re-invent the wheel as @smurf said) ;
- Lot of ROM available ;
- Treble, and GSIs have been created for that purpose (and updates frequencies).
Cons:
- Any update (if there is any) on the vendor part of the system will be hard to manage ;
-
All the gsi, or at least most a them,Some wanted gsi ROM (LOS, /e/,…) are unofficial support. They are in dev (debug) mode. Maybe we can fix this ; - Need a rooted device. For the moment ;
- As mentioned by @corvuscorax, the qualcomm lib are still used, which is possibly a privacy issue.
Full Custom ROM :
Pros:
- We control all the system partition ;
- (For some ROM) Once done, it will be possible to make it an official support ;
- (If it is possible) use free alternative to proprietary bin.
Cons:
- We have to maintain it (shouldn’t be a huge problem, some users already maintain LOS on other phones) ;
- Need to work hard on it.
Tell me if I forgot anything.
Someone know if LOS and /e/ are planning to support officially gsi (like Bliss, Resurrection, etc.)?
8 Likes
If we look at it from a privacy perspective ( Telemetry, Spyware, list of privacy threats on FP3 Android 9 )
I think the main reason people would want a custom ROM without gaps probably is privacy - otherwise simply rooting the device would be enough.
However gaps are unfortunately not the only spyware on the phone. At least with the google spying you sort of know where it goes, and google at least gives you some control over the data they collected through the google account. Also it’s kinda “under control” as disabling the google-play-services - or denying network access to google play services - as well as a hand full of other nosy apps ( keyboard, location services, ‘find my device’, …) - actually turns that off. (A VPN based firewall can do that, don’t even need root)
But unfortunately, like probably 90% of devices now, FP3 is a Qualcomm phone, and the qualcom stuff is rooted much deeper in the system - mostly on the vendor partition. There is spyware on the phone that are not apps but a system service running - some of it even with root privileges.
And as a privacy aware user I would like to get rid of that crap. But a GSI solution that keeps FP3’s vendor partition untouched won’t allow that. It would replace google’s frontend with LOS and remove the gapps, but the “rootkit” installed by qualcomm is still armed (worst case scenario)
This isn’t trivial, since qualcomm’s “security features” are deeply interlinked with DRM featurs the phone has. using stuff like the QSEECOM lib and the matching kernel driver, etc… - all provided by proprietary libraries. This is a cesspool that gets deeper and deeper when you go in the direction of cell-modem and firmware.
And I really don’t know what to do there. It’s possible that some of the spy-features are part of proprietary libraries the phone won’t even work without, since they control critical hardware features.
As such I don’t really know what to say with the poll. A LineagePort using GSI would certainly neat and quick but since it leaves the qualcomm vendor stuff in place, it would kinda be like putting a band aid over a wound, without removing the splinters of depleted uranium first.
But FP3 can’t be the first qualcomm phone that people had this problem - and discussion with. Is there a list of the different features - QSECOM, video libs, drm stuff, modem userspace stuff, etc… listing
- what they do
- if they are required for the phone to work (or can just be ommitted / replaced by a software only variant)
- if there is an open source alternative
- etc…
9 Likes
Can one not disable those Qcomm services with adb? Like, you boot up the system (without networking), mount with USB debugging, and disable them right away.
You could argue if you cannot trust Qcomm then it is end of story. Who knows what they backdoored (intentionally or not) and how, after all? If that is your threat assessment, it makes more sense to use a non-Qcomm SoC.
1 Like
You could argue if you cannot trust Qcomm then it is end of story. Who knows what they backdoored (intentionally or not) and how, after all? If that is your threat assessment, it makes more sense to use a non-Qcomm SoC.
There are no free baseband processors, as i know.
2 Likes
Simple answer: If you disable the Qcomm stuff, your phone won’t have a radio any more.
AFAIK people who know how to selectively disable these things do not talk to the free software community. And we do not have the expertise, time, or tools to do any of that.
If you’re sufficiently concerned about this stuff then please do not buy a phone with that chipset in the first place. The Purim people are working on a free/libre phone. Buy one of these instead, and help them. That’s a better use of everybody’s time.
7 Likes
There are no free baseband processors
That’s basically correct, for a lot of inconvenient reasons.
However, it’s possible to shield the baseband away from the “real” phone so that it’s just another device you talk to with a well-defined command set, not an intrusive set of processes that run on your CPU concurrently with Linux and which could, if you’re unlucky / somebody some government wants to spy on/harm / ?!?, read and modify your device at will.
1 Like
qcom blobs are also used for encryption and modem.
There is lots of (userland)-qcom opensource available through CAF but they still depend on proprietary blobs, much like many linux wifi-drivers depend on proprietary firmware-blobs.
3 Likes
We can try to get rid of the worst/useless of them ?
Then we can do a magisk module to uninstall the one we can, or install an alternative if it is exists ?
I still have :
- com.qualcomm.qti.optinoverlay
- com.qualcomm.qti.qms.service.connectionsecurity
- com.qualcomm.qti.qms.service.trutzoneaccess
- com.qualcomm.timeservice
- com.qualcomm.qti.qms.service.telemetry
@corvuscorax did some test on the other thread.
5 Likes
I don’t know what services exist and what they do. Some of them are apps, and can be easily disabled/uninstalled with adb, but some are not.
The one case which was confirmed to spy (it sends periodic requests to the cloud - unencrypted - to a HTTP server while leaking phone specific data through user agent string - allowing tracking of phones) is what my firewall identified as “GPS daemon” (android.gps)
the firewall normally identifies apps by user ID, since each app has its own user. gps daemon isn’t an app, it’s a hardcoded “known” user ID, and there are several qualcom programs running with that user ID. unfortunately, without root, i couldn’t even identify which one of them sent the network requests. this needs further investigating.
I, personally, would be happy to just reliably disable the known and identified spyware. getting rid of all proprietary libs probably somewhere between futile and too much work to be feasible, but at least identifying and removing those that are known to “talk home” is IMHO a necessity.
6 Likes
Now we have root, it is possible to dig deeper. Did you try to mitm and bypass the certificate pinning ? Also, I don’t know if the bins which aren’t apps do certificate pinning.
Which app did you disable (thinking about telemetry ^^) ? Did you notice any behavior change ?
Also, the afwall wiki already has some system app info (no qualcomm relative)
From this XDA thread, it seems possible to disable :
- com.qualcomm.qti.qms.service.telemetry
- com.qualcomm.qti.qms.service.connectionsecurity
- com.qualcomm.qti.optinoverlay
Most of the other apk are gone with LOS 
5 Likes
I disabled com.qualcomm.qti.qms.service.telemetry and com.qualcomm.qti.qms.service.connectionsecurity without any problems.
I did not try mitm for the TLS encrypted stuff, since most of it could be blocked succesfully by-app (or the app simply disabled)
The one which I couldn’t block (the gps daemon requests) are not encrypted, (plain HTTP) so intercepting the request was trivial.
The purpose of the request is legitimate, it downloads a GPS almanach from qualcomms servers in order to allow devices to get GPS lock more quickly. the issue is that the HTTP request leaks device specific information using the UserAgent string (all documented in the other thread) which can be used to fingerprint the device.
This is especially annoying because its unencrypted HTTP, so not only can Qualcomm fingerprint the device, but so can anyone who intercepts that traffic.
I will investigate that a bit more once I have rooted my device
Edit: This old vulnerability is related:
https://www.cvedetails.com/cve/CVE-2016-5348/
its for an older version, but the same service. So not only does this leak information about your phones whereabouts (fingerprint, IP address can be tracked at least with city-accuracy) to qualcomm and anyone who’s listening to the traffic, but it also provides a security risk by spoofing potential responsses.
7 Likes
Nice work !
I don’t know if the gps with LOS has the same behavior. Maybe a patch or a hook can get rid of this leak of data
3 Likes
or a selective IP tables rule 
I think a lot of privacy concerns could be mitigated if qualcomm-specific libs and services can somehow be sandboxed in an environment where they can’t do any harm. (chroot, isolated network, maybe a proxy for selective network access if needed)
2 Likes
Yes but I meant, if the request is legitimate, it’ll need to reach the server ^^. So we can hide same data (e.g. the USER-AGENT).
7 Likes
There is no good reason why that almanac data is not opt-in, and why it is not served over HTTPS. Not only can the data be read, it can be modified as well.
2 Likes
I don’t fully understand. How deep? Do you also suspect software running on a layer deeper than the kernel, or only software from the vendor partition running on top of it, that could be theoretically blocked with a properly configured firewall?
3 Likes
I’m currently looking at some interesting stuff in the vendor partition.
very educative: strings vendor/bin/garden_app
…
-P: Inject Position. Takes 3 arguments seperated by a COMMA. Latitude, Longitude, and accuracy Defaults: %f,%f,%d
…
-L: Load additional cases from dynamic library. e.g: -L “example.so -l -t”
-G: Load Geofence command from a file. e.g: -R tombestone_07
-h: print this help
Use remote API? (y/n) (default n) :
@calvofl0 how deep is deep. Well, it’s qualcomm. They made the chip hardware. So there might be any number of undocumented features in the hardware itself (or… maybe they are documented if you sign the right NDA). Then there are binary firmware blobs they made and are used for a number of subsystem such as modem, wifi chip, GPU, camera, audio subsystem, etc… The CPU itself has proprietary qualcomm extensions providing a secure jailed execution environment, (QSECOM) which are used for drm and cryptography stuff.
There are kernel drivers, which are open source and part of the kernel sources we have from fairphone. I looked at some of them. Especially the QSECOM. It looks like it’s little more than a com layer allowing a data passthrough between the firmware layer and the userspace proprietary libs - through the kernel without the kernel really seeing whats going on. Then there’s the libs in userspace, which are used by a number of running services started from /vendor/etc/init.d (feel free to have a look at it, we have a full copy of vendor partition) These services “assist” hardware like GPS, Wifi, of course the modem, etc… and they use these libraries/SOs.
Then there are various apps. I think whats happening is the apps, which are technically limited by android, they have native bindings to the proprietary vendor libraries, which provide a non-standard API to utilize hardware features - potentially leapfrogging the kernel and any protection it would normally offer. This QSECOM library - if I understand it correctly - allows to inject code into a protected execution environment that even the kernel is blind to, so DRM relevant crypto-stuff can happen without compromising DRM keys even if the device is rooted. Kinda like a trusted computing module in a PC, but more versatile, since it can execute arbitrary code.
Some of this is Qualcoms attempt to make the device more secure, although I have a suspicion they compromise the linux kernel and android security measures in the process. Some of it is an attempt to establish mapping data. More specifically a corelation between MAC numbers and geocoordinates like google does. At least they say they are doing exactly that here:
To enhance system performance your software ID and IP address are associated with your Location Data for thirty days from receipt after which time it is permanently deleted. After removing IP addresses and software IDs, we aggregate the Location Data to create an anonymous database regarding the locations of cellular towers and WiFi access points.
in order to do so, they allow their driver software to collect that data and send it home from any mobile phone with qualcomm software. To make it less obvious, their “servers” use large cloud providers like amazon which everyone uses, so the IPs they connect to don’t stick out, as the closest route cloud based distributed delivery endpoints are used.
the collection of this wifi and cellphone sniffing data happens right at the driver level, although I assume most of the data uploading happens through their telemetry apps.
6 Likes
The Qualcomm core has “proprietary”, i.e. undocumented, extensions. We have no assurance that they can’t access the whole system, circumventing Linux, behind the kernel’s back. You get three guesses what they, or possibly anybody else who has access to their secret documentation, could potentially do with that.
Worse, due to that secrecy the only security research that might find holes in them is done by the NSA and others in that club, and we know from past experience that they’re singularly unwilling to get any of those bugs fixed. NOBUS and all that nonsense.
That code controls the radio and all the data to the kernel go through it, thus you can’t “firewall it off”.
6 Likes
qseecom comunicates with QSEEOS, which is qcoms proprietary implementation of the ARM TrustZone.
It will only run vendor-signed “Trustlets”.
There is an interesting blog-series on the topic (referring to an older implemention of qsee):
There is also an OSS implementation of the ARM Trustzone:
https://source.android.com/security/trusty
4 Likes