This is part 5 in a series of getting rid of Google in my computing. See the beginning and index here: Introduction.

More Network Snooping

Let's do some more testing and have a look at what's going on on the network.

Download F-Droid

I turned the block-anything firewall rule off for a few minutes and then used the Huawei browser (Chrome) to download and install the F-Droid store app. Swiftkey popped up a notification to sign in beforehand, which I respectfully declined. After the download Chrome executed a check (using avast) and found no risks in the downloaded file.

The packet capture file was saved as p40p-install-fdroid.cap but as expected showed nothing much of interest as everything was SSL-encrypted.

DNS lookups in chronological order:

[884739:2] info: 192.168.5.11 grs.dbankcloud.com. A IN
[884739:0] info: 192.168.5.11 connectivitycheck.platform.hicloud.com. A IN
[884739:3] info: 192.168.5.11 terms7.hicloud.com. A IN
[884739:0] info: 192.168.5.11 browsercfg-dre.cloud.hicloud.com. A IN
[884739:1] info: 192.168.5.11 dnkeeper.hicloud.com. A IN
[884739:3] info: 192.168.5.11 browserr-dre.dbankcdn.com. A IN
[884739:0] info: 192.168.5.11 sdkserver-dre.op.hicloud.com. A IN
[884739:1] info: 192.168.5.11 store.hispace.hicloud.com. A IN
[884739:3] info: 192.168.5.11 api.cloud.huawei.com. A IN
[884739:3] info: 192.168.5.11 token-dre.push.dbankcloud.com. A IN
[884739:2] info: 192.168.5.11 events-dre.op.hicloud.com. A IN
[884739:3] info: 192.168.5.11 metrics2.data.hicloud.com. A IN
[884739:3] info: 192.168.5.11 www.google.com. A IN
[884739:2] info: 192.168.5.11 consent.google.com. A IN
[884739:2] info: 192.168.5.11 www.gstatic.com. A IN
[884739:3] info: 192.168.5.11 fonts.gstatic.com. A IN
[884739:3] info: 192.168.5.11 play.google.com. A IN
[884739:1] info: 192.168.5.11 consent.google.be. A IN
[884739:2] info: 192.168.5.11 consent.youtube.com. A IN
[884739:1] info: 192.168.5.11 apis.google.com. A IN
[884739:2] info: 192.168.5.11 ogs.google.com. A IN
[884739:3] info: 192.168.5.11 adservice.google.com. A IN
[884739:2] info: 192.168.5.11 adservice.google.com. A IN
[884739:2] info: 192.168.5.11 adservice.google.com.lan. A IN
[884739:0] info: 192.168.5.11 connectivitycheck.gstatic.com. A IN
[884739:2] info: 192.168.5.11 www.bing.com. A IN
[884739:2] info: 192.168.5.11 f-droid.org. A IN
[884739:1] info: 192.168.5.11 gate.hockeyapp.net. A IN
[884739:1] info: 192.168.5.11 gate.hockeyapp.net.lan. A IN
[884739:1] info: 192.168.5.11 browsercfg-dre.cloud.hicloud.com. A IN
[884739:2] info: 192.168.5.11 f-droid.org. A IN
[884739:1] info: 192.168.5.11 sdkserver-dre.op.hicloud.com. A IN
[884739:0] info: 192.168.5.11 cs02-pps-drcn.dbankcdn.com. A IN
[884739:1] info: 192.168.5.11 metrics2.data.hicloud.com. A IN
[884739:0] info: 192.168.5.11 nsp-pps-creative-p01-dre.obs.eu-de.otc.t-systems.com.      A IN
[884739:1] info: 192.168.5.11 auth.ff.avast.com. A IN
[884739:2] info: 192.168.5.11 pkginstaller-ovs.hispace.hicloud.com. A IN
[884739:1] info: 192.168.5.11 sp-8f237ea3.apkrep.avcdn.net. A IN
[884739:2] info: 192.168.5.11 shepherd.sb.avast.com. A IN
[884739:2] info: 192.168.5.11 events-dre.op.hicloud.com. A IN
[884739:3] info: 192.168.5.11 ntp.sjtu.edu.cn. A IN
[884739:3] info: 192.168.5.11 metrics2.data.hicloud.com. A IN
[884739:2] info: 192.168.5.11 sdk.hockeyapp.net. A IN
[884739:0] info: 192.168.5.11 gate.hockeyapp.net.lan. A IN
[884739:1] info: 192.168.5.11 oneclient.sfx.ms. A IN
[884739:3] info: 192.168.5.11 query.hicloud.com. A IN
[884739:3] info: 192.168.5.11 sdk.hockeyapp.net. A IN
[884739:0] info: 192.168.5.11 sdk.hockeyapp.net. A IN

