At BlackHat Asia 2026 (Marina Bay Sands, Singapore, April 24, 2026), the Mobile Track Spotlight panel brought three Mobile Track review board members on stage for a candid, audience-driven discussion on the state of mobile security. Anant Shrivastava — founder of Cyfinoid Research, working in mobile software supply chain and cloud security — moderated, introducing panelists Shanna Daly (Sydney; runs Torren Cyber Group, specializing in digital forensics, incident response, and SOC work) and Pamela O’Shea (Melbourne; a pentest company specializing in mobile testing, web testing, and code review). With no prepared slides, the session ran on audience questions plus a few backup “filler questions,” covering AI-generated code bloat, hardware-backed security, jailbreak detection economics, AI-driven offensive research, and how practitioners should actually learn mobile security.
Summary
- Format: a track spotlight panel — all three speakers serve as judges on the BlackHat Asia Mobile Track review board. Anant opened by inviting “burning questions” from the room, with prepared questions in reserve if the audience was quiet.
- The discussion alternated between offensive and defensive viewpoints: what reviewers see in pentests and code reviews, how AI is reshaping both attacker and defender workflows, and where mobile differs fundamentally from web.
- The panel’s recurring thesis, from Anant: mobile apps run in a hostile environment at all times, so design for compromise rather than trying to detect it.
- It closed with a one-tip-each round for researchers and practitioners, followed by an invitation to continue conversations in the corridors.
Key Topics
AI-generated code bloat
- Pamela: the dominant trend is “lots of AI generated code” — code bloat keeps growing across the pentests she scopes.
- Mobile is unique because the app lives on the phone: unlike web apps that can grow without limit, “at some point people are going to have to claw back the AI code bloat in mobile.”
- More code means more to review; manually pinpointing the dangerous areas has become “a massive workload” — you simply can’t read it all.
PWAs, React Native, and cross-platform code
- Asked by Anant about progressive web apps, Pamela reported mostly seeing normal React apps that run across all platforms.
- Anant observes the inverse trend: PWA traction is declining in favor of installed apps, while Hermes (React Native’s compiler) keeps improving performance.
- Trade-off: a unified codebase means the same bug ships everywhere — “it’s easier that way” from a testing standpoint.
- Pamela’s warning: React is very hard to reverse from a black-box perspective —
Help out your pentesters and give them the source code, please. — Pamela O’Shea
AI in penetration testing
- Pamela has “consciously decided not to” let AI run the whole job. Automation is used for pattern coverage on large codebases; humans then focus on authentication and authorization logic, hunting “the P1s or the weird code paths that no one’s ever thought of trying.”
- Anant’s analysis: LLMs excel at low-hanging fruit because their knowledge body is immense for well-documented problems, but they stall on undocumented business logic. His example — an API endpoint with five functions where one rarely-used function has a weak or missing description: the LLM “is not going to be able to do anything around it” beyond the first parameter or two.
- The prerequisite is the task IT hates most:
…we have to do exactly the one thing anyone in IT hates: write good documentation. — Anant Shrivastava
Hardware-backed security (secure enclave / StrongBox)
- An audience member asked about hardware security trends — secure enclaves, StrongBox, and the fact that Android’s secure element is only reachable through OEMs.
- Anant reframed it: as reviewers, “every few months one or the other secure enclave is broken” — so is the bar shifting higher, or are the same bugs recurring?
- Pamela: hardware is heading in a great direction — the previous day’s boot ROM talk was excellent, and with the PIN isolated to a separate chip even physical access is getting harder. Containerizing functions means controlling one part of the chip no longer means controlling the rest.
- She also flagged that “the radio side is very very very messy and very very old” — baseband research isn’t stopping anytime soon.
- Another angle from the panel: implementation beats protocol — echoing the previous day’s car security talk, “it’s not the protocol that’s insecure, it’s the implementation.”
Jailbreak detection, SSL pinning, and security economics
- Pamela asks clients directly: do you want jailbreak detection and certificate pinning? For a bank, of course; for other businesses, maybe not. An overlooked angle: does the customer know they’re on a rooted device? “Don’t save anything here. It’s really hostile out there.”
- Anant noted OWASP ASVS treats these controls as optional, and framed security as an economic decision:
You don’t secure 10 rupees with 20,000. You always secure assets with things that are less costlier than the assets themselves. — Anant Shrivastava
- Over-engineered SSL pinning (pin to the leaf certificate, then the CA, then abandon it) fails in practice: a shopping app pinning to hashes would need an update every 90 days — and users won’t update.
- Real device fleets span from the latest iPhones to Android phones that stopped receiving updates years ago; since businesses want revenue from all of those users, the balance necessarily shifts.
Q&A Highlights
Has AI found truly good offensive attacks on mobile apps?
- Pamela: the “AI is going to take our jobs” fear is easing — it’s “doing a fairly decent job now,” with a new improvement every week. But mobile flows contain stop-start points (payments, facial recognition) that resist automation, so human testers still add real value.
- Anant: web flows are standardized and automatable; mobile automation breaks down because aspect ratios and click positions change with every device model. His verdict:
I think the best automation engine on Android is still Monkey, which basically does not have any sense of what it is doing. It just sends random click events. — Anant Shrivastava
How do you detect that a mobile app is running in a compromised environment?
- Pamela: “It’s how long is a piece of string.” Detection is about how much time you want an attacker to spend bypassing it — the standard checklist (emulator, rooted device, simulator) is well known and always bypassable. “It’s all about your threat appetite.”
- Shanna took the GRC angle: decide based on what the device can access and what data is stored on it.
- Anant argued the opposite stance — assume compromise. Google Play Integrity and iOS precautions can all be bypassed, so design so that compromise doesn’t matter: his example is a game’s high score, which should be validated server-side on every update rather than trusted from the client. That’s why the client-server model dominates mobile apps — and why games, which often skip it, are the ones drowning in mods and modified APKs.
Learning Resources
- Get good at web first (Pamela): mobile testing overlaps heavily with HTTP. Then take an app from a bounty platform that grants testing permission, unpack the APK/IPA, read the class files in each binary, decrypt, and explore the emulator over SSH — “Android [is] just another Linux file system.” Named platforms: Pentester Lab and Hack The Box.
- Read the platform documentation (Shanna): time spent in the Google SDK documentation builds the architectural intuition to tell malicious from benign behavior — analogous to reverse-engineering malware on Windows.
- Anant’s layered blueprint, from apps down to the OS:
- Applications: the OWASP Mobile Security Testing Guide and MASVS (Mobile Application Security Verification Standard).
- Build a trivial app in Android Studio or Xcode (one button, one calculation), install it, then decompile it and compare what you wrote against what landed on the device — including intermediate representations like smali.
- Study the API documentation and how the calls connect.
- At the OS layer: AOSP is open but “not 100% compilable” — look at LineageOS, or GrapheneOS for a defensive focus; compile them and watch how the building blocks assemble. (“If I have to understand something, I have to build it piece by piece.”)
- For offensive starters: load an APK or IPA into MobSF, see what it flags, then work out why.
- His joke alternative: open Claude Code, give it an instruction, let it hallucinate something, spend two days figuring out how it works — then start the traditional route anyway.
Key Takeaways
- Assume the device is hostile: mobile apps run in enemy territory 100% of the time — Anant quips “I am purely a man in the middle” — so put validation and trust on the server side.
- Size security to the asset: jailbreak detection and pinning are optional per ASVS; apply them when the data justifies the cost, and remember real users never update their apps.
- AI is a coverage tool, not a replacement: let it handle the documented, repetitive layers so humans can hunt business-logic flaws — but only good documentation makes even that possible.
- Threat-model the whole wireless ecosystem (Pamela’s closing tip): headphones, GPS, watches, pairing events, access points — she cited the day’s talk on tracking people through their wireless headphones as proof that mobile apps touch far more than web-style request/response traffic.
- Learn by building and breaking: spin it up, break it, fix it, write your own code and break that — defenders who know what good looks like can spot bad much faster.
