Multi-mode Bluetooth earphone privacy disclosure and security vulnerability detection method, device and equipment

Abstract

The invention provides a multi-mode Bluetooth earphone privacy disclosure and security vulnerability detection method, device and equipment, and relates to the technical field of communication. The method comprises the following steps: dynamically analyzing a matched application program of a target Bluetooth headset, extracting a rule of the application program for identifying and analyzing a Bluetooth low energy (BLE) broadcast message, and constructing a Bluetooth private protocol dictionary for controlling the headset; actively scanning a surrounding wireless communication environment, and capturing and analyzing a BLE broadcast message and classic Bluetooth equipment information from at least one target Bluetooth headset; and based on the extracted rule and the constructed private protocol dictionary, performing automatic analysis on the collected equipment information and communication data, and judging whether the at least one target Bluetooth earphone has a security vulnerability of a predefined type or not. According to the invention, the problem of rapid and systematic security assessment of batch Bluetooth devices can be solved.

Description

Technical Field

[0001] This invention relates to the field of communication technology, and in particular to a method, apparatus, and device for detecting privacy leaks and security vulnerabilities in multi-mode Bluetooth headsets. Background Technology

[0002] With the rapid development of intelligent and wireless consumer electronics, Bluetooth headsets have become an indispensable part of modern life. As an important component of the smart wearable ecosystem, the Bluetooth headset market continues to expand, with shipments in China reaching 113.53 million units in 2024, a year-on-year increase of 19.0%. However, along with widespread adoption, the potential security and privacy risks of Bluetooth headsets are becoming increasingly prominent. Currently, industry and academia's focus on Bluetooth security is mainly on common vulnerabilities at the protocol level, such as BrakTooth, while few studies systematically focus on the widespread systemic security flaws introduced by manufacturers during product implementation. These flaws are not isolated but form a complete attack chain from user privacy leaks to remote device control, seriously threatening users' digital security and personal privacy.

[0003] In recent years, the Bluetooth headset market has experienced sustained rapid growth, with shipments showing a significant year-on-year increase. This growth stems not only from the increasing popularity of the technology but also from technological innovation. Dual-Mode Bluetooth technology has become a crucial development direction. Dual-Mode headsets can simultaneously support both Bluetooth Classic (BR / EDR) and Bluetooth Low Energy (BLE) modes. This design allows the headset to achieve both high-bandwidth audio transmission (BR / EDR) and leverage the low-power characteristics of BLE for fast connection, device management, and data synchronization. However, this "one device, two modes" architecture also presents new challenges and complexities for security research.

[0004] The complexity of the Bluetooth protocol stack is a major reason for the frequent occurrence of vulnerabilities. Researchers have revealed security risks at different levels through various attack methods, and these risks are particularly prominent in dual-mode headsets.

[0005] Fuzzing is an effective method for discovering protocol stack vulnerabilities. Research has revealed serious security issues even in mainstream Bluetooth chips. For example, BrakTooth exploited malformed Link Manager Protocol (LMP) packets to launch denial-of-service (DoS) attacks against multiple mainstream Bluetooth chips, potentially even enabling remote code execution. L2Fuzz, specifically targeting the L2CAP layer, systematically discovered vulnerabilities at this layer through state-aware fuzzing.

[0006] Implementation flaws in the underlying firmware pose another major security risk. Tools like FirmXRay have successfully identified vulnerabilities in the Bluetooth link layer through static analysis of bare-metal firmware. These vulnerabilities are often related to specific vendor implementations. In dual-mode headsets, the firmware for the two modes may have cross-calling and shared code; a vulnerability in one mode may affect the other, even allowing attackers to escalate privileges or traverse information between different modes. Furthermore, analysis of pre-installed Android applications and related firmware has revealed security risks that can arise from improper use of the Bluetooth API.

[0007] BLE is widely used in the auxiliary functions of dual-mode headphones due to its low power consumption. However, its broadcast mechanism and the use of device identifiers also bring unique privacy issues.

[0008] Research indicates that attackers can exploit BLE's broadcast mechanism for device spoofing. The BlueDoor attack demonstrated how to steal sensitive information from devices by exploiting BLE vulnerabilities. Furthermore, during pairing, attackers can utilize man-in-the-middle attacks (MITMs) to intercept and tamper with device information, establishing insecure connections. In dual-mode headsets, attackers can exploit vulnerabilities in BLE mode for identity spoofing, then escalate to BR / EDR mode to steal data, bypassing user security warnings.

[0009] The broadcast nature of BLE beacons enables cross-application tracking. Researchers have found that different applications can listen to signals from nearby BLE devices to correlate user behavior across different applications, creating a complete user profile. The BLESCOPE tool automatically identifies easily trackable IoT devices by analyzing BLE APIs with static UUIDs within applications. For dual-mode headsets, if their BLE mode is used to send specific identifiers, users' location and usage habits could be shared by multiple applications, leading to serious privacy breaches.

[0010] As the control center for Bluetooth headsets, mobile devices rely heavily on their operating system-level security mechanisms. Research shows that malicious Bluetooth peripherals can bypass Android's security sandbox by simulating legitimate devices (such as keyboards and mice), thereby performing unauthorized operations. This indicates that even with robust system security mechanisms, external malicious devices can become new entry points for attacks. Dual-mode headsets face the same risk; for example, attackers could impersonate a keyboard in BR / EDR mode to steal user input while continuously monitoring the device's status in BLE mode.

[0011] Improper use of the Bluetooth API in mobile applications (Apps) is another important research area. Researchers have used data flow analysis tools such as FlowDroid to detect insecure code in Android applications, discovering that many apps access Bluetooth functionality without user authorization and may transmit sensitive data to unauthorized devices. Recent research has also expanded to the analysis of specific platform applications such as WeChat Mini Programs, revealing new risks in their use of the Bluetooth API. In the use case of dual-mode headphones, if the control application has vulnerabilities, attackers could exploit its data synchronization or switching functions between BR / EDR and BLE modes to leak information or hijack control.

[0012] Current mainstream Bluetooth headsets, in their design of features offering superior user experience such as "quick pairing" and "audio streaming," commonly suffer from three types of systemic vulnerabilities: leakage of persistent identity identifiers based on BLE broadcasting, weak authentication mechanisms for pairing that can be completely bypassed, and unauthenticated communication based on proprietary protocols. These vulnerabilities collectively pose a serious challenge to user security. More importantly, because these vulnerabilities are deeply embedded in the design logic of device firmware and accompanying applications, traditional passive sniffing and manual reverse engineering methods are time-consuming and labor-intensive, making it difficult to conduct rapid and systematic security assessments of the massive number of devices on the market. Summary of the Invention

[0013] This invention provides a method, apparatus, and device for detecting privacy leaks and security vulnerabilities in multi-mode Bluetooth headsets, in order to solve the problem of rapid and systematic security assessment of batch Bluetooth devices.

[0014] In a first aspect, embodiments of the present invention provide a method for detecting privacy leaks and security vulnerabilities in multi-mode Bluetooth headsets, including: Dynamic analysis is performed on the accompanying application of the target Bluetooth headset to extract the rules used by the application to identify and parse Bluetooth Low Energy (BLE) broadcast messages, and a Bluetooth private protocol dictionary for controlling the headset is constructed. Actively scan the surrounding wireless communication environment, capture and parse BLE broadcast messages and classic Bluetooth device information from at least one target Bluetooth headset; Based on the extracted rules and the constructed private protocol dictionary, the collected device information and communication data are automatically analyzed to determine whether the at least one target Bluetooth headset has a predefined type of security vulnerability.

