CN117195236A - Vulnerability detection method and device for target service, electronic equipment and storage medium - Google Patents

Abstract

The disclosure provides a vulnerability detection method of target service, relates to the technical field of computers, and particularly relates to the technical field of data processing and data security. The specific implementation scheme is as follows: acquiring a compiling file of a target service, wherein the compiling file comprises a framework file and an executing file, the framework file comprises a general function, and the executing file comprises a processing function; determining interface information of the target service according to at least one of parameters of the general function, a structure of the processing function and data transferred between the general function and the processing function; generating data to be tested according to the interface information; and performing vulnerability detection by using the data to be tested. The disclosure also provides a vulnerability detection device of the target service, an electronic device and a storage medium.

Description

Vulnerability detection method and device for target service, electronic equipment and storage medium

Technical Field

The present disclosure relates to the field of computer technology, and in particular, to the field of data processing and data security technology. More particularly, the disclosure provides a vulnerability detection method, device, electronic equipment and storage medium of target service.

Background

The computer system architecture includes multiple layers, such as an application layer, a framework layer, a hardware abstraction layer (Hardware Abstraction Layer, HAL), a driver layer, and so on. The layers cooperate with each other to complete various services. However, security issues exposed by the communication interfaces between the various tiers are not negligible.

Disclosure of Invention

The disclosure provides a vulnerability detection method, device and equipment of target service and a storage medium.

According to a first aspect, there is provided a vulnerability detection method of a target service, the method comprising: acquiring a compiling file of a target service, wherein the compiling file comprises a framework file and an executing file, the framework file comprises a general function, and the executing file comprises a processing function; determining interface information of the target service according to at least one of parameters of the general function, a structure of the processing function and data transferred between the general function and the processing function; generating data to be tested according to the interface information; and performing vulnerability detection by using the data to be tested.

According to a second aspect, there is provided a vulnerability detection apparatus of a target service, the apparatus comprising: the system comprises an acquisition module, a processing module and a storage module, wherein the acquisition module is used for acquiring a compiling file of a target service, the compiling file comprises a framework file and an execution file, the framework file comprises a general function, and the execution file comprises a processing function; the determining module is used for determining interface information of the target service according to at least one of parameters of the general function, a structure of the processing function and data transferred between the general function and the processing function; the generating module is used for generating data to be tested according to the interface information; and the detection module is used for performing vulnerability detection by using the data to be tested.

According to a third aspect, there is provided an electronic device comprising: at least one processor; and a memory communicatively coupled to the at least one processor; wherein the memory stores instructions executable by the at least one processor to enable the at least one processor to perform a method provided in accordance with the present disclosure.

According to a fourth aspect, there is provided a non-transitory computer readable storage medium storing computer instructions for causing a computer to perform a method provided according to the present disclosure.

According to a fifth aspect, there is provided a computer program product comprising a computer program stored on at least one of a readable storage medium and an electronic device, which, when executed by a processor, implements a method provided according to the present disclosure.

It should be understood that the description in this section is not intended to identify key or critical features of the embodiments of the disclosure, nor is it intended to be used to limit the scope of the disclosure. Other features of the present disclosure will become apparent from the following specification.

Drawings

The drawings are for a better understanding of the present solution and are not to be construed as limiting the present disclosure. Wherein:

FIG. 1 is a schematic diagram of an exemplary system architecture of vulnerability detection method and apparatus to which a target service may be applied, according to one embodiment of the present disclosure;

FIG. 2 is a flow chart of a vulnerability detection method of a target service according to one embodiment of the disclosure;

FIG. 3 is a schematic diagram of the relationship between client functions, server functions in a framework file, and processing functions in an execution file, according to one embodiment of the present disclosure;

FIG. 4 is a flow chart of a vulnerability detection method of a target service according to one embodiment of the disclosure;

FIG. 5 is a block diagram of a vulnerability detection apparatus of a target service according to one embodiment of the disclosure;

fig. 6 is a block diagram of an electronic device of a vulnerability detection method of a target service according to one embodiment of the disclosure.

Detailed Description

Exemplary embodiments of the present disclosure are described below in conjunction with the accompanying drawings, which include various details of the embodiments of the present disclosure to facilitate understanding, and should be considered as merely exemplary. Accordingly, one of ordinary skill in the art will recognize that various changes and modifications of the embodiments described herein can be made without departing from the scope and spirit of the present disclosure. Also, descriptions of well-known functions and constructions are omitted in the following description for clarity and conciseness.

