CN115244516A

CN115244516A - Service calling information acquisition method and device and service vulnerability testing method

Info

Publication number: CN115244516A
Application number: CN202080098251.1A
Authority: CN
Inventors: 郭子亮
Original assignee: Guangdong Oppo Mobile Telecommunications Corp Ltd; Shenzhen Huantai Technology Co Ltd
Current assignee: Guangdong Oppo Mobile Telecommunications Corp Ltd; Shenzhen Huantai Technology Co Ltd
Priority date: 2020-06-09
Filing date: 2020-06-09
Publication date: 2022-10-25
Also published as: WO2021248310A1

Abstract

A method and a device for acquiring service calling information and a method for testing service vulnerability are provided, wherein the method for acquiring the service calling information comprises the following steps: acquiring a service identifier of a target service to be called; carrying out class reflection analysis on the service identification; obtaining a first target class corresponding to the target service according to the class reflection analysis result; and when the first target class is matched with the reference class, performing calling information reflection analysis on the first target class to obtain service calling information corresponding to the target service.

Description

Service calling information acquisition method and device and service vulnerability testing method

Technical Field

The application relates to the technical field of service testing, in particular to a method, a device, a mobile terminal and a computer readable storage medium for acquiring service calling information, and a method, a device, a system, a mobile terminal and a computer readable storage medium for testing service vulnerabilities.

Background

The application program can call a service interface of the operating system in the running process so as to use the system service provided by the operating system. The system services can be tested by using the service call information of the service interface to check the response condition of the services.

Under the condition of no operating system source code, the method for determining service calling information by the traditional method mainly comprises the following steps: and manually reversing the operating system framework file to find service calling information provided by the system service.

However, this method requires a technician to perform reverse analysis on the framework files of the operating system manually, which is inefficient.

Disclosure of Invention

The embodiment of the application provides a method and a device for acquiring service calling information, a mobile terminal and a computer readable storage medium, and a method, a device, a system, a mobile terminal and a computer readable storage medium for service vulnerability testing can effectively improve the efficiency of acquiring service calling information.

A method for acquiring service calling information comprises the following steps:

when a service calling information acquisition instruction is received, acquiring a service identifier of a target service to be called;

performing class reflection analysis by taking the service identifier as a reflection object;

obtaining a first target class corresponding to the target service according to the class reflection analysis result;

when the first target class is matched with the reference class, the first target class is used as a reflection object to carry out calling information reflection analysis;

and obtaining service calling information corresponding to the target service according to the result of the calling information reflection analysis.

An apparatus for acquiring service invocation information, comprising:

the service identifier acquisition module is used for acquiring the service identifier of the target service to be called when receiving the service calling information acquisition instruction;

the class reflection module is used for carrying out class reflection analysis by taking the service identifier as a reflection object;

the class determining module is used for obtaining a first target class corresponding to the target service according to the result of the class reflection analysis;

the calling information reflection module is used for performing calling information reflection analysis by taking the first target class as a reflection object when the first target class is matched with the reference class;

and the calling information determining module is used for obtaining service calling information corresponding to the target service according to the result of the calling information reflection analysis.

A mobile terminal comprises a memory and a processor, wherein the memory stores a computer program, and the computer program causes the processor to execute the operation of the service calling information acquisition method when being executed by the processor.

A computer-readable storage medium on which a computer program is stored, which, when executed by a processor, implements the operations of the method for acquiring service invocation information.

The method, the device, the mobile terminal and the computer readable storage medium for acquiring the service calling information acquire the service identifier of the target service to be called; obtaining a first target class corresponding to the target service according to the class reflection analysis result of the service identifier; when the first target class is matched with the reference class, service calling information corresponding to the target service is obtained according to a calling information reflection analysis result of the first target class, and under the condition that no operating system source code exists, the calling information is obtained without a manual reverse analysis method, and the calling information of the service can be automatically and quickly obtained through gradual reflection analysis.

A service vulnerability testing method comprises the following steps:

acquiring service calling information of a target service to be called; the service calling information is determined according to the result of the calling information reflection analysis; the calling information reflection analysis is reflection analysis which is carried out by taking a first target class as a reflection object when the first target class is matched with a reference class; the first target class is obtained by performing class reflection analysis by taking a service identifier of the target service as a reflection object;

sending a calling instruction to a service interface of the target service according to the service calling information;

receiving first calling response information returned by the service interface according to the calling instruction;

and carrying out vulnerability test analysis according to the first call response information to obtain a vulnerability test result of the target service.

A vulnerability testing apparatus of a service, comprising:

the calling information acquisition module is used for acquiring service calling information of the target service to be called; the service calling information is determined according to the result of calling information reflection analysis; the calling information reflection analysis is reflection analysis which is carried out by taking a first target class as a reflection object when the first target class is matched with a reference class; the first target class is obtained by performing class reflection analysis by taking the service identifier of the target service as a reflection object;

the calling instruction sending module is used for sending a calling instruction to a service interface of the target service according to the service calling information;

the response information receiving module is used for receiving first calling response information returned by the service interface according to the calling instruction;

and the test result determining module is used for carrying out vulnerability test analysis according to the first call response information to obtain a vulnerability test result of the target service.

A mobile terminal comprises a memory and a processor, wherein the memory stores a computer program, and the computer program is executed by the processor to enable the processor to execute the operation of the vulnerability testing method of the service.

A computer-readable storage medium, on which a computer program is stored which, when executed by a processor, implements the operations of the vulnerability testing method of the service.

According to the service vulnerability testing method, device, mobile terminal and computer readable storage medium, the service calling information automatically obtained through gradual reflection analysis is obtained, the service interface of the target service is called according to the service calling information, the vulnerability testing result of the target service is obtained according to the response information returned by the service interface, manual reverse analysis of the calling information is not needed, and vulnerability testing efficiency can be effectively improved.

A vulnerability testing system of a service, comprising: a control end and an agent end which are connected with a network;

the control terminal is used for sending a service calling information acquisition instruction to the agent terminal;

the proxy end is used for acquiring the service identifier of the target service to be called when receiving the service calling information acquisition instruction; performing class reflection analysis by taking the service identifier as a reflection object; obtaining a first target class corresponding to the target service according to the class reflection analysis result; when the first target class is matched with the reference class, the first target class is used as a reflection object to carry out calling information reflection analysis; obtaining service calling information corresponding to the target service according to the result of the calling information reflection analysis;

the control terminal is also used for receiving the service calling information returned by the agent terminal; sending a calling instruction to a service interface of the target service according to the service calling information; receiving first calling response information returned by the service interface according to the calling instruction; and carrying out vulnerability test analysis according to the first call response information to obtain a vulnerability test result of the target service.

