A detection method and system for application binding service vulnerabilities

Abstract

This invention discloses a method and system for detecting vulnerabilities in application-bound services. First, relevant information about the application to be detected is collected, and preliminary extraction of application component information is performed to filter candidate applications and service components. Then, the publicly exposed binding service RPC interface of the application is located, and all its callable methods are extracted. The decompiled method code is obtained, and inputs triggering method vulnerabilities are constructed. Corresponding test application cases are generated, and fuzz testing is performed on the candidate RPC methods on a test device to analyze the impact and discover vulnerabilities. This achieves vulnerability detection for custom binding services in Android system applications.

Description

Technical Field

[0001] This invention relates to the field of vulnerability detection technology, and in particular to a method and system for detecting vulnerabilities in application-bound services. Background Technology

[0002] Service binding refers to associating a service (such as a database, API, or other application) with a client program in a network or software system, enabling the client to invoke the service's functions. In the Android operating system, service binding is an important component for implementing inter-process communication (IPC).

[0003] Inter-Process Communication (IPC) is a mechanism for communication between different processes. In the Android operating system, since applications and system services typically run in different processes, a mechanism is needed to support communication and data exchange between them. Android's IPC mechanism is primarily based on the Binder driver. Binder is an IPC mechanism in Android that provides an efficient way to communicate across processes. There are three main roles in the Binder mechanism: the client, the server, and the Binder driver, which handles the communication between them. A Service is a component used to perform long-running tasks in the background or handle remote requests. Services can communicate with clients through a binding mechanism (which returns a Binder object that implements the interface). The binding mechanism allows clients to establish a connection with a Service and interact through that connection. Most of the core functionality of the Android system is broken down into separate System Services components, allowing third-party applications to securely and indirectly access protected resources.

[0004] Because Android system services possess a large amount of system resources and high-level permissions, their security issues have attracted considerable attention. Numerous studies in recent years have uncovered many security problems, including incomplete documentation, permission redelegance, inconsistent access control, and a lack of input exception handling. As people's lives become increasingly reliant on mobile applications, these applications themselves have become a significant source of sensitive user data, especially basic applications providing services such as office work, social networking, and shopping. Furthermore, the services exposed by some privileged pre-installed applications also pose significant security risks. However, the problems existing in custom service interfaces for Android system applications have received little discussion and research. Summary of the Invention

[0005] This invention provides a method and system for detecting vulnerabilities in application-bound services, thereby enabling vulnerability detection of custom-bound services in Android system applications.

[0006] This invention provides a method for detecting application-bound service vulnerabilities, comprising:

[0007] Extract the installation package file from the application to be tested;

[0008] The installation package file is decoded to obtain the application manifest file, and the application manifest file is parsed to obtain the exposed service components;

[0009] The binary file of the application to be detected is disassembled to obtain assembly code. Static analysis is performed on the assembly code to identify services that can be bound from the exposed service components.

[0010] Obtain the RPC implementation method of the service that can be bound;

[0011] The interface call processing method is selected from the RPC implementation method. The abstract syntax tree of the interface call processing method is extracted and parsed to obtain the call interface number and name description information, as well as the relevant operations for reading and writing packets. The condition information of the interface branch is analyzed to obtain the type of input variable and the constraint information of the call method. The field composition of the custom type input variable used to construct complex variable types is also extracted. The call interface number, the name description information, the type of input variable, the constraint information of the call method, and the field composition of the custom type input variable are used as the input information of the RPC implementation method call interface.

[0012] Static analysis is performed on the conditional statements, loop structures, and data flow in the code of the RPC implementation method to obtain the input variable dependencies of the RPC implementation method.

[0013] A constraint-based test generation method and combined test technology are adopted. Based on the input information of the RPC implementation method call interface and the dependency relationship of the input variables of the RPC implementation method, input values ​​that meet the set conditions are generated, and test cases for input variables are obtained.

[0014] The input information of the RPC implementation method call interface, the test cases of the input variables, and the exposed service component information of the RPC implementation method are stored in the test device. The test program is installed on the test device to perform dynamic fuzz testing and obtain vulnerability detection conclusions.

