Tangem sells an NFC-based hardware wallet. A credit-card-sized secure element instead of a USB dongle. Before spending money on the physical card, I pulled the companion Android app apart to see how it handles keys, network traffic and WalletConnect signing requests.
Downloaded the release APK, v6.0.1 of com.tangem.wallet. Decompiled all 51 dex files with
jadx. Used androguard to pull apart the binary manifest, network security config
and signing block. From there it was mostly grepping for the classic mobile-vuln patterns. Disabled TLS
validation, exported components, weak crypto, hardcoded secrets, WebView JS bridges. Then reading real
source for the parts that looked interesting.
The file came from outside the Play Store, so provenance mattered before trusting anything inside it. Two things lined up. Google Play's listing shows the app was "Updated on Jul 28, 2026", which matches the APK's own internal resource timestamps almost to the hour. And a public Tangem support reply on that same listing references "Online Attestation failed" as a real, specific error condition. That turned out to match an actual code path found later in the teardown. Not something a fake listing would think to fabricate. A VirusTotal cross-check came back inconclusive, since nobody had submitted this exact build before. It neither confirmed nor refuted anything.
The basics are done right. cleartextTrafficPermitted="false" globally. Trust anchors restricted
to the system store only, with no debug overrides baked into a release build. allowBackup="false",
so there is no ADB-backup extraction path for app data. No certificate pinning, though. A rogue or compelled
CA in the OS trust store could still intercept traffic, via a rooted device or a malicious profile. Standard
hardening, not maximal.
Locally stored sensitive values go through a hand-rolled AndroidSecureStorageV2 class.
AES-256-GCM, a random IV per write, and the key generated and held inside Android Keystore. StrongBox-backed
on hardware that supports it. That is the correct pattern. Not the common mistake of encrypting with a key
stored in plaintext next to the ciphertext. The main local database is encrypted at rest via SQLCipher
too.
X509TrustManager with empty checkServerTrusted and
checkClientTrusted bodies. A textbook TLS-validation bypass, accepting any certificate with no
checks at all. It is gated behind Build.VERSION.SDK_INT < 25, so it only fires on Android 7.0
and older. On any device from the last several years the code path never runs, and real-world exploitability
today is close to zero. It is still a genuine defect in bundled code. Scoped to the in-app support chat, not
anything wallet-related or key-related.
This was the part worth tracing end to end. It is the most realistic remote attack surface for a wallet app.
I followed the whole path, from an incoming wc:// deep link to the point a transaction gets
signed:
PreSign state and parks there on an
internal channel. Only a sign() call unblocks it, and that is wired to exactly one place, the
Compose UI's confirm button. Nothing progresses without that user-originated signal.No auto-approve path anywhere in that chain. Combine that with Tangem's whole premise, where the private key never leaves the physical card and the app only relays signing requests over NFC, and this is a reasonable defense-in-depth design at the software layer.
Every scanned card goes through an attestation check. Offline, as a challenge-response against the card's own secure chip, and depending on mode, online against Tangem's backend. Here is the important part. On a real production card a failed attestation is a hard, non-bypassable error. There is no "continue anyway" button. The only code path offering an override exists for a developer and test firmware variant, not consumer hardware. That is a meaningful anti-counterfeiting control, not a scary dialog you can tap through.
Root, bootloader and Xposed detection runs via a bundled commercial anti-tampering module, risk-tiered sensibly. The general wallet UI shows a dismissible "I understand, continue" warning on a compromised device. The newer Tangem Pay spending feature hard-blocks itself entirely on the same signal.
More surprising, the app carries a specific, dated check for CVE-2026-20435, a MediaTek chipset vulnerability. Complete with a hardcoded list of roughly two dozen affected SoC model numbers and a patch-level cutoff date. That is not boilerplate. Someone on that team tracks vendor security bulletins for specific hardware and reacts when a patch closes the gap. Not what you expect to find by accident in a wallet app's decompiled source.
Biometric authentication is bound to a BiometricPrompt.CryptoObject wrapping a real Keystore
cipher, rather than a plain boolean success callback. That distinction matters. A callback-only
implementation can be faked with instrumentation, and Frida-style hooks are a known technique against exactly
this pattern. A CryptoObject-bound one cannot, because the key operation stays locked at the hardware and TEE
level whatever the app layer reports.
For software that 100K+ people trust with crypto, this is a noticeably more careful app than the "wallet that got the basics wrong" horror stories this space produces. Real hardware-backed key storage. A signing flow that cannot be tricked into an auto-approve. A card attestation system with actual teeth. Security engineering that goes as far as tracking a specific chipset CVE. The one defect found, the legacy TLS bypass in the chat SDK, is real and low-impact given how narrow its trigger condition is.
Here is what I cannot speak to yet. The NFC and card pairing experience. Whether the physical secure element lives up to its claims. Day-to-day reliability. Customer support quality beyond what showed up in Play Store reviews. That needs an actual card in hand, and a follow-up once one is ordered.