> For the complete documentation index, see [llms.txt](https://jieyab89-osint.gitbook.io/jieyab89-osint-cheat-sheet-wiki-tips/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://jieyab89-osint.gitbook.io/jieyab89-osint-cheat-sheet-wiki-tips/scripting-for-osint/android-mobile-application-for-osint.md).
# Android Mobile Application for OSINT
## Requirement skills
1. Basic programming
2. Basic HTTP request
3. Basic websocket request
4. Basic DBMS and NOSQL
5. Basic IT security like API
6. Basic reverse engineering
7. 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
1. Frida
2. Python
3. Ghidra
4. Jadx
5. adb
6. Lambda firerpa
7. Burpsuite
8. Php
9. Js
10. C & C++
11. Emulator android
12. Code editor
13. HTTP Toolkit
14. GDB
15. APK leaks (Dwi Siswanto)
16. Wireles ADB
You can check at main repo for red team OSINT
Device or hardware requirement
1. Android device (rooted)
2. IOS device (jailbreak)
3. Cable
4. Laptop (Windows and Linux)
5. Flipper zero (condition)
6. 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
1.
2.
Guide : and
Module package manager
1.
2.
3.
4.
Module and script add on (this is for bypass root and ssl pin and others)
1.
2.
3.
4.
5.
6.
7.
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
**Troubleshoot lambda firerpa**
If you have a trouble with lambda such as get token or other issue. You can following the step:
1. Try restart your device
2. If restart device didnt work. Try uninstall and install again
3. Check your device version make sure your device is support lambda
4. Try the reinstall the python package with this command
```
pip3 install -U --force-reinstall 'lamda[full]'
```
5. Check the official doc ""
**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
{% embed url="" %}
After that connect your device with usb or adb wireles
Nice. After install. Check the package name application using this command
```bash
frida-ps -Uai
```
Reverse engineering time (basic)
Open the jadx and analysis
Code snipet
```java
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);
```
```java
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 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);
}
}
}
```
```java
new SSLPinning().onCreate();
```
The code at clsas SSLPinning()
```java
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.
```java
// 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
```javascript
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
{% embed url="" %}
Run the script
Script python get tokenn lambda
Lambda doc :
```python
from lamda.client import Device
ip = input("Input your device IP: ").strip()
d = Device(ip)
print(d._get_session_token())
```
Intercept with burpsuite
Config the IP proxy (wifi)
Burpsuite proxy settings
Check the proxy at HTTP history
## Checklist OWASP MASTG :
## 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.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://jieyab89-osint.gitbook.io/jieyab89-osint-cheat-sheet-wiki-tips/scripting-for-osint/android-mobile-application-for-osint.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.