We analyzed the iOS app[1] and observed similar traffic as well as a number of basic security issues (hardcoded encryption keys, use of 3DES and some traffic over HTTP).
Thanks for writing this article! I quite enjoyed it.
question: does the DeepSeek's app use of hardcoded encryption keys rise beyond just their attempt to obfuscate and protect their app's private API endpoints? I believe this an attempt to make abusing their mobile app's private web APIs more difficult since even with cert-pinning disabled and HTTPS MITM'd you still can't observe the real traffic and replicate their requests.
If all its doing is obfuscation though, then I don't understand why pointing out that the keys are hardcoded is meaningful. It certainly doesn't engender trust. But if the app's binary is ultimately decoding some encrypted data, it needs the key, meaning it's ultimately available to the reverse engineer. Whether it's hardcoded or not doesn't matter.
It's a bad look, but if the app used the latest tech and assigned each client its own symmetric encryption key for a session, wouldn't you still be able to access the same data? What would be meaningfully different from a security perspective if they had done this obfuscation better?
Apple disallowed HTTP by default, you can flip a bit in the config to allowlist some/all endpoints to HTTP. Not clear what the App Store actually does when reviewing this info when you submit.
Despite their goal of enforcing in 2017, it is still not a hard requirement. Back then, about 80% of the apps we tested disabled ATS either partially or fully [1]. It’s rare to see Apple walk something back [2], but here is a blog at the time that talked about it [3].
[1] https://www.nowsecure.com/blog/2025/02/06/nowsecure-uncovers...