The Android system is widely applied due to the characteristics of openness, compatibility, convenience and the like. In the Android system architecture, HIDL (HAL interface definition language) is a communication interface between the framework layer and the hardware abstraction layer. The HIDL is based on a client-server model. The framework layer includes, for example, third party applications, system applications, and the like as clients. The hardware abstraction layer comprises a plurality of service processes as a service end, wherein each service process is used for providing a service related to hardware. Such as invoking a camera, providing a bluetooth data transfer service, providing a display service for a display, setting up a firewall, etc.

The service (HIDL service) provided by the hardware abstraction layer serves as an independent process, and interfaces are exposed to the outside. The interface exposed by the HIDL service may be invoked by a third party application on the Android device. Therefore, the HIDL service is also one of the local attack surfaces in the Android ecology, i.e. there is a risk of being attacked by the HIDL service interface. In addition, the HIDL service is often implemented in the C/C++ language, and thus is also subject to security threats caused by code defects such as buffer overflows.

At present, automatic vulnerability detection can be performed on the HIDL service by auditing source codes of the HIDL service or performing fuzzy test on interface definition husband of the HIDL service based on CodeQL (a code analysis platform supporting multiple languages and frameworks).

However, codeQL only supports security audits for source code and is therefore only applicable to security testers who own HIDL services to implement source code. The source code of the HIDL service is mostly implemented by chip manufacturers and is released in binary form. In such cases, codeQL cannot be applied for source code auditing. The interface definition file also belongs to the source code and is not typically published by the vendor. In such cases, the ambiguity test cannot be directly performed based on the interface definition file.

Therefore, because the number of HIDL services in Android ecology is numerous and is mostly closed, the existing vulnerability detection method for acquiring source codes has great limitation, and is difficult to comprehensively and efficiently mine vulnerabilities.

In the technical scheme of the disclosure, the related processes of collecting, storing, using, processing, transmitting, providing, disclosing and the like of the personal information of the user accord with the regulations of related laws and regulations, and the public order colloquial is not violated.

In the technical scheme of the disclosure, the authorization or consent of the user is obtained before the personal information of the user is obtained or acquired.

FIG. 1 is a schematic diagram of an exemplary system architecture of a vulnerability detection method and apparatus to which a target service may be applied, according to one embodiment of the present disclosure. It should be noted that fig. 1 is only an example of a system architecture to which embodiments of the present disclosure may be applied to assist those skilled in the art in understanding the technical content of the present disclosure, but does not mean that embodiments of the present disclosure may not be used in other devices, systems, environments, or scenarios.

As shown in fig. 1, a system architecture 100 according to this embodiment may include terminal devices 101, 102, 103, a network 104, and an electronic device 105. The network 104 is used as a medium to provide communication links between the terminal devices 101, 102, 103 and the electronic device 105. The network 104 may include various connection types, such as wired and/or wireless communication links, and the like.

A user may interact with the electronic device 105 via the network 104 using the terminal devices 101, 102, 103 to receive or send messages or the like. The terminal devices 101, 102, 103 may be a variety of electronic devices including, but not limited to, smartphones, tablets, laptop portable computers, and the like. The terminal devices 101, 102, 103 may be devices of the Android system.

The vulnerability detection method of the target service provided by the embodiments of the present disclosure may be generally performed by the electronic device 105. Accordingly, the vulnerability detection apparatus of the target service provided by the embodiments of the present disclosure may be generally disposed in the electronic device 105.

Fig. 2 is a flow chart of a vulnerability detection method of a target service according to one embodiment of the disclosure.

As shown in fig. 2, the vulnerability detection method 200 of the target service includes operations S210 to S240.

In operation S210, a compiled file of a target service is acquired.

For example, the execution body of the embodiment of the present disclosure may be an electronic device with a display screen, and the electronic device may be a PC terminal. The electronic device (PC side) can be connected with the terminal device (Android device), a debugging tool (Android Debug Bridge shell, adb shell) is called, a command line interface is displayed, and commands are input in the command line interface to enumerate and display all services on the terminal device.

The services to be subjected to vulnerability detection in the embodiment of the disclosure may include HIDL services, and all HIDL services may be listed and presented. The HIDL services include a camera service, a bluetooth service, a display service, a firewall service, and the like. A specific service may be determined from the enumerated HIDL services as the target service to be tested.

The compiled file of the HIDL service is compiled from the source code file of the HIDL service. The source code file of the HIDL service includes an interface definition file of the HIDL service, which includes functions defined for accessing the service, and definitions including parameter names, parameter types, return value types, function names, and the like of the functions. For complex structure functions, structural information of the structure is also included. These all belong to interface information of the HIDL service. Since the HIDL service is client-server modeled, the interface definition file includes a client function and a server function.

The interface definition file of the HIDL service is compiled to generate a C language file, and the C language file and the interface definition file are both source codes. The compiling file is obtained after compiling the C language file, and comprises a general framework file and an execution file for realizing the service. The frame file and the execution file are binary files.