The attempted connections to various Google properties are due to the browser's Chrome underpinnings. nsp-pps-creative-p01-dre.obs.eu-de.otc.t-systems.com is an object storage endpoint (OBS) within German Telekom's Open Telecom Cloud - in this case the actual location of the F-Droid store app binary, and an interesting selection for content hosting. Props to F-Droid...

Download Wireguard App from F-Droid

Next up, now that we have the F-Droid store installed, we'll get ourselves the Wireguard tunnel client to use for pretty much everything. The application installation again invoked the automatic virus scan.

DNS lookups in chronological order:

[884739:0] info: 192.168.5.11 store.hispace.hicloud.com. A IN
[884739:0] info: 192.168.5.11 f-droid.org. A IN
[884739:0] info: 192.168.5.11 telemetry.api.swiftkey.com. A IN
[884739:0] info: 192.168.5.11 telemetry.api.swiftkey.com.lan. A IN
[884739:2] info: 192.168.5.11 snippetdata.api.swiftkey.com. A IN
[884739:3] info: 192.168.5.11 sdk.hockeyapp.net. A IN
[884739:3] info: 192.168.5.11 api.cloud.huawei.com. A IN
[884739:3] info: 192.168.5.11 metrics2.data.hicloud.com. A IN
[884739:2] info: 192.168.5.11 token-dre.push.dbankcloud.com. A IN
[884739:3] info: 192.168.5.11 ftp.lysator.liu.se. A IN
[884739:3] info: 192.168.5.11 pkginstaller-ovs.hispace.hicloud.com. A IN
[884739:2] info: 192.168.5.11 sp-8f237ea3.apkrep.avcdn.net. A IN

This time around the binary came from the FTP server of Lysator, the academic computer club at Linköping University, Sweden.

ApkPure Application Start

One of the "free" app stores, all of which should be taken with a grain of salt as mentioned in the last installment. During startup of the application, requests are made to these domains in addition to the (expected) apkpure.com itself:

applovefrom.com
api.tradplusad.com
app-measurement.com
winudf.com
dht.libtorrent.org
firebase-settings.crashlytics.com
googleads.g.doubleclick.net
graph.facebook.com
sdk.adtiming.com
static.doubleclick.net
www.google-analytics.com
www.youtube.com

These domains can safely be blackholed in the DNS server and are generally caught by the default adblocker blackhole lists anyway.

Application Installation from ApkPure

Initiating an installation from within the ApkPure store app creates a relatively small number of DNS lookups:

app-measurement.com
grs.dbankcloud.asia
grs.dbankcloud.cn
grs.dbankcloud.com
grs.dbankcloud.eu
h5hosting.dbankcdn.com
pkginstaller-ovs.hispace.hicloud.com
tracker.winudf.com
d-04.winudf.com
d-21.winudf.com

Application downloads will fail if their distribution servers d-??.winudf.com are not reachable, so these need to be allowed. tracker.winudf.com can safely remain blocked.

Winudf is a domain registered by the Chinese registrar Enom, Inc. in Beijing with most other data cloaked. Initial registration was in 2003, updated last in 2020. Alienvault and Malwarebytes have recently (April 2021) lifted their malware identification and removed the entries from their blocklists, partially also due to issues with ApkPure downloads. I'm not sure this has been properly researched and weighed though -- little is known about that site and due to ApkPure having elevated rights one should be very skeptical about such a constellation.

I removed the Apkpure store app again after running these tests, preferring to sideload APKs obtained "offboard" as previously explained.

Switching Off Airplane Mode

This traffic was generated by the fully installed phone when switching off airplane mode (trace file: huawei-airplane-off.cap):

Some traffic was hitting the LAN DNS server, bypassing the VPN tunnel. This is the normal connectivity check, plus access to the Evolved Packet Data Gateway (ePDG) of my mobile provider to establish Voice over Wifi calling capability (see section below):

