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

I wanted to be methodical in evaluating the Huawei P40 Pro and capture evidence of what I found. Eventually this would enable me to put together a more complete picture of the risk of privacy invasion and data disclosure the device brings with it.

Testbed Setup

The testbed is an extension of my segmented home network. It consists of a dedicated Wifi SSID bridged into its own Vlan 30 ending on a tagged firewall interface. The phone is the only device on this network and it has a static lease assigned to its MAC address so it is always handed out the same IP address by the DHCP server. The firewall is a Mikrotik routerboard which can produce Wireshark-compatible packet capture files via the /tool sniffer command.

To start testing the following policies are configured in the firewall:

• allow DHCP traffic to firewall (which is also the DHCP server)
• allow DNS traffic to DNS server in Vlan 10
• drop everything else

A packet sniffer is running on the firewall Vlan interface to capture any data sent and received by the phone. The filtering DNS server (unbound) is running on a server in the LAN and is configured to log answers to received queries.

After the initial tests and turning off functionality within the phone OS which I didn't like (more on that in the next installment), I relaxed the firewall rules to actually let traffic through to the Internet and enable the phone to communicate with sites beyond just trying to resolve their IP addresses. During this stage the packet captures taken on the firewall were saved for later reference.

Setup of the Environment

So there is a DNS server running in the home LAN with unbound. For the initial tests and setup of the phone only this DNS server was accessible. Outbound DNS traffic towards the Internet is blocked as a general rule.¹

There is also a remote VPS which runs my self-hosted mail service as well as terminates my VPN connections, see below. The software I use for that is fairly standard:

• unbound for DNS
• dovecot for IMAP
• postfix for SMTP
• a Wireguard tunnel endpoint

The unbound DNS server on both machines (at home and VPS) acts as a local resolver with an extensive blacklist of around 52,000 domains returning NXDOMAIN for every request. Block lists are updated nightly via cronjob and they are the same on both servers.

Additionally, a special hand-crafted blocklist is set up for Huawei-specific domains that block access to their cloud services and whatever else they are using (AV scanners, CDNs, ...). This blocklist is manually maintained based on my findings and files on both machines are kept synchronized.

Certain elements in this blocklist would have an impact on other devices in the house. To prevent any side effects these zones are blocked only for specific tags which are assigned to the Huawei phone:

### file: /etc/unbound.conf
# set up tags
define-tag: "facebook google microsoft"
# assign tags to devices
access-control-tag: IP_ADDRESS_OF_PHONE/32 "facebook google microsoft"

### file: /var/lib/unbound/unbound-local-blacklist.zone
# facebook stuff
local-zone: "facebook.com" always_nxdomain
local-zone-tag: "facebook.com" "facebook"
# same for all the others...

While running the tests the unbound log is monitored by running journalctl -u unbound -f in a terminal window. This is an example output showing successful queries for 0.pool.ntp.org and fedoraproject.org, a query for the Internet detection mechanism connectivitycheck.gstatic.com by Google which the server let pass also, and two unsuccessful queries for www.baidu.com plus one successful one for www.google.com. Note the queries are coming from several different devices:

Jul 06 17:50:33 [2925717:1] info: 192.168.4.20 0.pool.ntp.org. AAAA IN NOERROR 0.000000 1 87
Jul 06 17:51:05 [2925717:1] info: 192.168.2.147 fedoraproject.org. A IN NOERROR 0.015984 0 206
Jul 06 17:51:30 [2925717:0] info: 192.168.4.10 connectivitycheck.gstatic.com. A IN NOERROR 0.019406 0 63
Jul 06 17:51:36 [2925717:1] info: 192.168.6.148 www.baidu.com. A IN NXDOMAIN 0.000000 1 31
Jul 06 17:52:36 [2925717:1] info: 192.168.6.148 www.google.com. A IN NOERROR 0.031039 0 48
Jul 06 17:52:40 [2925717:1] info: 192.168.6.148 www.baidu.com. A IN NXDOMAIN 0.000000 1 31

Why 2 DNS Servers?

Ever since the advent of Pihole, the go-to solution for blocking unwanted advertisements, malware, and other questionable sites has been blackholing DNS queries. This is easy enough to do with a Raspberry Pi running Pihole or any other solution that brings along its own DNS server which can be suitably configured.

This works fine in the local LAN at home or work, but once the phone or computer connects to another Wifi network (say at a cafe or hotel) or indeed uses cellular data while out and about, the situation becomes a bit more complicated. A good solution is to run a local DNS blocker such as Blokada or Adguard on your phone. It filters out the queries, returns NXDOMAIN, and peace is restored.

The caveat here is that these blockers set up a "fake" VPN connection as that is the only way Apple and Google² will allow interference with DNS queries. There are two issues with that:

• only one VPN service can be active at a time.
• I am not aware of a DNS filter for iOS or Android that both filters DNS and provides a VPN connection at the same time.

So that means you have to chose between either no ads or encrypted VPN connections e.g. on a dodgy hotel Wifi, but not both. Not good. Luckily there is a way around that, and that's using an always-on VPN of your choice (for example, OpenVPN or Wireguard) and blocking the DNS queries on the server configured in the VPN settings, at the other end of the tunnel. In my case the VPS, but you can run your own physical server at home or at work if you want.