[0015] Specifically, the static analysis of the assembly code to identify services that can be bound from the exposed service components includes:

[0016] Based on the service name of the exposed service component, traverse the exposed service class code one by one and check whether the class method contains a binding method;

[0017] If the binding method is not found in the current service class, continue to check whether its inherited parent class has overridden the binding method, until the service base class is found.

[0018] Check if the return type of the binding method is the Binder class or its subclasses. Determine if each class inherits from the Binder class by extracting the class inheritance relationship. If so, the service can be bound, and the bindable service is obtained.

[0019] Specifically, the method for obtaining the RPC implementation of the bindable service includes:

[0020] Retrieve all interface methods registered in the interface inheritance chain of the return Binder class of the service that can be bound, and find the RPC implementation method of all interface methods from all subclasses.

[0021] Specifically, in the process of finding the RPC implementation methods of all interface methods from all subclasses, the search proceeds sequentially from the subclass to the parent class, ensuring that the RPC implementation methods in the subclass are not overridden by the parent class; if the current class does not implement the interface, the code of all methods of the class and its subclasses is extracted.

[0022] Specifically, the step of selecting interface call processing methods from the RPC implementation methods includes:

[0023] The RPC implementation method is decompiled to obtain the programming code;

[0024] The programming code is input into the analysis model for analysis, and sensitive candidate RPC implementation methods are output.

[0025] The interface call processing method is selected from the candidate RPC implementation methods.

[0026] This invention also provides a detection system for application-bound service vulnerabilities, comprising:

[0027] The installation package file extraction module is used to extract the installation package file from the application to be detected.

[0028] The file parsing module is used to decode the installation package file to obtain the application manifest file, and to parse the application manifest file to obtain the exposed service components;

[0029] The static analysis module is used to disassemble the binary file of the application to be detected to obtain assembly code, perform static analysis on the assembly code, and identify services that can be bound from the exposed service components.

[0030] The RPC implementation method acquisition module is used to acquire the RPC implementation method of the service that can be bound.

[0031] The interface input information generation module is used to filter out interface call processing methods from the RPC implementation methods, extract and parse the abstract syntax tree of the interface call processing methods, obtain the interface number and name description information and related operations for reading and writing packets, analyze the condition information of the interface branches, obtain the type of input variables and the constraint information of the call methods, and also extract the field composition of custom type input variables used to construct complex variable types. The interface number, the name description information, the type of input variables, the constraint information of the call methods and the field composition of the custom type input variables are used as the RPC implementation method call interface input information.

[0032] The input variable dependency generation module is used to perform static analysis on the conditional statements, loop structures and data flow in the code of the RPC implementation method to obtain the input variable dependency of the RPC implementation method.

[0033] The input variable test case generation module is used to generate input values ​​that meet set conditions by using a constraint-based test generation method and combined test technology, based on the input information of the RPC implementation method call interface and the dependency relationship of the input variables of the RPC implementation method, and thus obtain input variable test cases.

[0034] The vulnerability detection module is used to store the input information of the RPC implementation method call interface, the test cases of the input variables, and the exposed service component information of the RPC implementation method into the test device, install the test program on the test device to perform dynamic fuzz testing, and obtain vulnerability detection conclusions.

[0035] Specifically, the static analysis module includes:

[0036] The disassembly unit is used to disassemble the binary file of the application to be detected to obtain assembly code;

[0037] The binding method query unit is used to traverse the exposed service class code one by one according to the service name of the exposed service component and check whether the class method contains a binding method; if the binding method is not found in the current service class, it continues to check whether its inherited parent class has overridden the binding method, until it is traced back to the service base class and the binding method is found.

[0038] The service binding query unit is used to check whether the return type of the binding method is the Binder class or its subclasses. It determines whether each class inherits from the Binder class by extracting the class inheritance relationship of each class. If so, the service can be bound, and the bindable service is obtained.

[0039] Specifically, the RPC implementation method acquisition module is used to acquire all interface methods registered in the interface inheritance chain of the return Binder class of the bindable service, and find the RPC implementation methods of all interface methods from all subclasses.

[0040] Specifically, the interface input information generation module includes:

[0041] The decompilation unit is used to decompile the RPC implementation method to obtain programming code;