According to the vulnerability testing system of the service, the agent end automatically acquires the service calling information through gradual reflection analysis under the triggering of the control end, the control end calls the service interface of the target service according to the service calling information and obtains the vulnerability testing result of the target service according to the response information returned by the service interface, manual reverse analysis of the calling information is not needed, and the vulnerability testing efficiency can be effectively improved.

Drawings

In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings used in the embodiments or the prior art descriptions will be briefly described below, it is obvious that the drawings in the following description are only some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative efforts.

FIG. 1 is a flow diagram of a method for obtaining service invocation information in one embodiment;

FIG. 2 is a flow diagram of a method for obtaining service invocation information in another embodiment;

FIG. 3 is an application scenario diagram of a vulnerability testing method of a service in an embodiment;

FIG. 4 is a flow diagram of a method for vulnerability testing of services in one embodiment;

FIG. 5 is a block diagram showing an exemplary configuration of a device for acquiring service invocation information;

FIG. 6 is a block diagram of a vulnerability testing apparatus of the service in one embodiment;

FIG. 7 is a block diagram that illustrates the architecture of a vulnerability testing system of the service in one embodiment;

FIG. 8 is a diagram illustrating an internal structure of a mobile terminal according to an embodiment;

fig. 9 is a schematic diagram of the internal structure of a server in another embodiment.

Detailed Description

In order to make the objects, technical solutions and advantages of the present application more clearly understood, the present application is further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the present application and are not intended to limit the present application.

In an embodiment, as shown in fig. 1, a method for acquiring service invocation information is provided, and this embodiment is illustrated by applying the method to a terminal, it may be understood that the method may also be applied to a server, and may also be applied to a system including the terminal and the server, and is implemented by interaction between the terminal and the server. The terminal can be, but is not limited to, various personal computers, notebook computers, smart phones, tablet computers and portable wearable devices, and the server can be implemented by an independent server or a server cluster consisting of a plurality of servers. In some embodiments, the method may also be applied to an application or plug-in configured on the terminal.

As shown in fig. 1, a method for acquiring service invocation information includes operations S101 to S105. The concrete description is as follows:

operation S101: and when receiving a service calling information acquisition instruction, acquiring a service identifier of the target service to be called.

A service may be referred to herein as a system service (system services), which refers to a program, routine, or process that performs specified system functions in order to support other programs. The system may refer to an operating system configured on the terminal, and may be an operating system such as Android (Android), windows, IOS, and the like. When an application needs to use a certain service (or test a certain service), an interface corresponding to the service can be called to apply the function provided by the service. Further, the Android system service may be a service component running in a system service process in the terminal device configured with the Android system, and may be called by the common app through the Binder.

The service call information refers to information that can call a service interface, and may include an interface number, a call number (which may be simply referred to as a call number), a call parameter, and the like. In addition, a service may include multiple methods, and therefore, when a specific method in the service is to be called, the service call information may further include a method name, a call parameter, and the like.

Further, the service call information acquisition instruction refers to an instruction that triggers the service call information acquisition program to start execution. And the terminal starts to execute the service identifier acquisition program and the subsequent reflection analysis program when receiving the service calling information acquisition instruction.

The target service is a service to be called for which the present service calling information obtaining method is directed, that is, after the present service calling information obtaining method is executed, the target service can be called based on the obtained service calling information. The target service may refer to all or part of the service in the operating system. Further, the service invocation information obtaining instruction may include service selection information used for indicating the service selected by the user, and in this case, the target service may refer to a system service corresponding to the service selection information. If the service invocation information does not contain the service selection information, the target service can be determined according to preset rules, for example: all the system services are determined as target services, or the target services are selected from the system services through a certain algorithm, or the target services are randomly determined from the system services.

In addition, for an Android system, two Android system services are provided, one is a Java layer system service, the programming language is Java, and the Java layer system service is usually customized by a manufacturer and has no open source code; another is at the native layer system service for starting the upper layer service or providing the basic operation environment to the upper layer system service, such as ServiceManager, and the writing language is generally c/c + +. The embodiment of the invention can acquire the service calling information of the Java layer system service so as to carry out vulnerability test on the Java layer system service.

The service identifier is information for identifying a target service, and may be represented by a service name (ServiceName), a service number, a function implementation code of the service, or the like. Further, the service identifier of the target service may be obtained by performing identifier query from a service identifier database, and using the queried identifier as the service identifier of the target service; the service identification may also be determined by reflection or the like.

Operation S102: and performing class reflection analysis by taking the service identifier as a reflection object.

The reflection is a mechanism provided by the Java programming language for obtaining the bytecode of any class at a running Time (Runtime) other than the Compile Time (compiler Time), and can reflect and obtain information such as an interface, a variable, a method and the like. The information obtained by reflection may be used to invoke methods in the service.

Further, in operation S102, the information provided by the ServiceManager is subjected to reflection analysis by using the service identifier as a reflection object, and since the result of the reflection analysis is the class of the service managed by the ServiceManager, the embodiment of the present invention refers to the reflection analysis as class reflection analysis.

The ServiceManager is a special system service, which is started before other system services and can provide service registration and service retrieval functions for the outside. The embodiment of the invention performs step-by-step reflection analysis based on the ServiceManager, and can obtain service calling information.

Operation S103: and obtaining a first target class corresponding to the target service according to the class reflection analysis result.

The Class (Class) is the basis for implementing information encapsulation by Object-Oriented Programming (OOP). A class is a user-defined type of reference data, also called a class type. Instances of classes are referred to as objects.

This step obtains a first target class according to the result of the class reflection analysis. The results of this type of reflection analysis may contain information related to the first target class, such as: class name, class and other parameters of the first target class.

Operation S104: and when the first target class is matched with the reference class, performing calling information reflection analysis by taking the first target class as a reflection object.

The reference class may be a predetermined class related to the running of the application, for example, a class corresponding to a Java layer system service. Specifically, the reference class may be a class named aaa.bbb.ccc.stub or aaa.bbb.ccc.stub.proxy. The aaa, bbb, ccc may be replaced according to actual situations, and when performing class matching judgment, it is mainly checked whether suffixes of the first target class name are still, proxy, etc., and if so, the first target class is considered to be matched with the reference class.

Further, in an embodiment, after the step of performing the class reflection analysis by using the service identifier as a reflection object, the method further includes: determining a class identifier corresponding to the first target class according to the result of the class reflection analysis; and when the class identification is matched with a preset reference class identification, judging that the first target class is matched with the reference class.

The class identifier refers to information capable of identifying a class, and information capable of uniquely representing the first target class can be determined from the result of the class reflection analysis, and the information can be used as the class identifier of the first target class. In addition, the reference class id refers to a predetermined class id for picking out a first target class that conforms to a predetermined type, and may refer to the above-mentioned "Stub", "Proxy", "Stub.

In one embodiment, the step of determining the class identifier corresponding to the first target class according to the result of the class reflection analysis includes: obtaining the class name of the first target class according to the result of the class reflection analysis; and determining the class identification according to the class name of the first target class.

