Hunting Android Application Bugs Using Android Studio.

A story of how i used android studio to bypass the client-side authorization and leaking user passcodes.


  • I didn't like the write-ups when the hacker didn't explain the technical details good, and he just jump to paylaod and boom bounty. because we didn't learn anything form it, we just waste our time. So in this write-up i tried to explain the detailed walkthrough and if you have any thing unclear to you please reach out to me on Twitter

  • When you read any write-up always keep in mind that there is a hard work behind the sense and the finding not easy as you read it, i have spend a lot of hours trying and debugging before find the right exploitation. With this way you wouldn't get disappointed while hunting bugs.


Before go for technical details i want to explain how the target work so you can understand the vulnerability well.

This target offers a hardware products ( Android OS ) to their clients which contain some of their own applications, those application used by the client to manage restaurants, hotels, etc..

They have a Web Dashboard, user can login to his merchant using the web dashboard and login using their mobile application too. BUT, there is a small different here.

The web dashboard contain a lot of tabs in the menu bar for managing employees, customers, orders and settings and other things. but in the mobile device they had one application for each category. ( customer app, employees app, order app, and so on) all this app connected to each other by their main app which required on the mobile device called com.comapny.engine

Client Side Authorization Bypass

Summery of the vulnerability

In 2017, i have submitted a High severity issue to this program when i found that they didn't make any kind of authorization check in their APIs endpoint, low user can interact with the admin APIs and do whatever he want. they told me that they didn't enforce a back-end validation and quickly triage the report.

Recently, they add their mobile applications to the scope. i have cleared eMAPT from eLearnsecurity one month ago so i told my self to practice some of my learned skills on a real life hunting.

Technical Details

I quickly go for their documentation page to see how user can install those apps in an emulator to use it for testing purpose, they have a sandbox domains for the testing purpose for their developers (not for hunters).

After installing all the apps in my android emulator, i quickly go to see if the old vulnerability exist in the mobile apps as well, most of the time you will find the web and mobile apps request the same back-end APIs. so i told m self if they communicate with the same back-end APIs, so probably the the issue will be exist in the mobile apps as well ( it's not fixed from 2017 yet).

So i logged as low user in the main app

when i tried to open the customer apps which need an admin privilege i found a message told me that i don't have the permission to do that

Ohhh, i like this kind of message because it means we have something to play around it :D

I decided to decompile the application to see how the application validate the user permission.

so i used MobSf framework to quickly do this for me, i decompiled the customer app

I downloaded the java source code and then open it using text editor. There is two methods i can use to quickly find the function which cause this message.

  • Use the text editor search function to search for the message that displayed to me, searching for a word like "Permission"

  • Using android studio logcat to identify what function called once we opened the app.

The first method didn't take me anywhere so i used android studio.

  • First we need to get the customer app APK from the android device

    • adb pull /data/app/

  • Then we need the source code to pass it to android studio, we already have it from MobSf

So i opened android studio with with debug APK option, then i attached my java source code to the application.

After short time i found a class called PermissionChecker.class in the common2 folder.

Well, without looking at the source code i told my self yes that's what i look for.

Identifying the vulnerability

The following screenshot shows the class source code.

From the code we can see a function called checkAccessPermission this function check if the current user has the accessPermissionName on his permissions.

The accessPermissionName is a recognized variable which hardcoded in the top of the class.

To better analyze the workflow let's debug the application, i set breakpoints in the code as follows

Then i click on the debug button to lunch the application in debugging mode.

Once the application opened i see the debugger has stopped.

I kept to search for what happened at the runtime and what variables assigned until i found the the debugger has stopped at the checkAccessPermission when i looked at the variables on it i found the variable accessPermissionName set to _ACCESS So what i thought was right, the function check if the current user has this permission assigned to him or not.

Exploiting the vulnerability

So i quickly stopped the debugger and go for the web dashboard to see what permission i have as low user. Why ? simply we need to replace the _ACCESS value with a permission that i already have as low user, so when the function check if the current user has the permission XXX it will open the app, Right ?

I logged in to the merchant dashboard as Admin, and then i requested the permission API under /v3/merchant/{ID}/permissions

the following screenshot shows that there is a permission called MANUAL_ENTRY_ALLOWED which assigned to the low role that i already created and give it to my low user TestRole

So i copied this value and i run the debugger again.

Once we come to the checkAccessPermission function, let's change the value of the accessPermissionName from _ACCESS to MANUAL_ENTRY_ALLOWED

Then continue the debugger until it finished

And yes, the application opened successfully and i'm able to see the customer information, ok what's next ? just view only ? No, let's try to modify or add new data.

i clicked on "Add Customer" Button, and i found that the debugger has worked again, it seems that this function working with each step to make sure the user was allowed to do that.

So i repeated the steps again by changing the value from _ACCESS to MANUAL_ENTRY_ALLOWED

i found the add page has opened, i inserted the required data and click on save and again, the debugger has worked to check the permission and once again i repeated the steps. and as shown below, i have added the user successfully.


I reported this to the program at 17 July 2020 may be around 10pm, they replayed to me asked if i can reproduce this without a debugger, at the first the team thought this issue wasn't exploitable in their production app, but i told them it's possible since low user can login to his account form emulator even in production env.

4 days later, they confirmed the bug and it exist in all their applications that use the same class PermissionChecker , the team updated the severity to High and reward me 2500$

Leaking the passcode through logs

Android logs is a good place to look for sensitive data exposure. this issue doesn't have a lot of technical details, so i will go through it direct.

I opened the engine app using android studio and then i opened the logcat tab.

Then i started opening each application one by one, after that i go for logcat and search for some strings

When i type my user email address i found that a search result returned.

When i looked through the data i found the class MerchantService.class has a function called doNotifyLocalProperites

This function get the user information including the passcode and log it to android logs

Great, i can see the owner passcode, the passcode are meant to use as a login authentication in the mobile device which set by the owner through the web dashboard

So i logged out from my account and once i click on any application, it will ask me to enter my passcode.

So i entered the owner passcode which i got form the logs. and now i have owner access over the merchant which mean i takeover it. As example i opened the setup app

I reported this issue to the program at 21 July 2020, and they replayed after 30 mins tell me they may not consider this as an issue since it relies on device logs which you can't normally access on production devices. but i explained to them that his issue not exist due to android studio but it's an issue in the code itself. i updated the report with the a screenshot shows the vulnerable function and the line of code which log the data.

Then they marked it as Low and reward me 300$. i replayed to them that i'm not comfortable with the bounty discussion because the mitigation they will do in the first vulnerability above wouldn't mitigate this issue.

As i said above, the team was very professional and in less than 5 hours, they discussed the impact again and decided to upgrade it to Medium and award me another 450$ plus a 50$ bonus.

Thanks for taking the time to read this.