[0042] The sensitive candidate RPC implementation method analysis unit is used to input the programming code into the analysis model for analysis and output the sensitive candidate RPC implementation methods.

[0043] An interface call processing method filtering unit is used to filter out interface call processing methods from the candidate RPC implementation methods;

[0044] The interface call input information generation unit is used to extract and parse the abstract syntax tree of the interface call processing method, obtain the interface call number and name description information, as well as the relevant operations for reading and writing packets, analyze the condition information of the interface branches, obtain the type of input variables and the constraint information of the call method, and also extract the field composition of custom type input variables used to construct complex variable types. The interface call number, the name description information, the type of input variables, the constraint information of the call method, and the field composition of the custom type input variables are used as the input information of the RPC implementation method call interface.

[0045] One or more technical solutions provided in this invention have at least the following technical effects or advantages:

[0046] 1. First, collect relevant information about the application to be tested, complete the initial extraction of application component information, and filter out candidate applications and service components; then locate the application's publicly exposed binding service RPC interface, extract all its callable methods, obtain the decompiled method code, construct the input to trigger the method vulnerability, and generate corresponding test application cases to perform fuzz testing on the candidate RPC methods on the test device, analyze the impact and discover vulnerabilities, thereby realizing the vulnerability detection of custom binding services of Android system applications.

[0047] 2. This invention implements an effective method for extracting custom-bound services of applications and identifying candidate RPCs that pose security risks. By disassembling and performing precise static analysis on the application installation package, combined with the use of a large model for method screening, it can quickly identify potential targets, reduce manual input, narrow the scope of analysis and verification, and improve vulnerability detection efficiency.

[0048] 3. This invention employs a dynamic fuzz testing method to further discover and exploit vulnerabilities in candidate RPC methods detected by static analysis. It collects input information and its dependencies through static analysis, and constructs input features that can trigger vulnerabilities using a constraint-based test generation method and combined testing techniques. The test is then automatically executed in a test device or simulator by relying on the test program. Vulnerabilities are discovered by analyzing and observing test logs and device status, and vulnerability verification is further completed. Attached Figure Description

[0049] Figure 1 A flowchart illustrating a method for detecting application-bound service vulnerabilities provided in an embodiment of the present invention;

[0050] Figure 2 This is a schematic diagram of a method for detecting application-bound service vulnerabilities provided in an embodiment of the present invention.

[0051] Figure 3 This is a block diagram of a detection system for application binding service vulnerabilities provided in an embodiment of the present invention. Detailed Implementation

[0052] This invention provides a method and system for detecting vulnerabilities in application binding services, thereby enabling vulnerability detection of custom binding services in Android system applications.

[0053] The technical solutions in the embodiments of the present invention are designed to achieve the above-mentioned technical effects, and the overall concept is as follows:

[0054] For attack scenarios involving application-bound services: Suppose an attacker discovers an exposed, bindable service within an application. They can attempt to bind to this vulnerable service by publishing a malicious third-party application. They inject carefully crafted transaction inputs into the acquired handle object (e.g., Binder). The server-side application parses the input parameters in the handle object and calls the corresponding function. This can lead to a series of problems, such as denial-of-service attacks, privilege escalation, arbitrary code execution, leakage of sensitive information, and disruption of normal business functionality, depending on the payload and the target of the malicious transaction.

[0055] To detect application-specific service binding vulnerabilities, this invention proposes a method for such detection. The method includes: 1) Reverse engineering and disassembling the application installation package using reverse engineering tools, combined with static analysis techniques such as inheritance relationship analysis, control flow graph analysis, and type inference to accurately extract the application's custom-defined service binding and its exposed RPC methods. Based on the decompiled code, a large model is used to filter out candidate RPC methods with security risks, quickly identifying potential targets and narrowing the scope of analysis and verification; 2) By deeply analyzing the service binding communication process, the attack model is clarified, and dynamic fuzzing is used to further discover and exploit vulnerabilities in the statically detected candidate RPC methods. Input information and its dependencies are collected through static analysis. Constraint-based test generation methods and combined testing techniques are used to construct input features that can trigger vulnerabilities. Tests are automatically executed on real devices or simulators using test programs. Vulnerabilities are discovered by analyzing and observing test logs and device status, further completing vulnerability verification. This combination of static and dynamic analysis efficiently and accurately discovers relevant vulnerabilities and directly reproduces vulnerability exploitation scenarios.

[0056] To better understand the above technical solutions, the following will provide a detailed explanation of the technical solutions in conjunction with the accompanying drawings and specific implementation methods.

[0057] like Figure 1 and Figure 2 As shown, the detection method for application binding service vulnerabilities provided in this embodiment of the invention includes:

[0058] Step S110: Extract the installation package file from the application to be tested;

[0059] This step involves scraping applications from major mobile app stores and extracting the applications to be analyzed from real devices. Python web scraping techniques and the ARIA2 tool are used to download third-party applications in batches from mainstream app stores (e.g., Xiaomi, Huawei, Samsung, etc.). Pre-installed applications are installed on devices by the manufacturer or carrier at the factory; they are usually integrated into the device's system partition and are generally not available from app stores. To collect as many pre-installed applications as possible from various mobile phone manufacturers' systems, and given the inability to collect a sufficient number of real devices, static analysis tools are used to extract the installation package files (e.g., APK files) of pre-installed applications from system image files.

[0060] Step S120: Decode the installation package file to obtain the application manifest file, and parse the application manifest file to obtain the exposed service components;

[0061] This step is explained in detail. Using the JEB reverse engineering tool, the installation package file is unpacked, and the exposed service components are obtained by parsing the manifest file. After opening the installation package file, an analysis context is generated. The application's metadata and manifest file are analyzed. The service nodes with the `android:exported` attribute set to `true` are extracted from the application's manifest file, or the nodes are checked for implicit intent-filtering to identify exported service components. Ultimately, the information about the service components exposed by the application is obtained, including the service name, implicit intent-filtering rules, and the permissions required to call the service.

[0062] Step S130: Disassemble the binary file of the application to be tested to obtain assembly code, perform static analysis on the assembly code, and find the services that can be bound from the exposed service components;

[0063] This includes performing static analysis on the assembly code to identify services that can be bound from the exposed service components, including:

[0064] Based on the service name of the exposed service component, traverse the exposed service class code one by one and check whether the class method contains a binding method;

[0065] If the binding method is not found in the current service class, continue to check whether its inherited parent class has overridden the binding method, until the service base class is found.

[0066] Check if the return type of the binding method is the Binder class or its subclasses. Determine if each class inherits from the Binder class by extracting the class inheritance relationship. If so, the service can be bound, and the bindable service is obtained.

[0067] Specifically, the code of each exposed service class is traversed one by one according to the service name. The class methods are checked to see if they contain a binding method named onBind, which takes an Intent object as a parameter and is responsible for receiving the binding intent passed through Binder communication. If the binding method is not found in the current service class, the code continues to check whether its inherited parent class has overridden the binding method, until the service base class is reached and the binding service is found.

[0068] Next, we analyze the binding methods in the bound service class and the return object types of these methods. We construct a control flow graph (CFG) for each method's code block and extract the exit blocks for analysis. We iterate through each exit block, checking if the last executed statement contains a return instruction and obtaining the return type and value. Since we are analyzing assembly instruction code, the parameter information obtained from return and related instructions (if any) is only the register values ​​and types. Therefore, we need to continue analyzing subsequent instructions for type inference. Based on the instruction content, we mainly analyze instructions that set the target register to a constant and those that handle instance objects. During the analysis, we consider combining class and interface inheritance relationships and reference assignment statements for dynamic type inference. This is due to the polymorphism of Java, where the object's type is not determined by the declared type but by the specific type of the object at runtime. This makes the object type determination more accurate and reduces false positives when further analyzing class method and field calls.

[0069] Finally, check if the return type of the binding method is the Binder class or its subclasses. Determine if each class inherits from the Binder class by extracting the class inheritance relationship. If so, the binding service can be bound.

[0070] Step S140: Obtain the RPC implementation method of the service that can be bound;

[0071] This step provides a detailed explanation of how to obtain the RPC implementation method of the service that can be bound, including:

[0072] Retrieve all interface methods registered in the interface inheritance chain of the Binder class that can be bound to the service, and find the RPC implementation methods of all interface methods in all subclasses.

[0073] To accurately locate all RPC implementation methods, the search proceeds sequentially from subclass to parent class during the process of finding the RPC implementation methods of all interface methods in all subclasses, ensuring that the RPC implementation methods in subclasses are not overridden by the parent class; if the current class does not implement an interface, the code of all methods of that class and its subclasses is extracted.

[0074] Step S150: Select the interface call processing method (onTransact method) from the RPC implementation method, extract the abstract syntax tree (AST) of the interface call processing method and parse it, obtain the call interface number and name description information and the relevant operations for reading and writing packets, analyze the condition information of the interface branch, obtain the type of input variable and the constraint information of the call method, and also extract the field composition of the custom type input variable used to construct complex variable types. Use the call interface number, name description information, type of input variable, constraint information of the call method and field composition of the custom type input variable as the input information of the RPC implementation method call interface.

[0075] To exclude non-sensitive RPC implementation methods and reduce the workload of manual inspection, the interface call processing methods are selected from the RPC implementation methods, including:

[0076] The RPC implementation method is decompiled to obtain the programming code;

[0077] The programming code is input into the analysis model for analysis, and the output yields sensitive candidate RPC implementation methods. Specifically, the output is guided by calling the ChatGPT-3.5-turbo large model, adjusting the prompt, and setting custom instructions. The following design principles are followed when constructing prompts: 1) Role setting; 2) Clear and explicit instructions; 3) Providing necessary context; 4) Standardizing result output; 5) Multiple rounds of testing and adjustment. Specifically, the task description specifies whether the model's judgment method has security risks, clarifies the attack scenarios, and supplements domain background knowledge. Since the code contains nested function calls, the relevant method code also needs to be extracted to improve the analysis context. Considering a maximum nesting depth of 5, the implementation code of the abstract call method is also extracted.

[0078] Select the interface call handling method from the candidate RPC implementation methods.

[0079] Step S160: Perform static analysis on the conditional statements, loop structures, and data flow in the RPC implementation method code to obtain the input variable dependencies of the RPC implementation method;

[0080] Step S170: Using a constraint-based test generation method and combinatorial testing technology, based on the input information of the RPC implementation method call interface and the dependency relationship of the input variables of the RPC implementation method, input values ​​that meet the set conditions are generated, and different combinations of variable values ​​are systematically explored to improve test coverage and obtain test cases for input variables;

[0081] Step S180: Store the input information of the RPC implementation method call interface, the input variable test cases, and the exposed service component information of the RPC implementation method into the test device, install the test program on the test device to perform dynamic fuzz testing, and draw vulnerability detection conclusions.

[0082] This step involves writing a test application to execute test cases on a specific interface. This test application can be a simple client responsible for calling RPC methods in the application under test. Based on the component information of the candidate RPC methods, and considering cases where specific permissions are required for service method calls, the Manifest file needs to be modified during test program development to set the application's package name and permissions. Finally, the test application is packaged. The test program reads the input file, sets the intent object based on the interface and component information, assigns and instantiates variables according to the input variables and test cases, constructs the data packet payload in the intent, and directly triggers the Binder event to call the `transact` method.

[0083] Before testing, install both the test application and the application under test on the test device or emulator. Open the test application and start the test; the system will automatically execute the constructed test cases and monitor the device's response. During this process, errors, abnormal behaviors, and potential vulnerabilities can be checked by observing test logs, monitoring device status, and capturing network traffic. Various abnormal situations may be triggered during testing, such as unhandled exceptions, crashes, or performance degradation. These issues can be analyzed in detail using captured log information to help the development team identify the root causes. Furthermore, an alert mechanism can be set up based on specific anomaly patterns to promptly detect and record potential vulnerabilities. Finally, based on the observation results, a detailed application vulnerability detection report is generated.

[0084] like Figure 3 As shown, the detection system for application binding service vulnerabilities provided in this embodiment of the invention includes:

[0085] The installation package file extraction module 100 is used to extract the installation package file from the application to be detected.

