Editorial illustration for Anand: Gmail black-box limits AI reverse engineering of proprietary software
Gmail's Black Box Blocks AI Reverse Engineering
Nishant Tiwari, a software engineer at PayPal with 2.8 million followers on Instagram, ran a simple test on Uber's app last month. He pulled the same ride across four phones, three Android and one iPhone, repeating the trip five or six times. His AI-assisted reverse-engineering setup flagged scripts in Uber's client-side code reading battery status and other device details. The pattern that emerged: fares shifted with battery levels.
What made that experiment possible is a tool called Reverse Engineering Anything, an open-source GitHub project built by a user going by morluto, who did not respond to requests to discuss the project. REA connects AI agents directly to reverse-engineering software, letting people without formal training in assembly or binary analysis pick apart how an app actually works. The repository's star count jumped from roughly 10,000 in early October to more than 447,000 now, putting it among the five most-starred projects on GitHub.
That growth raises a harder question for any company shipping proprietary software: once AI can narrate what a program is doing step by step, how much of that product's logic stays private, and how much becomes something any customer can just read.
For enterprise software companies, the risk is therefore not simply whether AI can inspect their applications. It is whether it can produce a reliable substitute for a feature customers are willing to pay for.
Why this matters
Tiwari's Uber experiment shows what AI reverse-engineering tools can already do to client-side code once it ships to a browser or an app: pull apart scripts, flag what they're grabbing from a device, and do it across multiple phones in an afternoon. That's a real shift for anyone who assumed obfuscated JavaScript was a decent shield. But Anand's point about Gmail matters just as much, maybe more.
Server-side logic that never reaches the client stays out of reach, limited to black-box prodding and guesswork. The lesson for developers and founders isn't that proprietary software is dead. It's that the perimeter has moved.
Anything living in the browser is now fair game for a motivated engineer with the right AI tooling, while anything kept server-side still holds. Agarwal's framing of AI as a tool developers use to spot patterns cuts both ways here: the same techniques that help teams audit their own code are what outside researchers use to audit everyone else's. Architecture decisions about what runs where just became a security question, not just a performance one.
Related Reading
AI Tools & Apps Claude gains shared context in Excel, PowerPoint; Microsoft adds Copilot Cowork
AI Tools & Apps Sarvam Signs 5-Year Defence AI Deal Covering Army, Navy and Air Force
AI Tools & Apps LG's recent webOS update adds Microsoft Copilot app, now removable
From Archives Korea Advances AI Ecosystem With NVIDIA OpenShell Secure Runtime
From Archives Apple cracks the door open to Siri AI as Wiz details enterprise AI agents
Common Questions Answered
What did Nishant Tiwari discover about Uber's pricing algorithm using AI reverse engineering?
Tiwari's AI-assisted reverse-engineering setup detected scripts in Uber's client-side code that read battery status and other device details across multiple phones. After repeating the same ride five or six times on three Android phones and one iPhone, he discovered a pattern showing that fares shifted based on battery levels, revealing potential pricing manipulation tied to device status.
How does AI-powered reverse engineering differ from traditional obfuscation methods for protecting proprietary software?
Traditional obfuscated JavaScript was previously considered a decent shield for protecting client-side code, but AI reverse-engineering tools can now pull apart scripts and flag what they're accessing from a device in a matter of hours. This represents a significant shift in security assumptions, as AI can analyze code across multiple devices simultaneously and identify patterns that manual inspection would miss.
What is the main vulnerability difference between client-side and server-side code mentioned in the article?
Client-side code that ships to browsers or apps is vulnerable to AI reverse engineering once it reaches users' devices, as demonstrated by Tiwari's Uber experiment. In contrast, server-side logic that never reaches the client remains out of reach from reverse-engineering tools, providing stronger protection for proprietary software features and business logic.
Why is AI reverse engineering considered a threat to enterprise software companies beyond just code inspection?
The real risk for enterprise software companies is not simply whether AI can inspect their applications, but whether AI can produce a reliable substitute for features that customers are currently willing to pay for. This means AI could potentially replicate proprietary functionality without authorization, directly threatening the business model and revenue streams of software vendors.
Further Reading
- Cheap AI-Assisted Reverse Engineering and What It Will Do - arXiv
- WiREBench: Evaluating AI Agents' Capabilities in Reverse-Engineering Black-Box Applications in the Real World - NeurIPS
- Defeating AI-Assisted Reverse Engineering (or at Least Trying To) - Quarkslab
- What happens when AI reverse engineers your app? - Oktsec
- Mobile App Security In The Age Of Agentic Reverse Engineering - Cryptomathic