The framework file includes generic functions that correspond to the functions defined in the interface definition file. The generic functions include a client function for requesting the HIDL service and a server function for implementing the service. The execution file includes processing functions for implementing the service itself. It will be appreciated that the generic functions in the framework files are similar to the service definition functions, and the processing functions in the execution files are the services themselves.

Because the frame file and the execution file are binary files, function information cannot be directly obtained, and interface information cannot be obtained. Binary framework files and execution files may be obtained through command lines. For example, a command for viewing the target service process is input in the command line display interface, and the memory of the target service process can be accessed to determine the frame file of the target service and the name and path of the execution file.

In operation S220, interface information of the target service is determined according to at least one of parameters of the general function, a structure of the processing function, and data transferred between the general function and the processing function.

Because the frame file and the execution file are compiled from the source code of the target service. The function information contained in the frame file and the function information contained in the execution file should be consistent with the definition function information in the source code.

For example, the frame file may be decompiled to obtain a first decompiled file. The function information in the first decompiled file is consistent with the function information defined in the source code. And decompiling the execution file to obtain a second decompiled file. The function information in the second decompiled file is also consistent with the function information defined in the source code.

The client function of the target service can be found from the decompiled file, and the type of the client function is determined and used as the interface information of the target service. According to the interface information, what type of data needs to be provided for the target service when the vulnerability test is performed can be determined, and then a test case can be generated for the vulnerability test.

For example, if a prototype of the client function of the target service is displayed in the first decompiled file, the parameter type of the client function may be directly determined as the parameter type of the target service.

Since decompilation does not necessarily show all binary data completely as a function prototype, for example, a function has a complex structure. If the first decompilation file does not show the client prototype of the target service, decompilation can be performed on the execution file to obtain a second decompilation file, and the function prototype is determined from the function structure of the second decompilation file, so that the parameter type in the function prototype is determined and used as the interface information of the target service.

In addition, the data transferred by the general function to the processing function in the execution file in the general file can be followed, and the data type of the data transferred between the general function and the processing function is determined, wherein the data type is consistent with the parameter type of the function, so that the data type can be used as interface information of the target service.

In operation S230, data to be tested is generated according to the interface information.

According to the embodiment of the disclosure, the data to be tested is generated according to the parameter type, wherein the data type of the data to be tested is consistent with the parameter type.

The interface information of the target service indicates the data type to be met by the request of the target service, so that a test case meeting the parameter type in the interface information can be generated as the data to be tested.

For example, the parameter type of the interface information is the int type, and then the test case of the int type can be generated. The parameter type of the interface information is string type, so that a test case of string type and the like can be generated.

The test case can be automatically generated based on the parameter types of the interface information, and manual participation is not needed.

In operation S240, vulnerability detection is performed using the data to be tested.

According to an embodiment of the present disclosure, the data to be tested is processed using the target service; monitoring the running state of the target service and the return data of the target service; and determining test data which causes abnormality of at least one of the running state and the return data of the target service as vulnerability data.

For example, the test case may be sent to the target service, the target service is run, the running state and return value of the target service are monitored, and whether the target service is abnormal is determined. Vulnerability information may be determined if the target service operating state is abnormal or the return value is abnormal. The target service operating state is abnormal, such as on-hook. The return value exception includes, for example, returning a value outside the expected range, or a value outside a preset type, and so forth.

Test cases that cause anomalies in the target service may be collected as vulnerability data, i.e., these vulnerability data may cause anomalies in the service. And reporting the vulnerability data so that related personnel can analyze the vulnerability data, further repair the vulnerability and optimize the target service.

According to the embodiment of the disclosure, the compiling file of the target service is obtained, the compiling file comprises the frame file and the execution file, the data type which is required to be met by the target service is determined according to the parameters of the general function in the frame file, the structure of the processing function in the execution file and the data transferred between the general function in the frame file and the processing function in the execution file, the data to be tested is automatically generated according to the data type, and then the vulnerability detection is carried out, so that the vulnerability detection efficiency can be improved.

Aiming at some services which cannot obtain source codes, by acquiring compiled files of the services, the vulnerability detection method of the target services provided by the embodiment can also be used for detecting the vulnerabilities of the services, so that comprehensive and efficient floor drain hole detection of an Android system is realized.

It should be noted that, the vulnerability detection method of the target service provided in this embodiment can be applied not only to the HIDL service of the Android system, but also to the service modeled by other clients-servers.

An embodiment of determining the parameter type of the target service from the parameters of the general function is described below.

According to an embodiment of the disclosure, operation S220 includes decompiling the frame file to obtain a first decompiled file, where a general function in the first decompiled file is consistent with a function defined in the source file; determining a client function of the target service from the first decompiled file; and determining interface information of the target service according to the parameter type of the client function of the target service.

