Hacker News Reader

Comment by the_third_wave | Hacker News Reader

That's why you install a firewall on your phone and disallow all outgoing traffic by default - possible with Android, impossible with iOS as far as I know - and keep those drivers away from the 'net. Yes, the device works, you just see loads of 'connection errors' in logcat but those just tell me things work as intended by me by not working as intended by the likes of Qualcomm.

As to aGPS being necessary this depends on how often you use GPS. Without aGPS it takes a while for the device to lock after a total cold start but once it has locked it should be able to reacquire lock within a short timeframe. As long as you do not move more than 100 km from the position you were when you last switched off GPS, the clock is within 20 seconds and you're not breaking any speed limits you'll get a fix within a few minutes assuming the receiver can see some satellites. In other words, GPS works fine without aGPS.

View on HN

> That's why you install a firewall on your phone and disallow all outgoing traffic by default

If it's being done by the firmware on the Qualcomm SOC then a firewall in Android is not going to save you.

The firmware on the SOC does not connect directly to the 'net, it interfaces with Android to do so. Android uses the Linux kernel and the Linux IP stack. That IP stack uses Netfilter [1] for filtering and packet mangling. The firewall uses iptables to define Netfilter rulesets which control which data gets sent where, which application is allowed to send data - this includes the kernel (and modules) itself. Block all outgoing traffic - which I do by default - and no data goes out. Try it if you don't believe this, you'll find out it is how things work.

So yes, Android - or rather the Linux kernel on which Android is built - is going to "save me" in that I am in control over which application (including whatever Qualcomm uses) gets to send data. Apple users are out of luck since iOS does not allow this type of filtering but Android does.

[1] https://www.netfilter.org/

> The firmware on the SOC does not connect directly to the 'net, it interfaces with Android to do so.

Do you have any documentation on this? Even firmware such as Intel ME or UEFI implementations connect directly to the Internet itself. So I have a hard time believing the firmware on a Qualcomm SOC does not directly connect to the Internet itself.

No, I do not have any documentation on this nor do I expect any documentation from the likes of Qualcomm where they claim not to exfiltrate data without prior agreement to be all that convincing. What I do have is experience in using firewalls on Android devices for as long as I've used those (about 12 years). I regularly use packet sniffers to see what these devices send to the 'net both to check whether my own stuff is working OK and to check for unwanted traffic. Setting the firewall to block outgoing traffic before enabling network connectivity has always been effective, this includes devices using Qualcomm modems. I use WiFi for these tests just like described in the article as testing for unwanted traffic going over the 3/4/5G connection is only possible if you have a private 4/5G network which I do not (yet) have. I tend not to use 3/4/5G data though - I only have a single device on which I have data enabled and paid for, the rest goes through life using only WiFi. If Qualcomm has made a deal with all mobile operators to push their telemetry through 3/4/5G even on accounts which have data disabled (as in 'not paid for' as well as 'function disabled in Android') they're in for a world of hurt when that news is brought to the light. I assume they have no such agreements as it would not make any sense seeing how easy it is to just use Android and iOS to push that data back to the mothership - which seems to be what they are doing. They are far from the only ones doing this, it is actually the main reason why I block outgoing traffic by default. Just give it a try sometimes, take a device and hook it up to the network through WiFi. Use a packet sniffer on the router to intercept everything coming from that device and feed the result to something like Wireshark. Do the same with that device with a firewall filtering all outgoing traffic and compare the results.

The article is about the hardware chip directly sending these information, not through drivers. It is not about iOS or Android or any other OS.

According to the link nwcs posted, it's being done by a user level Java process, not by the modem firmware or anything like that.

The download is done from the Android side.

It's a privileged app ( a service in Android lang ) that once fetched sends the data to the modem, where GPS is actively implemented, and augmented by such extra data.

Pray tell, how does the hardware chip send data to Qualcomm? That data goes over the 'net, right? How does that hardware chip interface with the 'net? The answer here is 'through the OS' since that is how network connections are made on these devices. Even if the hardware chip contained an IP stack it would still need a network connection to get the data back to Qualcomm. That network connection goes either over the wireless interface (3/4/5G), via WiFi, Bluetooth, NFC or any of the other interfaces the device has - all of which are controlled through the OS.

