Android recon for Bug Bounty hunters: A complete guide

Found an interesting Android target in a Bug Bounty Program but have no idea where to begin?

Once you’ve built your Android lab, the next crucial step is performing recon on the scope in question.

This guide walks you through the complete Android reconnaissance process – from extracting the APK to mapping every endpoint, secret and vulnerable component. You’ll learn the exact workflow professional hunters use to uncover critical vulnerabilities without even launching the app.

In your first reconnaissance session, you’ll master:

Extracting APKs from the Play Store, devices or third-party repositories
Running static analysis to find API endpoints, hardcoded credentials and security misconfigurations
Leveraging automated tools like MobSF, MARA and Drozer to catch common vulnerabilities
Performing manual deep-dive analysis with jadx-gui to spot business logic flaws
Building a prioritised attack list ready for exploitation testing

Why effective Android reconnaissance makes all the difference

Many Bug Bounty hunters make the same costly mistake: they install the app, fire up Burp Suite and start clicking through the interface haphazardly in the hope of stumbling upon vulnerabilities. They’re testing blind.

This approach fails for a simple reason: you’re limited to what the user interface exposes. Meanwhile, the app’s codebase contains dozens of hidden endpoints, forgotten debug features, hardcoded credentials and vulnerable components that never appear in normal usage. These hidden elements are where critical findings typically live.

In our previous guide on building an Android mobile hacking lab, we showed you how to set up emulators, rooted devices and runtime tools like Frida. This equips you to handle dynamic testing – but you need to understand what you’re testing first.

Recon reveals the complete attack surface before you run a single request through your proxy. These attack vectors can include:

Hidden API endpoints that developers forgot to remove or never documented – staging servers, admin panels and legacy APIs still accessible in production
Hardcoded secrets living directly in the code – eg AWS keys granting cloud infrastructure access, Firebase URLs pointing to misconfigured databases, OAuth tokens that bypass authentication
Forgotten components left enabled in production – eg debug activities that expose sensitive functionality, backup flags allowing data extraction without root access
Vulnerable dependencies that developers never update – eg third-party libraries with known exploits, outdated SDKs containing critical CVEs
Logic flaws in authentication and authorisation – eg client-side checks that can be bypassed, weak token validation, improper session management
Weak cryptography implemented by developers who don’t understand security – eg custom encryption algorithms, hardcoded keys, insecure random number generation
Cloud service misconfigurations – eg Firebase databases without access rules, publicly readable S3 buckets, exposed Google Cloud storage containers

Think about military strategy. Soldiers don’t charge into unknown territory; they study maps, identify weak points in defences, understand enemy positions. Reconnaissance provides that intelligence advantage.

A thorough recon workflow gives you two decisive advantages over other hunters:

Recon advantage #1: efficiency

You know exactly where to focus your limited testing time instead of randomly exploring the interface. When you’ve identified potential vulnerabilities through static analysis, you can systematically validate each one instead of hoping to discover something through trial and error. In short, you can achieve much more in less time.

CHECK OUT THE FIRST ARTICLE IN THIS SERIES The ultimate Bug Bounty guide to exploiting SQL injection vulnerabilities

Recon advantage #2: finding subtler, high-impact bugs

You can find critical and high-severity issues that researchers hunting ‘blind’ will miss. While they’re still testing login forms, you’ve already reported a critical Firebase misconfiguration because the decompiled code told you exactly where to look.

Real understanding comes from combining automated tools with manual analysis. Scanners catch only surface-level issues: missing security flags, known CVEs, hardcoded API keys in plaintext. Manual analysis, by contrast, catches subtle flaws: business logic vulnerabilities, context-specific misconfigurations, clever exploits that require an understanding of the developer’s intentions.

APK extraction methods: getting your target’s source code

Before analysing anything, you need the actual APK file. The necessary extraction method depends on your target’s distribution and your access level.

Downloading directly from Google Play Store

This is the fastest approach for publicly available apps, letting you download APKs directly from Google’s servers without using a device or installing the app.