[0086] Specifically, the installation package file extraction module 100 is used to crawl applications from major mobile app stores and extract applications to be analyzed from real devices. Python web scraping technology and the ARIA2 tool are used to download third-party applications in batches from mainstream app stores (e.g., Xiaomi, Huawei, Samsung, etc.). Pre-installed applications are installed on devices by the device manufacturer or operator at the factory; they are usually integrated into the device's system partition and are generally not available from app stores. To collect as many pre-installed applications as possible from multiple mobile phone manufacturers' systems, and given the inability to collect a sufficient number of real devices, static analysis tools are used to extract the installation package files (e.g., APK files) of pre-installed applications from system image files.

[0087] The file parsing module 200 is used to decode the installation package file to obtain the application manifest file, and to parse the application manifest file to obtain the exposed service components.

[0088] Specifically, the file parsing module 200 is used to unpack the installation package file using JEB reverse engineering tools and obtain the exposed service components by parsing the manifest file. After opening the installation package file, an analysis context environment is generated. The application's metadata and manifest file are analyzed. By parsing the application's manifest file, service nodes with the `android:exported` attribute set to `true` are extracted, or the nodes are checked for implicit intent-filtering to identify exported service components. Ultimately, the application's exposed service component information is obtained, including the service name, implicit intent-filtering rules, and the permissions required to call the service.

[0089] The static analysis module 300 is used to disassemble the binary file of the application to be tested to obtain assembly code, perform static analysis on the assembly code, and find the services that can be bound from the exposed service components.

[0090] Specifically, the static analysis module 300 includes:

[0091] The disassembly unit is used to disassemble the binary file of the application to be tested to obtain assembly code;

[0092] The binding method query unit is used to traverse the exposed service class code one by one according to the service name of the exposed service component and check whether the class method contains a binding method; if the binding method is not found in the current service class, it continues to check whether its inherited parent class has overridden the binding method, until it is traced back to the service base class and the binding method is found.

[0093] The service binding query unit is used to check whether the return type of the binding method is the Binder class or its subclasses. It determines whether each class inherits from the Binder class by extracting the class inheritance relationship of each class. If so, the service can be bound, and the bindable service is obtained.

[0094] The RPC implementation method acquisition module 400 is used to acquire the RPC implementation methods of services that can be bound.

[0095] Specifically, the RPC implementation method acquisition module 400 is used to obtain all interface methods registered in the interface inheritance chain of the Binder class of the service that can be bound, and find the RPC implementation methods of all interface methods from all subclasses.

[0096] The interface input information generation module 500 is used to filter the interface call processing method (onTransact method) from the RPC implementation method, extract the abstract syntax tree (AST) of the interface call processing method and parse it, obtain the call interface number and name description information and read and write related operations, analyze the condition information of the interface branch, obtain the type of input variable and the constraint information of the call method, and also extract the field composition of the custom type input variable used to construct complex variable types. The call interface number, name description information, type of input variable, constraint information of the call method and field composition of the custom type input variable are used as the RPC implementation method call interface input information.

[0097] Specifically, the interface input information generation module 500 includes:

[0098] The decompilation unit is used to decompile RPC implementation methods to obtain programming code;

[0099] The Sensitive Candidate RPC Implementation Analysis Unit is used to input programming code into the analysis model for analysis and output sensitive candidate RPC implementation methods. Specifically, it guides the model's output by calling the ChatGPT-3.5-turbo large model, adjusting the prompt, and setting custom instructions. The following design principles are followed when constructing prompts: 1) Role setting; 2) Clear and explicit instructions; 3) Providing necessary context; 4) Standardized result output; 5) Multiple rounds of testing and adjustment. Specifically, the task description specifies whether the model's judgment method has security risks, clarifies the attack scenario, and supplements domain background knowledge. Since the code contains nested function calls, it is also necessary to extract relevant method code to improve the analysis context. Considering a maximum nesting depth of 5, the implementation code of the abstract call method is also extracted.

[0100] The interface call processing method filtering unit is used to filter out interface call processing methods from candidate RPC implementation methods.

