Software component analysis method and device, storage medium and electronic equipment

Abstract

The invention provides a software component analysis method and device, a storage medium and electronic equipment, and relates to the technical field of software analysis. According to the software component analysis method, for each executable file, file features of the executable file in multiple dimensions are identified, and the file feature of each dimension corresponds to a feature hit rule; determining the matching degree between the file features of at least two dimensions in the file features of the multiple dimensions and the standard file features of the corresponding dimensions in the file feature warehouse, and determining that the software components of the executable file are the software components associated with the standard file features of the corresponding dimensions when the corresponding feature hit rules are met. Accordingly, understandingly, the file features, the matching degrees of which and the standard file features on the corresponding dimensions in the file feature warehouse meet the corresponding feature hit rules, comprise multiple dimensions, so that the software components of the application program can be accurately identified.

Description

Technical Field

[0001] The present application relates to the technical field of software analysis, and in particular to a software component analysis method, device, storage medium and electronic device. Background Art

[0002] With the development of science and technology, the functions of automobiles are showing a trend of diversification. For example, various applications can be installed in the operating system of the car's computer to achieve different functions. For example, the installed applications may include a music application to achieve the function of listening to music, and a navigation application to achieve the function of navigation, etc. However, one or more applications installed in the operating system of the car computer may have vulnerabilities, which may cause the operating system of the car computer to be attacked, and there is a risk of affecting the safe operation of the operating system of the car computer. Therefore, before installing the application in the operating system of the car computer, the software component analysis of the application can be performed to analyze whether each software component has vulnerabilities.

[0003] At present, the file name of the executable file in the software package file set of the application can be found from a preset file name database. When the file name of the executable file in the software package file set of the application is found, the software component associated with the file name of the executable file can be found from the preset file name database. However, the file name of the executable file in the software package file set of the application may usually change (such as the version information field or software manufacturer information in the file name changes). As a result, the software component of the application cannot be accurately identified. Summary of the invention

[0004] The present application provides a software component analysis method, device, storage medium and electronic device, which are used to solve the problem that the software components of an application cannot be accurately identified in the prior art.

[0005] In a first aspect, the present application provides a software component analysis method, which is applied to an electronic device, comprising:

[0006] Acquire a software package file set of the application, wherein the software package file set includes at least one executable file for different functions of the application;

[0007] For each executable file, identifying file features of the executable file in multiple dimensions, wherein the file features in each dimension correspond to feature hit rules;

[0008] Matching file features in multiple dimensions with a pre-stored file feature warehouse;

[0009] Determine the matching degree of file features of at least two dimensions among the file features on the multiple dimensions with the standard file features on the corresponding dimensions in the file feature warehouse, and if the corresponding feature hit rules are met, determine that the software component of the executable file is the software component associated with the standard file feature of the corresponding dimension.

[0010] In a possible implementation, the file features on multiple dimensions include printable string features and code snippet features of executable files, the standard file features include standard printable string features and standard code snippet features, and determining the matching degree of the file features on multiple dimensions with the standard file features on corresponding dimensions in the file feature warehouse to meet the corresponding feature hit rules includes:

[0011] If the number of hits of multiple sub-features in the printable string feature in the standard printable string feature is greater than the first numerical threshold, and the number of hits of multiple sub-features in the code snippet feature is greater than the second numerical threshold, then the matching degree of the file features on multiple dimensions with the standard file features on the corresponding dimensions in the file feature warehouse is determined, and both meet the corresponding feature hit rules.

[0012] In a possible implementation, the file feature warehouse includes file names of multiple standard executable files, and the file names of the multiple standard executable files are respectively associated with software components. For each executable file, file features of the executable file in multiple dimensions are identified, including:

[0013] For each executable file, get the executable file name;

[0014] If the target feature in the file name of the executable file is inconsistent with the target feature in the file name of one of the standard executable files, the file features of the executable file in multiple dimensions are identified.

[0015] In a possible implementation, after obtaining the file name of each executable file, the method provided by the present application further includes:

[0016] If the file name of the executable file is consistent with the file name of one of the standard executable files, the software component associated with the corresponding standard executable file is determined as the software component of the executable file.

[0017] In a possible implementation, for each executable file, file features of the executable file in multiple dimensions are identified, including:

[0018] For each executable file, determining whether the file type of the executable file can be identified;