Why this matters: Official Play Store versions reflect the production code users run in the wild. They contain the actual production code you need to analyse, complete with all dependencies and resources. Third-party sources sometimes host modified or outdated versions that waste your precious testing time.

Using APKeep for authenticated downloads

APKeep is a command-line tool that downloads APK files directly from Google Play Store or APKPure-hosted mirrors without requiring a physical device or manual browser interaction.

For instance:

1# Install APKeep (requires Rust)
2cargo install --git https://github.com/EFForg/apkeep.git
3
4# Download the latest version
5apkeep-a com.instagram.android .

This pulls from APKPure’s mirrored builds, which don’t require credentials but may lag behind the official release by a few hours.

For architecture-specific variants, specify the build type:

1apkeep-a com.instagram.android -o'arch=x86' .

Why architecture matters: Some apps ship native libraries (.so files) containing security-critical code. The x86 version might include different vulnerabilities to the ARM version, especially in custom cryptography or network implementations.

Direct Play Store access with OAuth

For the latest version, authenticate with Google Play directly. First, obtain an OAuth token:

Visit Google’s embedded setup page
Open browser developer tools (Network tab)
Log into your Google account
Accept Terms of Service if prompted
Find the final request to accounts.google.com
Locate the oauth_token cookie in the response
Copy the value (starts with oauth2_4/)

You can find detailed authentication steps here.

This method guarantees you’re testing the exact version users receive, including any emergency patches or regional variants.

Using third-party APK repositories

Sites like APKCombo and APKMirror archive multiple versions of popular apps. This is valuable for:

Version comparison: Developers often fix vulnerabilities without providing detailed changelogs. Downloading version 2.1 and 2.2, then comparing the code, reveals exactly what changed – exposing the vulnerability pattern they tried to patch.

Historical analysis: Older versions sometimes contain functionality that developers removed but forgot to fully disable on the backend. You might find deprecated API endpoints still accepting requests.

Why do third-party sources matter? They provide the historical context that reveals security trends. If a developer introduced certificate pinning in version 3.0, everything before that version was vulnerable to traffic interception – and the backend APIs designed for those old versions might still lack proper security controls.

Extracting from devices or emulators

When you need to analyse an app you’ve installed yourself – perhaps it’s not publicly available, or you need to test a specific configuration – direct device extraction works perfectly.

Why device extraction helps: Some apps behave differently after installation, downloading additional components or unpacking resources. The version on your device represents the fully initialised state, including any dynamically loaded code modules.

Standard APK extraction:

1# Find your target package
2adb shell pm list packages | grep target
3
4# Locate the APK file path
5adb shell pm path com.target.app
6
7# Copy it to your machine
8adb pull /data/app/com.target.app-XXX/base.apk target.apk

Handling split APKs (app bundles)

Modern Play Store distributions use Android app bundles: where instead of one large APK, Google generates multiple smaller APKs tailored to each device. Users download only what they need: the base code, their specific CPU architecture, their language, and any feature modules they’ll actually use.

Why splits complicate analysis: If you only grab base.apk, you’re missing potentially critical code. Feature modules might contain payment processing, admin panels or debug functionality. Architecture-specific splits include native libraries that could have memory corruption vulnerabilities.

Identify split APKs:

1adb shell pm path com.target.app
2# Output shows multiple paths:
3# package:/data/app/com.target.app-XXX/base.apk
4# package:/data/app/com.target.app-XXX/split_config.arm64_v8a.apk
5# package:/data/app/com.target.app-XXX/split_config.en.apk

Extract everything:

1adb pull /data/app/com.target.app-XXX/ target_apk_bundle/

Now you’ve captured the complete app. Merge them with APKTool for unified analysis, or examine each split individually to understand how functionality divides across modules.

Verifying APK authenticity and integrity

Before investing hours in analysis, confirm you’re examining legitimate code:

1apksigner verify --print-certs target.apk

