Android Mobile Application for OSINT

Intercept and find hidden API for custom your OSINT tool

Requirement skills

Basic programming
Basic HTTP request
Basic Websocket request
Basic DBMS and NOSQL
Basic IT Security like API
Basic reverse engineering
Basic signal request (condition)

Android apps protection

Security protections in Android applications consist of mechanisms designed to safeguard apps against unauthorized analysis, tampering, data theft, and runtime manipulation. Because Android applications run on user-controlled devices, where the operating system environment cannot be fully trusted, developers must implement multiple defensive layers to preserve application integrity, protect sensitive logic, and secure communications.

Below are several common protection mechanisms used in modern Android applications.

1. Root Detection

Root detection is a technique used to determine whether a device has been modified to grant privileged (root-level) access. A rooted device allows deep system control, which can enable attackers to inspect application memory, modify internal files, bypass security restrictions, and run advanced analysis tools.

Applications typically perform checks such as searching for the presence of “su” binaries, examining system partition states, identifying known root management applications, and detecting abnormal system configurations. In addition to local checks, many applications rely on remote attestation services such as the Google Play Integrity API to assess whether the device environment can be considered trustworthy. If root access is detected, applications may restrict functionality, block execution, or increase monitoring.

2. Frida Detection

Frida is a dynamic instrumentation framework widely used for analyzing and modifying application behavior at runtime. It allows an attacker or researcher to hook into internal functions, alter parameters, or bypass security mechanisms such as SSL pinning without modifying the application package itself.

To mitigate this risk, many applications implement anti-instrumentation defenses. These may include scanning for suspicious processes, detecting unauthorized dynamic libraries, monitoring known communication ports, and searching memory for artifacts associated with code injection. When Frida-related activity is detected, the application may terminate, disable sensitive features, or report the incident to a backend system.

3. SSL Pinning

SSL pinning is a network security mechanism designed to prevent man-in-the-middle (MITM) attacks. In standard HTTPS communication, the system verifies that the server’s certificate is signed by a trusted certificate authority. However, this model can be undermined if a malicious certificate authority is installed on the device.

With SSL pinning, the application embeds a known, trusted certificate or public key reference within its code. During a secure connection, the certificate presented by the server is compared against this embedded reference. If the values do not match, the connection is immediately rejected. This ensures that the application only communicates with legitimate backend servers, even in untrusted network environments.

4. Emulator Detection

Emulator detection aims to identify whether the application is running inside a virtualized environment. Emulators are commonly used in security research and reverse engineering because they provide flexible control over the runtime environment.

Detection methods often involve checking device characteristics such as model identifiers, manufacturer values, sensor availability, and system configuration patterns typically associated with emulators. If emulator execution is detected, the application may limit functionality or alter behavior to reduce the risk of analysis.

5. Debugger Detection

Debugger detection is used to determine whether the application is being analyzed through debugging tools. Debugging allows an external party to step through code execution, inspect variables, and manipulate program flow.

Applications can detect debuggers by checking system flags, using platform APIs that reveal debugger attachment, or identifying execution timing anomalies that suggest runtime intervention. When a debugger is detected, the application may shut down or restrict access to sensitive features.

6. Code Obfuscation

Code obfuscation is a technique used to make application code more difficult to understand after decompilation. Tools such as ProGuard and R8 are commonly used to rename classes and methods into meaningless identifiers, remove unused code, and complicate control flow.

Although obfuscation does not make reverse engineering impossible, it significantly increases the time and effort required to analyze the application’s internal structure and logic.

7. Integrity and Tamper Detection

Integrity and tamper detection mechanisms ensure that the application has not been modified. Techniques include verifying the application’s digital signature at runtime, calculating cryptographic hashes of code sections, and validating the integrity of native libraries.

If discrepancies from the original build are detected, the application may assume it has been repackaged or altered and can respond by terminating execution or restricting functionality.

Conclusion

Android application security relies on a layered defense strategy that addresses communication security, runtime environment trust, resistance to dynamic instrumentation, and protection against static reverse engineering. While no single mechanism is sufficient on its own, the combination of these protections significantly raises the difficulty of analyzing, modifying, or exploiting an application without authorization.

