BannerHub v6 · privacy
Privacy hardening,
told honestly.
BannerHub v6 strips upstream telemetry from GameHub 6.0.9 at the bytecode level — and discloses both halves: what it kills and what it deliberately leaves in place. Anyone with a DNS recorder can verify both, so we'd rather tell you up front.
This page covers only the BannerHub-side patches to the v6 build (gamehub-609-build). It does not cover GameHub's upstream behaviour, the Wine / Box64 stack, or the individual Windows games you run inside it. Source of truth: the repo's PRIVACY.md.
✕ What we kill
Each row was a live telemetry channel on vanilla GameHub 6.0.9 and is no longer reachable in BannerHub v6. The commit link is the actual code that did it.
| Channel | What it leaked | How it's killed | Commit |
|---|---|---|---|
| Firebase Analytics | screen views, session starts, purchases, app opens → app-measurement.com | Manifest kill-switch (firebase_analytics_collection_deactivated=true + Ad-ID/SSAID disables) — the SDK never initializes | 178c5ec |
| Mob Push SDK | device identifiers, push tokens, lifecycle events → Mob | Bytecode removes 3 init call sites; manifest disables every com.mob.* / cn.fly.* component (auto-init ContentProvider can't fire) | 282c9ea |
| Google Ad-ID / ADSERVICES perms | advertising-ID exposure to any Play Services caller | 3 <uses-permission> declarations stripped | 6817568 |
| XiaoJi OTA update URL | firmware-update phone-home to xiaoji.com/firmware/update/x1 | URL register rewritten to 127.0.0.1; per-arch OTA native libs stripped | 6817568 |
| Heartbeat / playtime tracker | per-game playtime sessions → XiaoJi (heartbeat/game/*) | Suspend lambda bodies replaced with return Unit.INSTANCE; playtime list returns empty | 519ba65 |
| Google Play Services Measurement | persistent app_instance_id, session_id, lifecycle pauses → Google | Three GMS manifest components flipped to android:enabled="false" | d4675ec |
…vgabc.com/events | general in-app analytics events → XiaoJi | Every analytics URL const-string is overwritten with http://127.0.0.1 right after it loads, so the POST fails (connection-refused) — no data leaves the device | b043f8c |
…/events/device-performance-session-summary | device specs + perf telemetry → XiaoJi | Same loopback redirect — the device-perf URL is rewritten to 127.0.0.1; the reporter's own error path swallows the failure. (6.0.9 renamed this endpoint from …-config; the patch matches on the stable vgabc.com/events marker, so it caught the rename.) | b043f8c |
| Firebase Crashlytics — runtime re-enable (Plan 11) | crash reports + the Firebase housekeeping hosts firebase-settings.crashlytics.com, firebaselogging-pa.googleapis.com (Firelog) & firebaseinstallations.googleapis.com. The app re-enabled Crashlytics collection at runtime, overriding the manifest flag — so Crashlytics was actually live | Disable Firebase auto-init: bytecode return-void in the app's Firebase-setup helper, after FirebaseApp.initializeApp but before the collection re-enable — so the manifest "off" holds. Device-confirmed gone (6.0.8) | patch |
Empirically verified on 6.0.9 (Jun 18 2026, v1.0.0-609): a live per-app DNS / TLS-SNI / connection capture of the patched build (using our own DNSWatch app) across a full session recorded zero connections to statistic-gamehub-api.vgabc.com or any vgabc.com/events host — instead the analytics POST visibly hit the loopback dead end (127.0.0.1) right on the device. The only servers reached were the benign ones in the "still visible" list below (catalog Worker, GitHub/badges, Steam/content CDNs, and XiaoJi's functional account backend).
Earlier confirmations: a 6.0.8 side-by-side TLS-SNI capture (Jun 2026) of stock vs patched showed the patched build reaches none of the killed channels (vgabc, Mob push, config beacons, app-measurement.com, and — with the Firebase fix — the three Firebase housekeeping hosts); an earlier 6.0.4 full-session trace showed the same. The kill patches carry forward to 6.0.9 as the same mechanisms re-fingerprinted against the new bytecode.
🪶 Rolled into every build
The 6.0.4 line shipped these as Lite-only strips. On the 6.0.9 base there's no separate Lite, so the two privacy-relevant ones now apply to every variant by default.
Aliyun NumberAuth — carrier phone-login SDK
Alibaba's carrier "one-tap" login (com.mobile.auth.gatewayauth.*) resolves your phone number through your mobile carrier — an identity surface — and bundles anti-tamper / root / emulator / proxy fingerprint checks. Dead weight under BannerHub's login bypass. The sole System.loadLibrary site is stubbed to a no-op, then libpns-*-alijtca_plus.so is deleted. 590584f
Haima cloud-gaming stack — HMCP / WebRTC
XiaoJi's cloud-gaming feature streams games from XiaoJi cloud servers — non-functional under the catalog redirect, and a live connection to XiaoJi infrastructure. The two SDK native load sites are neutralised first, then the 4 Haima libs + the whole features.cloud asset tree are stripped (~21.5 MB). 590584f
What we deliberately did not touch
Point a DNS recorder at the APK and you'll still see these. None carry per-user telemetry, but the connections are real — so here's each one and why it's left.
bigeyes.com & image CDNs
Game cover art and capsule images — plain GETs with no identifiers or events. Proxying every cover render through the Worker would cost real money for a marginal gain (your IP still hits some CDN). Leaks only your IP, like loading any web image.
Firebase housekeeping — now killed (v1.2.0-608)
firebase-settings.crashlytics.com, firebaselogging-pa.googleapis.com and firebaseinstallations.googleapis.com used to appear here. As of v1.2.0-608 the Disable Firebase auto-init patch (above) stops them — device-confirmed gone from the app's traffic. You may still see them device-wide from other apps that bundle Firebase; that's not BannerHub.
play.googleapis.com — GMS
Google Play Services' API backend (Phenotype config, FCM, Play Integrity…). Its Firebase-driven share dropped with Plan 11; any residual is system Play Services — a separate app we can't patch. Block it at the network layer only with care (it can break push / Play Integrity).
GOG & Steam endpoints
galaxy-log.gog.com fires if you use GOG as a source; shared.akamai.steamstatic.com serves Steam cover art. Both are vendor-side — outside BannerHub's patch surface, the same leaks you'd get on a PC.
The BannerHub Cloudflare Worker — bannerhub-api.the412banner.workers.dev
This serves the /v6/ catalog API — game lists, cover-art URLs, component metadata and per-game install scripts. It's what replaces XiaoJi's catalog and lets BannerHub function at all.
The honest trust-shift: we didn't move XiaoJi-side trust to nothing — part of it moved to The412Banner + Cloudflare, who see the edge traffic regardless. But the Worker runs no analytics, logs no per-user request bodies, and knows nothing about you beyond the source IP Cloudflare sees on any HTTPS request. The original analytics-kill design would have routed telemetry through the Worker and discarded it server-side; the shipped design stubs it client-side instead, so telemetry never reaches the Worker at all. Source: The412Banner/bannerhub-api.
Steam, GOG & Epic logins stay between you and the store
BannerHub is a launcher and catalog layer — not an auth broker. It never asks for, sees, stores, or relays your Steam, GOG, or Epic password or session token. Each sign-in goes straight to that store, exactly as it would in the store's own client.
GOG
"Sign in to GOG" opens GOG's own OAuth page (auth.gog.com) in a WebView — you type your password into GOG's form, so it goes straight to GOG. The returned token is stored only on your device and used only against GOG's own servers. It is never sent to the BannerHub Worker or GameHub.
Steam
Login happens inside the real Steam client running under Wine — the genuine Valve binary. Your credentials and Steam Guard go directly to Valve. BannerHub has no code in that path and never sees your password or session token.
Epic
Handled entirely by Epic Online Services. BannerHub ships no Epic login or networking code at all, so your Epic credentials go directly to Epic.
None of BannerHub's patches rewrite a Steam / GOG / Epic host, and the catalog redirect only ever touches XiaoJi's two landscape-api-*.vgabc.com hosts — so your store sign-ins never transit the BannerHub Worker, Cloudflare, or GameHub's servers. Verify in GogLoginActivity.java.
Intentionally out of scope
These aren't part of the XiaoJi / Firebase / Mob / Google surface this work targeted, so they're untouched:
- Steam Cloud / Web API / friends — Valve-side, when you launch a Steam game.
- GOG online services & achievement sync — GOG-side.
- Epic Online Services — Epic-side (BannerHub's
EpicPortalinjection is a compatibility feature, not a privacy one).
- Anti-cheat phone-homes (BattlEye, EAC, …) — embedded in the games.
- Your own Wine / Box64 prefix data, saves, screenshots — local to your device.
- Anything inside the Windows games you run — sovereign processes, their telemetry is their own.
Don't trust the table — verify it
The patches are open source and the artifacts reproducible. Four ways to check, yourself:
1 · DNS recorder
Run PCAPdroid (or AdGuard / NextDNS) on the device while you install, open, play and quit. The hostnames should match the "still visible" list above — with none of the killed channels.
2 · Logcat
adb logcat | grep -E "vgabc.com|statistic-gamehub|/events" during a session should return zero hits.
3 · Decoded manifest
apktool d the APK and confirm the Firebase deactivation flag, the disabled com.mob.* / GMS Measurement components, and the absent Ad-ID permissions.
4 · Smali check
In the two analytics reporter methods, every vgabc.com/events URL string is immediately followed by a const-string … "http://127.0.0.1" into the same register — so the live host is overwritten before the HTTP client runs. (The obfuscated class letters change each base version; see the patch sources for the current anchors.)
Found a leak the doc doesn't mention? Open an issue — disclosure gaps are treated as bugs.
See it for yourself
Grab v6, point a DNS recorder at it, and check the table holds. Both halves are verifiable.