[0015] In one possible implementation, the extraction of the rules used by the application to identify and parse Bluetooth Low Energy (BLE) broadcast messages includes: Dynamically intercept BLE scan requests initiated by the accompanying application and parse its scan filter parameters; Based on the scanning filter parameters, the application determines the filtering logic for identifying and setting the brand or model of headphones; The accompanying application is tracked to parse the vendor-defined data fields or service data fields in the received BLE broadcast messages, and the data parsing rules that convert binary broadcast data into device information are extracted.

[0016] In one possible implementation, constructing the Bluetooth private protocol dictionary for controlling the headset includes: Obtain the initial text content related to headphone function settings in the user interface of the accompanying application; When monitoring the accompanying application to read and write data via the Bluetooth interface, a function setting change in the user interface is triggered; Obtain the user interface text content after the function settings have been changed, and compare the user interface text content to determine the function name corresponding to the changed text. Associate the function name with the Bluetooth read / write data packets captured during monitoring that correspond to the function setting change; By traversing multiple function settings, a Bluetooth private protocol dictionary containing multiple function name-control command mapping relationships is constructed; wherein, the control commands are commands used to change the noise cancellation mode, adjust the volume level, or trigger firmware version queries.

[0017] In one possible implementation, the active scanning of the surrounding wireless communication environment includes: Run the BLE scanner to continuously listen for and receive surrounding BLE broadcast messages; The received BLE broadcast messages are parsed in a structured manner to extract the contents of the vendor-defined data fields and service data fields; Run the classic Bluetooth discovery program to obtain the media access control address and device category information of nearby classic Bluetooth devices.

[0018] In one possible implementation, after capturing and parsing the BLE broadcast message and classic Bluetooth device information from at least one target Bluetooth headset, the method further includes: The parsed BLE broadcast data is compared with the rules extracted from the application for identifying and parsing Bluetooth Low Energy BLE broadcast messages, and target Bluetooth headsets of known brands or models are selected from all BLE devices. For the selected target Bluetooth headsets, the extracted data parsing rules are applied to decode the binary content in the BLE broadcast data of the target Bluetooth headsets to obtain the device identifier or status information.

[0019] In one possible implementation, the security vulnerability includes a privacy data disclosure vulnerability; correspondingly, determining whether the at least one target Bluetooth headset has a predefined type of security vulnerability includes: The extracted data parsing rules are applied to decode the binary content in the captured BLE broadcast data; Check whether the decoded information string contains the classic Bluetooth media access control address or user account identifier of the target Bluetooth headset; If the aforementioned classic Bluetooth media access control address or user account identifier exists, a privacy data leakage vulnerability is identified.

[0020] In one possible implementation, the security vulnerability includes a weak pairing authentication vulnerability. Accordingly, determining whether the at least one target Bluetooth headset has a predefined type of security vulnerability includes: Confirm that the target Bluetooth headset is not in discoverable mode in classic Bluetooth mode; Construct and send a standard Bluetooth pairing request to the classic Bluetooth Media Access Control address of the target Bluetooth headset; Listen for feedback information from the system's Bluetooth management interface; If the feedback information indicates that the pairing was successful, it is determined that there is a weak authentication vulnerability in the pairing process.

[0021] In one possible implementation, after determining the existence of a weak authentication vulnerability in pairing, the method further includes: Initiate a request to establish an Advanced Audio Distribution Mode (A2DP) connection to the successfully paired target Bluetooth headset; Verify whether an A2DP connection is successfully established and audio streams can be received, or whether the target Bluetooth headset is disconnected from a legitimate user device.

[0022] In one possible implementation, the security vulnerability includes an application-layer unauthenticated communication vulnerability. Correspondingly, determining whether the at least one target Bluetooth headset has a predefined type of security vulnerability includes: Connect to the control service port of the target Bluetooth headset via Bluetooth communication protocol; Select a control instruction from the constructed private protocol dictionary; The control command is sent to the target Bluetooth headset through the control service port; Listen to the status feedback signal of the target Bluetooth headset or parse the data packets it returns; If the status feedback signal or the returned data packet confirms that the control command has been executed, it is determined that there is an application-layer unauthenticated communication vulnerability.

[0023] Secondly, embodiments of the present invention provide a device for detecting privacy leaks and security vulnerabilities in multi-mode Bluetooth headsets, comprising: The detection rule extraction module is used to dynamically analyze the accompanying application of the target Bluetooth headset, extract the rules used by the application to identify and parse Bluetooth Low Energy (BLE) broadcast messages, and construct a Bluetooth private protocol dictionary for controlling the headset. The device discovery and information collection module is used to actively scan the surrounding wireless communication environment, capture and parse BLE broadcast messages and classic Bluetooth device information from at least one target Bluetooth headset; The vulnerability assessment module is used to automatically analyze the collected device information and communication data based on the extracted rules and the constructed private protocol dictionary, and to determine whether the at least one target Bluetooth headset has a predefined type of security vulnerability.

[0024] Thirdly, embodiments of the present invention provide an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the method described in the first aspect or any possible implementation thereof.

[0025] Fourthly, embodiments of the present invention provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method described in the first aspect or any possible implementation thereof.

[0026] Fifthly, embodiments of the present invention provide a computer program product, including a computer program that, when executed by a processor, implements the method described in the first aspect or any possible implementation thereof.

[0027] In this embodiment of the invention, by first dynamically analyzing the supporting application to extract BLE broadcast message identification and parsing rules and constructing a Bluetooth private protocol dictionary, then actively scanning and capturing the BLE broadcast messages and classic Bluetooth device information of the target headset, and finally automatically analyzing device information and communication data based on the extracted rules and constructed dictionary, the invention effectively solves the problems of time-consuming and labor-intensive traditional manual reverse analysis and passive sniffing, which are difficult to scale up. It realizes the systematic and automated detection of three types of predefined security vulnerabilities in multi-mode Bluetooth headsets, greatly improving the efficiency, depth and breadth of vulnerability assessment, and can quickly cover a large number of different models of Bluetooth headset devices, providing an efficient and feasible technical solution for security assessment. Attached Figure Description

[0028] Figure 1 This is an application scenario diagram of the method for detecting privacy leaks and security vulnerabilities in multi-mode Bluetooth headsets provided in an embodiment of the present invention; Figure 2 This is a flowchart illustrating the implementation of a method for detecting privacy leaks and security vulnerabilities in multi-mode Bluetooth headsets according to an embodiment of the present invention. Figure 3 This is a flowchart illustrating the implementation of a method for detecting privacy leaks and security vulnerabilities in multi-mode Bluetooth headsets according to an embodiment of the present invention. Figure 4 This is a schematic diagram of the Bluetooth read / write request process after the earphone search function is enabled, according to an embodiment of the present invention. Figure 5 This is a schematic diagram of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0029] Currently, mainstream Bluetooth headphones generally suffer from three types of systemic flaws in the design of their "quick pairing" and "audio streaming" features, which offer an exceptional user experience. These flaws are as follows: 1. Privacy data leakage based on BLE broadcasting The fast connection mechanism of Bluetooth headsets relies on BLE channels for device discovery. After the user opens the Bluetooth headset's companion application, the program scans for nearby BLE broadcasts, filters out broadcast data belonging to its own brand of headsets, and parses the broadcast data into device information, displaying it to the user in a pop-up window. The application allows users to quickly pair with nearby Bluetooth headsets using buttons on the interface. This feature provides convenience, allowing users to easily discover nearby Bluetooth headset devices through pop-ups and quickly pair with them via Bluetooth Classic, instead of manually opening the system's Bluetooth settings to find and pair.

[0030] During this process, in order to display specific headphone model and battery level information to the user, the companion application needs to obtain the headphone's detailed specifications through some means. Simultaneously, to pair with the Bluetooth headphones, the companion application needs to obtain the headphone's classic Bluetooth MAC address. For the quick account connection function, the application needs to obtain the account information already connected to the Bluetooth headphones.

[0031] To obtain information about nearby Bluetooth headsets that are broadcasting BLE, some Bluetooth headset manufacturers have implemented related GATT services. After the accompanying application scans for nearby Bluetooth headsets, it connects to the headset via the BLE Generic Attribute profile (GATT) and returns this private data after passing through certain manufacturer-defined authentication mechanisms. However, some manufacturers have adopted a very simple design: embedding this information directly into the Manufacturer Specific Data or Service Data fields of the BLE broadcast packet. This design exposes private data, including classic Bluetooth MAC addresses, allowing any device with BLE sniffing capabilities to obtain this private information without direct interaction with the Bluetooth headset.

[0032] This high-risk broadcasting behavior isn't limited to the initial pairing of the device; it persists for most of its lifecycle. Based on the quick pairing functionality of most headphones, the device enters BLE broadcasting mode the moment the user opens the charging case, awaiting scanning and discovery by the pairing application. Some Bluetooth headphones offer multi-device connectivity and audio streaming features. Even with these features enabled, the headphones continue BLE broadcasting to ensure other devices can discover them. Furthermore, after pairing with the device, the pairing application interacts with the headphones via BLE or classic Bluetooth serial communication. Headphones interacting via BLE will also continue BLE broadcasting to allow the pairing application to recognize them.

[0033] From the moment a user opens the charging case of their Bluetooth earbuds until they close the case, the device's privacy information may be continuously leaked throughout its use. Attackers can build a detailed spatiotemporal database of users without any interaction. By deploying BLE scanners in different locations, attackers can correlate spatiotemporal data of specific MAC addresses to accurately infer a user's commuting patterns, lifestyle habits, workplace, and even infer their health status or social relationships by associating specific locations, thereby creating a precise profile from digital identity to physical identity.

[0034] 2. Logical flaws in the pairing process The Bluetooth standard clearly defines the security of the pairing process to prevent unauthorized connections. To enhance security, pairing should only be initiated when the device is in a clearly defined "pairable" mode, typically triggered by a physical action such as pressing and holding a button. After scanning for nearby headphones, the manufacturer's companion app usually prompts the user to perform a physical action to enter pairing mode before pairing can proceed.

[0035] However, tests revealed that the user interface layer guidance of most Bluetooth headset applications is disconnected from the underlying device state management. The headset's firmware logic does not strictly adhere to the security principle of "responding to new pairing requests only when the user triggers a 'pairable' state." Instead, it responds to pairing requests from any unknown device at any time. This means that the app's prompts are merely "suggestions," not mandatory security prerequisites. Bluetooth headset manufacturers have downgraded what should be a rigorous physical verification step into a technically unenforceable user interface prompt, thus opening the door to device hijacking. Attackers can completely ignore this process and directly pair with the device using the obtained MAC address.

[0036] Based on the above phenomena, a low-cost, high-success-rate device hijacking attack becomes possible. Attackers can ignore the normal pairing process and directly pair with the device using the obtained MAC address. First, the attacker uses Bluetooth analysis tools near the target to passively collect the classic Bluetooth MAC addresses of headphones leaked in broadcasts. Then, the attacker selects a target MAC address and uses a custom script to send a standard Bluetooth pairing request. Due to a logical flaw in the headphone firmware, it accepts this unauthorized request and completes pairing with the attacker's device. The Bluetooth protocol stipulates that headphones can typically only maintain one active A2DP connection, so after successfully pairing with the attacker, it automatically disconnects from the legitimate user. For the user, their music or calls will be abruptly interrupted, while for the attacker, the headphones have become a standard audio output device in their system. The harms of this vulnerability include active eavesdropping, DoS attacks, and providing a springboard for deeper attacks.

[0037] 3. Unauthenticated communication based on proprietary protocols After successful pairing, manufacturers typically implement fine-grained control over the headset using custom application-layer protocols. These proprietary protocols, running on top of Bluetooth GATT or Serial Port Profile (SPP) protocols, can have fatal design flaws: a complete lack of authentication and message integrity checks. Data packets from these proprietary protocols are often transmitted in plaintext or with simple encoding. Developers commonly over-trust and rely on Bluetooth link-layer encryption, assuming that once the devices are securely paired, the upper-layer application data is safe. This is a classic security boundary fallacy. While link-layer encryption effectively prevents external eavesdropping and tampering, it cannot distinguish between legitimate users sending data within the encrypted channel and attackers who have successfully paired the device. Due to the lack of application-layer signatures and authentication, the headset accepts any commands from the "paired device" without question.

[0038] This design flaw directly leads to a variety of high-risk attack vectors. An attacker only needs to capture a legitimate command packet once to resend it to the headset an unlimited number of times at any future time to trigger the same action; this is known as a replay attack. Because there is no nonce or timestamp mechanism, this attack can be used for pranks or harassment. Furthermore, by reverse engineering the accompanying application, attackers can obtain the instruction set of the proprietary protocol, allowing them to freely construct and send arbitrary valid commands, achieving malicious command injection. This can lead to high-risk harms including functional tampering (maliciously modifying device parameters, updating malicious firmware) and privacy theft (remotely activating the microphone).

[0039] The revelation of these three types of security issues reveals that while manufacturers introduce convenient features, they inadvertently bring significant security and privacy risks to users. These risks do not stem from a single vulnerability, but rather from a complete attack chain comprised of privacy data leaks, weak pairing authentication mechanisms, and unauthenticated communication. In the pursuit of fast connectivity and convenient control, Bluetooth headset manufacturers have sacrificed what should be core security design, thereby potentially threatening users' personal data, device control, and even personal safety.

[0040] Existing technologies primarily rely on time-consuming and labor-intensive manual reverse engineering and passive sniffing. This approach demands a high level of technical expertise from security researchers and struggles to conduct systematic and large-scale security assessments of the vast number of different headphone models on the market. This invention aims to improve the efficiency, depth, and breadth of Bluetooth headphone security vulnerability assessment by introducing an innovative and indispensable automated detection process that covers the entire process from device discovery to vulnerability verification.

[0041] The embodiments of the present invention will now be described in detail with reference to the accompanying drawings.

[0042] Figure 1This diagram illustrates an application scenario of the multi-mode Bluetooth headset privacy leakage and security vulnerability detection method provided in this invention. Figure 1 As shown, the automated detection framework is divided into three core modules: detection rule extraction module, device discovery and information collection module, and vulnerability judgment module.

[0043] The detection rule extraction module analyzes the Bluetooth interaction of the Android Bluetooth headset's companion application through dynamic code analysis, extracting rules on how the application filters nearby BLE broadcasts, conversion rules for converting BLE messages into device information, and sets of private protocols corresponding to headset function modifications.

[0044] The device discovery and information collection module is responsible for actively scanning nearby Bluetooth devices. It continuously scans nearby BLE broadcast packets and nearby discoverable classic Bluetooth devices, extracting basic information such as the device's MAC address, supported Universally Unique Identifier (UUID), broadcast address type, Manufacturer Specific Data, and Service Data.

[0045] The vulnerability assessment module automatically analyzes collected device information based on predefined vulnerability characteristics, logical rules, and general verification rules. This module is further divided into three sub-modules: a privacy leakage assessment engine, an insecure pairing assessment engine, and an application-layer authentication failure assessment engine, each targeting the three types of vulnerabilities analyzed in the aforementioned embodiments.

[0046] The solution provided in this invention can be used for detecting privacy and security vulnerabilities in various Bluetooth headsets. Specific application areas include Bluetooth headset manufacturers, third-party security assessment agencies and researchers, consumers, and enterprise users. Specific application methods are as follows for different application areas: 1. When applied to Bluetooth headset manufacturers, this invention provides an automated testing framework that allows for comprehensive security audits of firmware and accompanying applications during the product design, development, and quality control phases. This helps identify and fix the following three types of vulnerabilities before product launch: Privacy data breach: Ensure that sensitive information such as the classic Bluetooth MAC address is not leaked in BLE broadcasts to prevent users' whereabouts from being tracked.

[0047] Pairing process defects: Verify that the headphone firmware strictly follows pairing security guidelines to ensure that a new connection can only be established after explicit user authorization (such as physical button operation), thereby preventing device hijacking.

[0048] Unauthenticated communication: Check whether the private protocol contains the necessary authentication and message integrity verification mechanisms to prevent attackers from maliciously controlling the device through replay attacks or command injection.

[0049] 2. When applied to third-party security assessment agencies and researchers, third-party security labs or independent researchers can utilize this invention to build an automated security assessment platform. This platform conducts large-scale, systematic security assessments of different brands and models of Bluetooth headsets on the market, publishes industry security reports, provides purchasing advice to consumers, and urges manufacturers to improve product security. This approach is more efficient than traditional manual reverse engineering and can quickly cover a large number of devices.

[0050] 3. When applied to consumer and enterprise users, consumers can use applications or tools developed based on this invention to self-check whether their Bluetooth headsets have known security risks before purchase or during use. For example, a mobile application can scan nearby Bluetooth headset broadcasts and alert users to potential privacy data leaks. Enterprises can also use this technology to conduct security compliance checks on Bluetooth devices used by employees, especially in scenarios involving sensitive communications.

[0051] Figure 2 This is a flowchart illustrating the implementation of a method for detecting privacy leaks and security vulnerabilities in multi-mode Bluetooth headsets according to an embodiment of the present invention. Figure 2 This includes the following steps: S201: Perform dynamic analysis on the target Bluetooth headset's accompanying application, extract the rules used by the application to identify and parse Bluetooth Low Energy (BLE) broadcast messages, and construct a Bluetooth private protocol dictionary for controlling the headset.

[0052] The execution subject in various embodiments of the present invention can be a server, processor, microprocessor, or other device with data processing capabilities. In actual implementation, the specific implementation method of the execution subject can be selected according to actual needs. This embodiment does not impose any particular restrictions on this, as long as it is a device with data processing capabilities.

[0053] Specifically, by dynamically analyzing the running state of the Bluetooth headset's companion application, core rules for security detection are extracted. These rules will serve as the basis for subsequent security assessments to reveal potential privacy breaches and unauthorized control risks.

[0054] The rule extraction work focuses on two main aspects: filtering and parsing rules for Bluetooth Low Energy (BLE) advertising messages, and application-layer private communication protocol rules. BLE rules primarily reveal how the accompanying application identifies and processes nearby BLE devices, with a particular focus on whether they contain potentially misused privacy data. Private protocol rules are used to parse private communication instructions between the application and the Bluetooth headset, thereby understanding how headset settings are modified.

[0055] S202, actively scan the surrounding wireless communication environment, capture and parse BLE broadcast messages and classic Bluetooth device information from at least one target Bluetooth headset.

[0056] Among them, the device identifier, broadcast data and connection status information exposed by the target Bluetooth headset during operation are fully captured by active scanning.

[0057] S203, based on the extracted rules and the constructed private protocol dictionary, automatically analyzes the collected device information and communication data to determine whether at least one target Bluetooth headset has a predefined type of security vulnerability.

[0058] Based on the nearby BLE broadcast information and parsed device information obtained in the preceding steps, three types of critical security vulnerabilities are automatically identified through preset logical rules and dynamic behavior analysis: privacy data leakage vulnerabilities, weak pairing authentication vulnerabilities, and application-layer unauthenticated communication vulnerabilities. Each type of vulnerability corresponds to an independent judgment sub-engine, realizing a complete attack chain simulation.

[0059] In this embodiment, by first dynamically analyzing the supporting application to extract BLE broadcast message identification and parsing rules and constructing a Bluetooth private protocol dictionary, and then actively scanning and capturing the BLE broadcast messages and classic Bluetooth device information of the target headset, the device information and communication data are automatically analyzed based on the extracted rules and constructed dictionary. This effectively solves the problems of time-consuming and labor-intensive traditional manual reverse analysis and passive sniffing, which are difficult to scale up. It realizes the systematic and automated detection of three types of predefined security vulnerabilities in multi-mode Bluetooth headsets, greatly improving the efficiency, depth and breadth of vulnerability assessment. It can quickly cover a large number of Bluetooth headset devices of different models, providing an efficient and feasible technical solution for security assessment.

[0060] In one possible implementation, step S201 involves extracting the rules used by the application to identify and parse Bluetooth Low Energy (BLE) broadcast messages, including: Dynamically intercept BLE scan requests initiated by the accompanying application and parse its scan filter parameters; Based on the scan filter parameters, determine the filtering logic that the application uses to identify and set the brand or model of headphones; Track the parsing operations of the accompanying application on the vendor-defined data fields or service data fields in the received BLE broadcast messages, and extract the data parsing rules that convert binary broadcast data into device information.

[0061] In practice, on the Android platform, the application scans BLE advertising messages by calling the BluetoothLeScanner#startScan() method. This method includes three key parameters: ScanFilter, ScanSettings, and ScanCallback. The ScanFilter allows the application to precisely receive only the advertising messages it needs.

[0062] The purpose of setting the scan filter message type is to filter nearby Bluetooth devices. For example, if there are many different brands of Bluetooth headphones nearby, the application can add a filter to receive only Bluetooth devices of its own brand.

[0063] To gain a deeper understanding of how the Bluetooth headset's companion application processes BLE data, the following dynamic analysis method was designed to extract its filtering and parsing rules: BLE packet filtering rule identification: The LSPosed framework dynamically intercepts application calls to BluetoothLeScanner #startScan() and parses its ScanFilter parameters. This helps to accurately identify the specific device name, service UUID, or vendor data that the application relies on, thereby understanding its BLE packet filtering logic.

[0064] BLE Privacy Data Parsing and Tracing: To investigate whether BLE advertising messages are being used to leak sensitive information, the calls to the `ScanRecord#getManufacturerSpecificData()` and `getServiceData()` methods are traced. These two system functions extract Manufacturer Specific Data (MSD) and Service Data from Bluetooth Low Energy packets. Further tracing is done on the application's calls to functions such as `System#arraycopy()` on this binary data (MSD and Service Data), and how the data is parsed into objects such as device IDs, MAC address strings, or device models. This data flow tracing reveals how applications decode seemingly meaningless binary data from BLE messages into meaningful device information.

[0065] The above filtering and parsing rules will be used for subsequent actual analysis of Bluetooth headsets.

[0066] In this embodiment, by dynamically intercepting the BLE scanning requests of the accompanying application and parsing the scanning filter parameters, the filtering logic by which the application identifies specific brands or models of headphones can be accurately determined. Then, by tracking the application's parsing operations on the manufacturer-defined data fields and service data fields in the BLE broadcast messages, the data parsing rules for converting binary broadcast data into device information can be extracted. This process can deeply explore the BLE interaction logic between the application and the Bluetooth headphones, accurately grasp the manufacturer's processing method for BLE broadcast data, and provide a key basis for subsequent accurate identification of target Bluetooth headphones and parsing of potentially sensitive information contained therein. This avoids the problem of traditional detection methods failing to accurately identify the meaning of data due to a lack of understanding of the manufacturer's customized parsing logic, and significantly improves the targeting and accuracy of subsequent vulnerability detection.

[0067] In one possible implementation, a Bluetooth private protocol dictionary for controlling the headphones is constructed, including: Retrieve the initial text content related to headphone function settings from the user interface of the accompanying application; When the monitoring application reads or writes data via Bluetooth, a function setting change in the user interface is triggered. Obtain the user interface text content after the function settings have been changed, and compare the user interface text content to determine the function name corresponding to the changed text. Associate the function name with the Bluetooth read / write data packets captured during monitoring that correspond to the function setting changes; By iterating through multiple function settings, a Bluetooth private protocol dictionary containing multiple function name-control command mapping relationships is constructed; among them, control commands are commands used to change noise cancellation mode, adjust volume level, or trigger firmware version query.

[0068] Many Bluetooth headset manufacturers implement advanced function controls through custom application layer protocols. These proprietary protocols generally lack authentication and message integrity checks, allowing paired attackers to freely send malicious commands.

[0069] In the specific implementation process, this invention designs a set of general protocol extraction methods to construct a complete set of private protocol rules. This method makes comprehensive use of Hook Bluetooth read and write API and software interface string capture to form a complete analysis loop.

[0070] The first step is to obtain all readable text content in its initial state. Headphone apps typically use radio buttons or list views to display settings options, and the description text changes after modifying a setting. This text usually corresponds to various setting options, such as "noise cancellation mode" or "modify equalizer," and it forms the basis for subsequent operations and data association. The text read from the headphone application is identical for headphone brands.

[0071] After obtaining the initial text, monitor the communication API interfaces between the application and the Bluetooth headset. This includes Bluetooth and BLE read / write functions such as `BluetoothGatt#writeCharacteristic()` and `readCharacteristic()` for BLEGATT, and `BluetoothOutputStream#write()` and `read()` for the classic Bluetooth private serial port. While monitoring, manually modify a setting on the application interface. For example, change the "Noise Cancellation Mode" from "Off" to "On".

[0072] In this code, `BluetoothGatt#writeCharacteristic()` and `readCharacteristic()` are the Android system's write and read functions for Bluetooth Low Energy devices, respectively; `BluetoothOutputStream#write()` and `read()` are the write and read functions for Classic Bluetooth devices, respectively. Once the interface operation is complete, immediately retrieve all readable text from the application. By comparing the text content before and after the operation, the modified text can be accurately located, such as "Noise Reduction Mode: On". This changed text becomes the key to accurately extracting the function name.

[0073] Finally, the function name represented by the modified text (e.g., "Turn on headphone search") is associated one-to-one with the write and read data packets captured during monitoring, such as... Figure 3 As shown. Ultimately, by traversing all configurable functions, a Bluetooth headset private protocol dictionary containing "function name - write command - device response" can be constructed, providing core data for subsequent vulnerability analysis and security testing.

[0074] In this embodiment, by acquiring the initial text content of the user interface of the accompanying application, function setting changes are triggered while monitoring Bluetooth interface data read and write. The text content before and after the change is compared to determine the corresponding function name and associate it with the captured Bluetooth read and write data packets. Then, multiple function settings are traversed to construct a Bluetooth private protocol dictionary. This achieves automated reverse engineering and extraction of manufacturer-customized application layer protocols, eliminating the need for manual reverse engineering of tedious private protocols. This not only significantly reduces the difficulty and workload of protocol extraction but also comprehensively acquires the control command mapping relationships covering various functions such as noise reduction mode switching, volume adjustment, and firmware version query. This provides complete and accurate command basis for subsequent detection of application layer unauthenticated communication vulnerabilities, enabling vulnerability detection to cover more functional scenarios.

[0075] In one possible implementation, actively scanning the surrounding wireless communication environment includes: Run the BLE scanner to continuously listen for and receive surrounding BLE broadcast messages; The received BLE broadcast messages are parsed in a structured manner to extract the contents of the vendor-defined data fields and service data fields; Run the classic Bluetooth discovery program to obtain the media access control address and device category information of nearby classic Bluetooth devices.

[0076] In the specific implementation process, through Figure 1 The device discovery and information collection module shown performs device scanning and analysis. This module encapsulates the BLE scanning and connection library bleak (based on the system Bluetooth API) and the classic Bluetooth scanning and connection library pyBlueZ, enabling scanning and analysis of nearby BLE and classic Bluetooth devices without interfering with normal operation.

[0077] First, the scan results are filtered out by using the UUID information supported by BLE and classic Bluetooth to exclude non-audio BLE devices (such as Beacon and sensors) and classic Bluetooth peripheral devices (such as keyboards and mice), focusing only on Bluetooth headset devices.

[0078] This module implements continuous monitoring and structured parsing of BLE broadcast messages. It continuously calls the bleak interface in the background to capture broadcast data packets from all surrounding BLE devices in real time. For each received broadcast packet, it first parses its raw binary structure, focusing on extracting common carriers of embedded device metadata (such as model, battery level, user account, classic Bluetooth MAC address, etc.): Manufacturer Specific Data and Service Data fields.

[0079] During data extraction, the module pays particular attention to whether the broadcast data contains information related to the device's classic Bluetooth MAC address. Since BLE broadcast addresses are typically randomized in modern operating systems to protect user privacy, if manufacturers embed the classic Bluetooth MAC address in plaintext within the broadcast packet, this privacy protection mechanism is bypassed. Therefore, this module first compares each Bluetooth BLE broadcast data with known BLE filters extracted by the detection rule extraction module. Generally, detection rules (i.e., BLE filters) for multiple headphone brands are extracted, with one rule corresponding to each brand. If a supported BLE filter exists, the broadcast data can be determined to be a known Bluetooth headphone BLE broadcast type. An attempt is made to parse the broadcast data using the binary data parsing rule corresponding to the filter. If parsing is successful, it is confirmed to be from a known Bluetooth headphone. If no known BLE filter exists, the extracted binary data is decoded.

[0080] In addition to scanning and analyzing BLE broadcast messages, this module also uses pyBlueZ to scan nearby classic Bluetooth devices, saving information such as device MAC address, discoverability status, device name, and class of device. The scanned and parsed BLE and classic Bluetooth information is saved for further vulnerability assessment. When including both BLE and classic Bluetooth devices, a comprehensive scan of all surrounding BLE and classic Bluetooth devices is performed for vulnerability assessment.

[0081] In this embodiment, by running a BLE scanning program to continuously listen for and receive surrounding BLE broadcast messages and structure-parse the content of manufacturer-defined data fields and service data fields, and simultaneously running a classic Bluetooth discovery program to obtain the MAC address and device category information of nearby classic Bluetooth devices, the wireless communication data and basic device information of the target Bluetooth headset can be captured comprehensively and efficiently without interfering with the normal operation of the device. This ensures that the collected data covers both BLE and classic Bluetooth modes, avoiding the problem of missing key data that may occur with traditional scanning methods, and providing sufficient and complete data source support for subsequent multi-dimensional and comprehensive vulnerability assessment.

[0082] In one possible implementation, after capturing and parsing BLE broadcast messages and classic Bluetooth device information from at least one target Bluetooth headset, the method further includes: The parsed BLE broadcast data is compared with the rules extracted by the application for identifying and parsing Bluetooth Low Energy BLE broadcast messages, and the target Bluetooth headset of known brand or model is selected from all BLE devices. For the selected target Bluetooth headsets, the extracted data parsing rules are applied to decode the binary content in the BLE broadcast data of the target Bluetooth headsets to obtain the device identifier or status information.

[0083] In this embodiment, the parsed BLE broadcast data is compared with the extracted application BLE identification and parsing rules. This allows for the accurate selection of target Bluetooth headsets of known brands or models from numerous BLE devices, effectively eliminating interference from non-target devices such as beacons, sensors, and Bluetooth keyboards. The extracted data parsing rules are then applied to the selected target Bluetooth headsets to decode the binary content in the BLE broadcast data, accurately obtaining device identifiers or status information. This solves the problems of inaccurate target device identification and imprecise data parsing in traditional detection methods, providing a precise data foundation for subsequent targeted vulnerability assessment and further improving the efficiency and reliability of vulnerability detection.

[0084] The foregoing embodiments provide a summary of how this invention can automatically identify three types of critical security vulnerabilities: privacy data leakage vulnerabilities, weak pairing authentication vulnerabilities, and application-layer unauthenticated communication vulnerabilities. The identification process for these three types of critical security vulnerabilities will be described in detail below.

[0085] In one possible implementation, the security vulnerability includes a privacy data breach vulnerability. Accordingly, it is determined whether at least one target Bluetooth headset has a predefined type of security vulnerability, including: The extracted data parsing rules are applied to decode the binary content in the captured BLE broadcast data; Check whether the decoded information string contains the target Bluetooth headset's classic Bluetooth media access control address or user account identifier. If a classic Bluetooth media access control address or user account identifier is present, a privacy data breach vulnerability is identified.

[0086] In practical implementation, a privacy data leakage vulnerability engine is set up. This engine analyzes nearby BLE broadcast information and parsed device information obtained from the device discovery and information collection module to determine whether there are any issues with the leakage of sensitive information (plaintext or encoded information of bound user accounts and classic Bluetooth MAC addresses), especially the plaintext or encoded information of user accounts bound to Bluetooth headsets and classic Bluetooth MAC addresses. Through a comprehensive privacy leakage judgment engine, the privacy leakage risk of the device under normal use scenarios is assessed.

[0087] In this embodiment, the binary content in the captured BLE broadcast data is decoded by applying extracted data parsing rules. Then, the decoded information string is checked to see if it contains a classic Bluetooth MAC address or user account identifier. This can accurately identify the problem of Bluetooth headsets leaking sensitive privacy data through BLE broadcast. Even if the manufacturer has encoded or shifted this sensitive data, it can still be accurately decoded and detected with the help of the extracted parsing rules. This breaks through the limitation of traditional passive sniffing, which can only capture broadcast messages but cannot understand the deeper meaning of manufacturer-defined data. It achieves in-depth and reliable judgment of privacy data leakage risks and provides effective detection protection for user privacy security.

[0088] In one possible implementation, the security vulnerability includes a weak pairing authentication vulnerability. Accordingly, determining whether at least one target Bluetooth headset has a predefined type of security vulnerability includes: Confirm that the target Bluetooth headset is not in discoverable mode in classic Bluetooth mode; Construct and send a standard Bluetooth pairing request to the classic Bluetooth Media Access Control address of the target Bluetooth headset; Listen for feedback information from the system's Bluetooth management interface; If the feedback indicates that the pairing was successful, it is determined that there is a weak authentication vulnerability in the pairing process.

[0089] In one possible implementation, after determining that a weak pairing authentication vulnerability exists, the following is also included: Initiate a request to establish an Advanced Audio Distribution Mode (A2DP) connection to the successfully paired target Bluetooth headset; Verify whether an A2DP connection is successfully established and audio streams are received, or whether the target Bluetooth headset is disconnected from a legitimate user device.

[0090] In actual implementation, a pairing defect detection engine is set up. This engine aims to verify whether the target Bluetooth headset can still accept pairing requests from any device when it is not in "user-authorized pairing mode". Its detection logic strictly follows Bluetooth security specifications and manufacturer implementation defects.

[0091] State Detection: The engine first analyzes whether the target Bluetooth headset device exists in the list of all nearby discoverable classic Bluetooth devices obtained by the device discovery and information gathering module. If the device is not in discoverable state in classic Bluetooth mode (e.g., not actively broadcasting a discoverable flag), it proceeds to the next step of constructing a pairing request; Pairing request construction: Use pyBlueZ to construct a pairing command for the target device's MAC address and send a standard Bluetooth pairing request to the target device; Response monitoring: Listen to system Bluetooth logs or pairing status callbacks to determine whether the device responds to the pairing request without triggering the physical button and enters the PIN code negotiation or Just Works process; Result determination: If pairing is successful, the device is determined to have a "weak pairing authentication vulnerability", which means that attackers can bypass user authorization and directly hijack the device connection; Risk Escalation: Further attempts will be made to establish an A2DP or HFP connection after successful pairing to verify whether legitimate user connections can be forcibly disconnected, thereby achieving service blocking (DoS) or audio hijacking.

[0092] The engine's detection results can be directly mapped to real-world attack scenarios, such as "passing device hijacking" or "audio eavesdropping in public places," making it extremely valuable for practical evaluation.

[0093] In this embodiment, it is confirmed that the target Bluetooth headset is not in discoverable state in classic Bluetooth mode. Then, a standard pairing request is constructed and sent to its classic Bluetooth MAC address. The pairing success is determined by listening to the feedback information of the system's Bluetooth management interface. This method can actively simulate the hijacking behavior of an attacker. Without interfering with the user's normal use of the device, it can directly verify whether there are logical defects in the Bluetooth headset pairing process. This effectively solves the problem that traditional technologies can only perform theoretical analysis on pairing security but cannot verify it in practice. It can intuitively prove whether the device is at risk of being directly hijacked by bypassing authorization. It provides the most direct and convincing evidence for manufacturers to fix pairing process vulnerabilities and significantly improves the practical value of pairing security testing.

[0094] In one possible implementation, the security vulnerability includes an application-layer unauthenticated communication vulnerability. Accordingly, determining whether at least one target Bluetooth headset has a predefined type of security vulnerability includes: Connect to the control service port of the target Bluetooth headset via Bluetooth communication protocol; Select a control instruction from the constructed private protocol dictionary; Control commands are sent to the target Bluetooth headset via the control service port; Listen for the status feedback signals of the target Bluetooth headset or parse the data packets it returns; If the status feedback signal or the returned data packet confirms that the control command has been executed, it is determined that there is an application-layer unauthenticated communication vulnerability.

[0095] In actual implementation, an application-layer authentication-free judgment engine is set up. Based on successful pairing, this engine further detects whether the device lacks authentication and integrity verification for application-layer commands. Its core relies on the Bluetooth private protocol dictionary and dynamic command injection capability built in step S201. The specific steps are as follows: Service connection: Connect to the headphone's control service port (such as manufacturer-defined BLEUID or RFCOMM channel) via bleak / pyBlueZ.

