Mi Account ships the Facebook SDK

I spent an evening turning a stock Xiaomi phone into a portable Linux box with the goal of seeing what its system apps actually phone home about. By the time I was done, the answer was easy. The path to getting there — less so.

The lab on paper: unlock the bootloader, flash a Magisk-patched boot image, install Termux + a Kali rootfs via proot-distro, drop the mitmproxy CA into /system/etc/security/cacerts/ via a tiny Magisk module so apps trust it as a system root. Any non-pinning app can now be MITM’d with a Wi-Fi proxy.

Then I tried to be clever.

Frida has a Java bridge that hooks OkHttp’s pinning checks at runtime. I attached frida-server, attached to a target process, and the bridge crashed: Error: invalid instruction, cannot set property '_code' of null. There’s a multi-year-old open issue for ARMv7 + Android 11 + ART. The patchCode path doesn’t work. Switched to pure-native Interceptor.attach on SSL_write in the apex Conscrypt libssl — clean attach, hook installed, ran for several minutes against multiple targets, captured nothing. Most apps either statically link BoringSSL (Chrome) or use Conscrypt’s NativeCrypto JNI path that bypasses the exported SSL_write symbol entirely.

Tried installing mitmproxy on the phone. Recent versions need a Rust crate (mitmproxy-rs) with no armv7 binary. Pip wanted to compile cryptography from source, also via Rust. Termux’s pkg install python-cryptography works — until pip ignores it because some sub-dep pins a different version. proot-distro install ubuntu and proot-distro install debian both failed silently after dpkg-reconfigure locales. Kali installed fine, but its mitmproxy package depends on python3-mitmproxy-rs (no armhf). Got there eventually via pip install --no-deps mitmproxy==9.0.1 plus manually dpkg --extract’ing the wireguard .deb. Working mitmproxy in Kali — and then I realised I’d never needed any of it.

The actual capture took 30 seconds. Set the phone’s Wi-Fi proxy to the laptop. Run mitmdump --listen-host <laptop-ip>. Open Settings → Mi Account on the phone. Look at the log:

POST https://graph.facebook.com/v16.0/<APP_ID>/activities
User-Agent: FBAndroidSDK.16.0.0
application_package_name: com.xiaomi.account
custom_events: [
  {"_eventName":"fb_mobile_activate_app", "_ui":"AccountSettingsActivity", ...},
  {"_eventName":"fb_mobile_deactivate_app", "_valueToSum":24.543, ...}
]
advertiser_id: <device GAID>
anon_id: <fb anon id>
extinfo: ["a2","com.xiaomi.account",..., "11", "<model>", "en_US", "<tz>", ...]

The Mi Account app — a system service, can’t be uninstalled — embeds the Facebook Android SDK and POSTs your Google Advertising ID, device model, locale, timezone, and per-screen behaviour events to graph.facebook.com every time you open and close the screen. Opening a system Settings panel emits an event to Meta. Facebook responds {"success":true}.

None of this pattern is new. Privacy International’s 2018 report How Apps on Android Share Data with Facebook ¹ documented fb_mobile_activate_app / fb_mobile_deactivate_app auto-logging in 61% of the third-party Android apps they tested. Liu, Patras and Leith’s 2023 PLOS One paper On the data privacy practices of Android OEMs noted that Mi Account links the GAID to IMEI and a Xiaomi device ID. What’s worth saying out loud is that the same Facebook SDK auto-logging behaviour reported almost a decade ago in user-installable apps is still alive and well — running inside a non-removable OEM system service, on a phone updated to its last shipped MIUI build.

Xiaomi pins their own APIs (api.account.xiaomi.com, api.device.xiaomi.net) so I can’t see what they send to Mi servers. They don’t pin the Facebook SDK destination. The leak is visible specifically because the data is leaving.

The moral is dumber than I want it to be: every clever approach failed. The boringest possible setup — system trust cert plus a laptop on the same Wi-Fi — surfaced the answer instantly. Next time I’ll start there.