Further, the result of the class reflection analysis on the service identifier is a class name, and if the first target class contains suffixes such as "Stub", "Proxy", "Stub", and the like, it can be determined that the first target class matches the reference class. Further, if the first target class satisfies the following condition: name! If = null & & name.equals (serviceClass + ". Stub"), the first target class may be considered to match the reference class.

In addition, when the target service is multiple, the first target class may also be multiple, and at this time, the first target classes may be compared with reference classes (the reference classes compared with different target classes may be the same or different), so as to perform subsequent reflection analysis processing on the first target classes meeting the condition.

Operation S105: and obtaining service calling information corresponding to the target service according to the result of the calling information reflection analysis.

When the first target class is matched with the reference class, the first target class is the class to be searched, and service calling information such as a method name, a calling number, a calling parameter and the like related to the target service can be obtained by further performing reflection analysis on the first target class. Therefore, the embodiment of the present invention refers to this reflection analysis as call information reflection analysis.

The method for acquiring the service calling information acquires the service identifier of the target service to be called; obtaining a first target class corresponding to the target service according to the class reflection analysis result of the service identifier; when the first target class is matched with the reference class, service calling information corresponding to the target service is obtained according to a calling information reflection analysis result of the first target class, and under the condition of no operating system source code, the calling information is obtained without a manual reverse analysis method, and the calling information of a specific service (such as Java layer system service) can be automatically and quickly obtained through gradual reflection analysis. The manual work of reverse analysts can be liberated, the relevant information of the system service interface can be automatically generated, and a foundation is laid for subsequent fuzzy tests (such as vulnerability tests on services).

In an embodiment, the step of acquiring, when receiving the service invocation information acquisition instruction, the service identifier of the target service to be invoked includes: when a service calling information acquisition instruction is received, carrying out calling reflection analysis on a service enumeration interface in a service manager so as to trigger the service enumeration interface to return system service information; the system service information is information of services managed by the service manager; acquiring the system service information returned by the service enumeration interface; and acquiring the service name of the target service from the system service information as the service identifier.

The service manager may be a service capable of managing services of the operating system, and may be the ServiceManager. The service enumeration interface may refer to an interface having a function of service information enumeration (also referred to as enumeration), and may be a listServices interface in the java system. In this embodiment, the terminal obtains the service name of the target service by calling the listServices interface in the ServiceManager.

The operating system manages the service through the service manager, and thus the service managed by the service manager may refer to the service corresponding to the operating system. Further, the system service information may include a service name, service description information (information describing a function realized by the service), and the like.

Specifically, a listServices interface in the ServiceManager may be called, and the listServices interface lists system service information. The terminal may then identify the symbol, position, etc. from the enumerated system service information, and obtain a service name ServiceName (which may also be referred to as a system service name or service name) from the identified symbol, position, etc., for example: information in front of the middle bracket [ ] is determined as a service name, or information in a header field in the system service information is determined as a service name.

Further, the system service information enumerated through the listServices interface may be:

run XX.ssfuzzer.getservicesinfo

0:sip[android.net.sip.ISipService]

1:dpmservice[Unkown Service！]

2:com.qualcomm.location.izat.IzatService[com.qti.izat.IIzatService]

3:secure_element[Unkown Service！]

4:oiface[com.oppo.oiface.IOIfaceService]

5:neoservice[Unkown Service！]

6:omedia[com.oppo.omedia.IOMediaService]

7:qti.ims.ext[org.codeaurora.ims.internal.IQtiImsExt]

8:carrier_config[com.android.internal.telephony.ICarrierConfigLoader]

9:phone[com.android.internal.telephony.ITelephony]

where run xx. Ssfuzzer. Getservicinfo is a call instruction to the listServices interface. And the listServices interface responds to the calling instruction and then outputs a system service list, wherein the system service list comprises ten pieces of system service information with the serial numbers from 0 to 9. Wherein, the information in the middle bracket [ ] is service description information, and the information in front of [ ] is the service name. Take 7 qti.im.ext [ org.codearira.im.internal.iqtiimis ext ] as an example, "7" represents the number of the service in the system service list, "qti.im.ext" represents the service name, "org.codec.im.internal.iqtiimis ext" represents the service description information.

Further, when determining the service name, the terminal device may first identify the location of the [ ], and determine the information in front of the [ ] as the service name.

The embodiment acquires the system service information by calling the service listing interface, and then determines the service identifier according to the system service information, the determination process is simple, the determination can be realized by a simple calling code, and the acquisition efficiency of the calling service information can be effectively improved.

In one embodiment, the number of the first target classes may be one, two or even more. When the number of the first target classes is two or more, reflection analysis can be respectively performed on the first target classes in a synchronous or asynchronous mode, and service calling information corresponding to the first target classes is respectively obtained and used as service calling information corresponding to target services.

Taking a first target class as an example, in an embodiment, the step of performing call information reflection analysis by using the first target class as a reflection object includes: taking the class name of the first target class as a reflection object to perform calling number reflection analysis to obtain a calling number (TransactionCode) of the target service; acquiring a class name of a second target class; the second target class is an inner class of the first target class; when the class name of the second target class is matched with a preset reference class name, performing calling parameter reflection analysis by using the class name of the second target class as a reflection object to obtain a calling parameter; and obtaining a result of the calling information reflection analysis according to the calling number and the calling parameter.

The reference class name may be a specific type of class name, for example, a class name containing a method name and a call parameter in java. In particular, the suffix may contain the class name of Proxy.

Further, in an embodiment, the step of performing call parameter reflection analysis by using the class name of the second target class as a reflection object to obtain a call parameter includes: respectively performing method name reflection analysis and parameter value reflection analysis by taking the class name of the second target class as a reflection object to obtain a method name and a parameter value of the target service; and obtaining the calling parameter according to the Method name (Method) and the parameter value (attributes).

In some embodiments, the class name of the second target class may also be used as a reflection object to perform a reflection analysis, and according to the writing rule of java, a corresponding method name and parameter values may be obtained after the reflection analysis.

Further, in an embodiment, the step of performing call number reflection analysis by using the class name of the first target class as a reflection object to obtain the call number of the target service includes: taking the class name of the first target class as a reflection object to carry out calling number reflection analysis; and determining a member variable value corresponding to the reference number identification from the result of the call number reflection analysis as the call number of the target service.

The reference number is a number for distinguishing the calling number, and may be transport.

Further, an integer value of the determined member variable values may be determined as a call number of the target service.

The specific implementation process of the above embodiment may be as follows:

execute qti.im.ext [ org.codeoura.im.internal.iqtiimsext ] this call number reflection analysis statement. The following call number reflection analysis results can be obtained:

Java Method:

setHandoverConfig(14)[u'int',u'int',u'interface org.codeaurora.ims.internal.IQtiImsExtListener']