[0096] Command injection: Select typical control commands (such as "turn on noise reduction", "adjust volume to maximum", "query firmware version", etc.) from the pre-built private protocol dictionary and send them to the device by calling the bleak / pyBlueZ interface.

[0097] Response analysis: Listen for data packets or status changes (such as sound feedback or configuration updates) returned by the device to determine whether the device has executed the instruction.

[0098] Authentication failure determination: If a device executes an external command without performing any identity verification (such as token, signature, challenge-response), it is determined that there is an "application layer unauthenticated communication vulnerability".

[0099] In this embodiment, the system connects to the control service port of the target Bluetooth headset via the Bluetooth communication protocol, selects control commands from the constructed private protocol dictionary and sends them to the headset, and then listens to the headset's status feedback signals or parses the returned data packets. This can automatically verify whether the headset's application layer lacks authentication and message integrity verification mechanisms, eliminating the need for manual construction of data packets and test commands. This overcomes the limitations of traditional testing methods, which are cumbersome and cannot exhaustively cover all attack vectors. It can not only accurately determine the existence of application layer unauthenticated communication vulnerabilities, but also intuitively demonstrate the potential harms such as functional tampering and privacy theft caused by the vulnerability through command execution results. This makes vulnerability detection more systematic and convincing, and provides a clear direction for manufacturers to improve the security mechanisms of their private protocols.

[0100] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0101] The following are device embodiments of the present invention. For details not described in detail, please refer to the corresponding method embodiments described above.

[0102] Figure 4 The diagram shows a schematic of the multi-mode Bluetooth headset privacy leakage and security vulnerability detection device provided in an embodiment of the present invention. For ease of explanation, only the parts related to the embodiment of the present invention are shown, and are described in detail below: like Figure 4 As shown, the multi-mode Bluetooth headset privacy leakage and security vulnerability detection device 4 includes: The detection rule extraction module 401 is used to dynamically analyze the application accompanying the target Bluetooth headset, extract the rules used by the application to identify and parse Bluetooth Low Energy (BLE) broadcast messages, and build a Bluetooth private protocol dictionary for controlling the headset. The device discovery and information collection module 402 is used to actively scan the surrounding wireless communication environment, capture and parse BLE broadcast messages and classic Bluetooth device information from at least one target Bluetooth headset; The vulnerability assessment module 403 is used to automatically analyze the collected device information and communication data based on the extracted rules and the constructed private protocol dictionary, and to determine whether at least one target Bluetooth headset has a predefined type of security vulnerability.

[0103] In this embodiment of the invention, the newly added detection rule extraction module 401 realizes dynamic analysis and automated rule extraction of the Bluetooth interaction logic of the application. This module can automatically identify the BLE broadcast filtering and parsing rules of Bluetooth headsets and construct a private protocol instruction dictionary. This indispensable automated step directly replaces the most tedious and time-consuming manual reverse engineering step in traditional methods, thereby transforming the entire security assessment process from relying on human experience to rule-based automated execution. Therefore, this invention can efficiently batch-detect massive numbers of Bluetooth headset devices, making it a powerful tool applicable to large-scale security surveys, an advantage unmatched by existing technologies.

[0104] Traditional passive sniffing can only capture broadcast messages but cannot understand the deeper meaning of manufacturer-defined data within them. This makes it difficult to determine whether sensitive data such as classic Bluetooth MAC addresses or account information are hidden in specific binary data, thus limiting the accurate assessment of privacy risks.

[0105] The detection rule extraction module 401 of this invention can directly retrieve data parsing rules from the accompanying application and apply them to the BLE broadcast data captured by the device discovery and information collection module 402. It is precisely because of this added "rule extraction" step that this invention can accurately parse seemingly meaningless binary data into specific device information, thereby providing an unprecedented, application-logic-based, accurate judgment. This ensures that even privacy data hidden by manufacturers through displacement or encoding can be accurately identified, achieving a deep and reliable assessment of privacy leakage risks.

[0106] Security assessments in existing technologies typically remain at the level of theoretical analysis, making it difficult to proactively verify whether there are defects in the pairing process without interfering with normal user operation.

[0107] The vulnerability assessment module 403 of this invention is equipped with a "pairing defect assessment engine," which can proactively construct and send a pairing request even when the device is not in "pairable" mode. This indispensable step of "proactive request" allows this invention to directly simulate attacker behavior and verify whether the Bluetooth headset firmware does indeed have logical defects in a real-world scenario. This attack simulation method directly produces beneficial effects: it provides a vulnerability verification method with practical attack value, proving that even without any physical operation by the user, the device can still be hijacked, providing manufacturers with the most direct and convincing security warning.

[0108] Traditionally, testing the security of proprietary protocols requires researchers to manually reverse engineer the protocols, manually construct data packets, and send them. This process is complex, unsystematic, and struggles to encompass all attack vectors. The detection rule extraction module 401 of this invention can automatically construct a dictionary of proprietary protocols containing "function-instruction" pairs, and the "application-layer unauthenticated judgment engine" uses this dictionary to automatically inject instructions into the device. This "automated instruction injection" step directly bypasses the tedious manual work, making the verification of replay attacks and malicious instruction injection systematic and automated. This capability not only verifies the existence of vulnerabilities but also demonstrates their specific harms (e.g., automatically maximizing volume, modifying device settings), thus directly producing a positive effect of verifying and demonstrating the harm of vulnerabilities.

[0109] In this embodiment, by first dynamically analyzing the supporting application to extract BLE broadcast message identification and parsing rules and constructing a Bluetooth private protocol dictionary, and then actively scanning and capturing the BLE broadcast messages and classic Bluetooth device information of the target headset, the device information and communication data are automatically analyzed based on the extracted rules and constructed dictionary. This effectively solves the problems of time-consuming and labor-intensive traditional manual reverse analysis and passive sniffing, which are difficult to scale up. It realizes the systematic and automated detection of three types of predefined security vulnerabilities in multi-mode Bluetooth headsets, greatly improving the efficiency, depth and breadth of vulnerability assessment. It can quickly cover a large number of Bluetooth headset devices of different models, providing an efficient and feasible technical solution for security assessment.

[0110] Figure 5 This is a schematic diagram of an electronic device provided in an embodiment of the present invention. For example... Figure 5 As shown, the electronic device 5 of this embodiment includes a processor 50 and a memory 51. The memory 51 stores a computer program 52. When the processor 50 executes the computer program 52, it implements the steps in the various method embodiments described above. Alternatively, when the processor 50 executes the computer program 52, it implements the functions of each module / unit in the various device embodiments described above.

[0111] For example, computer program 52 may be divided into one or more modules / units, which are stored in memory 51 and executed by processor 50 to complete the present invention. The one or more modules / units may be a series of computer program instruction segments capable of performing a specific function, which describe the execution process of computer program 52 in electronic device 5.

[0112] Electronic device 5 may include, but is not limited to, processor 50 and memory 51. Those skilled in the art will understand that... Figure 5 This is merely an example of electronic device 5 and does not constitute a limitation on electronic device 5. It may include more or fewer components than shown, or combine certain components, or different components. For example, electronic device 5 may also include input / output devices, network access devices, buses, etc.

[0113] The processor 50 can be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor.