The frame file is encoded by the source code of the target service, and therefore, the function information in the frame file is consistent with the function information in the source code. Decompiling the frame file to obtain a first decompiled file, wherein the first decompiled file can display a prototype of the function.

The framework file includes a client function and a server function, where the client function and the server function have different identities, for example, the client function has an identity Bp, and the server function has an identity Bn. Each HIDL service also has its own identity, e.g., camera service identity is Camera, firewall service identity is Netdadgent, etc. Taking firewall service as a target service as an example, the name (identifier) of a client function of the target service may be BpNetdagent, and the name of a server function may be BnNetdagent. These identifications may be predefined.

Based on the identification information, bpNetdagent his dl can be searched in the first decompilation to obtain the client function of the target service (firewall service). Similarly, other services may search for bpxx_hidl. For example, a client function of BpNetdagent_hidl (hardware: hidl_XX, hardware:: hidl_string) served by the firewall by searching can extract the parameter type of the function as string from the client function. The data type of the test case may be determined to be string.

However, not all services' client functions contain parameter information. Some of the parameters of the client functions of the services are a structure, and if the structure includes a plurality of sub-functions, the parameters of the processing functions cannot be displayed. In this case, the parameter type of the target service may be determined according to the structure of the processing function.

An embodiment of determining the type of the target service according to the structure of the processing function is described below.

According to an embodiment of the present disclosure, operation S220 further includes decompiling the execution file to obtain a second decompiled file, where a processing function in the second decompiled file is consistent with a function defined in the source file; determining a target virtual function according to the layout of the virtual functions in the second decompilation file; and determining interface information of the target service according to the parameter type of the target virtual function.

For example, decompiling the execution husband to obtain a second decompiled file, where the second decompiled file may be searched for the processing function of the target service. Specifically, the searching may be performed according to a naming rule of the target service, for example, searching for a packet name containing the HIDL service, to obtain the processing function.

The processing functions in the second decompiled file may reflect the structure information. The processing functions are presented in the form of a virtual function list (abbreviated as virtual table) that is consistent with the structure information. The virtual table includes a plurality of virtual functions, the layout of the plurality of virtual functions is consistent with the layout of the plurality of sub-functions in the structure, and the layout can be set according to a certain standard or specification. For example, a first child function in the fabric is a parent function, a second child function is a child class constructor, a third child function is a destructor, and a fourth child function is a child class service implementation function. The sub-class service implementation function is a processing function for implementing the target service.

Correspondingly, the plurality of virtual functions in the virtual table are also parent functions, child constructors (e.g., sub_a), destructors (e.g., sub_b), and child service implementation functions (e.g., sub_c) in sequence.

Sub-class service implementation functions are extracted, for example, sub-class service implementation function (hardware: hidl_string, hardware:: hidl_xx), where sub-class service implementation function identification may be sub-class service implementation function identification. The parameter type of the target service can be determined as string from the sub_c function. So that the data type of the test case can be determined as string.

If the parameter type of the target service is not obtained based on the parameters of the client function in the framework file and the structure of the processing function in the execution file, the parameter type of the target service can be determined based on the data transferred from the server function in the framework file to the processing function in the execution file.

An embodiment of determining the parameter type of the target service based on the data transferred from the server-side function in the framework file to the processing function in the execution file is described below.

Operation S220 further includes determining a server function of the target service from the first decompiled file according to an embodiment of the present disclosure; determining the serialization data transferred between the server-side function of the target service and the processing function; analyzing the data type from the serialized data; and determining interface information of the target service according to the analyzed data type.

For example, taking a firewall service as the target service and taking a service end function name of the target service as BnNetdagent as an example, the bnnetdagent_hi may be searched in the first decompilation to obtain the service end function of the target service (firewall service). Similarly, other services may search for BnXX_hidl. Since the client function is transferring the request data to the server function as a serialized object (e.g., a parcel object), the serialized object may include the original data type as well as the serialized original data. Therefore, the server function can be followed, the object transferred by the server function can be obtained, and the original data type can be resolved from the object to serve as the parameter type of the target service.

FIG. 3 is a diagram of the relationship between client functions, server functions in a framework file, and processing functions in an execution file according to one embodiment of the present disclosure.

As shown in fig. 3, the framework file 310 includes a client function 311 and a server function 312. The execution file 320 includes a processing function 321. The client function 311, the server function 312, and the processing function 321 are corresponding. The client function 311 is a function provided for a client (e.g., a framework layer), and the server function 312 is a function provided for a server (e.g., a hardware abstraction layer). Client function 311 and server function 312 may be understood as definitions of functions or a framework of functions. The processing function 321 is a function of the service itself, and the processing function 321 is executed to realize the function of the service itself.