[0101] The API call input information generation unit is used to extract and parse the abstract syntax tree (AST) of the API call processing method, obtain the API call number and name description information, as well as the relevant operations for reading and writing packets, analyze the condition information of the API branch, obtain the type of input variables and the constraint information of the calling method, and also extract the field composition of custom type input variables used to construct complex variable types. The API call number, name description information, type of input variables, constraint information of the calling method, and field composition of custom type input variables are used as the input information of the RPC implementation method call interface.

[0102] The input variable dependency generation module 600 is used to perform static analysis on the conditional statements, loop structures and data flow in the code of the RPC implementation method to obtain the input variable dependency of the RPC implementation method.

[0103] The input variable test case generation module 700 is used to generate input values ​​that meet set conditions by using a constraint-based test generation method and combinatorial test technology, based on the input information of the RPC implementation method call interface and the dependency relationship of the input variables of the RPC implementation method, and systematically explore different combinations of variable values, thereby improving test coverage and obtaining input variable test cases;

[0104] The vulnerability detection module 800 is used to store the input information of the RPC implementation method call interface, the input variable test cases, and the exposed service component information of the RPC implementation method into the test device, install the test program on the test device to perform dynamic fuzz testing, and draw vulnerability detection conclusions.

[0105] In summary, this invention presents a vulnerability detection method for custom binding services in Android system applications. By collecting attack entry points through reverse analysis and combining static analysis modeling and dynamic fuzzing methods, it can identify potential vulnerability types and risks.

[0106] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0107] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0108] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0109] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0110] Any aspects of this invention not described in detail in the embodiments are well-known techniques to those skilled in the art. Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this invention and not to limit it. Although this invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of this invention without departing from the spirit and scope of this invention, and all such modifications and substitutions should be covered within the scope of the claims of this invention.

Claims

1. A method for detecting application-bound service vulnerabilities, characterized in that, include: Extract the installation package file from the application to be tested; The installation package file is decoded to obtain the application manifest file, and the application manifest file is parsed to obtain the exposed service components; The binary file of the application to be detected is disassembled to obtain assembly code. Static analysis is performed on the assembly code to identify services that can be bound from the exposed service components. Obtain the RPC implementation method of the service that can be bound; The interface call processing method is selected from the RPC implementation method. The abstract syntax tree of the interface call processing method is extracted and parsed to obtain the call interface number and name description information, as well as the relevant operations for reading and writing packets. The condition information of the interface branch is analyzed to obtain the type of input variable and the constraint information of the call method. The field composition of the custom type input variable used to construct complex variable types is also extracted. The call interface number, the name description information, the type of input variable, the constraint information of the call method, and the field composition of the custom type input variable are used as the input information of the RPC implementation method call interface. Static analysis is performed on the conditional statements, loop structures, and data flow in the code of the RPC implementation method to obtain the input variable dependencies of the RPC implementation method. A constraint-based test generation method and combined test technology are adopted. Based on the input information of the RPC implementation method call interface and the dependency relationship of the input variables of the RPC implementation method, input values ​​that meet the set conditions are generated, and test cases for input variables are obtained. The input information of the RPC implementation method call interface, the test cases of the input variables, and the exposed service component information of the RPC implementation method are stored in the test device. The test program is installed on the test device to perform dynamic fuzz testing and obtain vulnerability detection conclusions.

2. The detection method for application-bound service vulnerabilities as described in claim 1, characterized in that, The static analysis of the assembly code to identify services that can be bound from the exposed service components includes: Based on the service name of the exposed service component, traverse the exposed service class code one by one and check whether the class method contains a binding method; If the binding method is not found in the current service class, continue to check whether its inherited parent class has overridden the binding method, until the service base class is found. Check if the return type of the binding method is the Binder class or its subclasses. Determine if each class inherits from the Binder class by extracting the class inheritance relationship. If so, the service can be bound, and the bindable service is obtained.

3. The detection method for application-bound service vulnerabilities as described in claim 1, characterized in that, The method for obtaining the RPC implementation of the bindable service includes: Obtain all interface methods registered in the interface inheritance chain of the return Binder class of the service that can be bound, and find the RPC implementation method of all interface methods from all subclasses.

