June 3, 2026
Finding an Unintended Privilege Escalation While Solving Mobile Hacking Lab’s Food Store Challenge
While hunting for SQL Injection, I accidentally became the CEO of the Food Store.
@4b6o07
2 min read
Introduction
I recently started working through the Food Store challenge on Mobile Hacking Lab.
The lab is designed to teach SQL Injection in Android applications. My original goal was simple:
Find the vulnerable signup functionality, exploit the SQL Injection, and become a Pro User.
As usual, I opened the APK in JADX and started tracing the authentication flow.
What I didn't expect was finding a completely different vulnerability before even reaching the intended challenge.
Understanding the Application
The Food Store app has two user types:
Regular User
- 100 Credits
- Standard functionality
Pro User
- 10,000 Credits
- Premium privileges
After successful authentication, users are redirected to MainActivity.
At first glance everything looked normal.
Following the Login Flow
Inside LoginActivity I found the following code:
int credit = user.isPro() ? 10000 : 100;
intent.putExtra("USERNAME", inputUsername);
intent.putExtra("USER_CREDIT", credit);
intent.putExtra("IS_PRO_USER", user.isPro());
intent.putExtra("USER_ADDRESS", user.getAddress());int credit = user.isPro() ? 10000 : 100;
intent.putExtra("USERNAME", inputUsername);
intent.putExtra("USER_CREDIT", credit);
intent.putExtra("IS_PRO_USER", user.isPro());
intent.putExtra("USER_ADDRESS", user.getAddress());The application collects information from the authenticated user and forwards it to the next activity.
Nothing suspicious yet.
But security reviews often become interesting when you look at what happens on the receiving side.
Trust Issues
Moving into MainActivity, I found this:
String username = getIntent().getStringExtra("USERNAME");
this.userCredit =
getIntent().getIntExtra("USER_CREDIT", 0);
boolean isProUser =
getIntent().getBooleanExtra("IS_PRO_USER", false);String username = getIntent().getStringExtra("USERNAME");
this.userCredit =
getIntent().getIntExtra("USER_CREDIT", 0);
boolean isProUser =
getIntent().getBooleanExtra("IS_PRO_USER", false);The application was directly consuming values from Intent extras.
No database lookup.
No verification.
No integrity checks.
No session validation.
The activity simply trusted whatever it received.
At that moment a question came to mind:
What happens if I provide those values myself?
Testing the Theory
Instead of logging in normally, I decided to launch the activity manually using ADB.
adb shell am start -n com.mobilehackinglab.foodstore/.MainActivity \
--es USERNAME "CEO" \
--ei USER_CREDIT 999999999 \
--ez IS_PRO_USER true \
--es USER_ADDRESS "Owned"adb shell am start -n com.mobilehackinglab.foodstore/.MainActivity \
--es USERNAME "CEO" \
--ei USER_CREDIT 999999999 \
--ez IS_PRO_USER true \
--es USER_ADDRESS "Owned"The command executed successfully.
No errors.
No validation.
No complaints from the application.
Figure 1 — Launching MainActivity with Forged Values
Launching MainActivity with attacker-controlled Intent extras.
The Unexpected Result
The application immediately accepted every value I supplied.
Instead of becoming a regular user, I had become:
Guest: CEO
Credits: 999999999
Pro UserGuest: CEO
Credits: 999999999
Pro UserNo authentication.
No SQL Injection.
No database modification.
Just trusted client-controlled values.
At this point I was technically the richest customer in the entire Food Store.
Figure 2 — Welcome, CEO
The application displays attacker-controlled username, credit balance, and Pro User status.
Why This Happens
The application assumes that only LoginActivity will ever launch MainActivity.
That assumption becomes dangerous whenever sensitive information is passed through Intents.
The activity effectively says:
"If someone tells me they are a Pro User, I will believe them."
Which is exactly what happened.
The application trusted:
USERNAME
USER_CREDIT
IS_PRO_USER
USER_ADDRESSUSERNAME
USER_CREDIT
IS_PRO_USER
USER_ADDRESSwithout independently verifying any of them.
Lessons Learned
One thing I enjoy about Android security labs is that they often teach more than the intended lesson.
This challenge was supposed to be about SQL Injection.
Instead, before reaching the SQL Injection, I stumbled into an authorization weakness caused by trusting Intent extras.
It is a reminder that:
- Authentication is not authorization.
- Client-controlled data should never be trusted.
- Security-sensitive decisions should always come from a trusted source.
Final Thoughts
This was a fun unintended discovery while working through the Food Store challenge.
The challenge author wanted me to think like an attacker targeting SQL Injection.
The application encouraged me to think like an Android reverser.
In the end, I became the CEO of the Food Store with 999,999,999 credits before ever touching the intended vulnerability.
And honestly, that made the lab even more enjoyable.
Mobile Hacking Lab
Food Store Challenge.
Connect With Me
LinkedIn: www.linkedin.com/in/mr-abdul-basith-ba826b31b
X (Twitter): https://x.com/abdulbasith1205