This displays the signing certificate’s fingerprint. Compare it to the official Play Store version’s signature. Mismatched signatures mean someone modified the APK – either adding malware or removing security controls. Your findings won’t apply to the real target.

Why verification prevents wasted effort: Imagine spending three days analysing an APK from a sketchy download site, only to discover the real app has completely different code. Worse, you might report vulnerabilities that don’t actually exist in production!

You now have your target APK verified and ready for analysis. Now it’s time to take it apart.

Unpacking and analysing APK structure with APKTool

APKTool deconstructs APKs into readable components: the manifest declaring permissions and components, resources containing layouts and configurations, and Smali code representing the app’s logic at the bytecode level.

Why start with APKTool? Before reading code, you need to understand the app’s architecture. Which components are exposed? What permissions does it request? What resources might leak information? APKTool answers these structural questions.

Installation options

1# Arch Linux
2sudo yay -S android-apktool
3
4# Debian/Ubuntu
5sudo apt install apktool
6
7# Manual installation (latest version)
8wget https://github.com/iBotPeaches/Apktool/releases/latest/apktool.jar

Extracting APK contents

1apktool d target.apk -o target_unpacked

Installation creates a directory containing:

AndroidManifest.xml: The app’s declaration file listing every component, required permission and configuration setting
res/: All visual and text resources – layouts, strings, images, XML configurations
smali/: Disassembled bytecode in human-readable assembly format
lib/: Native code libraries for different CPU architectures
assets/: Additional files bundled with the app – databases, configuration files, media

Extracting intelligence from resources

Resources leak information developers never intended to expose. Examine res/values/strings.xml, res/xml/ and other resource files because developers frequently embed staging servers, development endpoints and internal API URLs there. For instance:

1<string name="api_base_url">https://api-staging.target.com</string>
2<string name="debug_endpoint">https://internal-admin.target.com</string>

These endpoints might lack production-level security controls. Test them – they often accept production API tokens or their authentication can be bypassed entirely.

Automated URL extraction: Instead of manually reading through resource files, use apk2url:

1git clone https://github.com/n0mi1k/apk2url
2./apk2url.sh /path/to/target.apk

This automatically extracts every URL found in the decompiled code and resources, giving you a complete list of potential API endpoints to investigate.

You now understand the app’s structure: what components exist, what permissions it requests, what URLs it contacts. But structure alone doesn’t reveal logic flaws or how the code actually works; for that, you need to read the implementation.

Decompiling to Java Source Code with jadx-gui for Manual Code Analysis

APKTool decompiles the APK into Smali, a human-readable representation of Dalvik bytecode that's accurate but difficult to read. It also allows you to modify and recompile the app.

jadx-gui independently decompiles the DEX bytecode directly into Java source code, making the app's logic much easier to understand for static analysis.

Why Java decompilation matters: You need to understand what the code does, not just what instructions it executes. Logic flaws, authentication bypasses and subtle vulnerabilities only become apparent when you can read the actual implementation.

Installation and setup

1# Arch Linux
2sudo pacman -S jadx
3
4# Manual installation
5wget https://github.com/skylot/jadx/releases/latest/jadx-gui.zip
6unzip jadx-gui.zip
7./jadx-gui

Loading and navigating your target

Launch jadx-gui and drag your APK into the window. It automatically:

Decompiles all classes to readable Java code
Extracts and displays resources
Builds a searchable index of every class, method, and string

The interface shows a tree structure on the left with all packages and classes. The right pane displays decompiled source code.

Hunting for hardcoded secrets and credentials

Developers constantly make the same mistake: embedding sensitive credentials directly in code because it’s convenient during development, then forgetting to remove them before release.

Use global search (Ctrl+Shift+F) to find common secret patterns such as:

api_key
secret_key
private_key
token
password
aws_access
firebase
bearer
authorization
client_secret
encryption_key

Why this works: Developers use predictable variable names. Even obfuscated apps often leave string literals intact, and developers rarely obfuscate test/debug builds.

