Key Takeaways:
- A key compiled into an app is the same on every phone that installs it
- This week’s example resolves its servers through a lookup service in China, encrypting each lookup with DES and an eight-character key built into the app
- A second hardcoded key decrypts the account profile cached on the device, and the app’s contacts prompt says it uploads your address book
- DNS filtering never sees these lookups, which is why app vetting needs to look at runtime behavior
A key compiled into an app is the same key on every phone that installs it. Pull it out of one copy and you hold it for all of them. Developers know this, and keys still ship in binaries every week. This week’s example puts two of them in front of things an organization cares about: where the app’s traffic goes, and the account data it keeps on the device.
What the app is
The app is one of China’s largest social and lifestyle apps, with a large shopping side. In early 2025 it spent a stretch as the No. 1 free app on the US App Store, so it is on more Western phones than its home market would suggest, work phones included.
The app has been anonymized. Reach out to us directly to get the name and the de-anonymized risk information.
What we observed
Q-scout ran the iOS build on a real device and traced what it did.
Most apps ask the phone to resolve a hostname and let the operating system use whatever DNS the network provides. This one doesn’t, for its own servers. It uses an HTTP-based lookup service run by Tencent, and it fetches that service’s settings from an address in China over plain HTTP. The URL ends in alg=des.
That parameter is accurate. Each lookup the app sends is encrypted with DES in ECB mode, using an eight-character key built into the app. The answers come back the same way, and they carry the server addresses plus the device’s public IP as the lookup service saw it. DES became a federal standard in 1977, and NIST withdrew it in 2005 because it can be brute-forced. Here it doesn’t need to be: the key is in the package.
A second hardcoded key, AES this time, decrypts the account profile the app caches on the phone. The profile shows what the account is and can do, for example creator, brand or commerce flags. Twenty-seven files in the app’s storage use a protection class that keeps them readable from the first unlock until the phone restarts.
Then there is the contacts prompt. In the app’s Chinese text, the permission request says it will encrypt and upload the user’s address book and store it on its servers, to recommend friends and people the user may know. The trace shows the app using the contacts permission, and the prompt is explicit about what happens next.
Why it matters
DNS is where many organizations do their filtering. Secure DNS services, protective DNS and a lot of web gateways decide what a phone may reach by seeing what it looks up. An app that resolves its own servers through a third-party service, over HTTP, never asks those controls. And because the lookups are protected by a 1977 cipher and a shared key, anyone on the same network who has pulled the key from the app can read them, and could answer them.
The contacts are the data loss part. A work phone’s address book holds colleagues, customers and partners, with direct numbers and titles. When an app’s own prompt says it uploads that list, one tap moves it off the device and onto a server the organization has no agreement with.
How we found it
Q-scout decompiles the binary and runs the app on a real device, tracing calls into the system’s encryption library, its network APIs and its file storage. That is how the DES and AES keys, the plain-HTTP settings URL and the file protection classes surfaced. Permission analysis reads the app’s own usage strings, which is where the contacts language came from. A software bill of materials covered the 209 components the app ships with.
What to do
Most fleets let this app on by default because nothing about it looks like an enterprise risk. A vetting policy that looks at what the app actually does, including DNS that bypasses the device and keys in the binary, catches it before it reaches a managed phone. Where it is already installed, revoking its contacts permission is the quick fix.
The fix on the developer’s side is well known. Keys belong on the server, lookups should use DNS over HTTPS or the operating system’s resolver, and DES has no place in a 2026 release.
Contact Quokka to learn which app this is and to see what the apps on your devices are doing with their keys.
