Search for a command to run...
Hi, I’m a Penetration Tester. My job is to intentionally make applications do things they’re not supposed to—finding flaws and exploiting them to ensure they’re secure. I specialize in Web, API, Android, and iOS security.
No comments yet. Be the first to comment.
Download Genymotion with virtual box: https://www.genymotion.com/product-desktop/download/ Installing Genymotion1. You can see something like “genymotion-3.X.X-linux_x64.bin” in your Downloads directory.2. Open your terminal and navigate to your Down...
This is a simple blog for connecting the Genymotion and the Burpsuite for Android Pentesing using OpenVPN. I use Genymotion (Google Pixel 3 — Android Version 9) and Kali Linux Let’s start the configuration. Make sure you save this two scripts. Githu...
Hello again, 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. Lo...
These vulnerabilities were Identified on one of the YesWeHack’s Private Program. I was hunting late night when i received an invitation from one of the Private Program. As they Were Interested on critical reports. I was looking for SQLi, Command Exec...
First of all, Select the required python version (Example: 3.11.9) 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 l...
On this page
I recently stumbled upon an interesting misconfiguration in the EvilCorp Bug Bounty Program. The Android application had Root/Jailbreak Detection enabled, and my goal was to bypass it without relying on runtime manipulation tools like Frida, Objection or MagiskHide.
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.
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.
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.
Here’s what I did:
Turned off my VPN connection.
Removed any proxy/VPN configuration from my PC.
Cleared the EvilCorp app’s cache/storage.
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.
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.
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.
The flow went like this:
Clicked “Create Account”
Landed on the registration page
Filled details → OTP sent
Successfully received OTP
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.
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
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.
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.
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.
Reported: 2024–06–19
Closed as Informational: 2024–08–01