Real example pattern:

1publicclass ApiClient {
2privatestaticfinalString API_KEY ="sk_live_ABC123XYZ789";
3privatestaticfinalString SECRET ="prod_secret_key_2024";
4}

These findings are immediately reportable as critical severity vulnerabilities. Anyone with the APK (which is every user) has access to credentials that might grant backend infrastructure access, database permissions or service account privileges.

Important ethical note: When you discover credentials, verify they’re real by checking if they authenticate – but never access production systems or data. Report your finding immediately without further testing to avoid legal issues.

YOU MIGHT ALSO LIKE Recon series recap: The ultimate guide to Bug Bounty reconnaissance and footprinting

Analysing custom authentication and authorisation logic

Navigate to packages containing authentication-related classes – look for names like ‘auth’, ‘login’, ‘user’, ‘session’, ‘token’.

Why manual code review catches what scanners miss: Automated tools can’t understand business logic. They can’t tell if your authentication properly validates tokens, or if it contains a hardcoded bypass for ‘testing purposes’ that still works in production.

Search for concerning patterns:

Client-side authentication checks

1if(username.equals("admin")&& password.equals("test123")){
2returntrue;
3}

This check happens before sending credentials to the server. Modify the APK to always return true, or hook it with Frida to bypass authentication entirely.

Weak token validation

1publicbooleanverifyToken(String token){
2return token.startsWith("auth_");
3}

The code only checks if the token starts with a specific string – not if it’s actually valid. Generate your own fake token and the app accepts it.

Role-based access control flaws

1if(user.isAdmin()){
2// Show admin panel
3}

If this check happens client-side, modify it to always return true. If the server doesn’t verify admin status independently, you’ve found a privilege escalation vulnerability.

Identifying insecure data storage vulnerabilities

Identify where and how the app stores sensitive information, such as:

SharedPreferences
SQLiteDatabase
FileOutputStream
getSharedPreferences
openFileOutput

Why storage matters: Session tokens, passwords, API keys and personal data stored insecurely can be extracted by other malicious apps, through backup mechanisms or by anyone with physical device access.

Example of a vulnerable implementation:

1SharedPreferences prefs =getSharedPreferences("user_data", MODE_PRIVATE);
2SharedPreferences.Editor editor = prefs.edit();
3editor.putString("auth_token", userToken);
4editor.putString("password", userPassword);
5editor.commit();

This code stores authentication credentials in plaintext XML files. Any app with backup access or root can read them.

This more secure implementation uses Android Keystore instead:

1// Encrypted storage with hardware-backed keys
2EncryptedSharedPreferences.create(...)

Finding intent handling vulnerabilities

Search for intent processing:

getIntent()
onNewIntent
getExtras
getStringExtra

Why intent handling creates vulnerabilities: Intents are Android’s inter-app communication mechanism. When apps process intents without validating the data, attackers can inject malicious input.

Vulnerable pattern example:

1Intent intent =getIntent();
2String url = intent.getStringExtra("url");
3webView.loadUrl(url);

This loads whatever URL another app provides – no validation involved. An attacker sends an intent with url = "file:///data/data/com.target.app/databases/users.db" and steals the database.

Another example:

1String filePath = intent.getStringExtra("filepath");
2File file =newFile(filePath);
3FileInputStream fis =newFileInputStream(file);

This creates a path traversal vulnerability. Supply a filepath such as "../../../../etc/passwd" and you can read arbitrary files.

Detecting WebView misconfigurations and JavaScript interface exploits

Audit WebView use across the codebase. Pay particular attention to JavaScript interfaces that expose device or file-system functionality:

1webView.getSettings().setJavaScriptEnabled(true);
2webView.addJavascriptInterface(newFileOperations(),"Android");

This exposes Java methods to JavaScript code running in the WebView. If the WebView loads untrusted content (user-provided URLs, deep links), attackers can call these exposed methods.

Example of an exploitable interface:

