top of page


20 NOVEMBER 2026
BENGALURU


( SPEAKER )
Vigneshwaran Elangovan
Android Architect
Protectt.ai
Vignesh is an Android Architect at Protectt.ai, where he works on Android runtime protection (RASP), code obfuscation, bytecode virtualization, and device attestation for banking and fintech apps deployed at scale. He has a decade long background in Android development, mobile architecture, and performance optimization, building and scaling consumer-facing applications for global enterprises including Tesco, DBS bank, BYJU'S, and NIUM. and writes about mobile security and AI at vickycodes.com.
Session
Obfuscation in the AI Era: Making Android Code Harder for LLMs to Reverse Engineer
Android engineers now reverse-engineer apps the fast way: unzip the APK, run JADX, paste the decompiled output into an LLM, and ask what the code does. It works alarmingly well — and it has a blind spot. LLMs reason over text. They don't execute the app, prove a call graph, or guarantee data-flow accuracy. That gap is a defensive opportunity.
This talk is about obfuscation designed specifically for how LLMs read code. I'll walk through four source-level techniques — context-window exhaustion, working-memory saturation, token confusion (Unicode homoglyphs and zero-width characters), and comment misdirection — and then the strongest tool in the stack: bytecode virtualization, which moves sensitive logic out of source-like control flow entirely and leaves an LLM staring at a generic interpreter loop over opaque bytes.
To test whether any of this actually matters, I built a synthetic banking app that combined these techniques, shipped it as an R8-minified release APK, decompiled it with JADX, and handed only that output to a frontier model. It did not recover the real embedded key. It confidently reported a decoy instead — it trusted an incomplete decompiled view over the bytecode and stopped too early.
I'll be honest about the limit: this is not real secrecy. A skilled human with runtime tracing still wins, and you should never ship real secrets client-side. The win is different, and it's the whole point — friction, delay, higher analyst cost, and forcing an attacker off the "paste into an LLM" shortcut and back into real reverse engineering.
You'll leave knowing:
Why LLM-assisted reverse engineering succeeds, and the specific weaknesses it inherits from being text-only
Four concrete, fully reversible obfuscation techniques you can reason about and apply selectively
How bytecode virtualization blinds LLM-only static review — and what it costs you at runtime
How to treat client-side protection as an economic problem (raising cost-to-objective) rather than as secrecy
Where this is worth it (high-value logic only) and where it's wasted effort
bottom of page