getCallForwardUncondTimer(2)[u'int',u'int',u'int',u'interface org.codeau-rora.ims.internal.IQtiImsExtListener']

setRcsAppConfig(16)[u'int',u'int']

the numbers inside the parentheses in each Java Method are the values of the member variables starting with transport _ one by one. An example is setHandoverConfig (14), meaning that qti.ims.ext has a setHandoverConfig interface with a call number of 14. The determination of the call number 14 may be as follows:

1. calling servicemanager.getservice ("qti.im.ext") to obtain < ServiceName >;

2. judging whether the < ServiceName >. Stub exists or not;

3. if yes, acquiring all member variables beginning with 'TANSATION _';

4. one member variable was found to be TRANSACTION _ setHandoverConfig, which has a value of 14.

It can be seen that the call number reflection analysis result includes the beginning of "TANSIACTION _" implicitly, and the corresponding integer value can be determined as the call number.

In the embodiment, the corresponding calling information is obtained by performing reflection analysis on the class names of the first target class and the second target class, the determination process is simple, and meanwhile, the detailed information such as the calling number, the method name, the calling parameter and the like can be obtained, and the calling of the service interface can be accurately realized according to the information.

In some embodiments, if the interface call function can be constructed by only calling one or part of the number, name, and parameters, only one or part of the above embodiments may be performed.

In one embodiment, the acquisition procedure of the service invocation information may be triggered by entering a command line in the terminal. The command line may include service selection information (also referred to as command line parameters) of the service to be called, so as to obtain service calling information of the selected target service in a targeted manner. Of course, the command line may not have service selection information, and the service invocation information may be acquired according to the situation, for example: service invocation information for all services in the operating system may be obtained.

Further, the step of acquiring the service identifier of the target service to be called when the service calling information acquisition instruction is received includes: when the service calling information acquisition instruction carries service selection information, determining a reference service corresponding to the service selection information from services of an operating system; and determining the service identification of the reference service as the service identification of the target service.

In another embodiment, the step of acquiring the service identifier of the target service to be called when the service calling information acquisition instruction is received includes: and when the service calling information acquisition instruction does not carry service selection information, determining the service identifier of each service of the operating system as the service identifier of the target service.

Further, in the case where the command line parameter is not provided, all system services are enumerated by default. In the case of providing command line parameters, system services may be enumerated specifically, such as: the system service qti.im.ext can be enumerated by a command line parameter "-a qti.im.ext", and when the command line parameter "run xx.ssfuzzer.getservicessinfo-a qti.im.ext" is run, the system service qti.im.ext is used as a target service, and then the system service information of the system service is enumerated, and the service call information of the system service is obtained according to further reflection analysis. Wherein, "-a" is a code symbol for triggering an enumeration procedure, and may be implemented by other symbols.

Fig. 2 is a flowchart illustrating a method for acquiring service invocation information in one embodiment. Taking a plug-in (which may be called a proxy) configured on a terminal as an example for explanation, the method includes the following steps:

s201, communicating with a ServiceManager, reflecting and acquiring a ServiceManager object, calling a listServices interface therein, and acquiring all system service names, servicenames.

S202, for a specific ServiceName, determining whether the ServiceName class has an internal class named < ServiceName >. Stub by reflection. If yes, the system service is described as a Java layer system service, and the process continues to execute S203. If the system service does not exist, the system service is described as a Native system service, and the enumeration of the calling method and the parameters thereof is not attempted.

S203, the reflection obtains the value of the member variable beginning with "transport _" in < ServiceName >. Stub, and the value is the call number of the system service interface.

S204, reflecting and acquiring all method names and calling parameters under the < ServiceName >. Stub.proxy to obtain an interface calling method and calling parameters of the system service.

And S205, outputting service calling information according to the calling number, the interface calling method and the calling parameters thereof.

According to the method for acquiring the service call information provided by the embodiment, the system service name (ServiceName) is acquired by a method for calling a listService interface in a ServiceManager in a reflection manner according to the Android Binder system service implementation principle and characteristics; whether a Stub class corresponding to the service name exists is judged in a reflection mode through the system service name, and if yes, a Java layer system service is found; then, obtaining the values of all integer member variables beginning with 'TRANSACTION _' under the Stub class again through reflection, wherein the values are the interface calling numbers (TransactionCodes) of the system service; finally, all Method names and Method parameters in the Proxy class are obtained through reflection, and the Method names and the Method parameters are interface calling methods (methods) and parameters (constructs). The embodiment can automatically and quickly acquire the calling information of the service through gradual reflection analysis without acquiring the calling information through a manual reverse analysis method under the condition of no operating system source code.

Fig. 3 is a schematic application environment diagram of a vulnerability testing method of a service in an embodiment. As shown in fig. 3, the application environment includes a control side 301 and an agent side 302, which can perform network communication. The control end 301 sends trigger information to the agent end 301 to control the agent end 302 to obtain service calling information, then the control end 301 calls the service interface, and performs vulnerability testing according to calling response information returned by the service interface to obtain a vulnerability testing result. Both the control end 301 and the proxy end 302 may be implemented by a terminal device or a server. Further, the terminal device may be, but not limited to, various personal computers, notebook computers, smart phones, tablet computers, and portable wearable devices, and the server may be implemented by an independent server or a server cluster formed by a plurality of servers. The proxy 301 may be the terminal in the foregoing embodiment, or may also be an application program or a plug-in configured in the terminal in the foregoing embodiment, so as to implement the method for acquiring the service invocation information.

In an embodiment, as shown in fig. 4, a service vulnerability testing method is provided, and this embodiment is exemplified by applying the method to a control terminal (which may be a specific terminal device, or an application program) in fig. 4. As shown in fig. 4, a vulnerability testing method of a service includes operations S401 to S404.

Operation S401: acquiring service calling information of a target service to be called; the service calling information is determined according to the result of calling information reflection analysis; the calling information reflection analysis is reflection analysis which is carried out by taking a first target class as a reflection object when the first target class is matched with a reference class; the first target class is obtained by performing class reflection analysis by using the service identifier of the target service as a reflection object.

The control terminal can send a service calling information acquisition instruction to the proxy terminal to trigger the proxy terminal to acquire service calling information of the target service and return the acquired service calling information to the control terminal.

For the implementation manner of obtaining the service invocation information of the target service by the proxy side, reference may be made to the embodiment of the method for obtaining the service invocation information, which is not described herein again.

In some embodiments, the service invocation information may also be obtained from a pre-built database. The service calling information in the database may be the service calling information generated by the agent terminal and then stored in the database.

Operation S402: and sending a calling instruction to a service interface of the target service according to the service calling information.

