Common Security Flaws in Android Applications: A Reverse Engineering Analysis

The android-reverse-engineering skill identifies seven critical security vulnerabilities—including hard-coded API keys, clear-text HTTP endpoints, and missing certificate pinning—by decompiling APK files and analyzing Retrofit interfaces, OkHttp configurations, and WebView JavaScript bridges.

The SimoneAvogadro/android-reverse-engineering-skill repository provides a structured framework for analyzing Android application binaries to surface common security flaws in Android applications. By automating decompilation and pattern matching against extracted source code, this skill enables security researchers to rapidly identify embedded secrets, insecure network configurations, and authentication weaknesses that static analysis tools often miss.

Hard-Coded Secrets and API Keys

Embedding credentials directly into application binaries represents one of the most prevalent common security flaws in Android applications. When developers include API keys, authentication tokens, or client secrets as string literals, these values survive compilation and remain accessible to anyone who decompiles the APK.

How the Skill Detects Embedded Credentials

The api-extraction-patterns.md reference file documents specific grep patterns designed to locate hard-coded secrets. Lines 86-88 define a comprehensive regex that matches common secret identifiers:

grep -rni 'api[_-]\?key\|api[_-]\?secret\|auth[_-]\?token\|bearer\|access[_-]\?token\|client[_-]\?secret' sources/

This pattern catches variations like api_key, api-key, authToken, and clientSecret regardless of obfuscation, since string literals remain readable even when class names are scrambled.

Insecure Network Transport

Clear-Text HTTP Vulnerabilities

Transmitting sensitive data over unencrypted HTTP channels exposes user credentials and application data to network eavesdropping. The skill specifically targets this vulnerability by extracting all URL literals from decompiled sources and flagging those using insecure protocols.

According to api-extraction-patterns.md lines 82-85, the following command identifies clear-text HTTP endpoints:

grep -rn '"http://[^"]*"' sources/

This pattern matches any string literal beginning with http://, immediately surfacing endpoints that should have been migrated to HTTPS.

Missing Certificate Pinning

Without certificate pinning, Android applications remain vulnerable to Man-in-the-Middle (MITM) attacks where attackers substitute valid TLS certificates with compromised ones. The skill analyzes OkHttp builder configurations to determine whether pinning is implemented.

The api-extraction-patterns.md reference (lines 44-48) documents the grep pattern for CertificatePinner:

grep -rn 'CertificatePinner' sources/

When this search returns no results while OkHttp usage is detected, analysts can conclude the application lacks certificate pinning—a critical security gap.

Insecure Authentication Flows

Poorly implemented authentication mechanisms represent severe common security flaws in Android applications. The call-flow-analysis.md guide demonstrates how to trace authentication flows from UI components through to network requests, revealing where tokens are generated, stored, or transmitted insecurely.

Lines 55-66 of call-flow-analysis.md outline the methodology for tracing a login endpoint:

# 1. Find the login string

grep -rni '"auth/login"' sources/

# 2. Locate the Retrofit interface

grep -rn '@POST("auth/login")' sources/

# 3. Follow usage to repository, ViewModel, and Activity

grep -rn 'c.a.b.d' sources/

This tracing exposes whether tokens are stored in plaintext SharedPreferences, transmitted in custom headers without encryption, or exposed to logging mechanisms.

WebView JavaScript Interface Exposure

Applications utilizing WebView components with @JavascriptInterface annotations create potential attack vectors where malicious JavaScript can invoke native Android methods. The skill identifies these exposure points through specific extraction patterns.

According to api-extraction-patterns.md lines 72-76, the following patterns detect WebView vulnerabilities:

grep -rn 'addJavascriptInterface' sources/
grep -rn 'loadUrl' sources/

These commands surface bridge configurations that may allow unauthorized access to device functionality or data leakage through JavaScript execution.

Obfuscation Limitations and String Exposure

Many developers mistakenly believe that ProGuard or R8 obfuscation protects their application logic. However, string literals are never obfuscated by standard Android build tools, leaving URLs, API keys, and error messages fully readable in the compiled binary.

The call-flow-analysis.md reference emphasizes this critical point in lines 36-41:

Even when class and method names are obfuscated to meaningless labels like a.b.c, the string literals remain unchanged. This makes them the primary entry point for reverse engineering efforts.

Attackers can therefore grep for specific error messages, URL patterns, or JSON keys to rapidly locate sensitive logic within obfuscated applications.

Automated Detection Scripts

The repository provides the find-api-calls.sh script to automate the detection of these common security flaws in Android applications. This script executes the documented grep patterns against decompiled sources, generating reports on Retrofit interfaces, OkHttp configurations, and embedded secrets.

To run a comprehensive security analysis including authentication patterns:

bash plugins/android-reverse-engineering/skills/android-reverse-engineering/scripts/find-api-calls.sh \
    output/sources/ --auth

The script leverages the patterns defined in api-extraction-patterns.md to surface HTTP endpoints, certificate configurations, and potential hard-coded credentials.

Summary

The android-reverse-engineering-skill targets the most prevalent common security flaws in Android applications through systematic binary analysis:

• Hard-coded credentials exposed via string literals that survive obfuscation
• Clear-text HTTP transport identified through URL extraction patterns
• Missing certificate pinning detected by analyzing OkHttp builder configurations
• Insecure authentication flows traced from UI components to network layers
• WebView JavaScript injection vectors surfaced through interface analysis
• Obfuscation gaps exploited via unprotected string literals

By combining automated decompilation with targeted grep patterns documented in api-extraction-patterns.md and call-flow-analysis.md, the skill provides a repeatable methodology for identifying security weaknesses that static analysis tools frequently overlook.

Frequently Asked Questions

How does the skill detect hard-coded API keys in obfuscated applications?

The skill relies on the fact that string literals are never obfuscated by ProGuard or R8. According to call-flow-analysis.md lines 36-41, even when class names are scrambled to meaningless labels like a.b.c, strings remain unchanged. The api-extraction-patterns.md file provides regex patterns at lines 86-88 that search for identifiers like api_key, auth_token, and client_secret within these exposed string literals.

Can the skill identify if an app uses certificate pinning to prevent MITM attacks?

Yes. The skill analyzes OkHttp configurations to detect the presence or absence of CertificatePinner. As documented in api-extraction-patterns.md lines 44-48, the skill uses grep -rn 'CertificatePinner' sources/ to locate pinning implementations. If OkHttp is present but this search returns no results, the application likely lacks certificate pinning and remains vulnerable to Man-in-the-Middle attacks.

What is the difference between clear-text HTTP detection and secret extraction?

Clear-text HTTP detection focuses on transport security, while secret extraction targets credential storage. The skill identifies clear-text HTTP by searching for URL literals starting with http:// using the pattern grep -rn '"http://[^"]*"' sources/ (as shown in api-extraction-patterns.md lines 82-85). Secret extraction uses broader regex patterns to find API keys and tokens embedded in the code (lines 86-88). Both represent distinct attack vectors: network eavesdropping versus binary reverse engineering.

How does the skill trace insecure authentication flows?

The skill implements call-flow analysis to track authentication from user interface to network layer. According to call-flow-analysis.md lines 55-66, analysts first locate login endpoint strings (e.g., "auth/login"), then find the corresponding Retrofit interface methods, and finally trace usage through repository classes, ViewModels, and Activities. This exposes whether tokens are stored in plaintext, transmitted in custom headers, or logged insecurely during the authentication process.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}