A black box detection method, system and medium based on a car built-in browser vulnerability

Abstract

The present application relates to the field of computer network security, and particularly relates to a black box detection method and system based on a built-in browser vulnerability of a car and a medium, through non-invasive network data acquisition, zero-interference detection of the car machine is realized, the integrity and security of the measured device are ensured. Secondly, the core dual-path identification and intelligent fusion mechanism, through the combination of direct identification of the user agent field and indirect inference of the network request behavior characteristics, and after strict verification and fusion, the inherent defects of the single information source are overcome, and the final output target browser kernel version information has high accuracy and robustness. Furthermore, the method constructs a complete closed loop from accurate identification to empirical verification, by injecting the accurately matched exploit code into the car machine and monitoring its real reaction, the vulnerability detection is improved from theoretical risk prompt to empirical confirmation level, greatly improving the authority and decision value of the detection result.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computer network security, in particular to a black box detection method and system based on a built-in browser vulnerability of a vehicle and a medium. BACKGROUND

[0002] With the popularization of intelligent and connected vehicles, the car machine (infotainment system) and its built-in browser kernel, such as the WebView component, have become a key human-computer interaction entrance, and its security is crucial. Once an attacker exploits a known vulnerability in the browser kernel, such as CVE, it may use it as a stepping stone to threaten vehicle security. Currently, the technical means in the industry to solve this problem mainly include the following two types.

[0003] Based on the static version management and its defects of the software bill of materials, the existing technical solution: the vehicle enterprise confirms the version of the browser kernel integrated at the system level of the car machine during the vehicle research and development or maintenance stage through the management of the software bill of materials (SBOM), and compares it with the public vulnerability database, such as the CVE database, to identify potential risks. First, the detection coverage is insufficient. This method cannot effectively cover the different versions of the browser kernel privately integrated by third-party applications in the car machine. These third-party applications constitute a blind spot for the security management of the vehicle enterprise and introduce uncontrollable risks. Second, it lacks empirical verification capability. This method can only make theoretical vulnerability correlation, and it is difficult to verify whether the vulnerability can be successfully exploited in the real car machine software and hardware environment, which may lead to false positives or false negatives, reducing the reliability of the detection results.

[0004] Based on the black box testing method and its defects of single-dimensional identification, the existing technical solution: some black box detection schemes attempt to identify the browser version through network traffic analysis, for example, relying on parsing the User-Agent (User Agent) string in the HTTP request as the only source of version information, and conducting subsequent testing accordingly. Technical defects: first, the version identification reliability is low. The User-Agent string may be tampered with, generalized, or provide incomplete information, leading to version identification errors, making all subsequent vulnerability tests lose accuracy. Second, it is difficult to cope with complex software environments. In modern car machines, system applications and multiple third-party applications may coexist, and they may use the same or different browser kernels. The existing method lacks effective means to automatically discover, distinguish, and establish independent vulnerability archives for these different application instances, leading to mixed test results and making it difficult to accurately locate the specific application with vulnerabilities. At the same time, for the same car machine of a vehicle enterprise caused by gray release and other means, accessing different interface paths, the existing method also has difficulty in effectively distinguishing and accurately identifying. SUMMARY

[0005] In order to solve one or more problems in the prior art, the main objective of this application is to provide a black-box detection method, system and medium based on vulnerabilities in automotive built-in browsers.

[0006] To achieve the aforementioned objectives, this application proposes a black-box detection method based on vulnerabilities in automotive built-in browsers, the method comprising:

[0007] Acquire network communication data sent by the vehicle's infotainment system;

[0008] From the network communication data, the user agent field and network request behavior characteristics are parsed out, wherein the network request behavior characteristics include the server address or interface accessed by the vehicle system that can characterize the vehicle model or software characteristics.

[0009] Based on the user agent field, obtain the first browser kernel version information;

[0010] Based on the network request behavior characteristics, a preset vehicle model behavior feature mapping library is queried to determine the vehicle model information corresponding to the vehicle system, and combined with the vehicle model browser version mapping library, the second browser kernel version information is obtained;

[0011] The first browser kernel version information and the second browser kernel version information are verified and fused to obtain the final target browser kernel version information;

[0012] Based on the target browser kernel version information, at least one proof-of-concept exploit code is matched from the vulnerability database.

[0013] Based on the target browser kernel version information and the matching proof-of-concept exploit code, a vulnerability test is performed on the vehicle infotainment system.

[0014] By monitoring the vehicle's infotainment system's operating status during the testing process, it can be determined whether the browser kernel corresponding to the target browser kernel version information has any corresponding security vulnerabilities.

[0015] This application also provides a black-box detection system based on vulnerabilities in automotive built-in browsers, including:

[0016] The first acquisition module is used to acquire network communication data sent by the vehicle's infotainment system;

[0017] The parsing module is used to parse the user agent field and network request behavior characteristics from the network communication data, wherein the network request behavior characteristics include the server address or interface accessed by the vehicle system that can characterize the vehicle model or software characteristics.

[0018] The second acquisition module is used to obtain the first browser kernel version information based on the user agent field;

[0019] The query module is used to query a preset vehicle model behavior feature mapping library based on the network request behavior characteristics, determine the vehicle model information corresponding to the vehicle system, and obtain the second browser kernel version information by combining the vehicle model browser version mapping library.

[0020] The verification and fusion module is used to verify and fuse the first browser kernel version information and the second browser kernel version information to obtain the final target browser kernel version information.

[0021] The matching module is used to match at least one proof-of-concept exploit code from the vulnerability database based on the target browser kernel version information.

[0022] The execution module is used to perform vulnerability testing on the vehicle system based on the target browser kernel version information and the matching proof-of-concept exploit code;

[0023] The determination module is used to determine whether there is a corresponding security vulnerability in the browser kernel corresponding to the target browser kernel version information by monitoring the operating status of the vehicle system during the test.

[0024] This application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of any of the methods described above.

[0025] This application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of any of the methods described above.

[0026] The black-box detection method, system, and medium based on vulnerabilities in automotive built-in browsers presented in this application achieve zero-interference detection of in-vehicle systems through non-intrusive network data acquisition, ensuring the integrity and security of the tested device and possessing excellent versatility and operability. Secondly, its core dual-path recognition and intelligent fusion mechanism overcomes the inherent unreliability of single information sources by combining direct recognition of user agent fields with indirect inference of network request behavior characteristics, and through rigorous verification and fusion. The final output of the target browser kernel version information has extremely high accuracy and robustness, laying a reliable foundation for subsequent testing. Furthermore, this method constructs a complete closed loop from accurate identification to empirical verification. By injecting precisely matched vulnerability exploit code into the in-vehicle system and monitoring its actual response, vulnerability detection is elevated from theoretical risk warning to empirical confirmation, greatly enhancing the authority and decision-making value of the detection results. In summary, this method solves the core pain points of existing technologies, such as incomplete detection coverage, low identification reliability, and lack of empirical verification capabilities, achieving highly reliable, highly accurate, and highly efficient integrated black-box security detection. Attached Figure Description

[0027] Figure 1 This is a flowchart illustrating a black-box detection method based on a vulnerability in a car's built-in browser, according to an embodiment of this application.

[0028] Figure 2 This is a flowchart illustrating a black-box detection method based on a vulnerability in a car's built-in browser, according to an embodiment of this application.

[0029] Figure 3 This is a schematic block diagram of the structure of a black-box detection system based on a vulnerability in a car's built-in browser, according to an embodiment of this application.

[0030] Figure 4 This is a schematic block diagram of the structure of a computer device according to an embodiment of this application.

[0031] The realization of the purpose, functional features and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0032] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of this application and are not intended to limit the scope of this application. All version numbers, domain names, and network addresses mentioned herein are exemplary descriptions used only to illustrate technical solutions and do not refer to any actual software version or network service.

[0033] Reference Figure 1 This application provides a black-box detection method based on vulnerabilities in a car's built-in browser, the method comprising:

[0034] S1. Obtain network communication data sent by the vehicle's infotainment system;

[0035] S2. Parse the user agent field and network request behavior characteristics from the network communication data, wherein the network request behavior characteristics include the server address or interface accessed by the vehicle system that can characterize the vehicle model or software characteristics.

[0036] S3. Obtain the first browser kernel version information based on the user agent field;

[0037] S4. Based on the network request behavior characteristics, query the preset vehicle model behavior feature mapping library to determine the vehicle model information corresponding to the vehicle system, and combine it with the vehicle model browser version mapping library to obtain the second browser kernel version information;

[0038] S5. Verify and merge the first browser kernel version information and the second browser kernel version information to obtain the final target browser kernel version information.

[0039] S6. Based on the target browser kernel version information, match at least one corresponding proof-of-concept vulnerability exploit code from the vulnerability database;

[0040] S7. Based on the target browser kernel version information and the matching proof-of-concept exploit code, perform vulnerability testing on the vehicle infotainment system;

[0041] S8. By monitoring the operating status of the vehicle system during the test, determine whether there is a corresponding security vulnerability in the browser kernel corresponding to the target browser kernel version information.

[0042] As described in steps S1-S4 above, step 1 forms the data foundation for all subsequent analyses. Based on the principle of black-box testing, no agent needs to be installed inside the vehicle's infotainment system or system permissions need to be obtained. Instead, all data packets generated by the vehicle's infotainment system when communicating with external servers are passively received or captured through network monitoring or gateway forwarding. This achieves non-intrusive detection, has strong versatility, and is applicable to vehicles in multiple stages such as R&D, production, and after-sales service, without causing any impact on the vehicle's infotainment system itself. Step 2 is crucial for information extraction. It identifies and separates two types of "fingerprints" with different characteristics from the raw network traffic: User Agent field: an explicit identity identifier that identifies the software itself; Network request behavior characteristics: implicit behavioral habits revealed by the device during operation. This lays the data foundation for subsequent "dual-path identification." By combining explicit declarations and implicit behaviors, it prepares for overcoming the unreliability of a single information source. Step 3 is the first fast identification path. It directly parses the browser type and version information contained in the User-Agent string, which is a direct and efficient identification method. This allows for the rapid acquisition of a preliminary hypothesis about the browser kernel version, providing an efficient initial target for subsequent detection. Step 4 is the second robust identification path and one of the core innovations of this invention. It does not rely on the software's self-description but rather infers its identity through its behavior, such as accessing specific car manufacturers' cloud services and map interfaces. This relies on a pre-built knowledge base constructed through extensive data analysis, including a car model-behavioral feature mapping library and a car model-browser version mapping library. This provides a version information source independent of and often more reliable than the User-Agent. Even if the User-Agent is tampered with or incomplete, this method can still infer the true software environment from the vehicle's inherent behavior, greatly improving the anti-interference capability and accuracy of the identification.

[0043] As described in steps S5-S8 above, step 5 is the decision-making center. It doesn't simply choose one source, but intelligently verifies both through a set of rules. When the information is consistent, the result is highly reliable; when the information conflicts, uncertainties are resolved through preset strategies, such as prioritizing the adoption of behavioral characteristics to infer results or expanding the testing scope. It combines the advantages of both information sources, overcomes their respective disadvantages, and ultimately outputs a higher-quality, more reliable "target browser kernel version information," providing a reliable target for accurate vulnerability testing. Step 6 is "ammunition preparation." The accurate version information obtained in the previous steps is correlated with known vulnerability databases, such as the CVE database, to filter out all exploit code applicable to that specific version. This avoids blindly testing all vulnerabilities. Steps 7 and 8 form a closed loop of "empirical verification." Using techniques such as DNS spoofing and traffic hijacking, the POC code is delivered to the vehicle's browser and triggered for execution. The actual reaction of the vehicle's infotainment system, such as application crashes or system restarts, is then observed to ultimately determine whether a vulnerability exists. This elevates vulnerability detection from the theoretical risk analysis level to the practical verification level. It doesn't provide a "potential" warning, but a "confirmed" conclusion, making the detection results authoritative and reliable, offering automakers clear remediation guidelines. It boasts a complete and autonomous technical system, from "multi-source information collection" to "intelligent fusion decision-making" and "precise empirical verification." It introduces the new dimension of "network request behavior characteristics" into the field of black-box detection and combines it with the traditional User-Agent identification path, using a dedicated "verification and fusion" module for intelligent decision-making. This addresses the shortcomings of "low reliability of version identification" and "lack of empirical verification" pointed out in the background technology. It makes reliable and accurate vulnerability verification possible in complex, uncontrolled real-world in-vehicle environments.

[0044] As mentioned above, non-intrusive network data acquisition enables zero-interference detection of the vehicle's infotainment system, ensuring the integrity and security of the tested device and demonstrating excellent versatility and operability. Secondly, its core dual-path recognition and intelligent fusion mechanism overcomes the inherent unreliability of single information sources by combining direct recognition of user agent fields with indirect inference from network request behavior characteristics, and through rigorous verification and fusion. The final output of the target browser kernel version information exhibits extremely high accuracy and robustness, laying a reliable foundation for subsequent testing. Furthermore, this method constructs a complete closed loop from accurate identification to empirical verification. By injecting precisely matched vulnerability exploit code into the vehicle's infotainment system and monitoring its actual response, vulnerability detection is elevated from theoretical risk warnings to empirical confirmation, greatly enhancing the authority and decision-making value of the detection results. In summary, this method addresses the core pain points of existing technologies, such as incomplete detection coverage, low identification reliability, and lack of empirical verification capabilities, achieving highly reliable, highly accurate, and highly efficient integrated black-box security detection.

[0045] In one specific embodiment, suppose a security team needs to conduct a security assessment of a newly mass-produced smart car. The vehicle's infotainment system comes pre-installed with a WebView component based on a newer browser kernel, such as kernel M. However, the user has installed a third-party media app from their app store. This app integrates an older browser kernel, such as kernel N, which has known high-risk vulnerabilities. Data Acquisition and Analysis: The team sets up a test hotspot to induce the vehicle's infotainment system to connect. During operations on the infotainment system—i.e., clicking the system user agreement, using built-in applications, and launching the third-party media app—all network traffic is captured. Dual-Path Identification: Two different UserAgents are parsed from the traffic, corresponding to "kernel M" and "kernel N" respectively, yielding the first version information. Simultaneously, analysis reveals that the infotainment system consistently accesses the vehicle manufacturer's service platform interface and a third-party media content distribution network. After querying the behavioral feature mapping library, it is confirmed that the former is a vehicle-specific interface, typically using kernel M; the latter is associated with kernel N, thus obtaining the second version information. Intelligent Fusion: The system detects two information sources pointing to different versions. Based on preset rules, it identifies them as two distinct application instances. The system application and the third-party media app each establish independent target browser kernel version files. Precise Testing and Verification: The system matches and loads corresponding Proof-of-Concept (POC) code from the vulnerability database for both kernel M and kernel N files. Through DNS spoofing, requests from the vehicle's infotainment system to the third-party media service domain are hijacked to a test server containing a kernel N vulnerability POC. Testers observed that the media app crashed immediately after loading the page, thus empirically confirming the existence of a high-risk vulnerability in the third-party app's built-in kernel N, while the system's built-in WebView functioned normally. It is worth noting that all version numbers, domain names, and network addresses mentioned in this article are illustrative and used only to illustrate the technical solution; they do not refer to any actual software version or network service.

[0046] Reference Figure 2 In one embodiment, the step of performing vulnerability testing on the vehicle-mounted system based on the target browser kernel version information and the matching proof-of-concept exploit code further includes security test control, the steps of which include:

[0047] S71. Analyze the vulnerability type in the proof-of-concept exploit code;

[0048] S72. Based on the vulnerability type of the proof-of-concept exploit code, determine the test risk level of the proof-of-concept exploit code, wherein the test risk level includes high risk and standard risk;

[0049] S73. If the test risk level is high risk, a network access rule is injected into the test environment before the test is executed. The rule is configured to forcibly block all network access of the vehicle system within a preset time threshold after the test starts.

[0050] S74. If the test risk level is standard risk, then the vulnerability test shall be performed directly.

[0051] S75. If a persistent system failure is detected in the vehicle infotainment system after the test is performed, an emergency recovery mechanism is triggered. The emergency recovery mechanism includes guiding the vehicle infotainment system to perform a power-off and restart operation.

[0052] As described in the steps above, the system does not blindly execute all Proof-of-Concept (POCs) before performing tests; instead, it analyzes them first. Vulnerability types can be categorized based on their potential impact. For example, a vulnerability that could lead to Remote Code Execution (RCE) is fundamentally different from a logic vulnerability that only causes abnormal UI rendering.

[0053] This approach achieves proactive understanding of testing behavior, upgrading "testing" from a simple execution action to an intelligent process including "pre-analysis," providing a basis for subsequent risk classification and control. Step 2 involves risk quantification and decision-making. Based on the analysis results of Step 1, and according to preset rules, such as: any vulnerability that could potentially gain system control or cause system-level collapse is considered "high-risk," each Proof of Concept (POC) is assigned a clear risk level label. The vague concept of "danger" is transformed into clear, programmable discrete decision variables, such as high-risk / standard-risk, allowing subsequent testing processes to branch based on these variables, achieving differentiated resource scheduling and security policy deployment. Steps 3 and 4 involve differentiated security policy execution. For high-risk testing, anticipating that attackers might establish remote control connections with the vehicle's infotainment system or leak data after successful vulnerability exploitation, their network access is proactively and temporarily cut off, forming a "circuit breaker" mechanism. For standard-risk testing, this additional overhead is unnecessary. This ensures that even in the worst-case scenario, if a vulnerability is successfully exploited, its harm is limited to the local area, preventing the formation of a sustained remote attack chain. This achieves the precise control effect of "verifying the existence of vulnerabilities while proactively curbing their potential harm." Step 5 is the final safety fallback. It acknowledges that any test carries unexpected risks and presupposes that if the vehicle's software completely fails and becomes "bricked," the only reliable recovery method is to reset the entire system through a hardware-level power cycle and restart. This gives the entire testing scheme "fault tolerance," ensuring that even if the test causes a severe system crash, there are clear and effective means to restore it. This fundamentally eliminates the biggest concern about conducting destructive testing on real, valuable assets like automobiles, giving the entire method extremely high practical feasibility.

[0054] In one embodiment, the step of verifying and fusing the first browser kernel version information and the second browser kernel version information includes:

[0055] Analyze the kernel version information of the first browser and the kernel version information of the second browser;

[0056] If the version number indicated by the first browser kernel version information is exactly the same as that indicated by the second browser kernel version information, then the version number is output as the target browser kernel version information;

[0057] Otherwise, if the first browser kernel version information is a version range and the second browser kernel version information is a specific version falling within that range, then the second browser kernel version information is output.

[0058] Otherwise, if the version numbers indicated by the kernel version information of the first browser and the second browser are adjacent, a test version range containing these two adjacent versions and all versions in between is output as the target browser kernel version information.

[0059] As mentioned above, Step 1 is the data preparation stage for fusion decision-making. It standardizes and analyzes the information obtained from two independent paths, namely User-Agent and behavioral features, ensuring that the two are comparable. For example, it unifies the version number format and identifies the differences between version range and specific version. This forms the basis for ensuring that intelligent verification can be executed accurately. Step 2 is the fast path in the ideal case. When the two independent technical paths reach completely consistent conclusions, the results have a very high confidence level. At this time, the system does not need complex calculations and directly adopts the consensus. The highest decision-making efficiency is achieved when the information is consistent, avoiding unnecessary computational overhead and quickly outputting the most reliable results. Step 3 resolves the conflict between "fuzzy and precise". User-Agent can sometimes only provide a generalized version range, such as "Chrome / 90", while the behavioral feature library can infer the specific version based on its prior knowledge, such as "Chrome / 90.0.4430.91". The principle of this rule is: when fuzzy information includes precise information and the two are not contradictory, precise information is adopted first. By narrowing a vague target, such as the entire Chrome 90 version, to a specific target, such as 90.0.4430.91, subsequent vulnerability matching becomes more targeted, avoiding a large number of ineffective tests within a vague range. Step 4 addresses the uncertainty of "minor differences." When the specific version numbers obtained from two information sources are very close, such as 90.0.4430.90 and 90.0.4430.91, this usually stems from minor errors in data collection, while the actual version of the vehicle's infotainment system is likely between these two adjacent versions. The principle of this rule is: instead of arbitrarily choosing one, it trades a controllable increase in testing resources for a significant improvement in detection coverage, proactively transforming uncertainty into a deterministic testing strategy. This is a highly fault-tolerant and safeguarding mechanism. It effectively prevents vulnerabilities from being missed due to minor deviations in version information, ensuring the rigor and high coverage of the detection. This is an intelligent trade-off between "efficiency" and "completeness," reflecting the robustness of the system. In this embodiment, the abstract concept of "verification and fusion" is concretized into a set of hierarchical, logically rigorous, and intelligent conflict resolution rules. The core value of these rules lies in their ability to handle information uncertainty. Instead of a simple "either / or" choice, they intelligently adopt different strategies based on the nature of the conflict—whether it's "fuzzy vs. precise" or "minor differences": either converging and focusing to improve efficiency or expanding the scope to ensure completeness. This design makes the entire version recognition system no longer fragile, but possesses strong adaptability and fault tolerance.

[0060] In one embodiment, the method further includes:

[0061] In the step of parsing the user agent field from the network communication data, each parsed user agent field, as well as the source IP address and target server address of the HTTP request containing the user agent field, are further recorded.

[0062] The user agent field, source IP address, and target server address are associated and bound to form an application feature association group;

[0063] Based on the application feature association group, separate browser kernel version files are created for different applications or service modules in the vehicle system.

[0064] In the step of matching at least one proof-of-concept exploit code from the vulnerability database based on the target browser kernel version information, the corresponding proof-of-concept exploit code is further matched for each application or service module according to the independent browser kernel version file, and vulnerability testing is performed on each module.

[0065] As mentioned above, Step 1 is refined data collection. It not only identifies "what" the traffic is (UserAgent), but also precisely records "where it came from" (source IP address) and "where it's going" (target server address). This triplet information constitutes the core identity feature of a network session. This ensures that each UserAgent is placed within the network context in which it originated, rather than being an isolated string, laying the foundation for accurate profiling. Step 2 is application entity profiling. It proactively binds the discrete data elements collected in Step 1 logically. Its core principle is that within a specific time window, traffic originating from the same source IP and pointing to a set of stable target servers, with the same or similar UserAgent, has a very high probability of belonging to the same application instance. This generates a more identifiable "application digital fingerprint," an application feature association group, than a single UserAgent. This allows the system to clearly divide mixed network traffic into different data streams, each representing an independent application or service module. Step 3 is personalized modeling. It creates a separate version management unit, or archive, for each "application feature association group" identified in Step 2, i.e., each application entity. This means that the system recognizes the in-vehicle infotainment system as a complex ecosystem composed of multiple independent software entities. This represents a qualitative shift in the detection target from "the entire in-vehicle infotainment system" to "every application within the in-vehicle infotainment system." This solves the version pollution problem in mixed environments, clearly showing that the system's built-in weather application uses Chrome 91, while the user-installed music application uses Chrome 85. Step 4 is precise test execution. It utilizes the refined profile established in Step 3 to guide subsequent test resource allocation. Its principle is "whoever has the vulnerability, tests it," matching each application profile with its own POC code corresponding to its browser kernel version and performing isolated testing. This achieves a "precision strike" testing strategy. This avoids using a system-level WebView vulnerability POC to test a third-party application using an outdated kernel, resulting in ineffective testing, and also avoids the entire system's WebView being misjudged and falsely reported due to vulnerabilities in third-party applications. The final result is that the detection report clearly identifies the specific application name and version of the existing vulnerability. In this embodiment, by introducing the concept of "application feature association groups," a precise deconstruction and modeling of the complex software ecosystem within the in-vehicle infotainment system is achieved. It elevates the perspective of black-box detection from a chaotic "black box" to a clearly structured "internal microservice architecture." This design addresses the core deficiency of the background technology: "difficulty in coping with complex software environments." It enables this invention to automatically discover and differentiate multiple browser kernel instances coexisting in the vehicle's infotainment system, especially third-party applications that are difficult for automakers to manage, and provides independent, customized vulnerability detection services for each instance.

[0066] In one embodiment, the method further includes the step of querying a preset vehicle model behavior feature mapping library based on the network request behavior characteristics to determine the vehicle model information corresponding to the vehicle system, and obtaining the second browser kernel version information by combining the vehicle model browser version mapping library:

[0067] From the network request behavior characteristics, the target server domain name accessed by the vehicle system is parsed out, and the specific application layer interface path or request parameters accessed under that domain name are further extracted.

[0068] The resolved target server domain name is combined with a specific application layer interface path or request parameter to form a fine-grained combined behavioral feature.

[0069] Based on the fine-grained combined behavioral features, the vehicle behavior feature mapping library is queried to obtain more accurate vehicle and software environment information, and then the second browser kernel version information is obtained from the vehicle browser version mapping library.

[0070] As mentioned above, Step 1 is the in-depth mining of behavioral features. It goes beyond simply using "accessing a car manufacturer's cloud platform, such as a domain name" as a behavioral feature; it delves into the cloud platform itself to analyze which API endpoint the vehicle's infotainment system is communicating with or what identity it is carrying. The principle is that under the same cloud service, different versions of the vehicle's infotainment software may be assigned to access different interfaces or use different parameters. This yields more refined and discriminative behavioral data. This is equivalent to going beyond simply "seeing someone enter a library, domain name," and further "seeing which specific bookshelf they are browsing, interface path," providing richer contextual information for accurate identification. Step 2 is high-resolution feature construction. It combines the multiple elements parsed in Step 1, such as domain name, path, and parameters, into a new, higher-dimensional feature identifier. The principle is that the combination of "domain name + path / parameter" can express far more software behavioral information than a single domain name. For example, api.auto.com / v1 / data and api.auto.com / v2 / data represent different software versions or service packages. This creates a key feature with stronger uniqueness and higher resistance to obfuscation. This allows each record in the behavioral feature database to be mapped more accurately to a specific software environment, greatly reducing the identification ambiguity caused by the vehicle's infotainment system accessing the same cloud platform but using different services. Step 3 is precise matching and inference. It uses the "combined behavioral features" constructed in Step 2 as the query key to retrieve the preset mapping database. The principle is that this mapping database is built using prior knowledge, such as test data and cloud configuration information, recording "which combined features correspond to which vehicle model and which software version". Through this precise matching, a more definite conclusion about the vehicle's infotainment system software environment can be drawn. Finally, a significantly improved "second browser kernel version information" is output. This makes the inference result based on behavioral features no longer "the range of versions that the vehicle model may use", but "the precise version used by the vehicle model under this specific software configuration". This directly elevates the reliability and value of the second identification path to a whole new level. In this embodiment, by improving the resolution of behavioral features, the cutting-edge and challenging problem of version identification ambiguity caused by modern software deployment, especially gray-scale releases, A / B testing, and incremental updates, is solved. This invention advances the understanding of behavioral characteristics from the level of "who you are communicating with, domain name" to the level of "how you are communicating with it, interface / parameters." This deepening allows the invention to gain insight into the differentiated software strategies behind unified cloud services, targeting different user groups or different versions of in-vehicle systems. It ensures that even in the complex software environments created by automakers employing agile development and cloud control technologies, the invention can accurately capture the unique "behavioral DNA" of the in-vehicle system and output highly reliable version identification results.

[0071] In one embodiment, the step of establishing independent browser kernel version files for different applications or service modules within the vehicle infotainment system based on the application feature association group includes:

[0072] For each application or service module that has been initially classified by the application feature association group, continuously capture and record the sequence of network requests initiated by it within a preset time period;

[0073] Based on the captured network request sequence, the network request sequence is analyzed to extract its sequence pattern features, and an application instance behavior fingerprint is generated based on these features. The sequence pattern features include: the time interval distribution pattern between consecutive requests, the fixed access order to multiple target server addresses, and the variation pattern of payload length in periodic requests.

[0074] Compare the behavioral fingerprints of all the constructed application instances;

[0075] If two network flows are found to have the same user agent field and target server address binding relationship, but their application instance behavior fingerprints are inconsistent, then they are determined to belong to different application instances.

[0076] Based on the results of the determination, a separate browser kernel version file is created for each instance.

[0077] As mentioned above, Step 1 is dynamic behavioral data collection. Recognizing that static characteristics of a single request, such as UA, IP, and domain name, are insufficient to handle advanced obfuscation scenarios, it continuously monitors initially categorized applications, recording their network activities in chronological order to form behavioral sequence data. This provides a temporal data foundation for in-depth behavioral analysis, transforming the analysis object from a static "snapshot" into a dynamic "behavioral video," creating conditions for identifying more stable behavioral patterns. Step 2 is in-depth behavioral pattern mining. It extracts sequence pattern features from simple request sequences that characterize the application's internal logic and implementation: Time interval distribution patterns reflect the application's internal timers, heartbeat mechanisms, or user interaction response logic. Fixed access order reveals the fixed workflow of application initialization, data retrieval, etc. Payload length variation patterns reflect the inherent characteristics of the application when transmitting different types of data, such as key exchange, audio / video streams, and control commands. This generates a difficult-to-forge, deep "application instance behavioral fingerprint." This fingerprint, based on the application's unconscious behavioral habits during runtime, has higher uniqueness and tamper resistance compared to static identifiers such as UA. Steps 3 and 4 involve intelligent identity disambiguation. The core principle is that even if two network flows are identical in static identifiers, if their inherent, long-term behavioral patterns show statistically significant differences, they must belong to two different software entity instances. This is an identity authentication based on "behavioral DNA." It effectively identifies advanced obfuscation techniques such as application cloning and dynamic spoofing. It can penetrate surface consistency to discern essential differences, solving the identity spoofing problem that static binding relationships may not be able to handle. Step 5 is refined file management. The identity disambiguation results are then implemented by creating a unique version file for each identified independent application instance. This achieves precise instance-level control. It ensures that even when faced with identical application copies, the system can distinguish them and independently manage the browser kernel version and vulnerability testing strategy for each instance, achieving unprecedented granularity in black-box detection. In this embodiment, application identification technology is elevated from "facial recognition" relying on static identifiers to a new level of "gait recognition" relying on dynamic behavioral patterns. It creatively introduces the concept of "application instance behavior fingerprint," which effectively solves the problem of identity spoofing and instance confusion that may occur in complex software environments by analyzing the deep features of the sequence patterns of network requests.

[0078] In one embodiment, the step of creating a separate browser kernel version file for each instance includes:

[0079] Analyze the transport layer and network layer protocol behavior of network flows generated by different application instances;

[0080] Based on the aforementioned protocol behavior, a process-level network fingerprint is generated to distinguish different host processes. The protocol behavior includes: the coordinated change pattern of the initial window size and timestamp sequence during TCP connection establishment; and the recursive pattern of the IP packet identifier field in continuous data streams.

[0081] The process-level network fingerprint is mapped to the specific active processes in the vehicle's operating system;

[0082] Based on the mapped process identity and its functional role, test priorities are assigned to the corresponding browser kernel version files.

[0083] As described above, Step 1 moves the analysis dimension down from the application layer to the underlying network protocol stack. It recognizes that different processes, due to subtle differences in their runtime environment, library versions, and even operating system scheduling policies, leave unique "marks" on the TCP / IP protocol implementation. These underlying protocol behaviors are handled by the operating system kernel and network stack, and are transparent and difficult to tamper with for upper-layer applications. This yields an analytical dimension that is independent of application-layer data, highly stable, and unique. This makes differentiation at the operating system process level possible, overcoming the limitation that application-layer information can be forged. Step 2 constructs an operating system-level identity. It utilizes the underlying behaviors analyzed in Step 1 to extract key features to form a "process-level network fingerprint": the coordinated change pattern of the TCP initial window size and timestamp sequence. This pattern is determined by the specific implementation and configuration of the operating system's TCP / IP protocol stack; different processes, especially those with different library versions or different priorities, may exhibit distinguishable patterns when establishing connections. The recursive pattern of the IP identifier field: IP IDs are assigned by the operating system kernel, and their incrementing sequence, such as linear incrementing or randomization, may exhibit identifiable patterns under different processes or different system loads, serving as "micro-features" of the device. This generates a highly unique process identifier that is almost impossible for application-layer software to forge. This allows the system to distinguish network flows that share the same set of application-layer characteristics, such as UA and target address, but actually belong to different processes. Step 3 is to associate network identity with system entities. By matching the "process-level network fingerprint" observed on the network side with the process list obtained in the vehicle's operating system through specific means, such as bypass analysis, active probing, or comparison with a known fingerprint database, a specific process identity is assigned to the abstract fingerprint, for example, com.auto.infotainment.renderer. This achieves precise tracing from network behavior to system entities. It answers the key question, "Which specific process in the vehicle's system generated this network traffic?" refining the detection granularity from "application" to "process". Step 4 is intelligent resource scheduling and risk focusing. It recognizes that the security importance of different processes varies. For example, if the main rendering process responsible for rendering the user interface is compromised, the damage is far greater than that of an auxiliary process responsible for network downloads. Therefore, testing priorities are assigned to the corresponding version files based on the role of the process. This achieves optimal allocation of testing resources. It prioritizes limited testing time and computing resources to the most critical and highest-risk attack surfaces, ensuring the rapid discovery of vulnerabilities that may cause the most serious impact, thereby greatly improving the efficiency and practical value of the overall detection strategy. In this embodiment, by mining the underlying behavioral characteristics of the operating system's network stack, the limitation of not being able to directly obtain process information in black-box testing is cleverly overcome, achieving insight into the micro-architecture of the vehicle's internal software.This not only effectively distinguishes different process instances under the same application, but more importantly, it introduces a risk assessment model based on process functional roles, enabling the entire vulnerability detection system to intelligently determine the "value target" of the attack and prioritize its verification.

[0084] In one feasible embodiment, after the step of obtaining the final target browser kernel version information and before the step of matching proof-of-concept exploit code from a vulnerability database, the method further includes:

[0085] When the target browser kernel version information is a test version range, or multiple independent browser kernel version files;

[0086] The scope of the vulnerability database corresponding to the target browser kernel version information is expanded to cover all versions within that version range, or the set of vulnerabilities known for all versions corresponding to the independent files.

[0087] Based on the process identity and functional role associated with the browser kernel version file, a testing priority is assigned to each vulnerability in the vulnerability set, and the final testing queue is formed according to the priority.

[0088] As mentioned above, Step 1 is the trigger condition judgment for scope expansion. It identifies two uncertainty scenarios that require special handling: one is that there is a slight ambiguity in the version number, generated by the adjacent version rule; the other is that there are multiple independent software entities in the system that need to be tested, generated by the application differentiation mechanism. This achieves systematic identification of testing uncertainty scenarios, providing clear decision signals for subsequent intelligent expansion, ensuring that the mechanism is activated only when necessary, and avoiding unnecessary resource waste. Step 2 is the test completeness guarantee mechanism. Its core principle is: to ensure no missed detections, when there is uncertainty in the target version, the best strategy is to cover all possible versions of the test scope at the cost of controllable resource growth. It actively transforms a single test target into a definite test set, transforming "version uncertainty" into "test determinism." It ensures the rigor and high coverage of the detection, fundamentally preventing missed vulnerabilities caused by ambiguous version information, making the final detection conclusion more authoritative. Step 3 is the intelligent scheduling optimization of large-scale test tasks. When the test set becomes larger due to expansion, the direct challenge is the issue of testing efficiency. This step utilizes the deep information of "process identity and functional role" established by weight 7 to assign a risk weight to each vulnerability in the set. The principle is that a vulnerability in the main rendering process of the vehicle's infotainment system has a far greater potential harm and testing urgency than the same vulnerability in a background auxiliary process. This achieves optimal allocation of testing resources. It enables the system to "test the most important first, then the less important," ensuring the fastest discovery of the highest-risk vulnerabilities. This maintains extremely high detection efficiency even with an expanded testing scope, achieving a clever balance of "ensuring completeness without sacrificing efficiency." In this embodiment, an inevitable derivative problem in a refined, multi-layered detection system is solved—how to systematically handle "uncertainty" and maintain "high efficiency." It is not an independent function, but rather acts as a "scheduling optimizer" for the entire detection system, intelligently transforming various outputs from previous identification steps, such as precise versions, version ranges, and multiple files, into an optimal test plan that is comprehensive and risk-ordered.

[0089] In one specific embodiment, suppose a security team is conducting black-box security testing on a new type of intelligent connected vehicle. The vehicle's infotainment system environment is complex; its built-in applications use a newer version of the browser kernel, such as kernel A, while a third-party video application installed by the user integrates an older version of the browser kernel, such as kernel B, which contains known high-risk vulnerabilities. The testing process is as follows:

[0090] Network traffic capture and feature extraction

[0091] The testing equipment is set up to detect network access to the vehicle's infotainment system. When testers operate the vehicle's infotainment system and trigger system applications, such as viewing user agreements, accessing weather services, and third-party video applications, generating network traffic, the testing system captures this communication data.

[0092] Through analysis, the system identified two main types of "fingerprints" in the network traffic: one type of traffic points to the car manufacturer's cloud service platform and declares that it uses kernel A; the other type of traffic points to an external video content service network and declares that it uses kernel B.

[0093] Application of feature association and preliminary classification

[0094] The system's approach no longer views the browser kernel version in isolation, but rather associates it with the network context. It binds kernel A to the "Automotive Enterprise Cloud Service Platform," forming an application characteristic association group and identifying it as a system application. Simultaneously, it binds kernel B to the "External Video Service Network," forming another application characteristic association group and identifying it as a third-party video application.

[0095] Behavioral fingerprint analysis and instance differentiation to combat cloning and spoofing.

[0096] The system's approach involves continuous monitoring and in-depth analysis of traffic initially categorized as "third-party video applications." Through observation, the system discovered that the application's traffic actually exhibits two distinctly different network behavior patterns:

[0097] Behavioral Pattern 1: Exhibits regular heartbeats, a fixed order of interface access, and stable behavior.

[0098] Behavioral Pattern Two: Loose behavior, irregular heartbeat, and simplified access process.

[0099] Based on these differentiated sequence pattern features, the system generates two different application instance behavior fingerprints and determines that they belong to two independent instances of the same video application, such as the official original version and the modified version coexisting.

[0100] Process fingerprint mapping and priority allocation

[0101] The system's execution plan delves deeper into the network protocol stack, analyzing the transport layer protocol behavior of the two application instances, such as specific parameters of TCP connections. Through analysis, the system discovered:

[0102] An example of behavior pattern one is presented, whose protocol characteristics are associated with the main process in the vehicle's operating system responsible for foreground user interaction.

[0103] An instance exhibiting behavior pattern two has protocol characteristics associated with a background auxiliary process.

[0104] Accordingly, the system assigns high test priority to application instances associated with the main process and standard test priority to instances associated with auxiliary processes.

[0105] Precise vulnerability testing

[0106] Based on the independent and accurate browser kernel version profile established by the above analysis, the system performs the final vulnerability verification:

[0107] For system applications, such as kernel A, match and test for the corresponding known vulnerabilities.

[0108] For third-party video applications, such as kernel B, the known high-risk vulnerabilities of older kernel versions are matched against two separate instances of the application.

[0109] Based on priority, the Proof-of-Concept (POC) code was first injected into the high-priority main process instance, and an application crash was successfully observed, confirming the existence of the vulnerability. Subsequently, verification tests were performed on the low-priority background process instance.

[0110] This embodiment demonstrates a progressive process from basic traffic analysis to precise process-level detection. By associating application features, system applications and third-party applications were successfully distinguished; through behavioral fingerprint analysis, different instances of the same app were identified; and finally, through process mapping, optimized configuration of test resources was achieved. This multi-layered analysis method ensures comprehensive coverage of all attack surfaces in complex in-vehicle environments while prioritizing the detection of the most critical security threats, thus improving detection efficiency and accuracy.

[0111] Reference Figure 3 This application also provides a black-box detection system based on vulnerabilities in automotive built-in browsers, including:

[0112] The first acquisition module 1 is used to acquire network communication data sent by the vehicle's infotainment system;

[0113] Parsing module 2 is used to parse the user agent field and network request behavior characteristics from the network communication data, wherein the network request behavior characteristics include the server address or interface accessed by the vehicle system that can characterize the vehicle model or software characteristics.

[0114] The second acquisition module 3 is used to obtain the first browser kernel version information based on the user agent field;

[0115] The query module 4 is used to query a preset vehicle model behavior feature mapping library based on the network request behavior characteristics, determine the vehicle model information corresponding to the vehicle system, and obtain the second browser kernel version information by combining the vehicle model browser version mapping library.

[0116] The verification and fusion module 5 is used to verify and fuse the first browser kernel version information and the second browser kernel version information to obtain the final target browser kernel version information.

[0117] Matching module 6 is used to match at least one proof-of-concept exploit code from the vulnerability database based on the target browser kernel version information.

[0118] Execution module 7 is used to perform vulnerability testing on the vehicle system based on the target browser kernel version information and the matching proof-of-concept exploit code;

[0119] The determination module 8 is used to determine whether there is a corresponding security vulnerability in the browser kernel corresponding to the target browser kernel version information by monitoring the operating status of the vehicle system during the test.

[0120] As described above, it is understood that each component of the black-box detection system based on the vulnerability of the car's built-in browser proposed in this application can achieve the function of any of the black-box detection methods based on the vulnerability of the car's built-in browser as described above, and the specific structure will not be repeated.

[0121] Reference Figure 4 This application also provides a computer device, which may be a server, and its internal structure may be as follows: Figure 4 As shown, the computer device includes a processor, memory, network interface, and database connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and database. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The database stores monitoring data and other data. The network interface is used for communication with external terminals via a network connection. When the computer program is executed by the processor, it implements a black-box detection method based on vulnerabilities in a car's built-in browser.

[0122] The processor described above executes the black-box detection method based on vulnerabilities in the vehicle's built-in browser, comprising: acquiring network communication data sent by the vehicle's infotainment system; parsing user agent fields and network request behavior characteristics from the network communication data, wherein the network request behavior characteristics include server addresses or interfaces accessed by the vehicle's infotainment system that can characterize vehicle models or software features; obtaining first browser kernel version information based on the user agent fields; querying a preset vehicle model behavior feature mapping library based on the network request behavior characteristics to determine the vehicle model information corresponding to the vehicle's infotainment system, and obtaining second browser kernel version information by combining the vehicle model browser version mapping library; verifying and fusing the first browser kernel version information and the second browser kernel version information to obtain the final target browser kernel version information; matching at least one corresponding proof-of-concept vulnerability exploit code from a vulnerability database based on the target browser kernel version information; performing vulnerability testing on the vehicle's infotainment system based on the target browser kernel version information and the matched proof-of-concept vulnerability exploit code; and determining whether a corresponding security vulnerability exists in the browser kernel corresponding to the target browser kernel version information by monitoring the operating status of the vehicle's infotainment system during the testing process.

[0123] One embodiment of this application also provides a computer-readable storage medium storing a computer program. When executed by a processor, the computer program implements a black-box detection method based on a vulnerability in a car's built-in browser, comprising the following steps: acquiring network communication data sent by a vehicle-mounted system; parsing a user agent field and network request behavior characteristics from the network communication data, wherein the network request behavior characteristics include server addresses or interfaces accessed by the vehicle-mounted system that can characterize vehicle models or software features; obtaining first browser kernel version information based on the user agent field; querying a preset vehicle model behavior feature mapping library based on the network request behavior characteristics to determine the vehicle model information corresponding to the vehicle-mounted system, and obtaining second browser kernel version information by combining the vehicle model browser version mapping library; verifying and fusing the first browser kernel version information and the second browser kernel version information to obtain the final target browser kernel version information; matching at least one corresponding proof-of-concept vulnerability exploit code from a vulnerability database based on the target browser kernel version information; performing vulnerability testing on the vehicle-mounted system based on the target browser kernel version information and the matched proof-of-concept vulnerability exploit code; and determining whether a corresponding security vulnerability exists in the browser kernel corresponding to the target browser kernel version information by monitoring the operating status of the vehicle-mounted system during the testing process.

[0124] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in this application and in the embodiments can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual-speed SDRAM (SSRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).

[0125] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, apparatus, article, or method that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, apparatus, article, or method. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, apparatus, article, or method that includes that element.

[0126] The above description is only a preferred embodiment of this application and does not limit the patent scope of this application. Any equivalent structural or procedural changes made based on the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

Claims

