Smartphone makers want their devices to stand out. Some go for extreme hardware configurations (hello, the Nokia 9 with five cameras), while others, lacking those resources, dress up otherwise unremarkable hardware with custom firmware. Sometimes the “uniqueness” of the firmware boils down to a branded launcher and wallpapers; in other cases, it’s a full-fledged Android overhaul.
The first approach was used by ZTE, which released the inexpensive Blade L4 with Beeline-branded firmware as the only option. In addition to a pile of Beeline’s own bloatware, it came “gifted” with the full Google Apps suite preinstalled (with no way to remove it) and an antivirus that refused to run without a Beeline SIM. The second approach is used by Xiaomi, known for its budget Redmi line and its MIUI firmware, where there’s hardly anything left of stock Android. Meizu does the same, shipping its phones with the Flyme firmware.
And while things are more or less clear with Google’s own phones—the company publicly discloses what data they collect and even lets you download a dump of it—what exactly do Chinese smartphones collect about us? And what information about you does AOSP or even LineageOS send home if you strip out (or just never install) Google services and apps? Let’s dig in.
ROMs under test
To start, let’s decide on the candidates for testing. We’ll have four of them:
- Pixel Experience — an AOSP-based ROM with the full suite of Google apps and services. It’s a custom ROM, but one that’s as close as possible to what Google ships on its Pixels. For us, it serves as a baseline to show what data a stock Google setup phones home with.
- LineageOS 16 — a custom AOSP ROM without Google apps or services. Here we’ll test the claim that if you don’t want to be tracked, you should run a custom ROM without GApps.
- MIUI 10.2.3.0 Global Stable — Xiaomi’s firmware. In practice it’s not quite Android anymore: a mashup of Chinese services, its own permission system, Google Play and friends, plus tons of preinstalled apps you can’t remove with stock tools—mostly harmless by default, but still there.
- Flyme 6.8.4.3R beta — Meizu’s Flyme firmware. Unfortunately, the official build never got past beta, and the unofficial (newer) build has all Meizu services stripped out, leaving us nothing to test. So we’ll have to stick with this version.
Who Knows What About Us
Starring:
- the “good corporation” known as Google;
- Xiaomi / Meizu / another vendor.
From the no-privacy disclaimer, we know that Big Brother Google collects and stores a vast amount of information. This includes:
- Your search history—not just in Google Search but also on YouTube, which, as you know, is owned by Google. By default this collection is enabled and not prominently disclosed, but you can turn it off in your account settings;
- Your full location history, collected from your smartphone. This is handled by the hard-to-kill GoogleLocationService, which runs even if GApps are installed in the “pico” variant. It determines your location not only via GPS, but also via cell towers and Wi‑Fi networks. All of this is stored locally but, when you’re online, gets uploaded to Google’s servers;
- Information about the apps on your device and their versions. These data are uploaded by the Play Store and are, hopefully, used only for analytics. This is what powers the “You might also like” section in the Play Store;
- All your contacts. They’re collected by the sync service, which is enabled by default;
- Recordings of all your voice queries;
-
- A complete, detailed log of your activity on your phone and in Search. You can find it here.
-
As the screenshot shows, Google even logs the exact time an app is launched on a specific device. And, as you’ve probably guessed, this feature is enabled by default.
In addition, a dedicated ad profile is created for you. You can view and edit it at this link.
We could spend a long time detailing exactly what Big Brother collects on you and me. But even this modest sample should be enough to give you a sense of how troubling the situation is.
The list of data Xiaomi collects is also quite extensive (original spelling retained):
Information you provide to us or send (including contact details): We may collect any personal information you provide, such as your name, mobile number, email address, shipping address, Mi account credentials (e.g., security-related info, full name, date of birth, gender), orders, invoices, materials or data you sync via Mi Cloud or other apps (e.g., photos, contact lists), information related to account creation and participation in the MIUI forum on Xiaomi or other platforms, phone numbers you enter in Contacts or send messages to, feedback, and any other information you share with us.
Device or SIM-related information: Information about your device, such as IMEI, IMSI, MAC address, MIUI version, Android version, part number and model name, and your network operator.
Information about you that we assign: We may collect and use identifiers we assign to you, such as your Mi Account ID.
Location information (only for specific services/features): Various data about your location, such as country code, city code, mobile network code, mobile subscriber identity, longitude and latitude, and language settings.
Log information: Data related to your use of certain features, apps, and websites. For example, cookies and other anonymous identifier technologies, IP addresses, message timestamp history, and standard system logs.
Other information: Environmental characteristic values (e.g., a fingerprint derived from your Mi Account number, phone number, device ID, connected Wi‑Fi ID, and location data).
We may also collect other types of information that are not linked to an identifiable individual and are anonymized. For example, device models and OS versions, and aggregate usage counts for Xiaomi mobile devices, which may be gathered when certain services are used. This information is collected to help us improve the services we provide to you. The type and amount of data collected depend on how you use, consent to, or participate in our products and/or services.
This is a quote from the official privacy policy (for those who don’t read legalese, I’ve prepared a plain-language translation), which essentially guarantees there’s no privacy at all. In that light, the old Soviet line “We want peace—and preferably all of it” takes on a new twist: “We want your data—and preferably all of it.” Sounds bleak? Brace yourself for worse.
Testbed
We won’t have just one testbed, but three:
- ZTE Blade L4, released in 2015;
- Xiaomi Redmi Note 4X, released in 2017;
- Xiaomi Redmi 4X.
The tooling is straightforward too: Fiddler, Wireshark, and tcpdump. We’ll install Fiddler and Wireshark on the main workstation, and tcpdump on the phone with a freshly installed (newly flashed) firmware. The procedure will be as follows:
- Flash a clean build of the firmware (ideally without GApps).
- Without signing into a Google account, install tcpdump and, if needed, Fiddler’s root CA certificate.
- Connect to a Wi‑Fi network hosted by the laptop (where Wireshark and Fiddler are running).
- Let it sit idle for about 30 minutes to capture baseline traffic.
- Tap through the UI, simulating normal user behavior, but don’t change any settings.
- Disable everything you can without root access, then repeat steps 4–5.
www
If you own an iOS device, check out a recent article on iPhone security.
Sniffing traffic from a live device
I spun up an access point on a laptop running Ubuntu 18.04, set up a gateway on it, and ran Wireshark. Obviously, that’s not very helpful if the traffic is HTTPS, but in many cases simply seeing a connection established to a specific address is evidence enough. The rest of the setup is dead simple: configure hostapd on the host machine, run Wireshark there as well, and on the phone import Fiddler’s root certificate and set up the proxy. Done.
LineageOS 16
LineageOS is a custom Android ROM built on the CyanogenMod codebase, which was once the gold standard among open-source ROMs. CyanogenMod spawned numerous forks, and LineageOS is arguably the most well-known.
Right after boot, it prompts us to opt in to sending anonymous statistics. But even after agreeing, the firmware stays quiet. It didn’t show up even after half an hour of waiting. When connected to a Wi‑Fi network, the firmware only performed a connectivity check and then went silent again.
Conclusion: If LineageOS sends anything at all, it doesn’t do it right away.
MIUI
From the outset, the firmware was behaving suspiciously. It was hammering the following servers with requests:
- connect.rom.miui.com;
- android.clients.google.com;
- www.gstatic.com;
- mtalk.google.com;
- data.mistat.intl.xiaomi.com;
- storage.googleapis.com;
- redirector.gvt1.com;
- www.youtube.com;
- dl.google.com;
- api.sec.miui.com;
- r8—sn-cxauxaxjvh-hn9e7.gvt1.com.
The first HTTP request was to connect., which is used to verify connectivity. Note that requests to this endpoint occur roughly every 1.5–2 minutes, despite no dropouts and consistently low latency.
Once the connection was verified, the phone contacted data.mistat.intl.xiaomi.com/mistats/v2 and sent nearly 2 KB of data. It appears to be some kind of telemetry.
Then two more large data packets were sent to another host in the same subnet (161.117.71.187), but unfortunately they were encrypted. Both of these addresses are located in Singapore.
The next interesting request went to relocationapi.. It included my country and a signature that, as I later saw, is attached to every packet as an anti-tamper measure. The following request to the same endpoint sent a status value, and then a few more data packets.
The next endpoint the phone reached out to was api.. The request body was empty, but it included cookies that contained all the information about my phone, including its unique serial number. In response, the phone received a serviceToken, which has since shown up in all subsequent HTTP requests—and not just to this host. Shortly after, it sent my User ID and Device ID there as well.
Next we see what I expected at the very beginning: a call to an ad network—specifically, their own. The host is globalapi.. The request sends the advertising SDK version and our User ID from the previous request. In response, we receive a list of keywords that will be used to load ads going forward, along with the cache retention time for this data (provided as TTL).
Because Mi devices—and especially the Redmi line—are so popular, a massive amount of telemetry and data flows to Xiaomi. To balance the load, the company has deployed a sizable global network. My phone was assigned to a server in India, and from then on all its data has been routed there.
Some of the data was exfiltrated via the Download Provider (com.), which no sane person would block from network access. By the way, the same pattern (i.e., identical packets/requests but with different channel and package_name values) is used by the Theme Manager (com.) and Calendar (com.). On average, these requests go out every 30–40 seconds to different endpoints, with varying channel and package_name values.
But the real snooping is only getting started: at some point resolver. returns not just our public IP address (though why a phone needs that is unclear), but also the country, city, ISP name, our actual IP address (if we’re behind a transparent proxy), the domain where telemetry should be sent (I got s.), the TTL in use, some tid, and two failover addresses to be used over Wi‑Fi and the mobile network respectively (I didn’t observe any requests to them, but if Xiaomi’s primary servers go down, they might get used).
I was about to wrap up this firmware review, but in the second dump I noticed a request to gstatic., which returned a text file with the following contents:
SIGNATURE:uE3dCcZfnDvXnxsV+uHVOmnzZS03kIcda4t2tA4tKY0w6vvx5vngBO6GTb/8j5+3ZvjqBBkx5f8rsiopC/7QgBQhDBBQMJj9i0oWycA/PzRiPGGpXySdyNobw5GKb8KB2GjFW5VXgC1GMuRkWHeCfGGV9zlXbueQeIschm+gayIA18g9D7Gs9cVzbzWo7VSL3ppbiJHD9FIf7VWeJjh8MhdYruWnHducGiztDKtXPNnWjgNKIlWYu5w3TiK3AtFinLUNE2ht15Z+nvRwcGVEmzeY8JKjDK3nRyhYrSWY3uDe5J9hUF9ViXSIWkDS5QP9aEx8wLv0+6EFSibpyZUK9Q==
VERSION:19
REQUIRED_HASH:NONE
This is metadata for SMS short codes.
That was everything I managed to pull from unencrypted traffic, but there was still plenty of SSL/TLS traffic I couldn’t inspect. The firmware mysteriously ignored the configured proxy settings, so I had to limit myself to analyzing whatever I could grab manually.
As for trying to shut down this massive surveillance apparatus, it’s packed with too many built‑in data collection tools. You won’t be able to disable them all through standard settings, and ripping out all the “snitch apps” will basically turn your phone into a bare-bones call-only handset—practically useless.
Pixel Experience
Pixel Experience is an AOSP/CAF based ROM, with Google apps included and all Pixel goodies.
This quote sums up what the ROM is about. Essentially, Pixel Experience is AOSP with the Pixel Launcher plus the full Google Apps (GApps) package.
Within five minutes of use, the firmware had sent 80,000 packets over the network, and I realized analyzing it all would take forever. I’ll just put together a list of addresses, and you can decide for yourself whether you’re okay with sending an unspecified (actually quite specific—62 MB) amount of your data to Google.
| IP Address | Hostname |
|---|---|
| 172.217.16.36 | www.google.com |
| 216.58.209.3 | connectivitycheck.gstatic.com |
| 216.239.35.12 | time.android.com |
| 74.125.131.188 | mtalk.google.com |
| 108.177.126.95 | ns1.google.com |
| 74.125.143.94 | |
| 209.85.234.188 | |
| 108.177.119.147 | ns1.google.com |
| 108.177.126.139 | ns1.google.com |
| 108.177.126.94 | ns1.google.com |
| 108.177.126.97 | ns1.google.com |
| 108.177.127.95 | ns1.google.com |
| 172.217.218.104 | |
| 172.217.218.91 | |
| 172.217.218.94 | |
| 172.217.218.95 | |
| 173.194.69.100 | |
| 173.194.69.190 | |
| 173.194.79.94 | |
| 173.194.79.95 | |
| 209.85.234.188 | |
| 216.239.35.12 | time4.google.com |
| 216.58.209.3 | |
| 224.0.0.22 | igmp.mcast.net |
| 224.0.0.251 | sns.dns.icann.org |
| 23.222.51.182 | a23-222-51-182.deploy.static.akamaitechnologies.com |
| 74.125.128.188 | |
| 74.125.131.188 | |
| 74.125.143.94 | |
| 74.125.143.95 | |
| 86.57.206.210 | 210-206-57-86.beltelecom.by |
| 8.8.8.8 | google-public-dns-a.google.com |
| 99.86.4.37 | server-99-86-4-37.fra6.r.cloudfront.net |
Personally, the biggest surprise was seeing requests go to a Beltelecom subdomain, with which I have next to nothing to do. Even more puzzling: why is the Google firmware phoning home to CloudFront?
You might be wondering why I left some cells in the table blank even though all the addresses resolve just fine. That was intentional: they’re all subdomains of 1e100., owned by Google, and they exist primarily to collect telemetry from the vast fleet of Android devices. I left those cells empty to show the scale: 16 *. addresses versus 17 of all other types combined. And it doesn’t really matter which specific location or PoP an address maps to (they have names like eg-in-f94., ec-in-f188.); what matters is the fact that data is being sent to these endpoints.
Jumping ahead: not a single firmware build tested today honored the configured proxy settings. Browsers dutifully used the proxy, but everything else bypassed it, with no packet content inspection whatsoever.
There were only seven HTTP requests. Three returned 204 (No Content), and the other four downloaded blacklists of numbers used to send spam. Apparently, the most notorious spammers are filtered right at the firmware level.
Out of the 33 hosts my phone contacted without my knowledge, 28 belong to Google, one to Amazon, and the rest are a mixed bag. In other words, Google gets the overwhelming majority of the data.
After all that, I started testing various apps. Almost no traffic went to any new hosts (except 108.177.127.84). The list of previously seen ones shrank by almost a factor of six: we still had active connections to 108.177.119.95, 108.177.126.147, 108.177.127.95, 173.194.69.100, and 173.194.79.95. Nothing unusual overall.
After disabling all Google software except the launcher (for lack of an alternative), the result was clear: the only remaining connection was to 108.177.127.95, a DNS-over-TCP server.
Bottom line: we got exactly what we bargained for. Google’s preinstalled services and apps behaved exactly as stated in the user agreement—sending usage statistics, updating data, and syncing. Unfortunately (or fortunately), once you disable or remove Google services, you’re left with plain vanilla AOSP.
Flyme
I think every reader has heard of this firmware. Many know about its smooth performance, pleasant interface, and, of course, the huge and stinky heap of non-removable Chinese services. Even on first boot, the firmware asks you to accept a sprawling user agreement. I tried to wade through this literary monster (which, by the way, I only found readable in English) so you, dear reader, don’t have to waste your time. The juicy bits start in the second third of the text.
After flashing the firmware and agreeing to that monstrous list of demands to ship all your data who-knows-where, you’d think it couldn’t get worse. But it does. After half an hour staring at the sniffer window, we moved on to phase two: poking through the apps. Every preinstalled app except the voice recorder demanded Internet access under various pretexts, and about half of them also wanted access to contacts. Even the keyboard refused to work without those permissions. We had to make an exception for it, because without being able to set a static IP address, we wouldn’t have been able to analyze any traffic in the first place.
The firmware issued DNS queries to the following hosts:
- connect.rom.miui.com;
- ni.qingmang.mobi;
- api-baas.flyme.cn;
- uxip-res.meizu.com;
- umap.meizu.com;
- u.meizu.com;
- servicecut.meizu.com;
- input.shouji.sogou.com;
- uc-res.mzres.com;
- api-push.meizu.com;
- findphone.meizu.com;
- upush.meizu.com;
- safe.res.meizu.com;
- safe.meizu.com;
- apilocate.amap.com;
- uxip-config.meizu.com;
- safe.mzres.com;
- pmir.3g.qq.com;
- www.baidu.com;
- umid.orion.meizu.com;
- p.meizu.com;
- apiinit.amap.com;
- scan.call.f.360.cn;
- uxip.meizu.com;
- mazu.3g.qq.com;
- restapi.amap.com;
- p-ns.meizu.com;
- map-api.cn-hangzhou.oss-pub.aliyun-inc.com;
- hades.meizu.com;
- stats.lineageos.org;
- aider.meizu.com;
- roam.meizu.com;
- aider-res.meizu.com;
- g.meizu.com.
This list doesn’t include Google addresses like the NTP server and connectivitycheck., but that doesn’t matter right now. Among the remaining addresses we can see findphone., which obviously belongs to the Find My Phone service. And it doesn’t care whether that feature is enabled on the phone: the request was sent anyway—so far only at the DNS level. Another interesting host is apilocate., which—as the name suggests—wants to determine the device’s location. But let’s not jump to conclusions; better to check what actually went out over HTTP.
HTTP
The very first HTTP request went to u. and sent the following data via a POST request:
- deviceType (device name and model; mine is “Redmi-Note4x”)
- Firmware version
- Firmware/ROM version
- Device IMEI (!)
- Device ID and serial number
- Name of the service that sent the data (in this case,
com.) and its versionmeizu. battery
Note that the data are signed, which means you can’t simply strip them out via a proxy. These data could allow the manufacturer to determine whether you’re using a Meizu smartphone or have flashed the firmware onto a third-party device.
The next packet to the same endpoint (u.) carries the exact same report, but this time the sender is the stock launcher (com.). Notably, these data are sent ostensibly to the vendor services update service, though I, for one, don’t see why an update would need the device’s IMEI, ID, and serial number. But hey, I’m sure they know best.
And sure enough, the response is JSON with fields that match the stated purpose. It includes the app name (in Chinese, despite English being selected during initial setup), package name, update type (mandatory or not), the latest server version, its release time and release notes, the update URL, the size and hash of the downloadable file, update conditions, and a silent-install flag. So what’s the problem? The request is sent over plain HTTP with no SSL/TLS, making the traffic easy to tamper with. Given that the update can be installed immediately (flag needsUpdate) and silently (flag silentUpgrade), and integrity is checked only by file size and a hash, Flyme devices can very easily become botnet targets. Worse, your personal data—including IMEI, device ID, and serial number—can be stolen by anyone on the same network.
Next, the system retrieves a list of app activities that, by default, don’t need to request permission to draw over the lock screen. By default, that includes the default launcher screen and an activity named com.. The package name (com.) corresponds on the Play Store to the popular Tencent QQ messenger, which is consistently flagged by antivirus products as adware.
What follows is a snippet of a response that Wireshark couldn’t identify or attribute—and it didn’t capture the beginning either. It contained a JSON payload of the following form:
{ "apkName":"com.DBGame.DiabloLOL", "category2Id":1004, "category2Name":"å¨ä½åé©", "categoryId":2, "categoryName":"游æä¸åº", "cnName":"ç«æ´äººèç", "createTime":1484690841000, "devName":"äºç±äºå¨ç§æ", "id":185417, "installCount":1028899, "stars":113710, "tagName":"横ç,æ ¼æ"},{ "apkName":"com.m37.yhjyj.mz", "category2Id":1001, "category2Name":"è§è²æ®æ¼", "categoryId":2, "categoryName":"游æä¸åº", "cnName":"æ°¸æ纪å", "createTime":1484690855000, "devName":"ç¨æ·494550072", "id":795971, "installCount":1015194, "stars":58590, "tagName":"å³æ¶,大ä½,éå¹»,ç»å¸"},{ "apkName":"com.netease.my.mz", "category2Id":9025, "category2Name":"å¶ä»æ¸¸æ", "categoryId":2, "categoryName":"游æä¸åº", "cnName":"梦幻西游", "createTime":1484690857000, "devName":"Netease_Game", "id":910997, "installCount":986444, "stars":601440, "tagName":"çé,ä»ä¾,Qç,大ä½,ç»å¸"},{ "apkName":"wb.gc.xmxx.zxb", "category2Id":1000, "category2Name":"ä¼é²çæº", "categoryId":2, "categoryName":"游æä¸åº", "cnNam
What we’re looking at is a listing of apps (the apkName field clearly holds the target app’s package name) along with its category (apparently intended to be Chinese characters, but they don’t render correctly in ASCII), creation time, an ID in some internal system, install count, and what appears to be a rating (the stars field). The sender address (183.61.122.111) reverse-resolves in Google Public DNS to soa.dns.guangzhou.gd.cn. Unfortunately, that’s where our intriguing sample ends, but it certainly raises questions. Advertising? A silent adware drop? The package names are not human-readable, leaving the purpose of these apps unclear. And, unsurprisingly, none of them are on Google Play.
Next, the geolocation agent kicked in (as indicated by the User-Agent: header) and sent 261 bytes of binary data to apilocate..
I was about to give up combing through the identical packets that were exfiltrating my valuable data, when I suddenly came across one that was different. Its contents:”
PLQ?çØ^E,³R@,jôq`²#
P«ÿëGÏË¿>é
KÙÌmeizu.com/pack/ramcleaner/whitelist/update.db_1560182405.zip","ver":1560182405},
{"type":"patch","url":"http://safe.res.meizu.com/pack/ramcleaner/whitelist/update.db_1560268805.zip","ver":1560268805}]},
"appinfo":{"packs":[{"type":"full","url":"http://safe.res.meizu.com/pack/app/appinfo.db_1560268805_full.zip","ver":1560268805}]},
"harassmentBlocking":{"packs":[{"type":"full","url":"http://safe.res.meizu.com/pack/harassmentblocking/update.db_1560268805_full.zip","ver":1560268805}]},
"qrcodeUrl":{"packs":[{"type":"full","url":"http://safe.res.meizu.com/pack/qrcodeurl/qrcodeurl.db_1560268805_full.zip","ver":1560268805}]},
"trashclean":{"packs":[{"type":"full","url":"http://safe.res.meizu.com/pack/trash/trashclean.db_1560268805_full.zip","ver":1560268805}]}
}
Let’s go through these archives one by one:
- update.db_1560182405.zip contains a single file, update.db. It lists Meizu services with one of two values (1 or 2). Unfortunately, it isn’t a real database but plain text, so there aren’t even column names. Looking at the download URL reveals “ramcleaner,” which suggests it’s just a config for the built‑in task killer. The numbers most likely indicate process priorities.
- appinfo.db_1560268805_full.zip is a JSON file whose structure looks suspiciously similar to the unnamed chunk we examined a couple of paragraphs above. Nothing new here.
- update.db_1560268805_full.zip is a list of 18 spam-caller numbers (“harassment blocking,” as mentioned in the URL, translates to “harassment prevention”). All the numbers are Chinese. That tells you all you need to know about the effectiveness of this protection if, for a country of 1.4 billion people, the list has only 18 spammers.
- qrcodeurl.db_1560268805_full.zip contains nine JSON lines with malicious URLs that, as the filename implies, are distributed via QR codes.
And in the last archive, trashclean.db_1560268805_full.zip, according to the same source, you’ll find parameters for cleaning junk from the device’s memory. This config ensures that “critically important” data from services—whose names clearly mark them as Meizu’s—won’t be lost. In short, nothing particularly nefarious.
www
I downloaded these archives and mirrored them on Mega in case the original links become unavailable.
After a couple of minutes, the phone downloaded a ZIP archive containing a JSON file with a very extensive (over 1,700 lines) list of permissions for these apps, along with comments in Chinese. You can grab the archive via the link above; it’s called newupdate.db_1560268805_full.zip.
Out of the blue, a hefty payload (22.5 KB) arrived containing a JSON config for some app. Apparently, this config lists apps and activities whose actions need to be intercepted (hooked).
First off, I captured traffic dumps from all the firmware builds and only then analyzed them, so when this nasty surprise surfaced, I no longer had a way to dig deeper. Based on the packet contents, I came up with two hypotheses about what it could be.
First hypothesis: we’re looking at a backdoor config, and here’s why I think so.
- The URL (
safe.) pretty much hints that some rules or filters are coming down from there.meizu. com/ service/ corrstartapp/ getrule - The field names in this JSON are suspiciously similar to a RAT config. For example:
{“1”:”runType===activity|||callerPkg===|||calleePkg===|||calleeClass===com.igexin.sdk.GActivity|||processName===|||action===|||data===|||extras===|||interception===true”}
“`
The second possibility: it’s essentially a signature database for an antivirus or an ad blocker. This is better supported by evidence, since the mentioned com. belongs to a well-known adware SDK. Apparently, the built‑in antivirus intercepts and then blocks calls to this SDK.
Next, the phone tries to download libJni_wgs2gcj. (again over plain HTTP) from amap-api.. I’m not a pro at reversing binaries, but I looked at a hex dump of the file and saw some telling strings suggesting obfuscation. Why would a not-so-secret library be obfuscated? Maybe its contents don’t match the name. There’s only one way to find out what it really does: Google it. 🙂 A quick search shows it’s a straight-up Trojan (https://vms.drweb.com/virus/?i=15762397&lng=en), and it’s been in AV databases since way back in August 2017.
And lest you get excited that any data is still left to you, here’s the final, logical nail in the coffin of your hopes:
{ "priority_directory": [ "DingTalk", "tencent/MobileQQ/shortvideo", "tencent/MicroMsg/WeiXin", "tencent/MicroMsg/Download", "Pictures/Screenshots", "Download", "Movies/Screenrecords", "iqiyi", "iqiyi_live", "iqiyi_p2p", "UCDownloads", "kugou", "kugoumusic", "kgmusic", "QQLive", "qqmusic", "Sina/weibo/weibo", "Sina/weibo/weibo_filter", "DCIM" ]}Yes, that’s the list of folders in your internal storage. Wave goodbye to your privacy: now all your data—including those cat photos and videos—is accessible to anyone, and they know exactly where to look.
I doubt a deeper dive into this firmware will reveal anything more interesting than what we’ve already found. Let’s jump straight to analyzing the firmware’s network traffic after our desperate attempts to disable anything we could.
After a Deep Clean
After the cleanup—disabling all bundled Meizu apps and force-stopping all services—the packet count dropped by roughly an order of magnitude: 477 vs. 7,661. A new host showed up (log.), to which the phone sent 4.2 KB of data over TLS. There was hardly any plain HTTP traffic; only the Calculator app (com.) woke up and sent some telemetry. It’s likely the firmware had already pushed out whatever it wanted in the previous hour and is now taking a breather.
My verdict is best captured by a Belarusian saying: “Don’t touch it or it’ll break.” Just stay away from this firmware and you’ll avoid the fate of a guinea pig under round-the-clock scrutiny by ominous suits. Given how much it transmits in plaintext, I can’t in good conscience call this spy masquerading as firmware something a real hacker would use.
Conclusions
Today we only scratched the surface of custom ROMs. Naturally, I picked the most compelling representatives of this big family for the overview, but as you’ve probably realized, if a vendor—especially a Chinese one—develops the firmware, you can forget about privacy. My choice is LineageOS, and I strongly recommend it as a solid alternative to MIUI and Flyme.