The service calling information comprises related information for calling the service interface, so that a calling instruction can be sent to the service interface according to the service calling information. The calling instruction can trigger the target service to complete a corresponding executive program and generate first calling response information when the calling instruction is received through the service interface. Of course, when the target service is restarted or a process is killed, the target service may not be able to respond to the call instruction, and the call response information at this time may be: and the target service does not respond, and the target service process fails and the information related to the service running state.

Operation S403: and receiving first call response information returned by the service interface according to the call instruction.

The control terminal interfaces first call response information returned by the target service through the service interface. The first call response information may include response information of the target service to the call instruction, an operation state of the service interface/the target service, and the like.

Operation S404: and carrying out vulnerability test analysis according to the first call response information to obtain a vulnerability test result of the target service.

The first call response information comprises the response condition of the target service/service interface to the call instruction, so that vulnerability test analysis can be performed, whether the target service stores the vulnerability or not is further determined, and a vulnerability test result is obtained.

Further, vulnerability test analysis can be performed on the processes in the service according to the first call response information, so that vulnerability test results of the various system service processes are determined.

In an embodiment, the step of performing vulnerability test analysis according to the first call response information to obtain a vulnerability test result of the target service includes: acquiring system running state information; and carrying out vulnerability test analysis according to the first call response information and the system running state information to obtain a vulnerability test result of the target service.

The ServiceManager maintains a list of all system services in the Android system, and the common App can call a system service interface in the ServiceManager to use the system services provided by the Android system, thereby realizing the safety test of the system services. From the perspective of security testers, the system service interfaces are also attack surfaces exposed by the Android system, and the system service interfaces can be used for testing high-authority system service processes, observing the response conditions of the high-authority system service processes and further discovering bugs. Under the condition that a system service interface realizes source codes, the work is easier, and because the method name and the method parameters of the system service realization are known, a program can be directly compiled to call the system service interface; however, in the case of only one OEM (Original Equipment manager) handset under test, without a system service to implement source code, the difficulty is serious. One of the methods is to manually reverse an Android system frame in a mobile phone, and use a method for manually searching for an Android system service interface, under an Android 9.0 condition, a service.vdex file in the mobile phone needs to be extracted to a computer terminal, then the vdex file is converted into a cdex file, then the cdex file is converted into a dex file, and then the dex file is opened by using a reverse tool such as JEB or JD-GUI, so that binary files such as service.odex realized in the mobile phone are reversely analyzed, characteristics of system service realization codes are searched completely depending on the experience of an analyst, and then the realization of system services is searched by means of the experience of the analyst.

According to the vulnerability testing method of the service, under the condition that no system service realizes a source code, the system service name, the calling number, the interface calling method and the parameters of the Java layer system service of the Android mobile phone are automatically obtained, the manual work of a reverse analysis person can be liberated, the vulnerability testing efficiency can be effectively improved, and a foundation is laid for the subsequent fuzzy testing. Meanwhile, through the vulnerability security test, the operating system can be adjusted according to the vulnerability test result so as to ensure the normal operation of the operating system.

Furthermore, after the system service interface is called, whether the vulnerability exists can be judged according to the response condition and the system performance. For example, in the process of calling the system service interface, the system may restart/a process may be killed, which may be a characteristic of judging whether a bug exists, but if it is still impossible to determine that a bug exists, the bug test process for the target service may be completed by combining other bug test data, in which case, calling the system interface may help to find out the bug.

In one embodiment, the service invocation information includes a service name, an invocation number, a method name, and a parameter value; the step of sending a call instruction to the service interface of the target service according to the service call information includes: acquiring first input data; generating an interface calling function according to the service name, the calling number, the method name and the parameter value; and sending a calling instruction carrying the first input data to the service interface according to the interface calling function so that the service interface generates and returns the first calling response information according to the first input data.

The input data can be sent to the target service in the process of calling the service interface, so that the target service carries out response operation on the input data, and the result obtained by the operation can be used as first calling response information.

The procedure of generating the interface call function may be exemplified as follows: suppose that the calling method name is setHandoverConfig, the calling number is 14, and the calling parameters include three: the first and second parameters are int type, the third parameter is an interface named org. According to the information, the following interface calling functions can be generated:

setHandoverConfig(int,int,org.codeaurora.ims.internal.IQtiImsExtListener)

according to the embodiment, the interface calling function is generated by combining the service calling information, and then the calling instruction is sent to the service interface so as to carry out vulnerability test analysis according to the calling response information returned by the service interface, the implementation process is simple, manual reverse analysis is not needed for obtaining the service calling information, and the whole vulnerability test analysis process has high efficiency.

In one embodiment, the input data can be further processed out of order, the system service interface is repeatedly called, and then whether the vulnerability exists or not is judged according to the system response condition and the system performance. Specifically, the step of performing vulnerability test analysis according to the first call response information to obtain a vulnerability test result of the target service includes: acquiring second input data; the second input data is data obtained by performing out-of-order processing on the first input data; sending a calling instruction carrying the second input data to the service interface according to the interface calling function so that the service interface generates and returns second calling response information according to the second input data; receiving second calling response information returned by the service interface; and carrying out vulnerability test analysis according to the first call response information and the second call response information to obtain a vulnerability test result of the target service.

Furthermore, the first input data can be subjected to multiple disorder processing, the input data obtained through the disorder processing is input into the target service, so that the response condition of the target service to the input data is obtained, the vulnerability test result is further obtained, and the obtained test result has high accuracy.

It should be understood that, although the respective operations in the above-described flowcharts are sequentially shown as indicated by arrows, the operations are not necessarily sequentially performed in the order indicated by the arrows. The operations may be performed in other sequences without a strict order of limitation unless explicitly stated otherwise. Moreover, at least a portion of the operations in the above-described flowcharts may include multiple sub-operations or multiple stages, which are not necessarily performed at the same time, but may be performed at different times, and the order of execution of the sub-operations or stages is not necessarily sequential, but may be performed in turn or alternately with other operations or at least a portion of the sub-operations or stages of other operations.

Fig. 5 is a block diagram of an apparatus 500 for acquiring service invocation information according to an embodiment. As shown in fig. 5, an apparatus for acquiring service invocation information includes a service identifier acquiring module 501, a class reflection module 502, a class determination module 503, an invocation information reflection module 504, and an invocation information determination module 505. Wherein:

the service identifier obtaining module 501 is configured to, when receiving the service calling information obtaining instruction, obtain a service identifier of a target service to be called.

A class reflection module 502, configured to perform class reflection analysis by using the service identifier as a reflection object.

A class determining module 503, configured to obtain a first target class corresponding to the target service according to the result of the class reflection analysis.

And the calling information reflection module 504 is configured to perform calling information reflection analysis by using the first target class as a reflection object when the first target class is matched with the reference class.

And the calling information determining module 505 is configured to obtain service calling information corresponding to the target service according to the result of the calling information reflection analysis.

The device for acquiring the service calling information acquires a service identifier of a target service to be called; obtaining a first target class corresponding to the target service according to the class reflection analysis result of the service identifier; when the first target class is matched with the reference class, service calling information corresponding to the target service is obtained according to a calling information reflection analysis result of the first target class, and under the condition that no operating system source code exists, the calling information is obtained without a manual reverse analysis method, and the calling information of the service can be automatically and quickly obtained through gradual reflection analysis.

In one embodiment, the apparatus further comprises: the class identifier determining module is used for determining a class identifier corresponding to the first target class according to the result of the class reflection analysis; and the matching judgment module is used for judging that the first target class is matched with the reference class when the class identification is matched with a preset reference class identification.

In one embodiment, the service identification obtaining module includes: the calling reflection submodule is used for carrying out calling reflection analysis on a service enumeration interface in the service manager when receiving a service calling information acquisition instruction so as to trigger the service enumeration interface to return system service information; the system service information is information of services managed by the service manager; the service information acquisition submodule is used for acquiring the system service information returned by the service listing interface; and the service name acquisition submodule is used for acquiring the service name of the target service from the system service information as the service identifier.

In one embodiment, the class identification determination module includes: the first class name acquisition sub-module is used for acquiring the class name of the first target class according to the result of the class reflection analysis; and the class identifier acquisition sub-module is used for determining the class identifier according to the class name of the first target class.

In one embodiment, invoking the information reflection module comprises: the number reflection submodule is used for carrying out calling number reflection analysis by taking the class name of the first target class as a reflection object to obtain a calling number of the target service; the second class name acquisition submodule is used for acquiring the class name of a second target class; the second target class is an inner class of the first target class; the parameter reflection sub-module is used for performing calling parameter reflection analysis by taking the class name of the second target class as a reflection object when the class name of the second target class is matched with a preset reference class name to obtain a calling parameter; and the reflection result determining submodule is used for obtaining the result of the calling information reflection analysis according to the calling number and the calling parameter.

In one embodiment, the parametric reflective submodule comprises: the first reflection unit is used for performing method name reflection analysis and parameter value reflection analysis on the class name of the second target class serving as a reflection object respectively to obtain a method name and a parameter value of the target service; and the calling parameter acquisition unit is used for obtaining the calling parameter according to the method name and the parameter value.

In one embodiment, the numbered reflection sub-module comprises: the second reflection unit is used for calling number reflection analysis by taking the class name of the first target class as a reflection object; and the calling number acquisition unit is used for determining the member variable value corresponding to the reference number mark from the calling number reflection analysis result as the calling number of the target service.

In one embodiment, the service identification obtaining module includes: the service determining submodule is used for determining a reference service corresponding to the service selection information from the service of the operating system when the service calling information acquisition instruction carries the service selection information; and the service identifier determining submodule is used for determining the service identifier of the reference service as the service identifier of the target service.

In an embodiment, the service identifier obtaining module is further configured to determine, when the service call information obtaining instruction does not carry service selection information, a service identifier of each service of the operating system as the service identifier of the target service.

FIG. 6 is a block diagram of an exemplary vulnerability testing apparatus 600. As shown in fig. 6, a vulnerability testing apparatus for a service includes a calling information obtaining module 601, a calling instruction sending module 602, a response information receiving module 603, and a testing result determining module 604. Wherein:

a calling information obtaining module 601, configured to obtain service calling information of a target service to be called; the service calling information is determined according to the result of calling information reflection analysis; the calling information reflection analysis is reflection analysis which is carried out by taking a first target class as a reflection object when the first target class is matched with a reference class; the first target class is obtained by performing class reflection analysis by using the service identifier of the target service as a reflection object.

A calling instruction sending module 602, configured to send a calling instruction to a service interface of the target service according to the service calling information.

A response information receiving module 603, configured to receive first call response information returned by the service interface according to the call instruction.

The test result determining module 604 is configured to perform vulnerability test analysis according to the first call response information, so as to obtain a vulnerability test result of the target service.

The vulnerability testing device of the service acquires the service calling information automatically acquired through step-by-step reflection analysis, calls the service interface of the target service according to the service calling information, and obtains the vulnerability testing result of the target service according to the response information returned by the service interface, and the vulnerability testing efficiency can be effectively improved without manual reverse analysis of the calling information.

In an embodiment, the step of performing vulnerability test analysis according to the first call response information to obtain a vulnerability test result of the target service includes: acquiring second input data; the second input data is obtained by carrying out disorder processing on the first input data; sending a calling instruction carrying the second input data to the service interface according to the interface calling function, so that the service interface generates and returns second calling response information according to the second input data; receiving second calling response information returned by the service interface; and carrying out vulnerability test analysis according to the first call response information and the second call response information to obtain a vulnerability test result of the target service.

The division of each module in the apparatus for acquiring service invocation information is only used for illustration, and in other embodiments, the apparatus for acquiring service invocation information may be divided into different modules as needed to complete all or part of the functions of the apparatus for acquiring service invocation information. The service vulnerability testing device has the same principle, and is not described herein again.

In one embodiment, a vulnerability testing system of a service is provided, the architectural diagram of which may be parameterized by FIG. 3. The system comprises a control end and an agent end which are connected through a network. Wherein:

and the control terminal is used for sending a service calling information acquisition instruction to the agent terminal.

The proxy end is used for acquiring the service identifier of the target service to be called when receiving the service calling information acquisition instruction; performing class reflection analysis by taking the service identifier as a reflection object; obtaining a first target class corresponding to the target service according to the class reflection analysis result; when the first target class is matched with the reference class, the first target class is used as a reflection object to carry out calling information reflection analysis; and obtaining service calling information corresponding to the target service according to the result of the calling information reflection analysis.

According to the vulnerability testing system of the service, the agent end automatically obtains the service calling information through gradual reflection analysis under the trigger of the control end, the control end calls the service interface of the target service according to the service calling information and obtains the vulnerability testing result of the target service according to the response information returned by the service interface, manual reverse analysis of the calling information is not needed, and the vulnerability testing efficiency can be effectively improved.

In one embodiment, the framework of the vulnerability testing system of the service may be a Drozer-based testing framework, implemented by two testing plug-ins, a control side and an agent side. The two test plug-ins can be respectively configured in different terminal devices.

In one embodiment, the agent is configured in a terminal device, and the terminal device runs with a service manager; and the proxy end is also used for communicating with a service manager through a cross-process communication tool when receiving the service calling information acquisition instruction so as to acquire the service identifier of the target service.

The cross-Process Communication tool may be a tool capable of implementing IPC (Inter-Process Communication). Further, the cross-process communication tool may be referred to as Binder, etc. Furthermore, a Client process (Client) where the agent is located can communicate with a Server process (Server) providing services through the Binder.