1. A black-box detection method based on vulnerabilities in automotive built-in browsers, characterized in that, The method includes: Acquire network communication data sent by the vehicle's infotainment system; From the network communication data, the user agent field and network request behavior characteristics are parsed out, wherein the network request behavior characteristics include the server address or interface accessed by the vehicle system that can characterize the vehicle model or software characteristics. Based on the user agent field, obtain the first browser kernel version information; Based on the network request behavior characteristics, a preset vehicle model behavior feature mapping library is queried to determine the vehicle model information corresponding to the vehicle system, and combined with the vehicle model browser version mapping library, the second browser kernel version information is obtained; The first browser kernel version information and the second browser kernel version information are verified and fused to obtain the final target browser kernel version information; Based on the target browser kernel version information, at least one proof-of-concept exploit code is matched from the vulnerability database. Based on the target browser kernel version information and the matching proof-of-concept exploit code, a vulnerability test is performed on the vehicle infotainment system. By monitoring the vehicle's infotainment system's operating status during the testing process, it can be determined whether the browser kernel corresponding to the target browser kernel version information has any corresponding security vulnerabilities.

2. The black-box detection method based on vulnerabilities in automotive built-in browsers according to claim 1, characterized in that, The step of performing vulnerability testing on the vehicle infotainment system based on the target browser kernel version information and the matching proof-of-concept exploit code also includes security test control, the steps of which include: Analyze the vulnerability types in the proof-of-concept exploit code; Based on the vulnerability type of the proof-of-concept exploit code, determine the test risk level of the proof-of-concept exploit code, wherein the test risk level includes high risk and standard risk; If the test risk level is high risk, a network access rule is injected into the test environment before the test is executed. The rule is configured to forcibly block all network access of the vehicle system within a preset time threshold after the test starts. If the test risk level is standard risk, then the vulnerability test will be performed directly. If a persistent system failure is detected in the vehicle infotainment system after the test is performed, an emergency recovery mechanism is triggered. The emergency recovery mechanism includes guiding the vehicle infotainment system to perform a power-off and restart operation.

3. The black-box detection method based on vulnerabilities in automotive built-in browsers according to claim 1, characterized in that, The step of verifying and fusing the first browser kernel version information and the second browser kernel version information includes: Analyze the kernel version information of the first browser and the kernel version information of the second browser; If the version number indicated by the first browser kernel version information is exactly the same as that indicated by the second browser kernel version information, then the version number is output as the target browser kernel version information; Otherwise, if the first browser kernel version information is a version range and the second browser kernel version information is a specific version falling within that range, then the second browser kernel version information is output. Otherwise, if the version numbers indicated by the kernel version information of the first browser and the second browser are adjacent, a test version range containing these two adjacent versions and all versions in between is output as the target browser kernel version information.

4. The black-box detection method based on the vulnerability of the car's built-in browser according to claim 1, characterized in that, The method further includes: In the step of parsing the user agent field from the network communication data, each parsed user agent field, as well as the source IP address and target server address of the HTTP request containing that user agent field, are recorded. The user agent field, source IP address, and target server address are associated and bound to form an application feature association group; Based on the application feature association group, separate browser kernel version files are created for different applications or service modules in the vehicle system. In the step of matching at least one proof-of-concept exploit code from the vulnerability database based on the target browser kernel version information, according to the independent browser kernel version file, the corresponding proof-of-concept exploit code is matched for each application or service module, and vulnerability testing is performed on each module.

5. The black-box detection method based on the vulnerability of the car's built-in browser according to claim 1, characterized in that, In the step of querying a preset vehicle model behavior feature mapping library based on the network request behavior characteristics to determine the vehicle model information corresponding to the vehicle system, and obtaining the second browser kernel version information by combining the vehicle model browser version mapping library, the method further includes: From the network request behavior characteristics, the target server domain name accessed by the vehicle system is parsed out, and the application layer interface path or request parameters accessed under that domain name are extracted. The resolved target server domain name is combined with the application layer interface path or request parameters to form a fine-grained combined behavioral feature. Based on the fine-grained combined behavioral features, the vehicle behavior feature mapping library is queried to obtain more accurate vehicle and software environment information, and then the second browser kernel version information is obtained from the vehicle browser version mapping library.

6. The black-box detection method based on the vulnerability of the car's built-in browser according to claim 4, characterized in that, The step of establishing independent browser kernel version files for different applications or service modules within the vehicle infotainment system based on the application feature association group includes: For each application or service module that has been initially classified by the application feature association group, continuously capture and record the sequence of network requests initiated by it within a preset time period; Based on the captured network request sequence, the network request sequence is analyzed to extract its sequence pattern features, and an application instance behavior fingerprint is generated based on these features. The sequence pattern features include: the time interval distribution pattern between consecutive requests, the fixed access order to multiple target server addresses, and the variation pattern of payload length in periodic requests. Compare the behavioral fingerprints of all the constructed application instances; If two network flows are found to have the same user agent field and target server address binding relationship, but their application instance behavior fingerprints are inconsistent, then they are determined to belong to different application instances. Based on the results of the determination, a separate browser kernel version file is created for each instance.

7. The black-box detection method based on the vulnerability of the car's built-in browser according to claim 6, characterized in that, The step of creating a separate browser kernel version file for each instance includes: Analyze the transport layer and network layer protocol behavior of network flows generated by different application instances; Based on the aforementioned protocol behavior, a process-level network fingerprint is generated to distinguish different host processes. The protocol behavior includes: the coordinated change pattern of the initial window size and timestamp sequence during TCP connection establishment; and the recursive pattern of the IP packet identifier field in continuous data streams. The process-level network fingerprint is mapped to the specific active processes in the vehicle's operating system; Based on the mapped process identity and its functional role, test priorities are assigned to the corresponding browser kernel version files.

8. A black-box detection system based on vulnerabilities in a car's built-in browser, characterized in that, include: The first acquisition module is used to acquire network communication data sent by the vehicle's infotainment system; The parsing module is used to parse the user agent field and network request behavior characteristics from the network communication data, wherein the network request behavior characteristics include the server address or interface accessed by the vehicle system that can characterize the vehicle model or software characteristics. The second acquisition module is used to obtain the first browser kernel version information based on the user agent field; The query module is used to query a preset vehicle model behavior feature mapping library based on the network request behavior characteristics, determine the vehicle model information corresponding to the vehicle system, and obtain the second browser kernel version information by combining the vehicle model browser version mapping library. The verification and fusion module is used to verify and fuse the first browser kernel version information and the second browser kernel version information to obtain the final target browser kernel version information. The matching module is used to match at least one proof-of-concept exploit code from the vulnerability database based on the target browser kernel version information. The execution module is used to perform vulnerability testing on the vehicle system based on the target browser kernel version information and the matching proof-of-concept exploit code; The determination module is used to determine whether there is a corresponding security vulnerability in the browser kernel corresponding to the target browser kernel version information by monitoring the operating status of the vehicle system during the test.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 7.

Images