1class FileOperations {
2@JavascriptInterface
3publicStringreadFile(String path){
4// Reads any file accessible to the app
5returnnewString(Files.readAllBytes(Paths.get(path)));
6}
7}

JavaScript can call: Android.readFile('/data/data/com.target.app/databases/users.db') to steal sensitive data.

File access enabled:

1webView.getSettings().setAllowFileAccess(true);
2webView.getSettings().setAllowFileAccessFromFileURLs(true);

These settings let JavaScript access local files via file:// URLs, potentially leading to data theft if the WebView loads untrusted content.

Exporting decompiled source for reference

Save the entire decompiled codebase for offline reference:

File > Save all > Select output directory

This lets you grep through the code, compare versions and share findings with your team.

You’ve now manually analysed the code and identified potential vulnerabilities based on understanding the developer’s implementation. Next comes automated scanning to catch common issues you might have missed and provide comprehensive coverage.

Automated security scanning with MobSF for OWASP mobile coverage

Manual analysis finds sophisticated vulnerabilities requiring context and understanding. Automated scanning catches the common mistakes every app makes – missing security flags, known CVE dependencies, predictable credential patterns.

Why automation complements manual work: You can’t manually check every permission, every library version, every security setting. Automated scanners process everything systematically, ensuring nothing slips through while you focus on complex logic flaws.

The MobSF (Mobile Security Framework) performs comprehensive security analysis covering the OWASP Mobile Top 10 and generates detailed reports with severity ratings.

Installation with Docker

1docker pull opensecurity/mobile-security-framework-mobsf
2sudo docker run -it --rm -p 8000:8000 opensecurity/mobile-security-framework-mobsf:latest

Access the web interface at http://127.0.0.1:8000 (credentials: mobsf:mobsf)

Running static analysis

Upload your APK through the web interface
MobSF automatically extracts, decompiles and analyses everything
Wait a few minutes for the analysis to complete
Review generated report with findings organised by severity

Understanding MobSF’s detection capabilities

Application security misconfigurations:

Debuggable flag enabled in production (allows runtime manipulation)
Backup allowed without restrictions (enables data extraction)
Cleartext traffic permitted (exposes communication to eavesdropping)
Tapjacking vulnerabilities (UI overlay attacks possible)

Why these matter: Each misconfiguration represents a security control the developer forgot to enable. Debuggable apps can be attached to using debugging tools, modified at runtime and have their code execution controlled by attackers.

Code-level vulnerabilities detected by MobSF:

Hardcoded secrets (API keys, passwords, tokens)
Weak random number generation (predictable ‘random’ values)
SQL injection vectors (unsanitised database queries)
Path traversal risks (arbitrary file access possibilities)
Insecure cryptographic implementations (deprecated algorithms, weak keys)
WebView security issues (JavaScript interface exposure, file access)

Privacy and data protection issues:

Excessive permission requests beyond app functionality
Unencrypted sensitive data storage
Personal information leaked in log statements
Insecure inter-process communication

Third-party library vulnerabilities:

MobSF scans every included library against CVE databases, flagging known vulnerabilities. This is particularly valuable because developers rarely update dependencies – apps often ship with libraries containing publicly known exploits.

Example finding: “App uses OkHttp 3.12.0, which contains CVE-2021-0341, allowing certificate validation bypass.”

Why dependency scanning matters: Exploiting known vulnerabilities requires minimal skill. Public exploits exist. If the app uses a vulnerable library version, you can often copy a proof-of-concept and immediately demonstrate impact.

Performing dynamic analysis with MobSF

Beyond static analysis, MobSF performs runtime analysis by instrumenting the app with Frida:

Configure your rooted device or emulator
Connect MobSF to the device
Launch dynamic analysis from the web interface
Dynamic mode captures:
All network traffic (endpoints contacted, data transmitted)
Runtime behaviour (which components activate, what they do)
File system operations (files created, modified, accessed)
API calls to sensitive system functions