Further, the vulnerability testing system of the service may be implemented by a control end (Console) 701 and an Agent end (Agent) 702 in FIG. 7. The Console is configured on the PC side, the Agent is configured on the mobile phone side, and the Console and the Agent can communicate through the adb protocol. The Agent communicates with a Service Manager (Service Manager) by means of IPC. The IPC approach is described from user mode 703 (a normal App typically runs in user mode). Many invisible important codes run in the kernel mode (e.g. 704 in fig. 7), and implement important functions such as memory management, file management, process management, and the like. The user mode runs on the kernel mode, and fig. 7 mainly shows the IPC communication between the user mode agent and the servicemanager, which is actually performed by the Binder driver of the kernel mode.

Further, on the PC side, the Console may provide the user with a function of acquiring an enumeration system service interface through a command line, that is, the user may obtain enumeration information of the system service by inputting the command line on the PC side, and may further know service call information thereof.

For the PC side, the Agent may be a common Android App, which communicates with the ServiceManager process through the Binder-based IPC, acquires all system service interface names through the listServices interface provided by the ServiceManager, and then acquires the interface calling Method number (TransactionCode) and the interface calling Method name (Method) of a specific system service and its parameters (instructions) through the reflection call.

For specific limitations on the vulnerability testing apparatus and the system for obtaining the service invocation information, reference may be made to the above limitations on the method for obtaining the service invocation information, which is not described herein again. All or part of each module in the vulnerability testing device and the vulnerability testing system of the service can be realized by software, hardware and a combination of the software and the hardware. The modules can be embedded in a hardware form or independent of a processor in the computer device, and can also be stored in a memory in the computer device in a software form, so that the processor can call and execute operations corresponding to the modules.

The service call information obtaining device and the service vulnerability testing device provided in the embodiment of the present application may be implemented in the form of a computer program. The computer program may be run on a mobile terminal or a server. Program modules formed by the computer program may be stored on the memory of the mobile terminal or the server. Which, when executed by a processor, performs the operations of the methods described in the embodiments of the present application.

The embodiment of the application also provides the mobile terminal. The mobile terminal comprises a memory and a processor, wherein the memory stores a computer program, and the computer program causes the processor to execute the operation of the service calling information acquisition method when being executed by the processor.

The embodiment of the application also provides a computer readable storage medium. A computer-readable storage medium on which a computer program is stored, which, when executed by a processor, implements the operations of the method of acquiring the service invocation information.

The embodiment of the application also provides the mobile terminal. The mobile terminal comprises a memory and a processor, wherein the memory stores a computer program, and the computer program causes the processor to execute the operation of the vulnerability testing method of the service when being executed by the processor.

The embodiment of the application also provides a computer readable storage medium. A computer-readable storage medium, on which a computer program is stored which, when executed by a processor, implements the operations of the vulnerability testing method of the service.

Fig. 8 is a schematic internal structure diagram of a mobile terminal according to an embodiment. As shown in fig. 8, the mobile terminal includes a processor, a memory, and a network interface connected through a system bus. Wherein, the processor is used for providing calculation and control capability and supporting the operation of the whole mobile terminal. The memory is used for storing data, programs and the like, and the memory stores at least one computer program which can be executed by the processor to realize the wireless network communication method suitable for the mobile terminal provided by the embodiment of the application. The memory may include a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The computer program can be executed by a processor to implement a method for acquiring service call information provided in the following embodiments. The internal memory provides a cached execution environment for the operating system computer programs in the non-volatile storage medium. The network interface may be an ethernet card or a wireless network card, and is used for communicating with an external mobile terminal. The mobile terminal can be a mobile phone, a tablet computer, a personal digital assistant or a wearable device.

Fig. 9 is a schematic internal structure diagram of a mobile terminal in another embodiment. As shown in fig. 9, the mobile terminal includes a processor, a memory, a communication interface, a display screen, and an input device, which are connected through a system bus. Wherein the processor of the mobile terminal is configured to provide computing and control capabilities. The memory of the mobile terminal comprises a nonvolatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operating system and the computer program to run on the non-volatile storage medium. The communication interface of the mobile terminal is used for carrying out wired or wireless communication with an external terminal, and the wireless communication can be realized through WIFI (wireless fidelity), an operator network, NFC (near field communication) or other technologies. The computer program is executed by a processor to implement a method of vulnerability testing of a service. The display screen of the mobile terminal can be a liquid crystal display screen or an electronic ink display screen, and the input device of the mobile terminal can be a touch layer covered on the display screen, a key, a track ball or a touch pad arranged on a shell of the mobile terminal, an external keyboard, a touch pad or a mouse and the like.

A computer program product comprising instructions which, when run on a computer, cause the computer to perform a method of obtaining service invocation information.

A computer program product containing instructions which, when run on a computer, cause the computer to perform a method of vulnerability testing of a service.

Any reference to memory, storage, database or other medium used herein may include non-volatile and/or volatile memory. Suitable non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically Programmable ROM (EPROM), electrically Erasable Programmable ROM (EEPROM), or flash memory. Volatile memory can include Random Access Memory (RAM), which acts as external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms such as Static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), synchronous Link DRAM (SLDRAM), rambus (Rambus) direct RAM (RDRAM), direct bused dynamic RAM (DRDRAM), and Rambus Dynamic RAM (RDRAM).

The above-mentioned embodiments only express several embodiments of the present application, and the description thereof is more specific and detailed, but not construed as limiting the scope of the present application. It should be noted that, for a person skilled in the art, several variations and modifications can be made without departing from the concept of the present application, which falls within the scope of protection of the present application. Therefore, the protection scope of the present patent shall be subject to the appended claims.

Claims

A method for acquiring service calling information is characterized by comprising the following steps:

when a service calling information acquisition instruction is received, acquiring a service identifier of a target service to be called;

performing class reflection analysis by taking the service identifier as a reflection object;

obtaining a first target class corresponding to the target service according to the class reflection analysis result;

when the first target class is matched with the reference class, the first target class is used as a reflection object to carry out calling information reflection analysis;

and obtaining service calling information corresponding to the target service according to the result of the calling information reflection analysis.
The method of claim 1, further comprising, after the step of performing a class reflection analysis using the service identifier as a reflection object:

determining a class identifier corresponding to the first target class according to the result of the class reflection analysis;

and when the class identification is matched with a preset reference class identification, judging that the first target class is matched with the reference class.
The method according to claim 2, wherein the step of obtaining the service identifier of the target service to be called when receiving the service calling information obtaining instruction comprises:

when a service calling information acquisition instruction is received, carrying out calling reflection analysis on a service enumeration interface in a service manager so as to trigger the service enumeration interface to return system service information; the system service information is information of services managed by the service manager;

acquiring the system service information returned by the service enumeration interface;

and acquiring the service name of the target service from the system service information as the service identifier.
The method according to claim 2, wherein the step of determining the class identifier corresponding to the first target class according to the result of the class reflection analysis comprises:

obtaining the class name of the first target class according to the result of the class reflection analysis;

and determining the class identification according to the class name of the first target class.
The method of claim 4, wherein the step of invoking information reflection analysis using the first target class as a reflection object comprises:

taking the class name of the first target class as a reflection object to perform calling number reflection analysis to obtain a calling number of the target service;

acquiring a class name of a second target class; the second target class is an inner class of the first target class;

when the class name of the second target class is matched with a preset reference class name, performing calling parameter reflection analysis by taking the class name of the second target class as a reflection object to obtain a calling parameter;

and obtaining the result of the calling information reflection analysis according to the calling number and the calling parameter.
The method according to claim 5, wherein the step of performing call parameter reflection analysis by using the class name of the second target class as a reflection object to obtain a call parameter comprises:

respectively performing method name reflection analysis and parameter value reflection analysis by taking the class name of the second target class as a reflection object to obtain a method name and a parameter value of the target service;

and obtaining the calling parameter according to the method name and the parameter value.
The method according to claim 5, wherein the step of performing call number reflection analysis by using the class name of the first target class as a reflection object to obtain the call number of the target service comprises:

taking the class name of the first target class as a reflection object to carry out calling number reflection analysis;

and determining a member variable value corresponding to the reference number identification from the result of the call number reflection analysis as the call number of the target service.
The method according to any one of claims 1 to 7, wherein the step of obtaining the service identifier of the target service to be called when receiving the service calling information obtaining instruction comprises:

when the service calling information acquisition instruction carries service selection information, determining a reference service corresponding to the service selection information from services of an operating system;

and determining the service identifier of the reference service as the service identifier of the target service.
The method according to any one of claims 1 to 7, wherein the step of obtaining the service identifier of the target service to be called when receiving the service calling information obtaining instruction comprises:

and when the service calling information acquisition instruction does not carry service selection information, determining the service identifier of each service of the operating system as the service identifier of the target service.
A service vulnerability testing method is characterized by comprising the following steps:

acquiring service calling information of a target service to be called; the service calling information is determined according to the result of calling information reflection analysis; the calling information reflection analysis is reflection analysis which is carried out by taking a first target class as a reflection object when the first target class is matched with a reference class; the first target class is obtained by performing class reflection analysis by taking the service identifier of the target service as a reflection object;

sending a calling instruction to a service interface of the target service according to the service calling information;

receiving first calling response information returned by the service interface according to the calling instruction;

and carrying out vulnerability test analysis according to the first call response information to obtain a vulnerability test result of the target service.
The method of claim 10, wherein the service invocation information includes a service name, a call number, a method name, and a parameter value;

the step of sending a call instruction to the service interface of the target service according to the service call information includes:

acquiring first input data;

generating an interface calling function according to the service name, the calling number, the method name and the parameter value;

and sending a calling instruction carrying the first input data to the service interface according to the interface calling function so that the service interface generates and returns the first calling response information according to the first input data.
The method according to claim 11, wherein the step of performing vulnerability testing analysis according to the first call response information to obtain a vulnerability testing result of the target service comprises:

acquiring second input data; the second input data is data obtained by performing out-of-order processing on the first input data;

sending a calling instruction carrying the second input data to the service interface according to the interface calling function, so that the service interface generates and returns second calling response information according to the second input data;

receiving second calling response information returned by the service interface;

and carrying out vulnerability test analysis according to the first call response information and the second call response information to obtain a vulnerability test result of the target service.
The method according to any one of claims 10 to 12, wherein the step of performing vulnerability testing analysis according to the first call response information to obtain a vulnerability testing result of the target service includes:

acquiring system running state information;

and carrying out vulnerability test analysis according to the first call response information and the system running state information to obtain a vulnerability test result of the target service.
An apparatus for acquiring service invocation information, comprising:

the service identifier acquisition module is used for acquiring the service identifier of the target service to be called when receiving the service calling information acquisition instruction;

the class reflection module is used for carrying out class reflection analysis by taking the service identifier as a reflection object;

the class determination module is used for obtaining a first target class corresponding to the target service according to the result of the class reflection analysis;

the calling information reflection module is used for performing calling information reflection analysis by taking the first target class as a reflection object when the first target class is matched with the reference class;

and the calling information determining module is used for obtaining service calling information corresponding to the target service according to the result of the calling information reflection analysis.
A vulnerability testing apparatus of a service, comprising:

the calling information acquisition module is used for acquiring service calling information of the target service to be called; the service calling information is determined according to the result of calling information reflection analysis; the calling information reflection analysis is reflection analysis which is carried out by taking a first target class as a reflection object when the first target class is matched with a reference class; the first target class is obtained by performing class reflection analysis by taking the service identifier of the target service as a reflection object;

the calling instruction sending module is used for sending a calling instruction to a service interface of the target service according to the service calling information;

the response information receiving module is used for receiving first calling response information returned by the service interface according to the calling instruction;

and the test result determining module is used for carrying out vulnerability test analysis according to the first call response information to obtain the vulnerability test result of the target service.
A vulnerability testing system of a service, comprising: a control end and an agent end which are connected with a network;

the control terminal is used for sending a service calling information acquisition instruction to the proxy terminal;

the proxy end is used for acquiring the service identifier of the target service to be called when receiving the service calling information acquisition instruction; performing class reflection analysis by taking the service identifier as a reflection object; obtaining a first target class corresponding to the target service according to the class reflection analysis result; when the first target class is matched with the reference class, the first target class is used as a reflection object to carry out calling information reflection analysis; obtaining service calling information corresponding to the target service according to the result of the calling information reflection analysis;

the control terminal is also used for receiving the service calling information returned by the agent terminal; sending a calling instruction to a service interface of the target service according to the service calling information; receiving first calling response information returned by the service interface according to the calling instruction; and carrying out vulnerability test analysis according to the first call response information to obtain a vulnerability test result of the target service.
The system according to claim 16, wherein the agent is configured in a terminal device, and the terminal device runs a service manager;

and the proxy end is also used for communicating with a service manager through a cross-process communication tool when receiving the service calling information acquisition instruction so as to acquire the service identifier of the target service.
A mobile terminal comprising a memory and a processor, the memory having stored thereon a computer program, characterized in that the computer program, when executed by the processor, causes the processor to carry out the steps of the method according to any of claims 1 to 9.
A mobile terminal comprising a memory and a processor, the memory having stored thereon a computer program, characterized in that the computer program, when executed by the processor, causes the processor to carry out the steps of the method according to any of claims 10 to 13.
A computer-readable storage medium, on which a computer program is stored which, when being executed by a processor, carries out the steps of the method according to any one of claims 1 to 9.
A computer-readable storage medium, on which a computer program is stored, which, when being executed by a processor, carries out the steps of the method according to any one of claims 10 to 13.