192.168.4.13 connectivitycheck.platform.hicloud.com. A IN NXDOMAIN 0.000000 1 56
192.168.4.13 connectivitycheck.platform.hicloud.com. AAAA IN NXDOMAIN 0.000000 1 56
192.168.4.13 connectivitycheck.cbg-app.huawei.com. AAAA IN NXDOMAIN 0.000000 1 54
192.168.4.13 connectivitycheck.cbg-app.huawei.com. A IN NXDOMAIN 0.000000 1 54
192.168.4.13 epdg.epc.mncxxx.mcc262.pub.3gppnetwork.org. A IN NOERROR 0.035813 0 204

As expected all the cloudy apps sprang to life and performed their synchronization attempts through the Wireguard tunnel. These were the queries hitting the VPS DNS server:

10.7.0.5 grs.dbankcloud.eu. A IN NXDOMAIN 0.000000 1 35
10.7.0.5 grs.dbankcloud.eu. AAAA IN NXDOMAIN 0.000000 1 35
10.7.0.5 grs.dbankcloud.cn. AAAA IN NXDOMAIN 0.000000 1 35
10.7.0.5 grs.dbankcloud.cn. A IN NXDOMAIN 0.000000 1 35
10.7.0.5 grs.dbankcloud.com. AAAA IN NXDOMAIN 0.000000 1 36
10.7.0.5 grs.dbankcloud.com. A IN NXDOMAIN 0.000000 1 36
10.7.0.5 grs.dbankcloud.asia. A IN NXDOMAIN 0.000000 1 37
10.7.0.5 grs.dbankcloud.asia. AAAA IN NXDOMAIN 0.000000 1 37
10.7.0.5 query.hicloud.com. A IN NXDOMAIN 0.000000 1 35
10.7.0.5 query.hicloud.com. AAAA IN NXDOMAIN 0.000000 1 35
10.7.0.5 configserver-dre.platform.hicloud.com. AAAA IN NXDOMAIN 0.000000 1 55
10.7.0.5 configserver-dre.platform.hicloud.com. A IN NXDOMAIN 0.000000 1 55
10.7.0.5 configserver.platform.hicloud.com. A IN NXDOMAIN 0.000000 1 51
10.7.0.5 configserver.platform.hicloud.com. AAAA IN NXDOMAIN 0.000000 1 51
10.7.0.5 configserver.platform.hicloud.com. A IN NXDOMAIN 0.000000 1 51
10.7.0.5 metrics2.data.hicloud.com. AAAA IN NXDOMAIN 0.000000 1 43
10.7.0.5 metrics2.data.hicloud.com. A IN NXDOMAIN 0.000000 1 43
10.7.0.5 pushtrs7.push.hicloud.com. A IN NXDOMAIN 0.000000 1 43
10.7.0.5 pushtrs7.push.hicloud.com. AAAA IN NXDOMAIN 0.000000 1 43
10.7.0.5 configserver-dre.platform.hicloud.com. AAAA IN NXDOMAIN 0.000000 1 55
10.7.0.5 configserver-dre.platform.hicloud.com. A IN NXDOMAIN 0.000000 1 55
10.7.0.5 api.cloud.huawei.com. AAAA IN NXDOMAIN 0.000000 1 38
10.7.0.5 api.cloud.huawei.com. A IN NXDOMAIN 0.000000 1 38
10.7.0.5 auth.ff.avast.com. AAAA IN NXDOMAIN 0.000000 1 35
10.7.0.5 auth.ff.avast.com. A IN NXDOMAIN 0.000000 1 35
10.7.0.5 sp-8f237ea3.honzik.avcdn.net. AAAA IN NXDOMAIN 0.000000 1 46
10.7.0.5 sp-8f237ea3.honzik.avcdn.net. A IN NXDOMAIN 0.000000 1 46
10.7.0.5 configserver-dre.platform.hicloud.com. AAAA IN NXDOMAIN 0.000000 1 55
10.7.0.5 configserver-dre.platform.hicloud.com. A IN NXDOMAIN 0.000000 1 55
10.7.0.5 sp-8f237ea3.honzik.avcdn.net. AAAA IN NXDOMAIN 0.000000 1 46
10.7.0.5 sp-8f237ea3.honzik.avcdn.net. A IN NXDOMAIN 0.000000 1 46
10.7.0.5 sp-8f237ea3.honzik.avcdn.net. AAAA IN NXDOMAIN 0.000000 1 46
10.7.0.5 sp-8f237ea3.honzik.avcdn.net. A IN NXDOMAIN 0.000000 1 46

