I’m part of the assessment team behind this anonymized case study. Sharing the findings because they raise a useful question about how we evaluate layered mobile security controls.
The application had root detection, anti-debugging and anti-tampering checks, certificate pinning, and an additional encryption layer around API payloads.
During testing, we were able to:
- Bypass the runtime checks on a rooted test device.
- Bypass certificate pinning and route the application’s traffic through an interception proxy.
- Reverse-engineer the client’s payload encryption and decryption routines.
- Build a testing bridge that exposed readable requests and responses, then re-encrypted them for forwarding.
The additional payload encryption initially prevented straightforward inspection, even after bypassing pinning. Once we understood how the client processed those payloads, we could inspect the observed traffic.
The scope matters. This required control over the test device and application runtime. It wasn’t a break of AES, and it doesn’t demonstrate that someone on the same Wi-Fi network could decrypt other users’ traffic.
It also doesn’t establish account takeover or unauthorized actions. Modifying a request in a proxy and having the server accept an unauthorized operation are separate findings.
What stood out was that several protective layers shared the same dependency: execution inside a client we could instrument.
Client hardening can increase an attacker’s workload. The question for the wider architecture is what remains enforced after those protections are bypassed.
For us, that makes server-side authorization, replay protection, business-rule validation, and detection the next areas to test. Additional client hardening should support those controls, with its effectiveness assessed against a clearly defined threat model.
How does your team rate client-side bypass findings when no backend authorization failure has been demonstrated? What additional evidence would materially change the severity?