4. The detection method for application-bound service vulnerabilities as described in claim 3, characterized in that, In the process of finding the RPC implementation methods of all interface methods from all subclasses, the search proceeds sequentially from subclass to parent class, ensuring that the RPC implementation methods in the subclass are not overridden by the parent class; if the current class does not implement the interface, the code of all methods of the class and its subclasses is extracted.

5. The detection method for application-bound service vulnerabilities as described in claim 1, characterized in that, The step of selecting interface call processing methods from the RPC implementation methods includes: The RPC implementation method is decompiled to obtain the programming code; The programming code is input into the analysis model for analysis, and sensitive candidate RPC implementation methods are output. The interface call processing method is selected from the candidate RPC implementation methods.

6. A detection system for application-bound service vulnerabilities, characterized in that, include: The installation package file extraction module is used to extract the installation package file from the application to be detected. The file parsing module is used to decode the installation package file to obtain the application manifest file, and to parse the application manifest file to obtain the exposed service components; The static analysis module is used to disassemble the binary file of the application to be detected to obtain assembly code, perform static analysis on the assembly code, and identify services that can be bound from the exposed service components. The RPC implementation method acquisition module is used to acquire the RPC implementation method of the service that can be bound. The interface input information generation module is used to filter out interface call processing methods from the RPC implementation methods, extract and parse the abstract syntax tree of the interface call processing methods, obtain the interface number and name description information and related operations for reading and writing packets, analyze the condition information of the interface branches, obtain the type of input variables and the constraint information of the call methods, and also extract the field composition of custom type input variables used to construct complex variable types. The interface number, the name description information, the type of input variables, the constraint information of the call methods and the field composition of the custom type input variables are used as the RPC implementation method call interface input information. The input variable dependency generation module is used to perform static analysis on the conditional statements, loop structures and data flow in the code of the RPC implementation method to obtain the input variable dependency of the RPC implementation method. The input variable test case generation module is used to generate input values ​​that meet set conditions by using a constraint-based test generation method and combined test technology, based on the input information of the RPC implementation method call interface and the dependency relationship of the input variables of the RPC implementation method, and thus obtain input variable test cases. The vulnerability detection module is used to store the input information of the RPC implementation method call interface, the test cases of the input variables, and the exposed service component information of the RPC implementation method into the test device, install the test program on the test device to perform dynamic fuzz testing, and obtain vulnerability detection conclusions.

7. The detection system for application-bound service vulnerabilities as described in claim 6, characterized in that, The static analysis module includes: The disassembly unit is used to disassemble the binary file of the application to be detected to obtain assembly code; The binding method query unit is used to traverse the exposed service class code one by one according to the service name of the exposed service component and check whether the class method contains a binding method; if the binding method is not found in the current service class, it continues to check whether its inherited parent class has overridden the binding method, until it is traced back to the service base class and the binding method is found. The service binding query unit is used to check whether the return type of the binding method is the Binder class or its subclasses. It determines whether each class inherits from the Binder class by extracting the class inheritance relationship of each class. If so, the service can be bound, and the bindable service is obtained.

8. The detection system for application-bound service vulnerabilities as described in claim 6, characterized in that, The RPC implementation method acquisition module is specifically used to acquire all interface methods registered in the interface inheritance chain of the return Binder class of the bindable service, and find the RPC implementation methods of all interface methods from all subclasses.

9. The detection system for application-bound service vulnerabilities as described in claim 6, characterized in that, The API input information generation module includes: The decompilation unit is used to decompile the RPC implementation method to obtain programming code; The sensitive candidate RPC implementation method analysis unit is used to input the programming code into the analysis model for analysis and output the sensitive candidate RPC implementation methods. An interface call processing method filtering unit is used to filter out interface call processing methods from the candidate RPC implementation methods; The interface call input information generation unit is used to extract and parse the abstract syntax tree of the interface call processing method, obtain the interface call number and name description information, as well as the relevant operations for reading and writing packets, analyze the condition information of the interface branches, obtain the type of input variables and the constraint information of the call method, and also extract the field composition of custom type input variables used to construct complex variable types. The interface call number, the name description information, the type of input variables, the constraint information of the call method, and the field composition of the custom type input variables are used as the input information of the RPC implementation method call interface.

Images