Why dynamic analysis complements static: Code might contain endpoints that never get called, or security checks that only activate under specific conditions. Dynamic analysis shows what actually happens when someone uses the app.

Understanding MobSF’s Limitations

MobSF excels at systematic checking but has blind spots:

Business logic flaws remain invisible: Exploiting an IDOR vulnerability that allows users to access other accounts requires you to understand what the API should enforce. Scanners can’t know that /api/user/123 should reject requests from user 456.

False positives need verification: MobSF might flag test API keys left in comments, or hardcoded strings that look like secrets but aren’t actually used.

Custom vulnerability patterns: Unique security issues specific to the app’s implementation – race conditions, state management bugs, complex authentication bypasses – require manual investigation.

Context-dependent vulnerabilities: Whether something is actually exploitable depends on circumstances MobSF can’t assess. An exported component may look vulnerable at first glance but still enforce the correct permission checks internally.

Use MobSF’s findings as a starting point. Every flagged issue needs manual verification. Is this actually exploitable? Does it impact real security? Can I demonstrate the risk?

Targeted vulnerability intelligence with the MARA framework

While MobSF provides broad coverage, MARA (Mobile Application Reverse engineering and Analysis) specialises in extracting actionable intelligence – specific attack vectors you can immediately test.

Why MARA differs from MobSF: Instead of generating comprehensive reports, MARA gives you raw data: every API endpoint, every cloud service configuration, every domain the app contacts. This intelligence directly feeds into your exploitation workflow.

Note: MARA development has slowed, but it remains effective for extracting specific types of findings.

Installation and setup

1git clone https://github.com/xtiankisutsa/MARA_Framework.git
2cd MARA_Framework
3./mara.sh

Extracting the complete API attack surface

1./mara.sh -s target.apk

MARA outputs every URL that is hardcoded anywhere in the APK, including:

Production API endpoints
Staging and development servers (often less secure)
Admin panels or internal tools
Third-party service integrations
Metrics and analytics endpoints

Why this creates immediate value: Feed these URLs directly into Burp Suite or Postman. Test each endpoint for authentication issues, injection vulnerabilities, information disclosure. Staging servers frequently lack production security controls – they accept production tokens but skip rate limiting or access control checks.

Firebase security assessment

Firebase – Google’s mobile backend platform – is incredibly popular and frequently misconfigured.

Firebase Realtime Database URLs
Firestore database instances
Misconfigured security rules

Why Firebase misconfigurations are critical: Default Firebase installations start completely open – anyone can read and write any data. Developers must actively configure security rules. Many forget, or configure them incorrectly.

Test immediately:

1curl https://target-app.firebaseio.com/.json

If this returns data without authentication, you’ve found a critical vulnerability. The entire database is publicly readable and writable.

Cloud credentials and storage bucket discovery

You might potentially find access to cloud service credentials, such as:

AWS access keys and secret keys
S3 bucket names and URLs
Google Cloud Platform service account credentials
Azure storage account keys

Why cloud credentials represent severe risk: An AWS access key grants access to the company’s cloud infrastructure. Depending on permissions, attackers might read databases, modify servers, or destroy resources. These findings often escalate to critical severity.

Found an S3 bucket name? Test access:

1aws s3 ls s3://discovered-bucket-name --no-sign-request

If it lists contents without credentials, the bucket is publicly readable – potentially exposing customer data, internal documents or application secrets.

Advanced reconnaissance: runtime analysis and version intelligence

Beyond primary tools, several specialised techniques catch vulnerabilities that standard workflows miss.

Runtime component testing with Drozer

Drozer provides an interactive framework for testing Android’s Inter-Process Communication (IPC) mechanisms – the ways apps talk to each other and expose functionality.

Why Drozer matters after static analysis: AndroidManifest.xml shows which components are exported, but doesn’t tell you if they’re actually vulnerable. Drozer lets you interact with those components, sending crafted inputs to trigger security issues.