For example, client function 311 is BpXX_hidl (X), and server function 312 is BnXX_hidl (Y). The parameter X of the client function 311 is consistent with the parameter Y of the server function 312. For example, if parameter X is a simple parameter, then parameter Y is also a simple parameter, and the types of parameter X and parameter Y are identical. If the parameter X is a structure, then the parameter Y is a structure that is consistent with the structure of the parameter X.

If both parameters X and Y are structures, the processing function 321 is correspondingly also in the form of a structure. The structure of the processing function 321 includes a virtual function list, where the virtual function list includes a parent function, a child function a (sub_a), a child function B (sub_b), and a child function C (sub_c). According to the layout standard or specification of the virtual function, the subfunction A is a subclass construction function, the subfunction B is a destructor, and the subfunction C is a subclass service realization function, namely a processing function. Then the parameters Y of the server function 312 are consistent with the parameters of the sub-function C.

In order to perform the vulnerability test, the parameter type of the client function needs to be determined as the data type of the data to be tested. By decompiling, if a prototype of the client function can be obtained directly, the required parameter types can be obtained. If the prototype of the client function cannot be obtained, the prototype of the client function 312, the prototype of the processing function 321, and the transfer data between the server function 312 and the processing function 321 may be obtained according to the correspondence between the client function 311, the server function 312, and the processing function 321, and the parameter type may be determined.

According to the embodiment of the disclosure, the data type of the data required by the vulnerability detection can be determined according to the corresponding relation among the client function, the server function and the processing function, so that the test case can be conveniently generated.

Fig. 4 is a flow chart of a vulnerability detection method of a target service according to one embodiment of the disclosure.

As shown in fig. 4, the vulnerability detection method of the target service includes operations S410 to S470.

In operation S410, a target service is enumerated and selected.

For example, the method can be connected with an Android device, call a debugging tool, display a command line interface, and input commands on the command line interface to enumerate and display all services on the terminal device.

In operation S420, a compiled file of the target service is acquired, the compiled file including a frame file and an execution file.

The specific implementation of operation S420 is similar to that of operation S210, and will not be described again here.

In operation S430, it is determined whether the interface information is extracted by the client function, if yes, operation S460 is performed, otherwise operation S440 is performed.

For example, if the first decompiled file of the framework file obtains a prototype of the client function, the client function is obtained by searching the client function identifier of the target service in the first decompiled file, and parameters of the client function are determined as interface information.

If the first decompiled file does not show the prototype of the client function, operation S440 is performed.

In operation S440, it is determined whether the interface information is extracted by the processing function, if yes, operation S460 is performed, otherwise operation S450 is performed.

For example, if the first decompiled file of the execution file obtains a prototype of the processing function, the processing function is obtained by searching the processing end function identifier of the target service in the second decompiled file, and the parameters of the client function are determined as the interface information of the target service. Or, the structural layout of the processing function is obtained, the sub-functions for realizing the service in the layout are determined according to the layout specification or standard, and the sub-functions are determined as the interface information of the target service.

If no prototype of the processing function is obtained in the second decompilation file, operation S450 is performed.

In operation S450, it is determined whether the data transferred through the server function extracts interface information. If yes, operation S460 is performed, otherwise the flow ends.

Searching a server function of the target service in the first decompilation, following the server function, determining the serialized data transferred to the processing function by using the server function, and analyzing the serialized data to obtain a data type, wherein the data type is used as interface information of the target service.

Since it is sequentially difficult to acquire the interface information of the target service in three ways of operations S430 to S450, the order of the three ways may be set, and after the acquisition failure in the way of operation S430, operation S440 is performed, and when the acquisition failure in operation S440 occurs, operation S450 is performed.

It should be noted that, in operations S430 to S450, the execution order may not be set, and at least one mode may be selected to obtain the interface information of the target service.

In operation S460, a test case is constructed according to the interface information.

The implementation of operation S460 is similar to that of operation S230, and will not be described again here.

In operation S470, the test data is transmitted to the target service for testing, and vulnerability data is monitored and collected.

According to an embodiment of the disclosure, the data to be tested is determined as parameters of a client function of the target service; transmitting the data to be tested to a server function of the target service through a client function of the target service; transmitting the data to be tested to the processing function through the server function of the target service; and running the processing function.

The test data is firstly used as parameters of the client function, and is transmitted to the server function by the client function, and then is transmitted to the processing function by the server function. And running a processing function, and processing the test data to obtain a return value.

If the operation of the processing function is abnormal or the return value is abnormal, the test data causing the abnormality can be determined to be vulnerability data, and the vulnerability data is reported, so that relevant personnel can repair the vulnerability.

Fig. 5 is a block diagram of a vulnerability detection apparatus of a target service according to one embodiment of the disclosure.

As shown in fig. 5, the vulnerability detection apparatus 500 of the target service includes an acquisition module 501, a determination module 502, a generation module 503, and a detection module 504.

The obtaining module 501 is configured to obtain a compiled file of a target service, where the compiled file includes a framework file and an execution file, and the framework file includes a general function and the execution file includes a processing function.

The determining module 502 is configured to determine interface information of the target service according to at least one of parameters of the general function, a structure of the processing function, and data transferred between the general function and the processing function.

The generating module 503 is configured to generate data to be tested according to the interface information.

The detection module 504 is configured to perform vulnerability detection using data to be tested.

According to an embodiment of the present disclosure, a compiled file is compiled from a source file of a target service, and a general function includes a client function for requesting the target service and a server function for implementing the target service.

The determination module 502 includes a first decompilation unit, a client function determination unit, and a first information determination unit.

The first decompilation unit is used for decompiling the frame file to obtain a first decompilation husband, and a general function in the first decompilation husband is consistent with a function defined in the source husband.

The client function determining unit is used for determining a client function of the target service from the first decompiled file.

The first information determining unit is used for determining interface information of the target service according to the parameter type of the client function of the target service.

The structure of the processing function includes a layout of a plurality of virtual functions. The determining module 502 further includes a second decompilation unit, an objective virtual function determining unit, and a second information determining unit.

The second decompilation unit is used for decompiling the execution file to obtain a second decompilation file, wherein the processing functions in the second decompilation file are consistent with the functions defined in the source file.

The target virtual function determining unit is used for determining the target virtual function according to the layout of the virtual functions in the second decompiled file.

The second information determining unit is used for determining interface information of the target service according to the parameter type of the target virtual function.

The determining module 502 further includes a server function determining unit, a serialized data determining unit, an parsing unit, and a third information determining unit.

The server function determining unit is used for determining a server function of the target service from the first decompiled file.

The serialization data determining unit is used for determining serialization data transferred between the server-side function and the processing function of the target service.

The parsing unit is used for parsing out the data type from the serialized data.

And the third information determining unit is used for determining the interface information of the target service according to the analyzed data type.

The detection module 504 includes a processing unit, a monitoring unit, and a vulnerability data determining unit.

And the processing unit is used for processing the data to be tested by using the target service.

The monitoring unit is used for monitoring the running state of the target service and the return data of the target service.

The vulnerability data determining unit is used for determining test data which enables at least one of the running state and the return data of the target service to be abnormal as vulnerability data.

The processing unit comprises a first transmission subunit, a second transmission subunit, a third transmission subunit and a running subunit.

The first transfer subunit is configured to determine the data to be tested as parameters of a client function of the target service.

The second transferring subunit is configured to transfer the data to be tested to a server function of the target service through a client function of the target service.

And the third transmission subunit is used for transmitting the data to be tested to the processing function through the server-side function of the target service.

The operation subunit is used for operating the processing function.

The interface information includes a parameter type. The generating module 503 is further configured to generate the data to be tested according to the parameter type, where the data type of the data to be tested is consistent with the parameter type.

According to embodiments of the present disclosure, the present disclosure also provides an electronic device, a readable storage medium and a computer program product.

Fig. 6 illustrates a schematic block diagram of an example electronic device 600 that may be used to implement embodiments of the present disclosure. Electronic devices are intended to represent various forms of digital computers, such as laptops, desktops, workstations, personal digital assistants, servers, blade servers, mainframes, and other appropriate computers. The electronic device may also represent various forms of mobile devices, such as personal digital processing, cellular telephones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their capabilities are meant to be exemplary only, and are not meant to limit implementations of the disclosure described and/or claimed herein.

As shown in fig. 6, the apparatus 600 includes a computing unit 601 that can perform various appropriate actions and processes according to a computer program stored in a Read Only Memory (ROM) 602 or a computer program loaded from a storage unit 608 into a Random Access Memory (RAM) 603. In the RAM 603, various programs and data required for the operation of the device 600 may also be stored. The computing unit 601, ROM 602, and RAM 603 are connected to each other by a bus 604. An input/output (I/O) interface 605 is also connected to bus 604.

Various components in the device 600 are connected to the I/O interface 605, including: an input unit 606 such as a keyboard, mouse, etc.; an output unit 607 such as various types of displays, speakers, and the like; a storage unit 608, such as a magnetic disk, optical disk, or the like; and a communication unit 609 such as a network card, modem, wireless communication transceiver, etc. The communication unit 609 allows the device 600 to exchange information/data with other devices via a computer network, such as the internet, and/or various telecommunication networks.

The computing unit 601 may be a variety of general and/or special purpose processing components having processing and computing capabilities. Some examples of computing unit 601 include, but are not limited to, a Central Processing Unit (CPU), a Graphics Processing Unit (GPU), various specialized Artificial Intelligence (AI) computing chips, various computing units running machine learning model algorithms, a Digital Signal Processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 601 performs the respective methods and processes described above, for example, a vulnerability detection method of a target service. For example, in some embodiments, the vulnerability detection method of the target service may be implemented as a computer software program tangibly embodied on a machine-readable medium, such as the storage unit 608. In some embodiments, part or all of the computer program may be loaded and/or installed onto the device 600 via the ROM 602 and/or the communication unit 609. When the computer program is loaded into the RAM 603 and executed by the computing unit 601, one or more steps of the vulnerability detection method of the target service described above may be performed. Alternatively, in other embodiments, the computing unit 601 may be configured to perform the vulnerability detection method of the target service in any other suitable way (e.g., by means of firmware).

Various implementations of the systems and techniques described here above may be implemented in digital electronic circuitry, integrated circuit systems, field Programmable Gate Arrays (FPGAs), application Specific Integrated Circuits (ASICs), application Specific Standard Products (ASSPs), systems On Chip (SOCs), complex Programmable Logic Devices (CPLDs), computer hardware, firmware, software, and/or combinations thereof. These various embodiments may include: implemented in one or more computer programs, the one or more computer programs may be executed and/or interpreted on a programmable system including at least one programmable processor, which may be a special purpose or general-purpose programmable processor, that may receive data and instructions from, and transmit data and instructions to, a storage system, at least one input device, and at least one output device.

Program code for carrying out methods of the present disclosure may be written in any combination of one or more programming languages. These program code may be provided to a processor or controller of a general purpose computer, special purpose computer, or other programmable data processing apparatus such that the program code, when executed by the processor or controller, causes the functions/operations specified in the flowchart and/or block diagram to be implemented. The program code may execute entirely on the machine, partly on the machine, as a stand-alone software package, partly on the machine and partly on a remote machine or entirely on the remote machine or server.

In the context of this disclosure, a machine-readable medium may be a tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. The machine-readable medium may be a machine-readable signal medium or a machine-readable storage medium. The machine-readable medium may include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples of a machine-readable storage medium would include an electrical connection based on one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

To provide for interaction with a user, the systems and techniques described here can be implemented on a computer having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to a user; and a keyboard and pointing device (e.g., a mouse or trackball) by which a user can provide input to the computer. Other kinds of devices may also be used to provide for interaction with a user; for example, feedback provided to the user may be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user may be received in any form, including acoustic input, speech input, or tactile input.

The systems and techniques described here can be implemented in a computing system that includes a background component (e.g., as a data server), or that includes a middleware component (e.g., an application server), or that includes a front-end component (e.g., a user computer having a graphical user interface or a web browser through which a user can interact with an implementation of the systems and techniques described here), or any combination of such background, middleware, or front-end components. The components of the system can be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include: local Area Networks (LANs), wide Area Networks (WANs), and the internet.

The computer system may include a client and a server. The client and server are typically remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other.

It should be appreciated that various forms of the flows shown above may be used to reorder, add, or delete steps. For example, the steps recited in the present disclosure may be performed in parallel, sequentially, or in a different order, provided that the desired results of the disclosed aspects are achieved, and are not limited herein.

The above detailed description should not be taken as limiting the scope of the present disclosure. It will be apparent to those skilled in the art that various modifications, combinations, sub-combinations and alternatives are possible, depending on design requirements and other factors. Any modifications, equivalent substitutions and improvements made within the spirit and principles of the present disclosure are intended to be included within the scope of the present disclosure.

Claims (17)

1. A vulnerability detection method of a target service, comprising:

acquiring a compiling file of a target service, wherein the compiling file comprises a frame file and an executing file, the frame file comprises a general function, and the executing file comprises a processing function;

determining interface information of the target service according to at least one of parameters of the general function, a structure of the processing function and data transferred between the general function and the processing function;

generating data to be tested according to the interface information; and

and performing vulnerability detection by using the data to be tested.

2. The method of claim 1, wherein the compiled file is compiled from a source file of the target service, the generic function comprising a client function for requesting the target service and a server function for implementing the target service; the determining the interface information of the target service includes:

Decompiling the frame file to obtain a first decompiled file, wherein a general function in the first decompiled file is consistent with a function defined in the source file;

determining a client function of the target service from the first decompiled husband; and

and determining the interface information of the target service according to the parameter type of the client function of the target service.

3. The method of claim 2, wherein the structure of the processing function comprises a layout of a plurality of virtual functions; the determining the interface information of the target service further includes:

decompiling the execution file to obtain a second decompiled file, wherein a processing function in the second decompiled file is consistent with a function defined in the source file;

determining a target virtual function according to the layout of the virtual functions in the second decompilation file; and

and determining the interface information of the target service according to the parameter type of the target virtual function.

4. A method according to claim 2 or 3, wherein said determining interface information of the target service further comprises:

determining a server function of the target service from the first decompiled file;

Determining the serialization data transferred between the server-side function of the target service and the processing function;

analyzing the data type from the serialized data; and

and determining interface information of the target service according to the analyzed data type.

5. The method of any of claims 2 to 4, wherein the using the data to be tested for vulnerability detection comprises:

processing the data to be tested by using the target service;

monitoring the running state of the target service and the return data of the target service; and

and determining test data which causes at least one of the running state and the return data of the target service to be abnormal as vulnerability data.

6. The method of claim 5, wherein the processing the data to be tested using the target service comprises:

determining the data to be tested as parameters of a client function of the target service;

transmitting the data to be tested to a server function of the target service through a client function of the target service;

transmitting the data to be tested to the processing function through the server function of the target service; and

And running the processing function.

7. The method of any of claims 1-6, wherein the interface information includes a parameter type; the generating the data to be tested according to the interface information comprises the following steps:

and generating the data to be tested according to the parameter type, wherein the data type of the data to be tested is consistent with the parameter type.

8. A vulnerability detection apparatus of a target service, comprising:

the system comprises an acquisition module, a processing module and a storage module, wherein the acquisition module is used for acquiring a compiling file of a target service, the compiling file comprises a frame file and an execution file, the frame file comprises a general function, and the execution file comprises a processing function;

a determining module, configured to determine interface information of the target service according to at least one of parameters of the general function, a structure of the processing function, and data transferred between the general function and the processing function;

the generation module is used for generating data to be tested according to the interface information; and

and the detection module is used for performing vulnerability detection by using the data to be tested.

9. The apparatus of claim 8, wherein the compiled file is compiled from a source file of the target service, the generic function comprising a client function for requesting the target service and a server function for implementing the target service; the determining module includes:

The first decompilation unit is used for decompiling the frame file to obtain a first decompilation file, and a general function in the first decompilation file is consistent with a function defined in the source file;

a client function determining unit, configured to determine a client function of the target service from the first decompiled file; and

and the first information determining unit is used for determining the interface information of the target service according to the parameter type of the client function of the target service.

10. The apparatus of claim 9, wherein the structure of the processing function comprises a layout of a plurality of virtual functions; the determination module further includes:

the second decompilation unit is used for decompiling the execution file to obtain a second decompilation file, wherein a processing function in the second decompilation file is consistent with a function defined in the source file;

the target virtual function determining unit is used for determining a target virtual function according to the layout of the virtual functions in the second decompiled file; and

and the second information determining unit is used for determining the interface information of the target service according to the parameter type of the target virtual function.

11. The apparatus of claim 9 or 10, wherein the determining module further comprises:

a server function determining unit, configured to determine a server function of the target service from the first decompiled file;

a serialized data determining unit, configured to determine serialized data transferred between a server function of the target service and the processing function;

the analysis unit is used for analyzing the data type from the serialized data; and

and the third information determining unit is used for determining the interface information of the target service according to the analyzed data type.

12. The apparatus of any one of claims 9 to 11, wherein the detection module comprises:

a processing unit for processing the data to be tested using the target service;

the monitoring unit is used for monitoring the running state of the target service and the return data of the target service; and

and the vulnerability data determining unit is used for determining test data which causes at least one of the running state and the return data of the target service to be abnormal as vulnerability data.

13. The apparatus of claim 12, wherein the processing unit comprises:

A first transfer subunit, configured to determine the data to be tested as parameters of a client function of the target service;

a second transferring subunit, configured to transfer, through a client function of the target service, the data to be tested to a server function of the target service;

a third transfer subunit, configured to transfer the data to be tested to the processing function through a server function of the target service; and

and the operation subunit is used for operating the processing function.

14. The apparatus of any of claims 8 to 13, wherein the interface information comprises a parameter type; the generating module is further configured to generate the data to be tested according to the parameter type, where the data type of the data to be tested is consistent with the parameter type.

15. An electronic device, comprising:

at least one processor; and

a memory communicatively coupled to the at least one processor; wherein,

the memory stores instructions executable by the at least one processor to enable the at least one processor to perform the method of any one of claims 1 to 7.

16. A non-transitory computer readable storage medium storing computer instructions for causing the computer to perform the method of any one of claims 1 to 7.

17. A computer program product comprising a computer program stored on at least one of a readable storage medium and an electronic device, which, when executed by a processor, implements the method according to any one of claims 1 to 7.