Food Store From Mobile Hacking Lab
This is a challenge that we have to analysis the code, and in the code we will found an SQLi that will led to a SQL injection. This is my own methodology and the way that I approach these challenges. The idea with this challenge is to convert our user into a Super User.
Before opening Jadx and starting to analyze the application, I found that the app only lets you register a regular user:
Static Analysis
I started looking in the source code to see how the application is adding the input to the database. I used JADX to verify this:
The way this app works stood out to me. The adduser function is responsible for inserting values into the database when a user signs up. Below is the line the app uses in the background to add a new user to the database:
String sql = “INSERT INTO users (username, password, address, isPro) VALUES (‘” + Username + “’, ‘” + encodedPassword + “’, ‘” + encodedAddress + “’, 0)”;
As we can see, this specific line does not sanitize the input provided by the user, which leads to a SQL Injection (SQLi) vulnerability. Since user input is concatenated directly into the SQL query, an attacker could manipulate the query to access or modify unauthorized data.
Before attempting any injections, I examined the database using DB Browser for SQLite to understand how the data was being stored. This step helped me confirm the structure of the database and identify where user information was saved, which is important when testing for SQLi vulnerabilities.
I first tried introducing the input in plaintext, but the app immediately crashed. This meant that when the app attempted to read the data, it caused an error and shut down. While this might seem like a failure, it was actually a good sign—it indicated that the SQL manipulation was successful, but the app couldn’t process the input because it wasn’t encoded.
My next idea was to escalate privileges by using the following query:
UPDATE users SET isPro = 1;
In this database, if isPro = 1, the user is treated as a Pro User. If isPro = 0, the user is considered a Regular User. Gaining Pro status would effectively give me additional access or features.
The issue, however, is that the vulnerable code only allows INSERT operations, since the query gets executed exactly as written inside the INSERT INTO statement. This means I can’t directly run an UPDATE unless I can break out of the original INSERT query.
At this point, I went back to analyze why plaintext input didn’t work in the first place. The answer was clear: I had completely bypassed the app’s logic. Normally, the app encodes the password and address fields in Base64 before inserting them into the database. Since my injected payload didn’t follow this rule, the application couldn’t process it correctly.
With this knowledge, my next approach was to insert the payload while making sure the password and address values were Base64-encoded. This way, I could stay consistent with the app’s expected logic while still attempting to inject SQL into the query.
z’, ‘YQ==’, ‘Yg==’, 1);–`
Finally, I got access as a ProUser: