Detection method of Java dynamic loading component

Abstract

The invention provides a detection method for a Java dynamic loading component, and relates to the technical field of computer software. According to the method, the dynamic loading API in the Java software is automatically extracted, the calling graph is constructed to obtain the calling of the dynamic loading API by the program, the parameter value of the dynamic loading API is analyzed by using an intra-process and inter-process data flow analysis method, the dynamic loading behavior of the Java program is positioned, and the dynamically loaded component during the operation of the Java program is identified. According to the method, the dynamic loading behavior of the Java program is positioned by adopting a static analysis method, so that the dynamically loaded component during the operation of the Java program can be effectively identified, and the defects of the existing Java software component analysis technology in a dynamic loading scene are overcome. Component information obtained through detection can be used for analysis tasks such as component vulnerability recognition, license compliance check and project dependency management, so that developers are helped to have more comprehensive understanding of the composition structure of the project, and the project is better managed and maintained.

Description

Technical Field

[0001] The present invention relates to the technical field of computer software, and particularly to a method for detecting Java dynamically loaded components. Background Art

[0002] As computer programs become more complex and project scales become larger, developers rely on third-party and open-source components to improve development efficiency, and the dependence on open-source software has greatly changed the amount of code written by developers in applications.

[0003] To achieve component management for automated projects and facilitate project compilation, testing, packaging, etc., developers have introduced build automation tools, and one of their important functions is to handle project dependencies. As one of the mainstream programming languages, Java also has its popular open-source build automation tool Maven. Maven provides two concepts, POM and coordinates. For example, a project that requires the Hibernate component only needs to declare the coordinates of Hibernate in the project POM. Maven will automatically resolve and download Hibernate and the dependencies required by Hibernate (referred to as transitive dependency relationships), and store them in the user's local repository. In this case, software composition analysis tools can use the API provided by Maven to obtain the direct and transitive dependencies of the current Java application by parsing the POM. The dependencies introduced by the POM can be called static dependencies. However, when Java application developers use special methods from the JDK or third-party libraries to dynamically load some dependencies during program runtime, these dependencies may not appear in the dependencies obtained by POM parsing. Therefore, these dependencies will also be ignored in subsequent potential risk analysis of components, and their risk situation remains unknown.

[0004] Currently, the Chinese patent "CN118153064A A Java component vulnerability detection method based on software composition analysis" adopts different component recognition strategies according to different introduction methods of project open-source components: for Java projects that manage project open-source components using dependency construction tools, analyze the project's dependency files to extract and identify the information of open-source components included in the project; for Java projects that introduce open-source components externally, analyze the code features of the project, and based on the similarity of class-level features and method-level features, give the information of third-party and open-source components on which the project depends. However, this method ignores the recognition of components introduced during program runtime. The Chinese patent "CN115357898A A method, device, and medium for dependency analysis of JAVA components" discloses a method, device, and medium for dependency analysis of Java components, including: starting the Maven tool on the local side, importing the Java component to be analyzed into the Maven tool, executing the plugin function of the Maven tool, downloading the information of open-source components corresponding to the Java component in the central repository to the local side, and performing dependency analysis on the POM file through the Maven tool to obtain the dependency analysis result of the Java component. However, the analysis result lacks dynamically loaded components introduced non-Maven.

[0005] Dynamic loading dependencies are runtime behaviors of a program, and developers often need to use specific dynamic loading APIs to implement them. Since the parameters of the dynamic loading method can only be determined during the dynamic runtime of the program, and the wide range of sources of dynamically loaded dependencies, which may come from project packaging, network links, and the local environment, combined with the complexity of the software construction and runtime environment and the mutual constraints and influences during the software production process, make the detection of Java components in the dynamic loading scenario face many challenges and limitations. Summary of the Invention

[0006] The technical problem to be solved by the present invention is to provide a detection method for Java dynamically loaded components in view of the above-mentioned deficiencies of the prior art. Automatically extract the dynamic loading APIs in Java software, use static analysis methods to construct a call graph to obtain the calls of the program to the dynamic loading APIs, use intra-procedural and inter-procedural data flow analysis methods to parse the parameter values of the dynamic loading APIs, locate the dynamic loading behaviors of the Java program, and identify the components dynamically loaded during the runtime of the Java program.

[0007] To solve the above technical problems, the technical solutions adopted by the present invention are as follows:

[0008] The present invention provides a detection method for Java dynamically loaded components, including the following steps:

[0009] Step 1: Obtain the Java project to be detected;

[0010] The Java project to be detected includes a compressed package of a Java project built using Maven and Java components generated after compilation; the compressed package of the Java project built using Maven is in the format of *.zip or *.rar, and the Java components generated after compilation are in the formats of *.jar, *.war, or *.aar;

[0011] Step 2: Preprocess the Java project to be detected, obtain the bytecode of the Java project to be detected and all Java components included in the Java project to be detected, and generate a candidate set of dynamically loaded components;

[0012] Preprocessing the Java project to be detected includes: scanning and decompressing the Java project to be detected to obtain the bytecode of the Java project to be detected. If the Java project to be detected has not been compiled, call the "mvn compile" command for compilation to obtain the bytecode of the Java project to be detected;

[0013] Obtain all Java components included in the Java project to be detected after scanning and decompression, generate a candidate set of dynamically loaded components, and use all Java components included in the Java project to be detected as elements in the candidate set of dynamically loaded components;

[0014] Step 3: Use Soot to convert the bytecode of the Java project to be detected into Jimple intermediate code, and construct a call graph of the Java project to be detected based on the call statements in the Jimple intermediate code, including nodes and call edges. Nodes represent method signatures, and edges represent call relationships; the method signature includes the method name, the parameter types of the method, and the return value type of the method;

[0015] Step 4: Collect multiple dynamically loaded APIs from the Java core library rt.jar according to the method name and return value type included in the method signature, determine whether the collected dynamically loaded APIs are called, and obtain the dynamically loaded components of the Java project to be detected;

[0016] Step 4.1: Collect multiple dynamically loaded APIs from the Java core library rt.jar, including class loaders, service provider interfaces, and reflection mechanisms;

[0017] Extract the method information from the Java core library rt.jar, including method modifiers, method return value types, method names, and method parameter lists, and use Soot to obtain all method signatures of each class in the Java core library rt.jar;

[0018] Traverse all method signatures of each class in the core class library rt.jar, set collection conditions according to the method name and return value type of each dynamic loading API, and combine with the parameter types of the methods to collect dynamic loading APIs:

[0019] The set collection conditions include:

[0020] (1) The method access modifier is public;

[0021] (2) At least one of the parameter types of the method is of type String or Class;

[0022] (3) The return value type of the method is of type Class or ServiceLoader. The return value type of the dynamic loading API of the class loader and reflection mechanism is of type Class, and the return value type of the SPI mechanism is of type ServiceLoader;

[0023] Step 4.2: Obtain the dynamic loading components of the Java project to be detected based on the collected dynamic loading APIs;

[0024] For the dynamically loaded APIs called in the collected dynamically loaded APIs, extract the call edges that call the dynamically loaded API in the call graph of the Java project to be detected, determine the call points of all dynamically loaded APIs, create a set of dynamic loading parameter values, and parse the parameter values of each called dynamically loaded API. Add the actual parameter values of the parsed dynamically loaded API to the set of dynamic loading parameter values, and use different methods to determine the dynamic loading components for different types of loading parameter values;

[0025] The specific method for parsing the parameter values of the called dynamically loaded API is:

[0026] If in the Jimple intermediate code of the call point, the parameter value form of the dynamically loaded API is a string constant or a Class constant, then use the parameter value of the dynamically loaded API as the loading parameter value of the dynamically loaded API and add it to the set of dynamic loading parameter values;

[0027] If the parameter value form of the dynamically loaded API is a variable, then use a data flow analysis method that combines intra-procedural and inter-procedural analysis to parse the parameter value of the dynamically loaded API, use the parsed parameter value of the dynamically loaded API as the loading parameter value of the dynamically loaded API, and add it to the set of dynamic loading parameter values;

[0028] The data flow analysis method that combines intra-procedural and inter-procedural analysis includes the following steps:

[0029] Step S1: For method i that directly calls the dynamic loading API, use the call graph of the Java project to be detected to find all methods that call method i;

