There are a lot of rumours these days about data leaks and misuse of user data, and it can feel overwhelming with the number of apps we use every day, especially in countries like China.
The challenge is to balance the usefulness of an app with its security and privacy. More importantly, who do you trust to determine if an app is safe? Is it user reviews, certifications, or perhaps a statement from a well-known blogger?
airabbit.blog
Maybe it's a mixture of everything - or nothing at all. I prefer to check things myself. This tutorial shows you how to inspect the network traffic of any application (in this case, an Android app available as an APK file) and use AI to see how chatty an app I want to use really is.
For simplicity, we’ll use a sample app called Deepleak. You can follow the same steps with any available APK, including one from a popular AI company that has recently made headlines.
Disclaimer
The data presented in this post is for demonstration and sample purposes only. None of the data shown represents actual user information. Users replicating these experiments must ensure they comply with all applicable laws, regulations, vendor policies, and terms of service. This guide is intended solely for educational purposes and does not constitute legal advice.
In this tutorial, we will use the Android Studio emulator and HTTP Toolkit (with the Frida Server interception experiment).
What is HTTP Toolkit?
HTTP Toolkit is an open-source tool for intercepting, debugging, and mocking HTTP(S) traffic. It allows you to capture and inspect web requests between your browser/apps and the internet, modify them in real-time, and set up mock responses for testing. It’s a favorite among developers and security testers.
Let’s go.
1. Prepare Android Studio
Install Android Studio.
Add an Emulator:
Follow the instructions shown below to add an emulator. Make sure to select the proper options as depicted.
Make sure you choose an image without the "Google Play" prefix, like the one below.
It does not matter if you install it on a table or a phone, what really matters is the system image.
You can remove the emulator later by opening Tools > SDK Manager and unchecking the corresponding installed packages.
Add the APK Package You Want to Inspect:
Import the APK into Android Studio.
Start the APK on the Target Emulator:
2. Configure HTTP Toolkit
Install HTTP Toolkit:
Download and install HTTP Toolkit from here.Create a New Interception Using Frida:
Follow the steps below to set up a new interception.
What is Frida?
Frida is a dynamic instrumentation toolkit that lets you inject code into running programs to examine their internal workings. It’s like having an X-ray view into software—you can observe and modify function calls in real-time. Security researchers use it to find bugs, reverse engineers use it to understand apps, and pentesters use it to bypass security during testing. Frida works by injecting JavaScript into target processes on major platforms (Windows, iOS, Android, etc.). It is popular for mobile app testing, key extraction, bypassing certificate pinning, and modifying app logic during legitimate security research.
- Select the Target Application: Choose the application you want to intercept. This can be any running app, including the one you just installed. For example, we will use the existing browser app—webview browser app.
-
Monitor the Traffic:
To see the traffic coming from the selected application, simply use the application or leave it running - many applications transmit data even when not being actively used.
In the Intercept tab, you should be able to see the traffic of the selected application.
Filter Specific Addresses:
You can filter the traffic by specific addresses at the bottom of the page.
Export the Traffic Trace:
Finally, you can export the entire trace to a plain text file (with a HAR or JSON extension).
Here is an example of a HAR file:
3. Analyze the Traffic with AI
At this stage, you can use AI to analyse the captured traffic for sensitive information or to determine what data is being transmitted. For example, use the following prompt
You are a security engineer who checks the logs of applications and notes what data is being transferred... here is the log, do an analysis. We have no control over the application, we do not say when sensitive data is exposed because we have intercepted the traffic so it is expected. We only care about security, not performance.
Below is a sample response for a popular app we have analyzed:
Below is a security‐focused summary of the data exchanged between the Deepleak mobile app (Deepleak/1.0.6 on Android) and its vendor’s server (chat.Deepleak.com). This report outlines the endpoints, the type of data sent and received, and highlights items of security interest (such as sensitive tokens and personally identifiable information).
---
### 1. `/api/v0/ip_to_country_code`
- **Method:** GET
- **Request Headers:**
- Client metadata (e.g. `x-client-platform`, `x-client-version`, `x-client-locale`)
- **Response:**
- **Data:** Contains the client’s IP address (e.g. `"xxx.xxx.xx.xxx"`) and country code (`"US"`).
- **Security Note:**
- Although no explicit user credentials are sent here, the disclosure of the client’s IP may aid in geolocation.
---
### 2. `/api/v0/check_client_update`
- **Method:** GET
- **Response:**
- **Data:** Returns minimal update information (with a null business data payload).
- **Security Note:**
- No sensitive information is exchanged in this call.
---
### 3. `/api/v0/users/current`
- **Method:** GET
- **Request Headers:**
- **Authorization:** A Bearer token is provided (e.g.
`Bearer XXkXXX`)
- **Response:**
- **Data:**
- **User Identifier:** e.g. `"xxxx"`
- **User Token:** (Matches the token sent in the header)
- **Email Address:** `"xxxx@xxx.com"`
- Additional fields such as mobile number, status, and chat-related flags.
- **Security Note:**
- This call transmits sensitive personally identifiable information (PII) and a long‑lived authorization token. If these tokens or the email were to be exposed or misused, they could compromise the user’s account.
---
### 4. `/api/v0/users/feature_quota`
- **Method:** GET
- **Response:**
- **Data:** Provides usage/feature quota details (e.g. a “thinking” quota with 10,000 units available and 0 used).
- **Security Note:**
- This is operational data; however, it is linked to the authenticated user.
---
### 5. `/api/v0/chat/create_pow_challenge`
- **Method:** POST
- **Request Payload:**
- JSON body with:
\`json
{"target\_path":"/api/v0/chat/completion"}
\`
- **Response:**
- **Data:** A cryptographic “challenge” object is returned, which includes:
- **Algorithm:** `"DeepleakHashV1"`
- **Challenge value:** (a long hexadecimal string)
- **Salt:** (short hex string)
- **Signature:** (hexadecimal signature)
- **Difficulty:** Numeric value (e.g. `144000`)
- **Expiration Info:** `expire_at` and `expire_after`
- **Target Path:** Confirms the intended API endpoint
- **Security Note:**
- These challenge parameters are part of a proof‑of‑work mechanism designed to verify the client’s legitimacy. The details are sensitive in that they could be misused if an attacker were to subvert the challenge–response process.
---
### 6. `/api/v0/chat_session/fetch_page`
- **Method:** GET
- **Response:**
- **Data:** A list of chat sessions is returned. Each session record includes:
- **Session IDs and Sequence Numbers**
- **Agent Information and Titles:** (e.g. user-provided titles like “who are you?”)
- **Timestamps:** `inserted_at` and `updated_at`
- **Security Note:**
- Chat session details could reveal user conversation history and behavior. Even if not inherently sensitive, such metadata can be personally identifying if combined with other information.
---
### 7. `/api/v0/chat_session/create`
- **Method:** POST
- **Request Payload:**
- JSON body:
\`json
{"agent":"chat"}
\`
- **Response:**
- **Data:** Returns the newly created session’s details, including:
- **Session ID:** e.g. `"xxxxxxxx"`
- Other metadata such as sequence ID and timestamps.
- **Security Note:**
- Session IDs are sensitive as they are used to identify and track the user’s chat sessions.
---
### 8. `/api/v0/chat/completion`
- **Method:** POST
- **Request Payload:**
- JSON body includes:
- **`chat_session_id`:** References a chat session (e.g. `"xxxx"`)
- **`parent_message_id`:** `null`
- **`prompt`:** e.g. `"who are you?\n"`
- **Flags:** such as `thinking_enabled`, `search_enabled`, `legacy_format`
- **Headers:**
- Includes a custom header (`x-ds-pow-response`) carrying the client’s proof‑of‑work response.
- **Response:**
- **Data:** Delivered as a text/event‑stream (chunked response) that progressively sends a chat reply. The eventual message content is a greeting from the AI assistant.
- **Security Note:**
- The prompt (user’s input) and the resulting conversation are transmitted to the vendor. These messages may contain sensitive user content. The use of the POW mechanism in a header further emphasizes the importance of protecting the integrity of the request.
---
### Additional Considerations
- **Cookies & Session Identifiers:**
- Several cookies (e.g. `HWWAFSESID`, `HWWAFSESTIME`, `ds_session_id`, and `__cf_bm`) are set during these interactions. These are marked as HttpOnly, Secure, and (where applicable) with `SameSite=None` or `strict`. They are used for session management and should be protected from unauthorized access.
- **Authorization Token Exposure:**
- The authorization token seen in the `/users/current` request is a critical piece of sensitive data. Its presence in the request and the corresponding user details in the response highlight the need for strict token protection.
- **Transport Security:**
- All data is exchanged over HTTPS. While TLS secures the data in transit, interception logs (as provided here) still reveal sensitive information that must be handled carefully on the vendor’s side.
---
### Conclusion
The Deepleak application sends various types of data to its vendor, including:
- **Client & Device Information:** via HTTP headers.
- **User Identification & Authentication Data:** such as user IDs, bearer tokens, and email addresses.
- **Session & Chat Data:** including chat session IDs, chat history metadata, and user prompts.
- **Proof‑of‑Work Challenge Parameters:** used to verify client requests to the chat completion endpoint.
- **Cookies & Session Management Data:** which maintain secure sessions.
From a security standpoint, although TLS protects data during transmission, the exposure of sensitive tokens, session identifiers, and personal data (like the user’s email) in intercepted logs emphasizes the need for strong server-side protection and secure storage practices. Any compromise of these elements could lead to session hijacking or unauthorized access to user data.
This report offers a high‑level summary of the sensitive data flows and security-relevant elements present in the communication between the app and its vendor server.
In this case, the app shared the IP address, the account email, and other expected data, so nothing unexpected was observed. However, this report is based on a short interception. For a more comprehensive analysis, you should monitor the app over a longer period—such as during startup and while running in the background.
Wrap-Up
With this approach, you can intercept any app on your Android device at any time (and even experiment with other interception methods) to better understand how secure a suspicious app really is, and make a decision based on real data rather than guesswork.
Top comments (0)