Tools

Frida
Python
Ghidra
Jadx
adb
Lambda firerpa
Burpsuite
Php
Js
C & C++
Emulator android
Code editor
HTTP Toolkit
GDB
APK leaks (Dwi Siswanto)
Wireles ADB

You can check at main repo for red team OSINT

Device or hardware requirement

Android device (rooted)
IOS device (jailbreak)
Cable
Laptop (Windows and Linux)
Flipper zero (condition)
IoT Board (condition)

Study Case

Please take a note : This is just the basics and a start for common Android checks. More advanced versions will be posted later. This point is just an introduction for now.

Bypass root

You can install on rooted android device for support the module and package module manager. Please take a note: (check your kernel) and android version and device name for check support you rooted kernel on your devices

Device name list

Kernel list

Guide : https://github.com/awesome-android-root/awesome-android-root/blob/main/docs/rooting-guides/kernelsu-guide.md and https://awesome-android-root.org/rooting-guides/lsposed-guide

Module package manager

Module and script add on

Any more. It depends on your application case in the field and what is needed, but in this session, this is all that is needed. You can search for it in my main repository, OSINT cheat sheet, red team and pentest section.

Bypass SSL pin

Install and enable LAMDA

Why do I use Lambda? Because Frida sometimes has errors and many issues, such as the latest Frida and other things. Sometimes it is also unstable in certain Android versions and kernels, causing your device to frequently restart or other problems.

After that access your IP android device and with port 65000

Installing burp cert

Open your burpsuite then access your ip address with the listen proxy example 8080

Download the cert and import on CA certificate

After that downloand and install mobile app fot test on this case im use

Release Update MSTG-Android-Java.apk · OWASP/MASTG-Hacking-PlaygroundGitHub

After that connect your device with usb or adb wireles

Nice. After install. Check the package name application using this command

frida-ps -Uai

Reverse engineering time (basic)

Open the jadx and analysis

Code snipet

CertificateFactory.getInstance("X.509");
InputStream certInputStream =
    getResources().openRawResource(R.raw.certificate);

Certificate ca = certificateFactory.generateCertificate(certInputStream);

KeyStore keyStore = KeyStore.getInstance(KeyStore.getDefaultType());
keyStore.load(null, null);
keyStore.setCertificateEntry("ca", ca);

TrustManagerFactory tmf =
    TrustManagerFactory.getInstance(TrustManagerFactory.getDefaultAlgorithm());
tmf.init(keyStore);

SSLContext sslContext = SSLContext.getInstance("TLS");
sslContext.init(null, tmf.getTrustManagers(), null);

SSL_PINING 

package sg.vp.owasp_mobile.OMTG_Android;

import android.os.Bundle;
import androidx.appcompat.app.AppCompatActivity;
import androidx.appcompat.widget.Toolbar;
import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.net.URL;
import javax.net.ssl.HttpsURLConnection;
import sg.vp.owasp_mobile.omtg_android.C0004R;

/* loaded from: classes.dex */
public class OMTG_NETW_004_SSL_Pinning extends AppCompatActivity {
    @Override // androidx.appcompat.app.AppCompatActivity, androidx.fragment.app.FragmentActivity, androidx.core.app.ComponentActivity, android.app.Activity
    protected void onCreate(Bundle bundle) {
        super.onCreate(bundle);
        setContentView(C0004R.layout.activity_omtg__netw_004__ssl__pinning);
        setSupportActionBar((Toolbar) findViewById(C0004R.id.toolbar));
        new Thread(new Runnable() { // from class: sg.vp.owasp_mobile.OMTG_Android.OMTG_NETW_004_SSL_Pinning.1
            @Override // java.lang.Runnable
            public void run() throws IOException {
                try {
                    new SSLPinning().onCreate();
                    BufferedReader bufferedReader = new BufferedReader(new InputStreamReader(((HttpsURLConnection) new URL("https://www.example.com").openConnection()).getInputStream()));
                    while (true) {
                        String line = bufferedReader.readLine();
                        if (line != null) {
                            System.out.println(line);
                        } else {
                            bufferedReader.close();
                            return;
                        }
                    }
                } catch (Exception e) {
                    e.printStackTrace();
                }
            }
        }).start();
    }
}