[0030] Step S2: Traverse the Jimple intermediate code of all methods that call method i, locate the statement that calls method i, and check whether the parameter value form of method i in this statement is a string constant or a Class constant. If the parameter value form of method i in this statement is a string constant or a Class constant, collect this constant as the parameter value; otherwise, repeat Step 4.1 until the number of repetitions reaches a pre-set threshold;

[0031] Step S3: Collect the string operation APIs in the Java Development Kit (JDK), simulate the string concatenation and substring operations in the project to be tested to obtain the parameter values finally passed to the dynamic loading API, and add the parameter values finally passed to the dynamic loading API to the dynamic loading parameter value set to obtain a dynamic loading parameter value set including class names of string types or Class type objects;

[0032] Use different methods to determine the dynamic loading components for different types of loading parameter values. The specific methods are as follows:

[0033] Judge the type of the loading parameter values in the dynamic loading parameter value set. If the dynamic loading parameter value is a class name of string type, collect the class libraries in the Java Development Kit (JDK), the dependencies configured in the POM file, and the class names in the dynamic loading component candidate set. When the class name represented by the parameter value only exists in the candidate components in the dynamic loading component candidate set, add the candidate component containing the class with the same class name as the parameter value to the dynamic loading component set. When there are multiple components with the same class name as the parameter value, traverse the string constants included in the Jimple intermediate code of all methods that call method i. If the constant contains the name of the candidate component where the same class name is located, add this component to the dynamic loading component set;

[0034] If the dynamic loading parameter value is a Class type object, first extract the file names in the META-INF / services directory of each candidate component in the dynamic loading component candidate set. If there is a file name that is the same as the interface name of the Class object represented by the dynamic loading parameter value, add this component to the dynamic loading component set;

[0035] Step 5: Extract all string constants in the Java project to be detected, and determine the dynamic loading component link according to the prefix and suffix of the string. If the dynamic loading component link is a Maven repository link, determine the dynamic loading component coordinates according to the link format; if the dynamic loading component link is not a Maven repository link, download the dynamic loading component; wherein, the prefix of the string includes "http: / / ", "https: / / ", and the suffix of the string includes ".jar", ".war", ".aar".

[0036] Step 6: Trace the origin of the dynamic loading components included in the Java project to be detected, and determine the GAV coordinates of the dynamic loading components included in the Java project to be detected;

[0037] The GAV coordinates include the organization name GroupId, the artifact name ArtifactId, and the version Version. Calculate the SHA-1 value of the dynamic loading component using the SHA-1 algorithm, and compare the SHA-1 value of the dynamic loading component with the SHA-1 value of the component in the pre-obtained Maven repository. If the SHA-1 value of the dynamic loading component is the same as the SHA-1 value of the component in the pre-obtained Maven repository, use the GAV coordinates of the component in the Maven repository as the GAV coordinates of the dynamic loading component;

[0038] If the SHA-1 value of the dynamic loading component is different from the SHA-1 value of the component in the pre-obtained Maven repository, use the Jaccard similarity calculation method to calculate the similarity between all class names in the dynamic loading component and all class names in the component in the Maven repository, and take the coordinates of the component with the largest similarity among the components with a similarity greater than the preset threshold as the coordinates of the dynamic loading component;

[0039] Step 7: Output a report containing the traced dynamic loading component coordinate information, including the organization group, component name, version, and purl information of the dynamic loading component, and output the analysis information dynamicInfos related to the dynamic loading component.

[0040] The beneficial effects of adopting the above technical solutions are as follows: A detection method for Java dynamic loading components provided by the present invention uses static analysis to locate the dynamic loading behavior of Java programs, can effectively identify the components dynamically loaded during the runtime of Java programs, and makes up for the deficiencies of existing Java software composition analysis technologies in dynamic loading scenarios. On this basis, the detected component information can be used for analysis tasks such as component vulnerability identification, license compliance inspection, and project dependency management, so as to help developers have a more comprehensive understanding of the composition structure of the project and better manage and maintain the project. Brief Description of the Drawings

[0041] Figure 1 This is a flowchart for detecting Java dynamic loading components provided by an embodiment of the present invention. Detailed Embodiment

[0042] The following further describes in detail the specific embodiments of the present invention in conjunction with the drawings and embodiments. The following embodiments are used to illustrate the present invention, but are not used to limit the scope of the present invention.

[0043] A method for detecting a Java dynamic loading component in this embodiment is as Figure 1 shown and includes the following steps:

[0044] Step 1: Obtain the Java project to be detected;

[0045] The Java project to be detected includes a Java project compressed package built using Maven and Java components generated after compilation; the format of the Java project compressed package built using Maven is *.zip or *.rar, and the format of the Java components generated after compilation is *.jar, *.war or *.aar;

[0046] Step 2: Preprocess the Java project to be detected, obtain the bytecode of the Java project to be detected and all Java components included in the Java project to be detected, and generate a candidate set of dynamically loaded components;

[0047] Preprocessing the Java project to be detected includes: scanning and decompressing the Java project to be detected to obtain the bytecode of the Java project to be detected. If the Java project to be detected has not been compiled, the "mvn compile" command is called for compilation to obtain the bytecode of the Java project to be detected;

[0048] Obtain all Java components included in the Java project to be detected after scanning and decompression, generate a candidate set of dynamically loaded components, and use all Java components included in the Java project to be detected as elements in the candidate set of dynamically loaded components;

[0049] Step 3: Use Soot to convert the bytecode of the Java project to be detected into Jimple intermediate code, and construct a call graph of the Java project to be detected based on the call statements in the Jimple intermediate code, including nodes and call edges. The nodes represent method signatures, and the edges represent call relationships; the method signature includes the method name, the parameter types of the method, and the return value type of the method;

[0050] Step 4: Collect various dynamic loading APIs from the Java core library rt.jar according to the method name and return value type of the method signature, determine whether the collected dynamic loading APIs are called, and obtain the dynamic loading components of the Java project to be detected;

[0051] Step 4.1: Collect various dynamic loading APIs from the Java core library rt.jar, including class loaders, service provider interfaces, and reflection mechanisms;

[0052] Extract the method information from the Java core library rt.jar, including method modifiers, method return value types, method names, and method parameter lists, and use Soot to obtain all method signatures of each class in the Java core library rt.jar;

[0053] Traverse all method signatures of each class in the core library rt.jar, set collection conditions according to the method name and return value type of each dynamic loading API, and combine the parameter types of the methods to collect dynamic loading APIs:

[0054] Considering the overriding and overloading features of Java, in order to ensure comprehensive collection of dynamic loading APIs, use the method name combined with the parameter type to collect dynamic loading APIs. The set collection conditions include:

[0055] (1) The method access modifier is public;

[0056] The method access modifier is public to ensure that the method can be called in the developer's code;

[0057] (2) At least one of the method parameter types is of String type or Class type;

[0058] Since all dynamic loading methods use the class name or Class object as a parameter, the method parameter type should at least include one String or Class object type;

[0059] (3) The method return value type is of Class type or ServiceLoader type. The return value types of the dynamic loading APIs of class loaders and reflection mechanisms are of Class type, and the return value type of the SPI mechanism is of ServiceLoader type;

[0060] Step 4.2: Obtain the dynamic loading components of the Java project to be detected based on the collected dynamic loading APIs;

[0061] For the dynamically loaded APIs called in the collected dynamically loaded APIs, extract the call edges that call the dynamically loaded APIs in the call graph of the Java project to be detected, determine the call points of all dynamically loaded APIs, create a dynamically loaded parameter value set, parse the parameter values of each called dynamically loaded API, and add the actual parameter values of the parsed dynamically loaded APIs to the dynamically loaded parameter value set. Use different methods to determine the dynamically loaded components for different types of loaded parameter values;

[0062] In this embodiment, the collected dynamically loaded APIs include the reflection mechanism (Class.forName(String className)), the class loader (ClassLoader.loadClass(String name)), and the SPI mechanism (ServiceLoader.load(Class <s>The API related to the service)), and the parameter type is the class name of the string type or the class object of the Class type;

[0063] The specific method for parsing the parameter value of the dynamically loaded API being called is as follows:

[0064] If, in the Jimple-form intermediate code at the call point, the parameter value form of the dynamically loaded API is a string constant or a Class constant, then use this parameter value of the dynamically loaded API as the loading parameter value of the dynamically loaded API and add it to the dynamically loaded parameter value set;

[0065] If the parameter value form of the dynamically loaded API is a variable, then use the data flow analysis method that combines intra-procedural and inter-procedural analysis to parse the parameter value of the dynamically loaded API, use the parsed parameter value of the dynamically loaded API as the loading parameter value of the dynamically loaded API, and add it to the dynamically loaded parameter value set;

[0066] The data flow analysis method that combines intra-procedural and inter-procedural analysis includes the following steps:

[0067] Step S1: For the method i that directly calls the dynamically loaded API, use the call graph of the Java project to be detected to find all methods that call method i;

[0068] Step S2: Traverse the Jimple-form intermediate code of all methods that call method i, locate the statement that calls method i, and check whether the parameter value form of method i in this statement is a string constant or a Class constant. If the parameter value form of method i in this statement is a string constant or a Class constant, then collect this constant as the parameter value; otherwise, repeat step 4.1 until the number of repetitions reaches the pre-set threshold;

[0069] In this embodiment, the threshold for the number of repetitions is set to 5, that is, the call chain of the method is of length 5;

[0070] Step S3: Collect the string operation APIs in the Java Development Kit (JDK), and simulate the string concatenation and substring extraction operations in the project to be tested to obtain the parameter value finally passed into the dynamically loaded API. Add the parameter value finally passed into the dynamically loaded API to the dynamically loaded parameter value set to obtain a dynamically loaded parameter value set including the class name of the string type or the Class type object;

[0071] Use different methods to determine the dynamically loaded component for different types of loading parameter values. The specific method is as follows:

[0072] Determine the type of the loaded parameter value in the dynamically loaded parameter value set. If the dynamically loaded parameter value is a string type class name, collect the class libraries in the Java Development Kit (JDK), the dependencies configured in the POM file, and the class names in the dynamically loaded component candidate set. When the class name represented by the parameter value only exists in the candidate component in the dynamically loaded component candidate set, add the candidate component containing the class with the same class name as the parameter value to the dynamically loaded component set. When there are multiple components with the same class name as the parameter value, traverse and call the string constants included in the Jimple intermediate code of all methods of method i. If the constant contains the name of the candidate component where the same class name is located, add this component to the dynamically loaded component set;

[0073] If the dynamically loaded parameter value is a Class type object, it indicates that this dynamically loaded API is an implementation interface of the SPI mechanism. According to the SPI mechanism principle, the class represented by this object is an interface, and when there is an implementation class of this interface in the component, a file named after the interface name should be created in the META-INF / services directory of the component, and the content of the file is the implementation class of the interface. Therefore, in this case, first extract the file names in the META-INF / services directory of each candidate component in the dynamically loaded component candidate set. If there is a file name that is the same as the interface name of the Class object represented by the dynamically loaded parameter value, add this component to the dynamically loaded component set;

[0074] Step 5: Extract all the string constants in the Java project to be detected, and determine the dynamically loaded component link according to the prefix and suffix of the string. If the dynamically loaded component link is a Maven repository link, determine the coordinates of the dynamically loaded component according to the link format; if the dynamically loaded component link is not a Maven repository link, download this dynamically loaded component; among them, the prefix of the string includes "http: / / ” and "https: / / ”, and the suffix of the string includes ".jar”, ".war”, and ".aar”;

[0075] Step 6: Trace the dynamically loaded components included in the Java project to be detected to determine the GAV coordinates of the dynamically loaded components included in the Java project to be detected;

[0076] The GAV coordinates include the organization name GroupId, the artifact name ArtifactId, and the version Version. Calculate the SHA-1 value of the dynamically loaded component using the SHA-1 algorithm, and compare the SHA-1 value of the dynamically loaded component with the SHA-1 value of the component in the pre-obtained Maven repository. If the SHA-1 value of the dynamically loaded component is the same as the SHA-1 value of the component in the pre-obtained Maven repository, use the GAV coordinates of the component in the Maven repository as the GAV coordinates of the dynamically loaded component;

[0077] If the SHA-1 value of the dynamically loaded component is different from the SHA-1 value of the component in the pre-acquired Maven repository, use the Jaccard similarity calculation method to calculate the similarity between all class names in the dynamically loaded component and all class names in the component in the Maven repository, and take the coordinates of the component with the largest similarity in the components with similarity greater than the preset threshold as the coordinates of the dynamically loaded component;

[0078] Step 7: Output a report containing the coordinate information of the dynamically loaded component obtained by tracing, including the organization group, component name name, version version, and purl information of the dynamically loaded component, and output the analysis information dynamicInfos related to the dynamically loaded component.

[0079] Determine the dynamically loaded component through the parameter value in the dynamic loading API, and determine the detailed information of the component according to the different sources of the component, and output the information of the dynamically loaded component in the form of a JSON report.

[0080] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that they can still modify the technical solutions described in the foregoing embodiments, or perform equivalent replacements on some or all of the technical features; and these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the scope defined by the claims of the present invention.< / s>

Claims

1. A detection method for Java dynamic loading components, characterized in that: It includes the following steps: Step 1: Obtain the Java project to be detected; Step 2: Preprocess the Java project to be detected, obtain the bytecode of the Java project to be detected and all Java components included in the Java project to be detected, and generate a dynamic loading component candidate set; Step 3: Use Soot to convert the bytecode of the Java project to be detected into Jimple-form intermediate code, and construct a call graph of the Java project to be detected based on the call statements in the Jimple-form intermediate code, including nodes and call edges. The nodes represent method signatures, and the edges represent call relationships; the method signature includes the method name, the parameter types of the method, and the return value type of the method; Step 4: Collect multiple dynamic loading APIs from the Java core class library rt.jar according to the method name and the return value type included in the method signature, determine whether the collected dynamic loading APIs are called, and obtain the dynamic loading components of the Java project to be detected; Step 5: Extract all string constants in the Java project to be detected, and determine the dynamic loading component link according to the prefix and suffix of the string. If the dynamic loading component link is a Maven repository link, determine the dynamic loading component coordinates according to the link format; if the dynamic loading component link is not a Maven repository link, download the dynamic loading component; wherein, the prefix of the string includes "http: / / ” and "https: / / ”, and the suffix of the string includes ".jar”, ".war”, and ".aar”; Step 6: Trace the origin of the dynamic loading components included in the Java project to be detected, and determine the GAV coordinates of the dynamic loading components included in the Java project to be detected; Step 7: Output a report containing the traced dynamic loading component coordinate information, including the organization group, component name name, version version, and purl information of the dynamic loading components, and output the analysis information dynamicInfos related to the dynamic loading components.

2. The detection method of a Java dynamic loading component according to claim 1, characterized in that: The Java project to be detected in Step 1 includes a Java project compressed package built using Maven and Java components generated after compilation; the format of the Java project compressed package built using Maven is *.zip or *.rar, and the format of the Java components generated after compilation is *.jar, *.war, or *.aar.

3. The detection method of a Java dynamic loading component according to claim 2, characterized in that: The said Step 2 includes: Preprocess the Java project to be detected, including: scan and decompress the Java project to be detected, obtain the bytecode of the Java project to be detected. If the Java project to be detected has not been compiled, call the "mvn compile” command to compile it to obtain the bytecode of the Java project to be detected; Obtain all Java components included in the Java project to be detected after scanning and decompression, generate a dynamic loading component candidate set, and use all Java components included in the Java project to be detected as elements in the dynamic loading component candidate set.

4. The detection method of a Java dynamic loading component according to claim 3, characterized in that: The said Step 4 includes: Step 4.1: Collect various dynamic loading APIs from the Java core library rt.jar, including class loaders, service provider interfaces, and reflection mechanisms; Step 4.2: Obtain the dynamic loading components of the Java project to be detected based on the collected dynamic loading APIs.

5. The detection method of a Java dynamic loading component according to claim 4, characterized in that: The specific method of Step 4.1 is as follows: Extract the method information in the Java core library rt.jar, including method modifiers, method return value types, method names, and method parameter lists, and use Soot to obtain all method signatures of each class in the Java core library rt.jar; Traverse all method signatures of each class in the core library rt.jar, set collection conditions according to the method names and return value types of each dynamic loading API, and combine the parameter types of the methods to collect dynamic loading APIs: The set collection conditions include: (1) The method access modifier is public; (2) At least one of the parameter types of the method is of type String or Class; (3) The method return value type is of type Class or ServiceLoader. The return value type of the dynamic loading APIs of class loaders and reflection mechanisms is of type Class, and the return value type of the SPI mechanism is of type ServiceLoader.