[0114] The memory 51 can be an internal storage unit of the electronic device 5, such as a hard disk or RAM. The memory 51 can also be an external storage device of the electronic device 5, such as a plug-in hard disk, Smart Media Card (SMC), Secure Digital (SD) card, or Flash Card. Furthermore, the memory 51 can include both internal and external storage units of the electronic device 5. The memory 51 is used to store the computer program 52 and other programs and data required by the electronic device 5. The memory 51 can also be used to temporarily store data that has been output or will be output.

[0115] For the sake of simplicity and clarity, only the above-described functional modules / units are used as examples. In practical applications, the functions described above can be assigned to different functional modules / units as needed. These modules / units can be implemented in hardware, software, or a combination of both.

[0116] This invention also provides a computer-readable storage medium storing a computer program. When the computer program is executed by a processor, it implements the methods described in the above-described method embodiments.

[0117] This invention also provides a computer program product, including a computer program. When the computer program is executed by a processor, it implements the methods described in the above-described method embodiments.

[0118] Computer programs include computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. Computer-readable media can include: any entity or device capable of carrying computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc.

[0119] In the above embodiments, the descriptions of each embodiment have their own emphasis. Parts not detailed or described in a particular embodiment can be referred to in the relevant descriptions of other embodiments. Unless otherwise specified or in conflict with logic, the terminology and / or descriptions between different embodiments are consistent and can be referenced interchangeably. Technical features in different embodiments can be combined to form new embodiments based on their inherent logical relationships.

[0120] The above-described embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included within the protection scope of the present invention.

Claims

1. A method for detecting privacy leaks and security vulnerabilities in multi-mode Bluetooth headsets, characterized in that, include: Dynamic analysis is performed on the accompanying application of the target Bluetooth headset to extract the rules used by the application to identify and parse Bluetooth Low Energy (BLE) broadcast messages, and a Bluetooth private protocol dictionary for controlling the headset is constructed. Actively scan the surrounding wireless communication environment, capture and parse BLE broadcast messages and classic Bluetooth device information from at least one target Bluetooth headset; Based on the extracted rules and the constructed private protocol dictionary, the collected device information and communication data are automatically analyzed to determine whether the at least one target Bluetooth headset has a predefined type of security vulnerability.

2. The method for detecting privacy leaks and security vulnerabilities in multi-mode Bluetooth headsets according to claim 1, characterized in that, The rules for extracting the application's methods for identifying and parsing Bluetooth Low Energy (BLE) broadcast messages include: Dynamically intercept BLE scan requests initiated by the accompanying application and parse its scan filter parameters; Based on the scanning filter parameters, the application determines the filtering logic for identifying and setting the brand or model of headphones; The accompanying application is tracked to parse the vendor-defined data fields or service data fields in the received BLE broadcast messages, and the data parsing rules that convert binary broadcast data into device information are extracted.

3. The method for detecting privacy leaks and security vulnerabilities in multi-mode Bluetooth headsets according to claim 1, characterized in that, The construction of the Bluetooth private protocol dictionary for controlling the headphones includes: Obtain the initial text content related to headphone function settings in the user interface of the accompanying application; When monitoring the accompanying application to read and write data via the Bluetooth interface, a function setting change in the user interface is triggered; Obtain the user interface text content after the function settings have been changed, and compare the user interface text content to determine the function name corresponding to the changed text. Associate the function name with the Bluetooth read / write data packets captured during monitoring that correspond to the function setting change; By traversing multiple function settings, a Bluetooth private protocol dictionary containing multiple function name-control command mapping relationships is constructed; wherein, the control commands include commands for changing noise cancellation mode, adjusting volume level, or triggering firmware version query.

4. The method for detecting privacy leaks and security vulnerabilities in multi-mode Bluetooth headsets according to claim 1, characterized in that, The active scanning of the surrounding wireless communication environment includes: Run the BLE scanner to continuously listen for and receive surrounding BLE broadcast messages; The received BLE broadcast messages are parsed in a structured manner to extract the contents of the vendor-defined data fields and service data fields; Run the classic Bluetooth discovery program to obtain the media access control address and device category information of nearby classic Bluetooth devices.

5. The method for detecting privacy leaks and security vulnerabilities in multi-mode Bluetooth headsets according to claim 2 or 4, characterized in that, After capturing and parsing BLE broadcast messages and classic Bluetooth device information from at least one target Bluetooth headset, the method further includes: The parsed BLE broadcast data is compared with the rules extracted by the application for identifying and parsing Bluetooth Low Energy BLE broadcast messages, and the target Bluetooth headset of known brand or model is selected from all BLE devices. For the selected target Bluetooth headsets, the extracted data parsing rules are applied to decode the binary content in the BLE broadcast data of the target Bluetooth headsets to obtain the device identifier or status information.

6. The method for detecting privacy leaks and security vulnerabilities in multi-mode Bluetooth headsets according to claim 1, characterized in that, The security vulnerabilities include privacy data leakage vulnerabilities. Accordingly, determining whether the at least one target Bluetooth headset has a predefined type of security vulnerability includes: The extracted data parsing rules are applied to decode the binary content in the captured BLE broadcast data; Check whether the decoded information string contains the classic Bluetooth media access control address or user account identifier of the target Bluetooth headset; If the aforementioned classic Bluetooth media access control address or user account identifier exists, a privacy data leakage vulnerability is identified.

7. The method for detecting privacy leaks and security vulnerabilities in multi-mode Bluetooth headsets according to claim 1, characterized in that, The security vulnerability includes a weak pairing authentication vulnerability. Correspondingly, determining whether the at least one target Bluetooth headset has a predefined type of security vulnerability includes: Confirm that the target Bluetooth headset is not in discoverable mode in classic Bluetooth mode; Construct and send a standard Bluetooth pairing request to the classic Bluetooth Media Access Control address of the target Bluetooth headset; Listen for feedback information from the system's Bluetooth management interface; If the feedback information indicates that the pairing was successful, it is determined that there is a weak authentication vulnerability in the pairing process.

8. The method for detecting privacy leaks and security vulnerabilities in multi-mode Bluetooth headsets according to claim 1, characterized in that, The security vulnerability includes an application-layer unauthenticated communication vulnerability. Correspondingly, determining whether the at least one target Bluetooth headset has a predefined type of security vulnerability includes: Connect to the control service port of the target Bluetooth headset via Bluetooth communication protocol; Select a control instruction from the constructed private protocol dictionary; The control command is sent to the target Bluetooth headset through the control service port; Listen to the status feedback signal of the target Bluetooth headset or parse the data packets it returns; If the status feedback signal or the returned data packet confirms that the control command has been executed, it is determined that there is an application-layer unauthenticated communication vulnerability.

9. A device for detecting privacy leaks and security vulnerabilities in multi-mode Bluetooth headsets, characterized in that, include: The detection rule extraction module is used to dynamically analyze the accompanying application of the target Bluetooth headset, extract the rules used by the application to identify and parse Bluetooth Low Energy (BLE) broadcast messages, and construct a Bluetooth private protocol dictionary for controlling the headset. The device discovery and information collection module is used to scan the surrounding wireless communication environment, capture and parse BLE broadcast messages and classic Bluetooth device information from at least one target Bluetooth headset; The vulnerability assessment module is used to automatically analyze the collected device information and communication data based on the extracted rules and the constructed private protocol dictionary, and to determine whether the at least one target Bluetooth headset has a predefined type of security vulnerability.

10. An electronic device, characterized in that, It includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the method as described in any one of claims 1 to 8.

Images