SSL_PINING_CERTIFICATE 

package sg.vp.owasp_mobile.OMTG_Android;

import android.os.Bundle;
import androidx.appcompat.app.AppCompatActivity;
import androidx.appcompat.widget.Toolbar;
import java.io.BufferedInputStream;
import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStream;
import java.io.InputStreamReader;
import java.net.MalformedURLException;
import java.net.URL;
import java.security.KeyManagementException;
import java.security.KeyStore;
import java.security.KeyStoreException;
import java.security.NoSuchAlgorithmException;
import java.security.cert.Certificate;
import java.security.cert.CertificateException;
import java.security.cert.CertificateFactory;
import java.util.Enumeration;
import javax.net.ssl.HttpsURLConnection;
import javax.net.ssl.SSLContext;
import javax.net.ssl.TrustManagerFactory;
import sg.vp.owasp_mobile.omtg_android.C0004R;

/* loaded from: classes.dex */
public class OMTG_NETW_004_SSL_Pinning_Certificate extends AppCompatActivity {
    @Override // androidx.appcompat.app.AppCompatActivity, androidx.fragment.app.FragmentActivity, androidx.core.app.ComponentActivity, android.app.Activity
    protected void onCreate(Bundle bundle) {
        super.onCreate(bundle);
        setContentView(C0004R.layout.activity_omtg__netw_004__ssl__pinning__certificate);
        setSupportActionBar((Toolbar) findViewById(C0004R.id.toolbar));
        try {
            HTTPSssLPinning();
        } catch (MalformedURLException e) {
            e.printStackTrace();
        } catch (IOException e2) {
            e2.printStackTrace();
        } catch (KeyManagementException e3) {
            e3.printStackTrace();
        } catch (KeyStoreException e4) {
            e4.printStackTrace();
        } catch (NoSuchAlgorithmException e5) {
            e5.printStackTrace();
        } catch (CertificateException e6) {
            e6.printStackTrace();
        }
    }

    private void HTTPSssLPinning() throws NoSuchAlgorithmException, IOException, CertificateException, KeyStoreException, KeyManagementException {
        CertificateFactory certificateFactory = CertificateFactory.getInstance("X.509");
        BufferedInputStream bufferedInputStream = new BufferedInputStream(getResources().openRawResource(C0004R.raw.certificate));
        Certificate certificateGenerateCertificate = certificateFactory.generateCertificate(bufferedInputStream);
        bufferedInputStream.close();
        KeyStore keyStore = KeyStore.getInstance(KeyStore.getDefaultType());
        keyStore.load(null, null);
        keyStore.setCertificateEntry("ca", certificateGenerateCertificate);
        Enumeration<String> enumerationAliases = keyStore.aliases();
        while (enumerationAliases.hasMoreElements()) {
            System.out.println("KeyStore: " + enumerationAliases.nextElement().toString());
        }
        TrustManagerFactory trustManagerFactory = TrustManagerFactory.getInstance(TrustManagerFactory.getDefaultAlgorithm());
        trustManagerFactory.init(keyStore);
        final SSLContext sSLContext = SSLContext.getInstance("TLS");
        sSLContext.init(null, trustManagerFactory.getTrustManagers(), null);
        new Thread(new Runnable() { // from class: sg.vp.owasp_mobile.OMTG_Android.OMTG_NETW_004_SSL_Pinning_Certificate.1
            @Override // java.lang.Runnable
            public void run() throws IOException {
                URL url;
                try {
                    try {
                        url = new URL("https://example.com");
                    } catch (MalformedURLException e) {
                        e.printStackTrace();
                        url = null;
                    }
                    HttpsURLConnection httpsURLConnection = (HttpsURLConnection) url.openConnection();
                    httpsURLConnection.setSSLSocketFactory(sSLContext.getSocketFactory());
                    InputStream inputStream = httpsURLConnection.getInputStream();
                    BufferedReader bufferedReader = new BufferedReader(new InputStreamReader(inputStream));
                    while (true) {
                        String line = bufferedReader.readLine();
                        if (line != null) {
                            System.out.println(line);
                        } else {
                            inputStream.close();
                            return;
                        }
                    }
                } catch (IOException e2) {
                    e2.printStackTrace();
                }
            }
        }).start();
    }
}

