Hardcoded Key and Weak Crypto in a Mobile Build
A fintech Android app stores an API signing key as a string constant in the APK, uses AES/ECB with a static IV for local caching, and pins certificates by comparing the SHA-256 of the leaf certificate to a value in strings.xml. The app also logs full request bodies (including account numbers) to logcat in release builds. QA says 'the code is obfuscated with ProGuard, so the key is safe.' The backend trusts the signed requests as proof of app integrity. A researcher publishes a script that extracts the key and forges requests. The team proposes moving the key to BuildConfig and enabling R8.
1. Assess the proposed fix and the 'obfuscation protects the key' claim.
Read the worked answer
Both are insufficient. BuildConfig and R8 change where/how the constant appears, not whether it ships - any key embedded in the APK is extractable by a determined attacker (decompile, grep, dynamic instrumentation). Obfuscation raises effort, not secrecy; for a key that authenticates requests to a backend, effort is not a control. The real defect is architectural: the backend treats a client-held secret as proof of integrity, which is unachievable on an untrusted device. Fix: move signing to a server-issued, per-user short-lived token bound to authentication, treat client requests as untrusted input, and add server-side anomaly detection. Key extraction then yields little because there is no static secret to steal.
2. Separately, rank the ECB/static-IV, the logging, and the pinning implementation for remediation, and explain the pinning flaw.
Read the worked answer
Logging first - account numbers in logcat are readable by any app with log access on debuggable/older devices and leak real customer data today; trivial to fix, high impact. Pinning next: comparing the leaf cert hash is brittle (breaks on renewal) and, more importantly, if the comparison is done in a way that can be patched out or if the pinset isn't enforced at the network stack, an attacker with instrumentation bypasses it; pin to the SPKI of a CA or intermediate with a backup pin, and enforce via the platform's network security config. ECB/static IV last but real: ECB leaks plaintext structure and a static IV makes encryption deterministic, so identical records produce identical ciphertext - use AES-GCM with a random per-record IV. Ordering follows data-exposure immediacy and fix cost.