1# Install Drozer
2pip3 install drozer
3
4# Run your device and forward ports for communication
5adb forward tcp:31415 tcp:31415
6
7# Connect to the device
8drozer console connect

Identifying the attack surface:

1run app.package.attacksurface com.target.app

This lists every exported component – activities, services, broadcast receivers, content providers – with each representing potential attack vectors.

Testing exported activities:

1run app.activity.start --component com.target.app com.target.app.DebugActivity

Does it launch? What does it expose? Debug activities often bypass authentication or reveal sensitive internal state.

Exploiting content providers:

Content providers act like databases shared between apps. Exported providers might allow SQL injection:

1run app.provider.query content://com.target.app.provider/users --projection"* FROM users; --"

Successful exploitation lets you extract or modify database contents from another app.

Finding broadcast injection vulnerabilities:

1run app.broadcast.send --action com.target.app.PRIVILEGED_ACTION --extra string key value

Apps use broadcasts to notify components about events. If privileged actions listen for broadcasts without proper authentication, any app can trigger them.

Warning: For these attacks to not be considered "self-exploitation" and to be concretely exploitable, you need to provide a PoC from a third-party application that you control yourself. However, we'll cover Drozer comprehensively in the next article of this series!

Version comparison for security regression analysis

Developers constantly update apps. Comparing versions reveals security improvements – and the vulnerabilities they fixed.

Why version diffing matters: When a developer patches a vulnerability, they often fix only the specific instance reported without addressing the underlying pattern. By seeing what they changed, you can search for similar flaws elsewhere in the code.

Download multiple versions:

1apktool d target_v1.0.apk -o v1
2apktool d target_v1.1.apk -o v2
3diff-r v1/ v2/ > changes.txt

Look for:

Authentication or validation code added (what vulnerability did it fix?)
Removed debug endpoints or components (why were they there originally?)
New API endpoints (do they have proper security controls?)
Changed cryptographic implementations (was the old version weak?)

Identifying debug features in production: Sometimes developers accidentally ship debug code in new versions, then remove it later. The window between versions represents an opportunity – test the functionality while it exists.

Mitigating Android app vulnerabilities: security best practices for developers

Understanding how these vulnerabilities should be fixed helps you write more impactful reports and assess whether partial mitigations already exist.

Hardcoded credentials must be changed and removed from the codebase entirely. Developers should migrate cryptographic keys to Android Keystore, store authentication tokens in EncryptedSharedPreferences, and move API secrets to backend environment variables that never touch the client.

Insecure data storage requires implementing Android’s EncryptedSharedPreferences with hardware-backed encryption. Sensitive information should never be stored in plaintext XML files, standard SharedPreferences or world-readable directories.

Exported components should be disabled by default. When exports are genuinely necessary, developers must protect them with custom permissions, validate all incoming intent data, and implement proper authentication checks before processing requests.

WebView misconfigurations need multiple layers of defence. Developers should disable unnecessary JavaScript interfaces, restrict file access to prevent local file disclosure, implement Content Security Policy headers, and never load untrusted content in WebViews with privileged access.

Firebase databases require properly configured security rules that authenticate users and validate data structure before permitting any read or write operations. Default open access should never reach production.

Vulnerable dependencies demand regular monitoring and updates. Developers should track CVE databases, implement automated dependency scanning in their CI/CD pipeline, and establish a process for rapidly patching critical vulnerabilities in third-party libraries.

From reconnaissance to exploitation: your next steps

Your reconnaissance phase is complete. You’ve mapped every component, extracted every endpoint, identified configuration weaknesses and flagged potential vulnerabilities. This intelligence becomes your exploitation roadmap.

In the next article, we’ll transform reconnaissance findings into validated vulnerabilities by:

Testing hardcoded credentials: Using discovered API keys to demonstrate unauthorised access via privilege escalation, data exposure, service impersonation.
Attacking Firebase misconfigurations: Proving unauthorised database access by reading, writing or deleting data without authentication.
Chaining vulnerabilities for maximum impact: Combining multiple findings – for example information disclosure that enables authentication bypass, which opens additional attack vectors – to produce critical-severity reports.