SSLPinnig

package sg.vp.owasp_mobile.OMTG_Android;

import java.security.KeyManagementException;
import java.security.KeyStoreException;
import java.security.NoSuchAlgorithmException;
import javax.net.ssl.HttpsURLConnection;
import javax.net.ssl.SSLContext;
import javax.net.ssl.TrustManager;

/* loaded from: classes.dex */
public class SSLPinning {
    public void onCreate() throws NoSuchAlgorithmException, KeyManagementException {
        try {
            SSLContext sSLContext = SSLContext.getInstance("TLS");
            sSLContext.init(null, new TrustManager[]{new HardenedX509TrustManager(null)}, null);
            HttpsURLConnection.setDefaultSSLSocketFactory(sSLContext.getSocketFactory());
        } catch (KeyManagementException unused) {
            System.exit(-1);
        } catch (KeyStoreException unused2) {
            System.exit(-1);
        } catch (NoSuchAlgorithmException unused3) {
            System.exit(-1);
        }
    }
}

new SSLPinning().onCreate();

The code at clsas SSLPinning()

SSLContext sSLContext = SSLContext.getInstance("TLS");
sSLContext.init(
  null,
  new TrustManager[]{ new HardenedX509TrustManager(null) },
  null
);
HttpsURLConnection.setDefaultSSLSocketFactory(
  sSLContext.getSocketFactory()
);

In this scenario, the application uses a custom trust manager named HardenedX509TrustManager and applies it globally through setDefaultSSLSocketFactory. This means all HTTPS connections made by the app are intended to use this custom certificate validation logic, enforcing SSL pinning across the entire application.

At first glance, this appears to be a strong design. By centralizing certificate validation and ensuring all network connections rely on the same pinned trust configuration, the developer reduces the risk of accidental fallback to the system’s default trust store. However, the core limitation remains the same: the enforcement still happens inside the application process at runtime.

Even though the trust manager is labeled “hardened,” it is still a Java object living inside the app’s memory space on Android. Any logic executed at this layer can potentially be observed, modified, or replaced using dynamic instrumentation tools such as Frida.

One common bypass point is the SSLContext.init() method. This is where the application supplies its TrustManager instances to the SSL stack. If an attacker hooks this method at runtime, they can replace the provided trust managers with a custom implementation that accepts all certificates without validation. In this case, the hardened trust manager is never actually used, even though the application code appears to configure it correctly.

Another direct bypass target is the checkServerTrusted() method inside HardenedX509TrustManager itself. This method is responsible for validating the server’s certificate chain during the TLS handshake. If an attacker hooks or overrides this method so that it performs no checks (or always returns successfully), then SSL pinning is effectively disabled. The TLS connection will proceed regardless of which certificate the server presents.

The fundamental issue is that SSL pinning logic, no matter how strict, is still client-side enforcement. If an attacker gains the ability to modify the client’s runtime behavior, they can neutralize the verification process without changing the app’s static code or bundled certificate. Global configuration does not prevent this, because the attacker is not bypassing configuration—they are altering execution.

In summary, this design can be bypassed because the trust decision ultimately depends on code that runs inside a controllable environment. Without additional protections such as anti-hooking mechanisms, runtime integrity checks, or moving critical validation into harder-to-instrument native layers, even a globally enforced custom trust manager remains vulnerable to runtime manipulation.

// OMTG_NETW_004_SSL_Pinning_Certificate (Certificate pinni

CertificateFactory.getInstance("X.509");
getResources().openRawResource(R.raw.certificate);
keyStore.setCertificateEntry("ca", cert);
TrustManagerFactory.init(keyStore);
SSLContext.init(null, trustManagers, null);