6. The detection method of a Java dynamic loading component according to claim 5, characterized in that: The specific method of Step 4.2 is as follows: For the dynamically loaded APIs called in the collected dynamic loading APIs, extract the call edges that call the dynamically loaded API in the call graph of the Java project to be detected, determine the call points of all dynamic loading APIs, create a dynamic loading parameter value set, and parse the parameter values of each called dynamic loading API. Add the actual parameter values of the parsed dynamic loading APIs to the dynamic loading parameter value set, and use different methods to determine the dynamic loading components for different types of loading parameter values.

7. A detection method for Java dynamic loading components according to claim 6, characterized in that: The specific method of parsing the parameter values of the called dynamic loading API is as follows: If the parameter value of the dynamic loading API in the Jimple intermediate code of the call point is in the form of a string constant or a Class constant, then use the parameter value of the dynamic loading API as the loading parameter value of the dynamic loading API and add it to the dynamic loading parameter value set; If the parameter value of the dynamic loading API is in the form of a variable, use a data flow analysis method that combines intra-procedural and inter-procedural analysis to parse the parameter value of the dynamic loading API, and use the parsed parameter value of the dynamic loading API as the loading parameter value of the dynamic loading API and add it to the dynamic loading parameter value set.

8. A detection method for Java dynamic loading components according to claim 7, characterized in that: The data flow analysis method that combines intra-procedural and inter-procedural analysis includes the following steps: Step S1: For the method i that directly calls the dynamic loading API, use the call graph of the Java project to be detected to find all methods that call method i; Step S2: Traverse and call the Jimple intermediate code of all methods of method i, locate the statement that calls method i, and check whether the parameter value form of method i in this statement is a string constant or a Class constant. If the parameter value form of method i in this statement is a string constant or a Class constant, collect this constant as the parameter value; otherwise, repeat step 4.1 until the number of repetitions reaches a preset threshold. Step S3: Collect the string operation APIs in the Java Development Kit (JDK), and simulate the string concatenation and substring extraction operations in the project under test to obtain the parameter values finally passed to the dynamically loaded APIs. Add the parameter values finally passed to the dynamically loaded APIs to the dynamically loaded parameter value set to obtain a dynamically loaded parameter value set including string type class names or Class type objects.

9. The detection method of a Java dynamic loading component according to claim 8, characterized in that: The specific method for determining the dynamically loaded components using different methods for different types of loaded parameter values is as follows: Judge the type of the loaded parameter value in the dynamically loaded parameter value set. If the dynamically loaded parameter value is a string type class name, collect the class libraries in the Java Development Kit (JDK), the dependencies configured in the POM file, and the class names in the dynamically loaded component candidate set. When the class name represented by the parameter value only exists in the candidate component in the dynamically loaded component candidate set, add the candidate component containing the class with the same class name as the parameter value to the dynamically loaded component set. When there are multiple components with the same class name as the parameter value, traverse and call the string constants included in the Jimple intermediate code of all methods of method i. If the constant contains the candidate component name where the same class name is located, add this component to the dynamically loaded component set. If the dynamically loaded parameter value is a Class type object, first extract the file names in the META-INF / services directory of each candidate component in the dynamically loaded component candidate set. If there is a file name that is the same as the interface name of the Class object represented by the dynamically loaded parameter value, add this component to the dynamically loaded component set.

10. The detection method of a Java dynamic loading component according to claim 9, characterized in that: The specific method of step 6 is as follows: The GAV coordinates include the organization name GroupId, the artifact name ArtifactId, and the version Version. Calculate the SHA-1 value of the dynamically loaded component using the SHA-1 algorithm, and compare the SHA-1 value of the dynamically loaded component with the SHA-1 value of the component in the pre-obtained Maven repository. If the SHA-1 value of the dynamically loaded component is the same as the SHA-1 value of the component in the pre-obtained Maven repository, use the GAV coordinates of the component in the Maven repository as the GAV coordinates of the dynamically loaded component. If the SHA-1 value of the dynamically loaded component is different from the SHA-1 value of the component in the pre-obtained Maven repository, use the Jaccard similarity calculation method to calculate the similarity between all class names in this dynamically loaded component and all class names in the component in the Maven repository, and take the coordinates of the component with the largest similarity among the components with a similarity greater than the preset threshold as the coordinates of this dynamically loaded component.

Images