Android, being built on top of Linux which contains Netfilter as I explained elsewhere [1] which allows you to block network access no matter whether the data originates from some hardware chip or somewhere else. The only way data could make its way off the device is if the radio firmware made a covert connection to Qualcomm which could be used to totally bypass the Linux kernel. That connection would not use the system IP stack and it could work even if the user does not have data active. It would need cooperation from network operators (all over the world) to get the data out of the carrier's network to Qualcomm. This is not what this article is about, it is quite possible that the likes of the NSA are up to this type of shenanigans since they may be able to force carriers to do their bidding [2] but Qualcomm is just another corporation looking to 'get to know their customers'. Read the article and you'll see that the data is exfiltrated through Android. A default block for outgoing data - like I use - blocks this just as well as it blocks other similar attempts.

[1] https://news.ycombinator.com/item?id=35707645

[2] https://www.pbs.org/wgbh/frontline/article/how-att-helped-th...

This completely bypasses the OS.

The kernel never even sees it.

Addendum: To the people downvoting, the article is clear:

> During operation, the covert operating system (AMSS) has complete control over the hardware, microphone and camera. The Linux kernel and deGoogled /e/OS end-user operating system function as a slave on top of the hidden AMSS operating system.

This operating system, know as firmware running in the DSP.

That's the only sane way to have a working device that needs to handle signals.

It's not hidden in any way, and the kernel/Android actively talks with it, configures it, turns it on/off.

But the kernel does not know what it does.

In fact, the article claims:

> During operation, the covert operating system (AMSS) has complete control over the hardware, microphone and camera

Yes, it claims AMSS can control hardware. It also claims data is exfiltrated. Read carefully and you'll see it does not claim the data is exfiltrated through AMSS - they're using WiFi for their experiment which has nothing to do with AMSS, the mobile radio firmware.

Correlation does not equate causation but they want you to think it does so you run to their web shop to buy a rebranded Google Pixel 7 (with Samsung's Exynos 5300 radio modem and accompanying firmware which has just as much control over the hardware as Qualcomm's AMSS has...).

Yep, everything you said is correct.

The AMSS has control of the hardware, but there's different components, each implementing different functionality, they may be able to talk with each other using various IPC mechanism, and they do, but mostly using Android as a middleman ( Linux )

WiFi ( known as cnss on QCOM ) is implemented in a different block than GPS, they don't have direct communication in place. It's routed via the Linux kernel ( and userspace processes )

The firmware may have the capability of doing this (it varies from device to device how much it can do compared to the OS), but the article is 100% incorrect about the source of these requests specifically, they are managed by android itself, they just "couldn't find an explanation", which strikes me as odd when an explanation from 3 years ago is literally the top google result for the OS and the domain name in question.

Complete control over the hardware, microphone and camera may allow more data to be gathered by e.g. turning on the microphone and recording everything it detects but the data still needs to get off the device somehow. The hidden AMSS operating system could theoretically be used to open a covert channel through 3/4/5G independent of the user's mobile subscription but that is not what this article is about - read it again if you missed it:

> We also didn't place a SIM-card in the phone either so it could only send and receive data over the WIFI network which we are monitoring with Wireshark. Wireshark is a professional software tool which allows us to monitor and analyze all traffic being sent over the network.

If the claims of Qualcomm using its hidden AMSS operating system for data exfiltration were true it would not matter whether the device has a SIM card installed or not. Even without a SIM card the thing is still able to reach cell towers, it still has an IMEI, it can still be used to call emergency services (112 or 911 etc), it just won't have an IMSI. Mobile operators are by law mandated to enable connectivity to emergency services to all devices so those connections are passed to their destination. Without an IMSI they do not know who to bill for connectivity so they do not pass any other traffic for such devices. Even with a SIM and thus an IMSI there is no guarantee the subscriber has paid for data so again the operator will only provide connectivity when there is some account to bill it to.

> After we provided our WiFi password in the setup wizard, the router assigned our /e/OS de-Googled phone a local IP address and it started generating traffic.

The data is exfiltrated through WiFi - which goes through the Linux kernel, using the Linux driver for the WiFi hardware. A default block for outgoing traffic puts an end to this just as surely as removing the battery does bar any covert manipulations of the device.

Realise that those who wrote this article are trying to sell you something, hence this rather poor article which tries to insinuate Qualcomm has somehow managed to get mobile operators to cooperate in a scheme to send private customer data through a covert channel. Realise also that they claim their 'Nitrokey' device does not contain a Qualcomm modem. That is quite possible... but it does contain a radio modem and the accompanying RT OS to control it - radio firmware delivered as a blob to be installed on that Nitrophone which is nothing more than a rebranded Google Pixel - using a Samsung Exynos 5300 modem - with GrapheneOS installed.

This is a sales pitch, nothing else.

vpn/sentry is back on the market

Reply on news.ycombinator.com