[0019] If the file type of the executable file can be identified, the file features of the executable file in multiple dimensions are identified.

[0020] In a possible implementation, after determining that the software component of the executable file is a software component associated with the standard file feature of the corresponding dimension, the method provided by the present application further includes:

[0021] In response to a risk screening request from a user terminal, obtaining general platform enumeration information associated with software components of a determined executable file from a file feature repository;

[0022] According to the determined software components of the executable file and the general platform enumeration information, searching for security vulnerability information associated with the software components of the executable file;

[0023] Send security vulnerability information to the user terminal.

[0024] In a possible implementation, after determining that the software component of the executable file is a software component associated with the standard file feature of the corresponding dimension, the method further includes:

[0025] Establishing associations between software components of each executable file and the identifiers of the application program;

[0026] The identifiers of the associated applications and the software components of each executable file are uploaded to the cloud server for storage.

[0027] In a second aspect, the present application further provides a software component analysis device, which is configured in an electronic device. The device provided by the present application includes:

[0028] A data acquisition unit, configured to acquire a software package file set of an application, wherein the software package file set includes at least one executable file of the application;

[0029] A feature recognition unit, for each executable file, identifies file features of the executable file in multiple dimensions, wherein the file features in each dimension correspond to feature hit rules;

[0030] A feature matching unit, used to match file features in multiple dimensions with a pre-stored file feature repository, wherein the file feature repository includes standard file features in multiple dimensions of multiple standard executable files and associated software components;

[0031] The software component determination unit is used to determine the matching degree between the file features of at least two dimensions among the file features of the multiple dimensions and the standard file features of the corresponding dimensions in the file feature warehouse, and if the corresponding feature hit rules are met, the software component of the executable file is determined to be the software component associated with the standard file features of the corresponding dimensions.

[0032] In a third aspect, the present application provides an electronic device, including:

[0033] processor;

[0034] a memory for storing processor-executable instructions;

[0035] The processor is configured to execute instructions to implement the software component analysis method provided in the first aspect of the present application.

[0036] In a fourth aspect, the present application further provides a storage medium. When the instructions in the storage medium are executed by the processor of the vehicle computer, the vehicle computer can execute the software component analysis method provided in the first aspect of the present application.

[0037] The present application provides a software component analysis method, device, storage medium and electronic device. For each executable file, the file features of the executable file in multiple dimensions are identified, wherein the file features of each dimension correspond to a feature hit rule; the matching degree of the file features of at least two dimensions among the file features in the multiple dimensions with the standard file features in the corresponding dimensions in the file feature warehouse is determined, and the corresponding feature hit rule is satisfied before the software component of the executable file is determined to be the software component associated with the standard file features in the corresponding dimension. It can be understood that since the file features whose matching degree with the standard file features in the corresponding dimension in the file feature warehouse satisfies the corresponding feature hit rule, include multiple dimensions, the software components of the application can be accurately identified. BRIEF DESCRIPTION OF THE DRAWINGS

[0038] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, a brief introduction will be given below to the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0039] Figure 1 One of the flowcharts of the software component analysis method provided in the embodiment of the present application;

[0040] Figure 2 The second flowchart of the software component analysis method provided in the embodiment of the present application;

[0041] Figure 3 Flowchart 3 of the software component analysis method provided in the embodiment of the present application;

[0042] Figure 4 A functional module block diagram of a software component analysis device provided in an embodiment of the present application;

[0043] Figure 5 A circuit module block diagram of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0044] Hereinafter, embodiments of the present disclosure will be described with reference to the accompanying drawings. However, it should be understood that these descriptions are exemplary only and are not intended to limit the scope of the present disclosure. In addition, in the following description, descriptions of well-known structures and technologies are omitted to avoid unnecessary confusion of the concepts of the present disclosure.

[0045] Various structural schematic diagrams according to embodiments of the present disclosure are shown in the accompanying drawings. These figures are not drawn to scale, and some details are magnified and some details may be omitted for the purpose of clear expression. The shapes of various regions and layers shown in the figures and the relative sizes and positional relationships therebetween are only exemplary, and may deviate in practice due to manufacturing tolerances or technical limitations, and those skilled in the art may further design regions / layers with different shapes, sizes, and relative positions according to actual needs.

[0046] In the context of the present disclosure, when a layer / element is referred to as being "on" another layer / element, the layer / element may be directly on the other layer / element or an intervening layer / element may exist therebetween. In addition, if a layer / element is "on" another layer / element in one orientation, the layer / element may be "below" the other layer / element when the orientation is reversed.

[0047] The following is a detailed description of the technical solution of the present application and how the technical solution of the present application solves the above-mentioned technical problems with specific embodiments. The following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be repeated in some embodiments. The embodiments of the present application will be described below in conjunction with the accompanying drawings.

[0048] See also Figure 1 , the embodiment of the present application provides a software component analysis method, applied to an electronic device, comprising:

[0049] S101: Obtain a set of software package files of an application.

[0050] The software package file set includes at least one executable file of the application. Further, the at least one executable file of the application may include multiple executable files for implementing different functions of the application. For example, when the application is an instant messaging application, the software package file set may include but is not limited to an executable file for implementing a communication function, an executable file for implementing message sending and receiving, and an executable file for implementing a video function.

[0051] Specifically, for each executable file, it can be determined whether the file type of the executable file can be identified. If the file type of the executable file can be identified, the file features of the executable file in multiple dimensions are identified. In this way, computing resources can be saved.

[0052] S102: For each executable file, identify file features of the executable file in multiple dimensions, wherein the file features in each dimension correspond to feature hit rules.

[0053] The file features on multiple dimensions include printable string features and code snippet features of executable files, and the standard file features include standard printable string features and standard code snippet features. The hit rule corresponding to the printable string feature of the executable file is that the number of hits of multiple sub-features in the printable string feature in the standard printable string feature is greater than the first numerical threshold; the hit rule corresponding to the code feature is: the number of hits of multiple sub-features in the code snippet feature is greater than the second numerical threshold. In addition, the file features on multiple dimensions can also include but are not limited to symbol table features, features of external dependency libraries, etc., which are not limited here.

[0054] S103: Match the file features in multiple dimensions with the pre-stored file feature warehouse.

[0055] The file feature repository includes standard file features of multiple standard executable files in multiple dimensions and associated software components.

[0056] S104: Determine the matching degree between the file features of at least two dimensions among the file features of the multiple dimensions and the standard file features of the corresponding dimensions in the file feature warehouse, and if the corresponding feature hit rules are satisfied, determine that the software component of the executable file is the software component associated with the standard file feature of the corresponding dimension.

[0057] S104 can be specifically implemented as follows: when the file features on multiple dimensions include printable string features and code snippet features of executable files, if the number of hits of multiple sub-features in the printable string feature in the standard printable string feature is greater than a first numerical threshold (such as 3), and the number of hits of multiple sub-features of the code snippet feature is greater than a second numerical threshold (such as 2), then determine the matching degree of the file features on multiple dimensions with the standard file features on the corresponding dimensions in the file feature warehouse, and satisfy the corresponding feature hit rules.

[0058] In some implementations, the software components of each executable file and the identifiers of the application program may be associated; the identifiers of the associated application program and the software components of each executable file may be uploaded to a cloud server for storage for subsequent tracing.

[0059] In summary, the software component analysis method provided by the embodiment of the present application identifies the file features of the executable file in multiple dimensions for each executable file, wherein the file features of each dimension correspond to a feature hit rule; the matching degree of the file features of at least two dimensions among the file features in the multiple dimensions with the standard file features in the corresponding dimensions in the file feature warehouse is determined, and the corresponding feature hit rule is satisfied before the software component of the executable file is determined to be the software component associated with the standard file features in the corresponding dimensions. It can be understood that since the file features whose matching degree with the standard file features in the corresponding dimensions in the file feature warehouse satisfies the corresponding feature hit rule, include multiple dimensions, the software components of the application can be accurately identified.

[0060] In some examples, the file feature repository includes the file names of multiple standard executable files, and the file names of the multiple standard executable files are respectively associated with software components. Figure 2 As shown, S102 can be specifically implemented as

[0061] S201: For each executable file, obtain the file name of the executable file.

[0062] S202: Determine whether the target feature in the file name of the executable file is consistent with the target feature in the file name of one of the standard executable files. If not, execute S203. In other implementations, if yes, execute S204.

[0063] For example, when the executable file is named "libssl.so.1.0.1", the target feature of the file name may be "libssl.so".

[0064] S203: Identify file features of the executable file in multiple dimensions.

[0065] S204: Determine the software components associated with the corresponding standard executable file as the software components of the executable file.

[0066] Based on the above S201-S204, the file name can be used to characterize the identity information of the file. When the target feature in the file name of the executable file is consistent with the target feature in the file name of one of the standard executable files, the software component associated with the corresponding standard executable file is directly determined as the software component of the executable file, which is highly accurate and efficient. If the target feature in the file name of the executable file is inconsistent with the target feature in the file name of one of the standard executable files, the file features of the executable file in multiple dimensions are further identified for subsequent determination of the software component, which can further improve the reliability of identifying the software component.

[0067] In some other embodiments, after S104, Figure 3 As shown, the method provided in the embodiment of the present application may also include:

[0068] S301: In response to a risk screening request from a user terminal, obtain common platform enumeration (CPE) information associated with software components of a determined executable file from a file feature repository.

[0069] S302: Searching for security vulnerability information associated with the software components of the executable file according to the determined software components of the executable file and the general platform enumeration information.

[0070] S303: Send the security vulnerability information to the user terminal.

[0071] It is understandable that, since the reliability of the determined software component of the executable file is high, the reliability of the security vulnerability information retrieved based on the software component of the executable file is also higher. This is more conducive to users accurately assessing the risk of the application based on the highly reliable security vulnerability information.

[0072] like Figure 4 As shown, the present application also provides a software component analysis device 400, which is configured in an electronic device. It should be noted that the basic principle and technical effect of the software component analysis device 400 provided in the embodiment of the present application are the same as those in the above embodiment. For the sake of brief description, for the parts not mentioned in the embodiment of the present application, reference can be made to the corresponding contents in the above embodiment. The device 400 provided in the embodiment of the present application includes a data acquisition unit 401, a feature recognition unit 402, a feature matching unit 403, and a software component determination unit 404, wherein:

[0073] The data acquisition unit 401 is used to acquire a software package file set of an application, wherein the software package file set includes at least one executable file of the application.

[0074] The feature identification unit 402 is used to identify the file features of each executable file in multiple dimensions, wherein the file features in each dimension correspond to feature hit rules.

[0075] The feature matching unit 403 is used to match the file features in multiple dimensions with the pre-stored file feature warehouse.

[0076] The file feature repository includes standard file features of multiple standard executable files in multiple dimensions and associated software components.

[0077] The software component determination unit 404 is used to determine the matching degree between the file features of at least two dimensions among the file features of the multiple dimensions and the standard file features of the corresponding dimensions in the file feature warehouse, and if the corresponding feature hit rules are met, the software component of the executable file is determined to be the software component associated with the standard file features of the corresponding dimensions.

[0078] In some embodiments, the file features on multiple dimensions include printable string features and code snippet features of executable files, and the standard file features include standard printable string features and standard code snippet features. The feature matching unit 403 is specifically configured to determine the matching degree of the file features on multiple dimensions with the standard file features on the corresponding dimensions in the file feature warehouse, respectively, if the number of hits of the multiple sub-features in the printable string feature in the standard printable string feature is greater than a first numerical threshold, and the number of hits of the multiple sub-features of the code snippet feature is greater than a second numerical threshold, and both satisfy the corresponding feature hit rules.

[0079] In some implementations, the file feature repository includes the file names of multiple standard executable files, and the file names of the multiple standard executable files are respectively associated with software components. The feature recognition unit 402 is specifically configured to obtain the file name of the executable file for each executable file; if the target feature in the file name of the executable file is inconsistent with the file name of the target feature in one of the standard executable files, then recognize the file features of the executable file in multiple dimensions.

[0080] In some embodiments, the software component determination unit 404 is further configured to determine the software component associated with the corresponding standard executable file as the software component of the executable file if the target feature in the file name of the executable file is consistent with the target feature in the file name of one of the standard executable files.

[0081] In some implementations, the feature recognition unit 402 is further configured to determine, for each executable file, whether the file type of the executable file can be recognized; if the file type of the executable file can be recognized, then recognize file features of the executable file in multiple dimensions.

[0082] In some implementations, the data acquisition unit 401 is further configured to, in response to a risk screening request from a user terminal, acquire general platform enumeration information associated with a software component of a determined executable file from a file feature repository.

[0083] The apparatus 400 provided in the embodiment of the present application further includes: a data search unit, configured to search for security vulnerability information associated with the software component of the executable file according to the determined software component of the executable file and the general platform enumeration information;

[0084] The data sending unit sends the security vulnerability information to the user terminal.

[0085] In some embodiments, the method provided in the embodiments of the present application further includes:

[0086] An association establishing unit, used to establish an association relationship between the software components of each executable file and the identifiers of the application program;

[0087] The data uploading unit is used to upload the identification of the associated application programs and the software components of each executable file to the cloud server for storage.

[0088] Figure 5 This is a schematic diagram of the structure of the electronic device provided in the embodiment of the present application. Figure 5 At the hardware level, the electronic device includes a processor, and optionally also includes an internal bus, a network interface, and a memory. Among them, the memory may include a memory, such as a high-speed random access memory (RAM), and may also include a non-volatile memory (non-volatile memory), such as at least one disk storage, etc. Of course, the electronic device may also include hardware required for other services. For example, the electronic device can be a server, or a stand-alone machine, etc., which is not limited here.

[0089] The processor, network interface and memory can be interconnected through an internal bus, which can be an ISA (Industry Standard Architecture) bus, a PCI (Peripheral Component Interconnect) bus or an EISA (Extended Industry Standard Architecture) bus. The bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 5 Only one bidirectional arrow is used in the diagram, but this does not mean that there is only one bus or only one type of bus.

[0090] The memory is used to store the program. Specifically, the program may include a program code, and the program code includes a computer operation instruction. The memory may include a memory and a non-volatile memory, and provides instructions and data to the processor.

[0091] The processor reads the corresponding computer program from the non-volatile memory into the memory and then runs it, forming a software component analysis device at the logical level. The processor executes the program stored in the memory and is specifically used to execute the software component analysis method provided in the above embodiment below.

[0092] The above application Figure 1 The method performed by the software component analysis device disclosed in the illustrated embodiment can be applied to a processor or implemented by a processor. The processor may be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the above method can be completed by an integrated logic circuit of hardware in the processor or an instruction in software form. The above processor can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components. The methods, steps and logic block diagrams disclosed in this application can be implemented or executed. The general-purpose processor can be a microprocessor or the processor can also be any conventional processor, etc. The steps of the method disclosed in this application can be directly embodied as a hardware decoding processor for execution, or a combination of hardware and software modules in the decoding processor for execution. The software module can be located in a storage medium mature in the art such as a random access memory, a flash memory, a read-only memory, a programmable read-only memory, or an electrically erasable programmable memory, a register, etc. The storage medium is located in the memory, and the processor reads the information in the memory and completes the steps of the above method in combination with its hardware.

[0093] The electronic device may also perform Figure 1 The method and the software component analysis device are implemented in Figure 1 The functions of the illustrated embodiments will not be described in detail in this application.

[0094] Of course, in addition to software implementation methods, the electronic device of the present application does not exclude other implementation methods, such as logic devices or a combination of software and hardware, etc. That is to say, the execution subject of the following processing flow is not limited to each logic unit, but can also be hardware or logic devices.

[0095] The present application also proposes a computer-readable storage medium, which stores one or more programs, wherein the one or more programs include instructions, which, when executed by an electronic device including multiple application programs, enable the electronic device to execute Figure 1 The method of the illustrated embodiment.