Again we see that the Avast virus scanner servers are contacted for updates to the signature files (and possibly other activities - who knows?).

Omitted from this list are all the sites contacted by installed apps, such as RSS feed updates, etc. Depending on the number of applications a veritable barrage of network traffic is caused all at once when coming off airplane mode.

I can only imagine what that does to cell operator networks every time a plane docks at an airport stand and 200 phones come online almost simultaneously...

Voice-over-Wifi

VoWifi, variously also "Wlan Call" or "Wifi Calling", is a GSMA standard evolved from the Generic Access Network (GAN) specification ratified in 2004.¹ Essentially it allows Voice over IP calling using available non-telco access infrastructure such as Wifi networks, while transparently utilizing inter-provider call routing and using normal provider-assigned phone numbers without requiring separate SIP accounts or similar. The P40 Pro supports VoWifi.

The implementation is actually quite interesting and consists of three phases:

1. the VoWifi-enabled phone first performs a DNS lookup for a provider-specific Evolved Packet Data Gateway (ePDG). These gateway FQDNs are allocated based on the IMSI, MCC, and MNC ranges; as an example, epdg.epc.mnc001.mcc262.pub.3gppnetwork.org for German Telekom.
2. after a successful lookup the phone attempts to establish an IPSec tunnel connection to the ePDG. This tunnel uses the normal UDP ports 500 for ISAKMP and 4500 for ESP and can traverse NAT.
3. if the tunnel was established successfully the VoWifi icon replaces the cell provider name on the phone display and calls (except emergency calls) are routed via the Wifi network.

VoWifi bypasses any configured VPN tunnel for all three phases.

The tunnel setup phase can be seen in this Wireshark trace taken on the firewall. 192.168.4.13 is the phone, 109.237.187.195 is the ePDG:

From a privacy point of view the fact that this traffic bypasses any tunnel raises the question of locatability. In a home Wifi setup, your public IP address will be exposed to the ePDG on the telco side. That may or may not be an issue.

VoWifi can be easily disabled by blocking the DNS queries and/or by filtering the UDP ports used for IPSec tunnel establishment (or of course turning it off in the phone settings).

Location Services (GPS, Glonass, Beidu)

When not using navigation or other location-based applications or services, the location services in the phone should be turned off.

Turning on location services in the settings triggers the usual connection check and let's-phone-home-to-the-cloud routine we've seen before. Additionally, we see hits for:

openlocation-dre.platform.dbankcloud.com
query.hicloud.com
tsms-dre.platform.dbankcloud.com
supl.platform.hicloud.com
hw.restlbs.map.wechatos.net

Going by the name the first site would offer or consume location data - its implications are hard to judge without further decryption and analysis of the actual traffic.

supl.platform.hicloud.com is the assisted GPS data server for Secure User Plane Location that satellite almanachs can be obtained from to speed up the initial location fix. If this server is blocked in the DNS, A-GPS would not be available. The SUPL server is not configurable so this is a tradeoff - service for anonymity.

The last line documents a connection to Tencent's WeChat, one of the most glaring privacy offenders worldwide which cooperates deeply with the Chinese regime. It is most likely serving a RESTful location-based services (lbs) API which might be used for tracking purposes. Having this built-into the operating system is probably the most concerning finding for privacy in these tests so far.

Backups & Data Transfer{sshd}

"Just because you're paranoid doesn't mean They aren't out to get you."

In case it's not clear by now: I will not entrust any of my data to a "cloud" service. Apart from the snooping I also have no faith in the stability and integrity of these services for backup purposes. Unless you can physically touch a disk/tape/SSD with your data, as far as I'm concerned you don't have a backup.

As for data transfer, I also need a way to efficiently get data from my PC onto the phone; for example as outlined in the section on sideloading apps but also to carry along music, movies, or image files for on-the-road consumption, or to sync my Keepass vault onto the phone.

There are lots of ways to accomplish that. One of the more popular is Syncthing which is cross-platform and also can be used for cloudy things if wanted. Personally for me the best solution I have found is to install an SSH server onto the phone and use good-old rsync to push and pull entire directory structures to and from it.