For now, focus on honing your reconnaissance skills. The success of your exploitation efforts depends entirely on the intelligence you gather. Even the most sophisticated exploitation techniques fail if you don’t know where to apply them.

With your mobile hacking lab configured and your reconnaissance methodology solid, you’re well positioned to discover vulnerabilities that less well-prepared hunters will miss.

Conclusion: reconnaissance builds the foundation for successful Android bug hunting

Hunters who skip reconnaissance and start dynamic testing without putting in the groundwork operate at a serious disadvantage. They’re limited to what the interface reveals – thereby missing the hidden components, forgotten endpoints and embedded secrets that represent potentially high-value findings.

Reconnaissance isn’t about finding exploits; it’s about understanding the complete attack surface before exploitation begins. What technologies does the app use? Which endpoints does it contact? What secrets live in the code? Where did developers make mistakes?

Sure, automated tools like MobSF and MARA are invaluable for handling systematic checking for common misconfigurations, known CVE dependencies and obvious credential patterns. They provide baseline coverage and catch mistakes you might overlook.

But automation has limits.

Performing manual analysis with tools such as jadx-gui goes beyond these limits. Reading the actual code, tracing data flows through the application, understanding the developer’s security assumptions – this is how you spot subtle business logic flaws, context-specific vulnerabilities and creative exploitation chains that no scanner will ever detect.

Every APK is a puzzle. Recon tells you where all the pieces are.

The next article in this series covers exploitation – taking your recon intelligence and systematically validating each finding. You’ll learn how to test hardcoded credentials, exploit misconfigured components, attack Firebase instances and chain multiple weaknesses into high-severity reports.

Your reconnaissance is complete. Your exploitation roadmap is ready. Now comes the systematic validation that transforms findings into accepted vulnerability reports.

Happy hunting! 🔍

HANDS-ON HACKING TRAINING Tackle labs and CTF challenges around common vulnerabilities on DOJO, our CTF training platform for bug hunters

Android recon for Bug Bounty hunters: A complete guide from APK extraction to mapping attack surfaces

Why effective Android reconnaissance makes all the difference

Recon advantage #1: efficiency

Recon advantage #2: finding subtler, high-impact bugs

APK extraction methods: getting your target’s source code

Downloading directly from Google Play Store

Using APKeep for authenticated downloads

Direct Play Store access with OAuth

Using third-party APK repositories

Extracting from devices or emulators

Handling split APKs (app bundles)

Verifying APK authenticity and integrity

Unpacking and analysing APK structure with APKTool

Installation options

Extracting APK contents

Extracting intelligence from resources

Decompiling to Java Source Code with jadx-gui for Manual Code Analysis

Installation and setup

Loading and navigating your target

Hunting for hardcoded secrets and credentials

Analysing custom authentication and authorisation logic

Client-side authentication checks

Weak token validation

Role-based access control flaws

Identifying insecure data storage vulnerabilities

Finding intent handling vulnerabilities

Detecting WebView misconfigurations and JavaScript interface exploits

Exporting decompiled source for reference

Automated security scanning with MobSF for OWASP mobile coverage

Installation with Docker

Running static analysis

Understanding MobSF’s detection capabilities

Performing dynamic analysis with MobSF

Understanding MobSF’s Limitations

Targeted vulnerability intelligence with the MARA framework

Installation and setup

Extracting the complete API attack surface

Firebase security assessment

Cloud credentials and storage bucket discovery

Advanced reconnaissance: runtime analysis and version intelligence

Runtime component testing with Drozer

Identifying the attack surface:

Testing exported activities:

Exploiting content providers:

Finding broadcast injection vulnerabilities:

Version comparison for security regression analysis

Mitigating Android app vulnerabilities: security best practices for developers

From reconnaissance to exploitation: your next steps

Conclusion: reconnaissance builds the foundation for successful Android bug hunting