[0096] Computer readable media include permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. Information can be computer readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disk read-only memory (CD-ROM), digital versatile disk (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer readable media does not include temporary computer readable media (transitory media), such as modulated data signals and carrier waves.

[0097] In addition, the present application also provides a computer program product, including a computer program, which, when executed by a processor, implements the present application. Figure 1 The software component analysis method shown.

[0098] In the above description, the technical details such as the patterning of each layer are not described in detail. However, those skilled in the art should understand that various technical means can be used to form layers, regions, etc. of desired shapes. In addition, in order to form the same structure, those skilled in the art can also design methods that are not completely the same as the methods described above. In addition, although the various embodiments are described above separately, this does not mean that the measures in the various embodiments cannot be used in combination to advantage.

[0099] Although the preferred embodiments of the present application have been described, those skilled in the art may make other changes and modifications to these embodiments once they have learned the basic creative concept. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments and all changes and modifications falling within the scope of the present application.

[0100] Obviously, those skilled in the art can make various changes and modifications to the present application without departing from the spirit and scope of the present application. Thus, if these modifications and variations of the present application fall within the scope of the claims of the present application and their equivalents, the present application is also intended to include these modifications and variations.

Claims

1. A software component analysis method, characterized in that: Applied to electronic equipment, the method comprises: Acquire a software package file set of an application, wherein the software package file set includes at least one executable file of the application; For each of the executable files, identifying file features of the executable file in multiple dimensions, wherein the file features in each dimension correspond to feature hit rules; Matching file features in multiple dimensions with a pre-stored file feature warehouse; If it is determined that the file features of at least two dimensions among the file features on the multiple dimensions match the standard file features on the corresponding dimensions in the file feature warehouse respectively, and the corresponding feature hit rules are satisfied, then the software component of the executable file is determined to be the software component associated with the standard file features of the corresponding dimensions.

2. The method according to claim 1, characterized in that: The file features on multiple dimensions include printable string features and code snippet features of the executable file, the standard file features include standard printable string features and standard code snippet features, and determining the matching degree of the file features of at least two dimensions of the file features on multiple dimensions with the standard file features on corresponding dimensions in the file feature warehouse to meet the corresponding feature hit rule includes: If the number of hits of multiple sub-features in the printable string feature in the standard printable string feature is greater than the first numerical threshold, and the number of hits of multiple sub-features of the code snippet feature is greater than the second numerical threshold, then it is determined that the matching degrees of the file features on the multiple dimensions and the standard file features on the corresponding dimensions in the file feature warehouse respectively meet the corresponding feature hit rules.

3. The method according to claim 1, characterized in that: The file feature warehouse includes file names of multiple standard executable files, each of which is associated with a software component. For each of the executable files, identifying file features of the executable file in multiple dimensions includes: For each of the executable files, obtaining the file name of the executable file; If the target feature in the file name of the executable file is inconsistent with the file name of the target feature in one of the standard executable files, the file features of the executable file in multiple dimensions are identified.

4. The method according to claim 3, characterized in that After obtaining the file name of each executable file, the method further includes: If the target feature in the file name of the executable file is consistent with the target feature in the file name of one of the standard executable files, the software component associated with the corresponding standard executable file is determined as the software component of the executable file.

5. The method according to claim 1, characterized in that For each of the executable files, identifying file features of the executable file in multiple dimensions includes: For each of the executable files, determining whether the file type of the executable file can be identified; If the file type of the executable file can be identified, the file features of the executable file in multiple dimensions are identified.

6. The method according to any one of claims 1 to 5, characterized in that: After determining that the software component of the executable file is a software component associated with a standard file feature of a corresponding dimension, the method further includes: In response to a risk screening request from a user terminal, obtaining general platform enumeration information associated with software components of the determined executable file from the file feature repository; According to the determined software components of the executable file and the general platform enumeration information, searching for security vulnerability information associated with the software components of the executable file; The security vulnerability information is sent to the user terminal.

7. The method according to any one of claims 1 to 5, characterized in that: After determining that the software component of the executable file is a software component associated with a standard file feature of a corresponding dimension, the method further includes: Establishing an association relationship between the software components of each executable file and the identifier of the application program; The identification of the associated application and the software components of each executable file are uploaded to the cloud server for storage.

8. A software component analysis device, characterized in that: Configured in an electronic device, the device comprises: A data acquisition unit, configured to acquire a set of software package files of an application, wherein the set of software package files includes at least one executable file of the application; A feature recognition unit, configured to recognize, for each of the executable files, file features of the executable file in multiple dimensions, wherein the file features in each dimension correspond to feature hit rules; A feature matching unit, used to match file features in multiple dimensions with a pre-stored file feature repository; The software component determination unit is used to determine the matching degree between the file features of at least two dimensions among the file features of the multiple dimensions and the standard file features of the corresponding dimensions in the file feature warehouse, and if the corresponding feature hit rules are met, the software component of the executable file is determined to be the software component associated with the standard file features of the corresponding dimensions.

9. An electronic device, characterized in that: include: processor; a memory for storing instructions executable by the processor; The processor is configured to execute the instructions to implement the software component analysis method according to any one of claims 1 to 7. 10 . A storage medium, when instructions in the storage medium are executed by a processor of a vehicle computer, the vehicle computer is enabled to execute the software component analysis method according to any one of claims 1 to 7.

Images