To do the same, install for example SimpleSSHd from F-Droid or the developer's site. Then start the server and log in interactively using the one time-password generated and shown on the phone display. Next, copy your public key file onto the phone: scp -P 2222 ~/.ssh/key.pub user@192.168.4.13:authorized_keys. Now you can log on using key-based authentication with your private key loaded in the ssh-agent.

Once this is set up you can create a couple small shell scripts (one liners, really) to sync particular directory hierarchies between your phone and the PC. For example to sync my music collection to the phone I use:

#!/bin/sh
#
# rsync Music folder to phone
# start SimpleSSHD on phone first
PHONE=192.168.4.13

rsync --delete --update --progress -e 'ssh -p 2222' -av ./ ${PHONE}:/sdcard/Music

This example will keep a precise copy of the music folder on the phone. It will remove files that I deleted from my collection (--delete flag).

Or to transfer any images taken with the phone into my pictures backup I use:

#!/bin/sh
#
# rsync selected folders from phone to here
# start SimpleSSHD on phone first
PHONE=192.168.4.13

rsync --update --progress -e 'ssh -p 2222' --exclude '*.thumbnails' -avz ${PHONE}:/sdcard/DCIM/ ./DCIM
rsync --update --progress -e 'ssh -p 2222'  -avz ${PHONE}:/sdcard/Movies/ ./Movies
rsync --update --progress -e 'ssh -p 2222'  -avz ${PHONE}:/sdcard/Pictures/ ./Pictures

When done with the syncing stop the SimpleSSHd server again. Alternatively, you can keep it running all the time and have the sync jobs executed as a nightly cron job from your home server to perform the pushes and pulls while you sleep. That way there's always a current backup should things turn pear-shaped.

Summary

The results so far:

Installing apps from stores such as F-Droid and ApkPure or side loading APK downloads is straightforward. Some apps refuse to work after installation because there are no Google Mobile Services present. Installation of MicroG can be used to get around this limitation, but is not desirable.

All app downloads must be made from sources that require no user account to prevent microtargetting with specially crafted downloads. The risk of otherwise boobytrapped apps including e.g. trojans must be carefully weighed.

While F-Droid apps are vetted, apps from ApkPure and other stores include a number of trackers which try to contact questionable sites. An app checker such as Exodus should be used to investigate, and proper DNS blocks must be in place and kept updated to prevent such traffic. This is a moving target.

After app installation a test should be made to see what outgoing connections are initiated by it and which of these should be blocked. Newer versions of Android offer the possibility to control network access rights for cellular or Wifi, and for specific SSIDs. Apps that do not need to access the network should have these permissions revoked by default.

The built-in connection to a Wechat-owned location-based services entity is troubling.

Considerations for the Future

(Anti-)Malware

The malware scanner is rendered almost useless due to the block policies of the AV sites. The risk of using it maybe does not offset the usefulness of a malware scan. If wanted, the built-in scanner could be replaced with something more trustworthy in a separate app. But which AV scanners are really trustworthy...?

Google's "War" on APKs

Coinciding with these tests Google announced it forced Play Store developers to move from the [X]APK application package format to .aab Android Application Bundles effective August 2021². What this means for the "alternative" app stores remains to be seen. Most likely these stores will find a way to avail themselves of the bundles and either adjust their installers to support them as well, or otherwise convert them to standard XAPKs.

In any event, Google forces developers to hand over their app signing key and uses it to sign packages on the publishers' behalf. What this effectively means is that you cannot trust the app to be in the same state as submitted to the Play Store by the original publisher, and indeed it may contain targeted "specialties".

This makes the entire app store concept highly suspicious and is reason enough to avoid the store completely. For a deeper discussion on this see my previous blog post.³

Application Updates

A good strategy for loading application updates must be found. Except for F-Droid and FFupdater this out of necessity is a manual step for apps that do not check for updates themselves (Signal and Newpipe do, for example). Other than malicious intent, applications are updated for valid reasons -- to fix security issues or bugs, or to enhance the functionality. For the reasons mentioned before app stores with user accounts must be avoided. Keeping the number of "dubious" apps from ApkPure & friends as low as possible saves work and reduces possible impact, but it must still be done.