With this setup a wireguard tunnel from the phone to the VPS offers encryption and the same DNS-based protection while on cellular data or on a remote Wifi. I actually leave the tunnel on even when at home. Those apps that need access to local resources in my LAN are excluded from the tunnel in the Wireguard configuration.

Note that turning off the tunnel while on a public network will disable all protections!

Tracking Changes

Domains used by malicious apps can and do change over time. To control that only benign domains are passed through the DNS there is a cronjob which analyses the past 24 hours of non-blocked queries originating from the phone and sends out a summary email at night. The output needs to be reviewed and the filter lists adjusted periodically.

To give you an idea of where to start here's an example script that will send a reverse-sorted list by number of successful queries:

#!/bin/sh
#
# find non-NXDOMAIN DNS hits from Huawei phone

# add user to group 'systemd-journal' with:
#   usermod -a -G systemd-journal <user>

# (wireguard tunnel) IP of phone
PHONEIP=10.7.0.5
# report period
PERIOD="today"
# receiver of this report (concatenate with ',' if multiple)
RECIPIENT=user@example.org

# create temp file to preserve linebreaks in output
TMPFILE="$(mktemp)"
/bin/echo -e "Subject: DNS Report for ${PHONEIP}\n\nSuccessful DNS queries from \
    ${PHONEIP} for ${PERIOD}:" >${TMPFILE}
journalctl -u unbound -S ${PERIOD} | grep ${PHONEIP} | grep NOERROR | \
    awk '{print $9}' | sort | uniq -c | sort -rn >>${TMPFILE}

cat ${TMPFILE} | /usr/sbin/sendmail ${RECIPIENT}

# clean up
rm ${TMPFILE}

Encrypted Communications

I've been running packet captures for years using for example tcpdump or Wireshark (and before that ethereal and snoop and countless other tools). The one striking difference between let's say the year 2001 and 2021 is the almost complete encryption of network traffic. Whereas 20 years ago it was extremely easy to see what was going on in any TCP stream, nowadays very few protocols are run in plain text versions. In fact the only one generally seen anymore is DNS, and even that is changing slowly. But any application written using standard SDKs use TLS/SSL encryption by default, and everywhere.

To the enthusiastic student of packets this is somewhat disappointing, and the only data they can draw conclusions from easily is metadata - hostnames, ports, division of upload/download traffic, certain rythmic patterns, or data strobes following events or activities triggered either by the user or the system.

Somewhat less easily a man-in-the-middle attack can be performed on the encrypted traffic, whereby a proxy is run that the software in question is forced to connect to, and which presents the device under scrutiny a local fake certificate. The proxy decrypts the traffic that was encrypted using this certificate, copies the plaintext data onto a side channel, and then encrypts the data with the correct certificate and forwards it to the destination. The process is repeated in reverse with response traffic.³ Common tools for this are Burp and mitmproxy.

During the course of this testing I have not deployed a MitM proxy as I was satisfied with observing the metadata. Unfortunately use of a MitM proxy has been made increasingly harder in newer Android versions. Android differentiates between a system and a user certificate store. Applications can chose to subscribe to the either the system store or both of them, or chose to use their own mechanism entirely. The stock Android system itself only ever trusts the system store, so things like software updates cannot be decrypted.

To inject MitM certificates into the system store the device must be rooted and the bootloader unlocked and tools like Magisk be used to change the system partition into read/write mode and physically place the file(s) there. Magisk unfortunately does not support Huawei phones anymore, and even on other Android 11 devices it's gotten quite complicated. The straw that breaks the camel's back is then the use of certificate pinning by applications, which regardless of any changes to the certificate stores will only ever accept "The One True Certificate"[TM]. I'm a great proponent of certificate pinning - luckily and unfortunately at the same time it makes the security researchers' jobs much harder.

The DoH/DoT Problem

DNS-based tracker blocking seems like the new kid on the block for privacy-focussed nerds and not at all mainstream, but the ad marketers are paying attention. Nobody more so than Yahoo, which like a zombie has been transformed from a news and mail service web site to an almost pure ad network. As of 2020 they were one of the largest ad networks contacted by mobile apps, at least based on my log file analysis.

With the advent of Pihole and Blokada and Adguard, these activities have started to eat into Yahoo's earnings. Meanwhile, DNS-over-HTTPS and DNS-over-TLS have established themselves as technologies designed to keep your local ISP from preying on your traffic, if not by outright selling it but at least by inserting ads for domain misses.

Ad farms, as of mid-2021 at least, have not taken to running DoH/DoT servers YET. They will, just give it some time. Except Yahoo. They repurposed one of their domains, yahoodns.net, previously used for IMAP mail access, to serve DoH endpoints, which their ad kits integrated into apps are contacting to get around our diligent attempts at blocking them.

Regardless of provenance the possible use of DoT/DoH poses a significant threat to DNS-based network blocks. Access to these servers must be prevented on firewall-level which is only possible for the known servers such as 1.1.1.1 and 9.9.9.9 and servers maintained on lists such as the DNS Privacy Public Resolvers and the Lists of public DNSCrypt and DoH servers. So far it seems relatively pointless to block these servers, as a lot of them also filter ad networks and trackers themselves.

Traffic to other servers will mix in with regular HTTPS traffic and be completely opaque. It seems only a matter of time until companies will start to operate Do[TH] servers for their own concealed use to evade DNS-based blocking attempts.

Once this happens privacy-oriented people will have no other chance than to step up their game in this arms race and deploy SSL-breaking MitMs such as Burp to contain this threat.