Application will trust with the cert "res/raw/certificate" then hook the function SSLContext.init()

The provided code shows that the Android application implements SSL pinning by loading a specific certificate bundled inside the app. This certificate is stored in the res/raw directory and loaded using a CertificateFactory. It is then placed into a new, empty KeyStore, which is used to initialize a TrustManagerFactory. The resulting trust managers are finally assigned to an SSLContext for HTTPS connections.

This design means the application does not trust the system’s default Certificate Authorities (CAs). Instead, it only trusts the certificate embedded within the app. As a result, interception certificates such as those from debugging proxies cannot be used to decrypt traffic through a standard man-in-the-middle attack. From a network perspective, this is a correct and common SSL pinning approach.

However, the strength of SSL pinning does not depend only on certificate validation. It also depends on how well the validation logic is protected at runtime.

Key Weakness: Validation Happens in the App Layer

All certificate verification logic in this implementation runs inside the application process on Android. This means the trust decision is made by code that is still under the control of the running app environment. If an attacker can instrument or modify the app while it is running, they can interfere with this logic.

In other words, the app restricts which certificates are trusted, but it does not protect the verification mechanism itself from runtime manipulation.

Why It Can Be Bypassed

Dynamic instrumentation tools such as Frida allow an attacker to inject code into a running application. Instead of removing the pinned certificate, the attacker can target the component responsible for checking it.

The most common targets are:

The SSLContext.init() method, where trust managers are assigned
The X509TrustManager implementation, which performs server certificate validation

If the original trust manager is replaced with a custom one that accepts all certificates without verification, SSL pinning becomes ineffective. The app still believes pinning is active, but the actual certificate checks are no longer enforced.

So, the vulnerability is not in the certificate itself, but in the fact that the trust manager can be replaced at runtime.

Core Security Issue

The main issue can be summarized as follows:

SSL pinning is implemented at a layer that can still be modified through runtime instrumentation.

Without additional protections such as anti-hooking defenses, runtime integrity checks, or moving critical verification logic into protected native code, SSL pinning alone only protects against network-level attacks. It does not protect against client-side manipulation.

You can hook the function and make a frida script. If you dont know how to make a frida script you can ask GPT for help make your own script to hook the function

frida scirpt

Java.perform(function () {

    console.log("[+] SSL PINNING BYPASS (ALL CASES) LOADED");

    /*********************************
     * TRUST MANAGER PALSU
     *********************************/
    var X509TrustManager = Java.use("javax.net.ssl.X509TrustManager");

    var FakeTrustManager = Java.registerClass({
        name: "dev.rootbalance.FakeTrustManager",
        implements: [X509TrustManager],
        methods: {
            checkClientTrusted: function (chain, authType) {},
            checkServerTrusted: function (chain, authType) {},
            getAcceptedIssuers: function () {
                return [];
            }
        }
    });

    /*********************************
     * HOOK SSLContext.init()
     *********************************/
    var SSLContext = Java.use("javax.net.ssl.SSLContext");

    SSLContext.init.overload(
        "[Ljavax.net.ssl.KeyManager;",
        "[Ljavax.net.ssl.TrustManager;",
        "java.security.SecureRandom"
    ).implementation = function (km, tm, sr) {

        console.log("[+] SSLContext.init() intercepted → bypassing pinning");
        this.init(km, [FakeTrustManager.$new()], sr);
    };

    /*********************************
     * LOG HTTPS TARGET
     *********************************/
    var HttpsURLConnection = Java.use("javax.net.ssl.HttpsURLConnection");

    HttpsURLConnection.connect.implementation = function () {
        try {
            console.log("[CONNECT] " + this.getURL().toString());
        } catch (e) {}
        return this.connect();
    };

    HttpsURLConnection.setRequestMethod.implementation = function (method) {
        console.log("[METHOD] " + method);
        return this.setRequestMethod(method);
    };

    /*********************************
     * LOG URL OBJECT
     *********************************/
    var URL = Java.use("java.net.URL");

    URL.$init.overload("java.lang.String").implementation = function (url) {
        console.log("[URL] " + url);
        return this.$init(url);
    };

});

