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 actually handles keys, network traffic, and WalletConnect signing requests.
Downloaded the release APK (v6.0.1, com.tangem.wallet), decompiled all 51 dex files with
jadx, and 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) and then
reading real source for the parts that looked interesting.
Since the file came from outside the Play Store, provenance mattered before trusting anything found 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 Play Store listing references "Online Attestation failed" as a real, specific error condition — which 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 (nobody had submitted this exact build before) rather than either confirming or refuting anything.
The basics are done right: cleartextTrafficPermitted="false" globally, trust anchors
restricted to the system store only (no debug overrides baked into a release build), and
allowBackup="false" so there's no ADB-backup extraction path for app data. No certificate
pinning, though — a rogue or compelled CA in the OS trust store (rooted device, malicious profile) could
still intercept traffic. Standard-but-not-maximal hardening.
Locally-stored sensitive values go through a hand-rolled AndroidSecureStorageV2 class:
AES-256-GCM, a random IV per write, and the key itself generated and held inside Android Keystore —
StrongBox-backed on hardware that supports it. That's the correct pattern, not the common mistake of
encrypting with a key that's itself stored in plaintext next to the ciphertext. The main local database is
also encrypted at rest via SQLCipher.
X509TrustManager with empty checkServerTrusted/checkClientTrusted
bodies — a textbook TLS-validation bypass, accepting any certificate with no checks at all. It's gated
behind Build.VERSION.SDK_INT < 25, meaning it only fires on Android 7.0 and older. On any
device from the last several years this code path never runs, so real-world exploitability today is close
to zero — but it's a genuine defect in bundled code, scoped to the in-app support-chat feature rather than
anything wallet- or key-related.
This was the part worth actually tracing end to end, since it's the most realistic remote attack surface
for a wallet app. Followed the whole path from an incoming wc:// deep link through to the
point a transaction actually gets signed:
PreSign state and just parks there
on an internal channel. The only thing that can unblock it is a sign() call wired to
exactly one place — the Compose UI's confirm button. Nothing progresses without that user-originated
signal.No auto-approve path found anywhere in that chain. Combined with Tangem's whole premise — the private key never leaves the physical card, the app only ever relays signing requests over NFC — this is a reasonable, defense-in-depth design at the software layer.
Every scanned card goes through an attestation check — offline (challenge-response against the card's own secure chip) and, depending on mode, online against Tangem's backend. The important part: on a real production card, a failed attestation is a hard, non-bypassable error — there's no "continue anyway" button. The only code path that offers an override exists for a developer/test firmware variant, not consumer hardware. That's a meaningful anti-counterfeiting control, not just a scary dialog that goes away if you tap through it.
Root/bootloader/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, while the newer Tangem Pay (spending/card) 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's not boilerplate — someone on that team is actively tracking vendor security bulletins for specific hardware and reacting when a patch closes the gap. Not something you'd 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 (Frida-style hooks are a known technique against exactly
this pattern); a CryptoObject-bound one can't, because the actual key operation stays locked at the
hardware/TEE level regardless of what the app layer reports.
For a piece of software that ~100K+ people are trusting with crypto, this is a noticeably more carefully built app than the "wallet app that got the basics wrong" horror stories that show up periodically in this space. Real hardware-backed key storage, a signing flow that can't be tricked into an auto-approve, a card attestation system with actual teeth, and 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 but low-impact given how narrow its trigger condition is.
What I can't speak to yet: the actual NFC/card pairing experience, whether the physical secure element lives up to its own claims, day-to-day reliability, or customer support quality beyond what showed up in Play Store reviews. That's the part that needs an actual card in hand — follow-up to come once one's ordered.