This script runs inside the Android app at runtime using Frida. Instead of attacking the server or changing the app’s certificate files, it changes how the app checks certificates while the app is running.

The key idea is simple: SSL pinning depends on a TrustManager that verifies the server certificate. This script replaces that TrustManager with a fake one that trusts everything.

1. Creating a Fake Trust Manager

The script creates a new class that implements X509TrustManager, which is the component responsible for checking server certificates during an HTTPS connection.

In this fake version:

checkServerTrusted() does nothing
checkClientTrusted() does nothing
getAcceptedIssuers() returns an empty list

Because no checks are performed, every certificate is accepted, even if it does not match the pinned certificate inside the app.

2. Hooking SSLContext.init()

This is the most important part.

Normally, when an app sets up HTTPS, it calls SSLContext.init() and provides its own TrustManager that performs SSL pinning. That is where the certificate validation logic is attached to the TLS system.

The script intercepts this method call and replaces the real TrustManager with the fake one. So even though the app thinks it is using its secure pinning logic, it is actually using the attacker’s TrustManager that trusts all certificates.

As a result:

The original pinning logic is never used
Any HTTPS certificate becomes valid
Traffic can be intercepted by a proxy without errors

3. Logging Network Activity

The script also hooks HttpsURLConnection and java.net.URL to print:

The URLs the app connects to
The HTTP methods being used

This does not help with the bypass itself, but it allows the attacker to see what network requests the app is making after pinning is disabled.

Core Reason the Bypass Works

SSL pinning in many apps is implemented in Java code inside the Android app process. Even if the certificate is pinned correctly, the verification still depends on code running on the device.

If an attacker can modify that code at runtime, they can control the result of the certificate check.

This script does exactly that by replacing the TrustManager with one that never rejects a certificate. Because of this, SSL pinning is effectively turned off without changing the app itself.

Other frida script

Frida CodeSharecodeshare.frida.re

Run the script

Script python get tokenn lambda

Lambda doc : https://device-farm.com/doc/en/installing-client.html

from lamda.client import Device

ip = input("Input your device IP: ").strip()

d = Device(ip)
print(d._get_session_token())

frida -H <IP:65000> -f <package.name.app> -l <script.js> --token <lambda token>

Intercept with burpsuite

Config the IP proxy (wifi)

Burpsuite proxy settings

Check the proxy at HTTP history

Checklist OWASP MASTG :

https://mas.owasp.org/MASTG/techniques/#unused

Why OSINT need check the mobile application?

In my experience working in IT security and OSINT, I believe this is important and can be utilized, especially in cases where you want to create tools and there are fraudulent activities for forensic purposes or threat actors who use applications such as scams, phishing, and others.

I have handled several cases, particularly within mobile apps, where there was limited information available about the target—for example, only a domain name was present without any further details. However, there were traces left behind, such as applications like desktop apps, mobile apps, or web apps. You can check these for further clues, such as identifying vulnerabilities in the application and gathering information about the threat actor, including API keys, API endpoints (REST APIs), or other strings.

This can help you with advanced information searches, such as how malware works, C2 servers, API endpoints, vulnerability findings, API keys, other strings, file hashes, and libraries used. There are many cases such as pirated applications, counterfeit applications, fraudulent applications, and malware applications. If you feel that you cannot find any information other than the name or username but only leave the application, you can check it further.

PreviousSample soon NextIOS Mobile Application for OSINT

Last updated 9 days ago

hashtagRequirement skills

hashtagAndroid apps protection

hashtag1. Root Detection

hashtag2. Frida Detection

hashtag3. SSL Pinning

hashtag4. Emulator Detection

hashtag5. Debugger Detection

hashtag6. Code Obfuscation

hashtag7. Integrity and Tamper Detection

hashtagConclusion

hashtagTools

hashtagStudy Case

hashtagChecklist OWASP MASTG :

hashtagWhy OSINT need check the mobile application?