Risk code segment identification method and device, computer equipment and readable storage medium

Abstract

The invention relates to a risk code segment identification method and device, computer equipment and a readable storage medium, and relates to the technical field of computers. The method comprises the following steps: extracting a calling relationship between an object and a method in a code file; the calling relation is used for representing the calling of the object to the method; carrying out risk calling detection processing on the calling relations to determine risk calling relations with calling risks from the calling relations; the calling risk is a risk of calling an abnormal method, and the abnormal method is a method in which a corresponding declaration code segment exists and a corresponding implementation code segment does not exist in a code file; and determining a calling code segment corresponding to the risk calling relationship in the code file to obtain a risk code segment in the code file. By adopting the method, the troubleshooting efficiency of the method which is not realized by calling the declaration can be improved.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method, apparatus, computer device, computer-readable storage medium, and computer program product for identifying risky code segments. Background Technology

[0002] In software development using dynamic programming languages ​​like Objective-C, method declarations and implementations are typically stored separately in the .h declaration file and the .m implementation file. A declared but unimplemented method is one that is explicitly declared in the .h file but whose implementation logic is not provided in the .m implementation file. Due to the compilation characteristics of dynamic languages, the compiler usually only checks the syntactic validity of the method declaration and does not check whether the corresponding implementation code exists in the .m implementation file. Therefore, calling a declared but unimplemented method usually does not result in an error during the code compilation phase, but it may pose a risk of runtime crashes.

[0003] In related technologies, it is usually necessary to manually check the code for calls to methods that are declared but not implemented; however, as the scale of software projects expands, the amount of code grows exponentially, and manual checking consumes a lot of time and manpower, resulting in low efficiency. Summary of the Invention

[0004] Therefore, it is necessary to provide a method, apparatus, computer device, computer-readable storage medium, and computer program product that can improve the efficiency of identifying risky code segments, addressing the aforementioned technical problem of low efficiency in investigating methods that are declared as not implemented.

[0005] Firstly, this application provides a method for identifying risky code segments, including:

[0006] Extract the call relationships between objects and methods in the code file; the call relationships are used to represent the calls made by the objects to the methods;

[0007] Risk call detection processing is performed on the call relationships to identify risky call relationships with call risks; the call risk is the risk of calling an abnormal method, and the abnormal method is a method that has a corresponding declaration code segment in the code file but no corresponding implementation code segment;

[0008] The risk code segment in the code file is obtained by determining the calling code segment corresponding to the risk calling relationship in the code file.

[0009] In one embodiment, extracting the call relationships between objects and methods in the code file includes:

[0010] Based on multiple preset call relationship extraction strategies, call relationships corresponding to multiple objects are extracted from the code file; each call relationship extraction strategy is used to extract the call relationship corresponding to one object; the multiple objects include at least non-proxy objects and proxy objects under the protocol;

[0011] The step of performing risk call detection processing on the call relationships to determine risky call relationships with call risks includes:

[0012] For each type of object and its corresponding call relationship, based on the type of the object corresponding to the call relationship, a target risk call detection strategy is determined from a set of preset risk call detection strategies; each risk call detection strategy is used to perform risk call detection processing on a call relationship corresponding to one type of object.

[0013] According to the target risk call detection strategy, the call relationship is subjected to risk call detection processing in order to determine the risk call relationship from the call relationship.

[0014] In one embodiment, the step of extracting the call relationships corresponding to multiple objects from the code file according to a preset multiple call relationship extraction strategy includes:

[0015] Determine all call relationships corresponding to all proxy objects under all protocols in the code file;

[0016] Based on the proxy object and optional protocol method under each protocol, the first call relationship under each protocol is selected from all the call relationships; the first call relationship under each protocol is the call relationship between the proxy object and the optional protocol method under the protocol.

[0017] In one embodiment, the step of filtering out the first invocation relationship under each of the protocols from all invocation relationships based on the proxy object and optional protocol method under each protocol includes:

[0018] For each protocol, candidate call relationships are selected from all the call relationships; the called method in the candidate call relationship is the optional protocol method under the protocol.

[0019] From the candidate call relationships, the first call relationship under the protocol is selected; the proxy object in the first call relationship under the protocol is the proxy object under the protocol.

[0020] In one embodiment, the invocation relationship corresponding to the proxy object under each protocol is the first invocation relationship between the proxy object under the protocol and the optional protocol method under the protocol.

[0021] The step of performing risk call detection processing on the call relationships according to the target risk call detection strategy, in order to determine the risk call relationships from the call relationships, includes:

[0022] For each protocol, in the code file, determine the call code segment corresponding to the first call relationship under the protocol;

[0023] Based on the calling code segment corresponding to the first calling relationship, a pre-method response judgment and detection process is performed on the first calling relationship to obtain the pre-method response judgment and detection result of the first calling relationship; the pre-method response judgment and detection process is used to determine whether there is a method response judgment code segment before the calling code segment corresponding to the first calling relationship in the code file; the method response judgment code segment is used to perform method response judgment on the first calling relationship;

[0024] If the detection result of the preceding method response indicates that the method response judgment code segment corresponding to the first call relationship does not exist, the first call relationship is determined to be the risky call relationship.

[0025] In one embodiment, the invocation relationship corresponding to the non-proxy object is a second invocation relationship between the non-proxy object and the custom method; the second invocation relationship is extracted from the implementation file in the code file;

[0026] The step of performing risk call detection processing on the call relationships according to the target risk call detection strategy, in order to determine the risk call relationships from the call relationships, includes:

[0027] In the declaration file of the code file, the declared custom method is identified; in the implementation file, the implemented custom method is identified.

[0028] Based on the declared custom method and the implemented custom method, risk call detection processing is performed on the second call relationship to determine the risk call relationship from the second call relationship.

[0029] In one embodiment, the step of performing risk call detection processing on the second call relationship based on the declared custom method and the implemented custom method, in order to determine the risk call relationship from the second call relationship, includes:

[0030] Based on the method identifier and class identifier of the declared custom method, and the method identifier and class identifier of the implemented custom method, determine whether the declared custom method is the exception method;

[0031] In the case where the declared custom method is the exception method, based on the method identifier and class identifier of the declared custom method, as well as the method identifier of the called custom method in the second call relationship and the class identifier of the class to which the non-proxy object belongs, it is determined whether a target call relationship exists in the second call relationship; the called method in the target call relationship matches the declared custom method.

[0032] If the target call relationship exists, the target call relationship is determined to be the risky call relationship.

[0033] In one embodiment, determining whether the declared custom method is the abnormal method based on the method identifier and class identifier of the declared custom method, and the method identifier and class identifier of the implemented custom method, includes:

[0034] If a target class identifier exists in the class identifier of the class to which the implemented custom method belongs, obtain the list of implementation method identifiers of the target class corresponding to the target class identifier; the target class identifier matches the class identifier of the class to which the declared custom method belongs; the list of implementation method identifiers of the target class includes the method identifiers of the implemented custom methods under the target class, and the list of implementation method identifiers of the target class is constructed based on the method identifiers of the implemented custom methods and the class identifier of the class to which the class belongs;

[0035] If the method identifier of the declared custom method does not exist in the implementation method identifier list of the target class, the declared custom method is determined to be the exception method.

[0036] In one embodiment, determining whether a target invocation relationship exists in the second invocation relationship based on the method identifier and class identifier of the declared custom method, and the method identifier of the invoked custom method and the class identifier of the non-proxy object in the second invocation relationship includes:

[0037] In the second invocation relationship, if there exists a second invocation relationship in which the method identifier of the called method matches the method identifier of the declared custom method, and the class identifier of the class to which the corresponding non-proxy object belongs matches the class identifier of the class to which the declared custom method belongs, then the corresponding second invocation relationship is determined as the target invocation relationship.

[0038] In one embodiment, after obtaining the risky code segment in the code file, the method further includes:

[0039] Generate a warning message for the risk code segment;

[0040] The aforementioned prompt information serves as a risk warning for the risky code segment.

[0041] Secondly, this application also provides a risk code segment identification device, comprising:

[0042] The call relationship extraction module is used to extract the call relationships between objects and methods in a code file; the call relationship is used to represent the call of the object to the method;

[0043] The risk call detection module is used to perform risk call detection processing on the call relationship in order to determine the risky call relationship with call risk; the call risk is the risk of calling an abnormal method, and the abnormal method is a method that has a corresponding declaration code segment in the code file but no corresponding implementation code segment;

[0044] The code segment determination module is used to determine the calling code segment corresponding to the risk calling relationship in the code file, and obtain the risk code segment in the code file.

[0045] Thirdly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to perform the following steps:

[0046] Extract the call relationships between objects and methods in the code file; the call relationships are used to represent the calls made by the objects to the methods;

[0047] Risk call detection processing is performed on the call relationships to identify risky call relationships with call risks; the call risk is the risk of calling an abnormal method, and the abnormal method is a method that has a corresponding declaration code segment in the code file but no corresponding implementation code segment;

[0048] The risk code segment in the code file is obtained by determining the calling code segment corresponding to the risk calling relationship in the code file.

[0049] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, performs the following steps:

[0050] Extract the call relationships between objects and methods in the code file; the call relationships are used to represent the calls made by the objects to the methods;

[0051] Risk call detection processing is performed on the call relationships to identify risky call relationships with call risks; the call risk is the risk of calling an abnormal method, and the abnormal method is a method that has a corresponding declaration code segment in the code file but no corresponding implementation code segment;

[0052] The risk code segment in the code file is obtained by determining the calling code segment corresponding to the risk calling relationship in the code file.

[0053] Fifthly, this application also provides a computer program product, including a computer program that, when executed by a processor, performs the following steps:

[0054] Extract the call relationships between objects and methods in the code file; the call relationships are used to represent the calls made by the objects to the methods;

[0055] Risk call detection processing is performed on the call relationships to identify risky call relationships with call risks; the call risk is the risk of calling an abnormal method, and the abnormal method is a method that has a corresponding declaration code segment in the code file but no corresponding implementation code segment;

[0056] The risk code segment in the code file is obtained by determining the calling code segment corresponding to the risk calling relationship in the code file.

[0057] The aforementioned risky code segment identification method, apparatus, computer equipment, computer-readable storage medium, and computer program product, through risky call detection processing of the call relationship between objects and methods in code files, can determine whether the call relationship poses a call risk to an abnormal method that has a corresponding declaration code segment but no corresponding implementation code segment, that is, determine whether the call relationship poses a call risk to a declared but unimplemented method, and thus obtain the risky call relationship; by identifying the call code segment corresponding to the risky call relationship in the code file, it is possible to identify risky code segments that pose a risk of calling declared but unimplemented methods; the risky code segment identification method based on the above process no longer relies on manual investigation, thus improving investigation efficiency. Attached Figure Description

[0058] To more clearly illustrate the technical solutions in the embodiments of this application or related technologies, the drawings used in the description of the embodiments of this application or related technologies will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0059] Figure 1This is a diagram illustrating the application environment of a risky code segment identification method in one embodiment.

[0060] Figure 2 This is a flowchart illustrating a risky code segment identification method in one embodiment;

[0061] Figure 3 This is a flowchart illustrating the steps of filtering out the first call relationship under each protocol from all call relationships based on the proxy object and optional protocol method under each protocol in one embodiment.

[0062] Figure 4 This is a flowchart illustrating the steps of performing risk call detection processing on call relationships according to a target risk call detection strategy in one embodiment, so as to determine risk call relationships from the call relationships;

[0063] Figure 5 This is a flowchart illustrating the steps of performing risk call detection processing on a second call relationship based on the declared custom method and the implemented custom method in one embodiment, so as to determine the risk call relationship from the second call relationship;

[0064] Figure 6 This is a flowchart illustrating the steps in one embodiment to test if a proxy object may call an optional protocol method that is declared not implemented.

[0065] Figure 7 This is a flowchart illustrating the steps of testing a custom method that is declared but not implemented and invoked on a non-proxy object in one embodiment.

[0066] Figure 8 This is a structural block diagram of a risk code segment identification device in one embodiment;

[0067] Figure 9 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0068] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0069] It should be noted that the terms "first," "second," etc., used in this application can be used to describe various elements, but these elements are not limited by these terms. These terms are only used to distinguish the first element from the second element. The terms "comprising" and "having," and any variations thereof, used in this application, are intended to cover non-exclusive inclusion. The term "multiple" used in this application refers to two or more. The term "and / or" used in this application refers to one of the embodiments, or any combination of multiple embodiments.

[0070] It should be noted that the data involved in this application (including but not limited to code files used for analysis, stored code files, and displayed prompts) are all data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0071] The risk code segment identification method provided in this application embodiment can be applied to, for example... Figure 1 The application environment shown is as follows. In this environment, server 102 communicates with terminal 104 via a network. A data storage system can store the data that server 102 needs to process. This data storage system can be integrated onto server 102 or located on the cloud or other network servers. Server 102 can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing cloud computing services. Terminal 104 can be, but is not limited to, various personal computers, laptops, smartphones, tablets, drones, low-altitude aircraft, IoT devices, and portable wearable devices. IoT devices can include smart speakers, smart TVs, smart air conditioners, smart in-vehicle devices, projection devices, etc. Portable wearable devices can include smartwatches, smart bracelets, head-mounted devices, etc. Head-mounted devices can be virtual reality (VR) devices, augmented reality (AR) devices, smart glasses, etc.

[0072] For example, firstly, server 102 receives a code file uploaded by terminal 104; then, server 102 extracts the call relationships between objects and methods in the code file; the call relationship is used to represent the call of an object to a method; next, server 102 performs risk call detection processing on the call relationship to determine risky call relationships with call risks; the call risk is the risk of calling an abnormal method, and an abnormal method is a method that has a corresponding declaration code segment but no corresponding implementation code segment in the code file; then, server 102 determines the call code segment corresponding to the risky call relationship in the code file, and obtains the risky code segment in the code file; finally, server 102 generates a prompt message for the risky code segment and displays the prompt message through terminal 104 to provide a risk warning for the risky code segment.

[0073] In some embodiments, such as Figure 2 As shown, a method for identifying risky code segments is provided, which can be applied to... Figure 1 Taking a server as an example, it can be understood that this method can also be applied to a terminal, and can also be applied to a system that includes both a server and a terminal, and is implemented through the interaction between the server and the terminal. The method includes the following steps:

[0074] Step S202: Extract the call relationships between objects and methods in the code file.

[0075] The code file is a code file written in an object-oriented programming language. More specifically, the code file is a code file written in an object-oriented dynamic programming language, such as Objective-C.

[0076] In this context, the call relationship represents an object's invocation of a method. The object and method refer to objects and methods in object-oriented programming languages. In practice, there are multiple call relationships, each corresponding to an object's invocation of a method.

[0077] In this step, when a user needs to submit a code file, the server extracts at least one call relationship between each object and each method from the code file.

[0078] In code files, the delegate design pattern is often involved. The delegate design pattern is a design pattern for inter-object communication used for data delivery, consisting of a protocol, a proxy object, a delegator, and a proxy. Therefore, objects in the code file include both proxy objects and non-proxy objects. In practical applications, the server employs different call relationship extraction strategies to extract the first call relationship corresponding to the proxy object and the second call relationship corresponding to the non-proxy objects from the code file.

[0079] Step S204: Perform risk call detection processing on the call relationship to identify risky call relationships with call risks.

[0080] Among them, the risk of invocation refers to the risk of invoking an abnormal method. An abnormal method is a method that has a corresponding declaration code segment in the code file but no corresponding implementation code segment. That is, an abnormal method is a method that is declared but not implemented. In practical applications, the code file includes the .h declaration file (also called the header file) and the .m implementation file. The method declaration code segment should be located in the .h declaration file, and the method implementation code segment should be located in the .m implementation file.

[0081] In this step, the server performs risk call detection on each call relationship to determine the existence of risky call relationships in each call relationship, and extracts the risky call relationships if they are found to exist.

[0082] In practical applications, the server adopts different risk call detection strategies to perform risk call detection processing on the first call relationship corresponding to the proxy object and the second call relationship corresponding to the non-proxy object.

[0083] Step S206: Determine the calling code segment corresponding to the risk calling relationship in the code file to obtain the risk code segment in the code file.

[0084] Among them, the calling code segment corresponding to the risk calling relationship is the code segment in the code file corresponding to the risk calling relationship.

[0085] In this step, for each risky call relationship, the server determines the code segment corresponding to the risky call relationship in the code file, obtains the call code segment corresponding to the risky call relationship, and uses it as a risky code segment in the code file.

[0086] In the aforementioned risky code segment identification method, the server, through risky call detection processing of the call relationships between objects and methods in the code file, can determine whether the call relationship poses a call risk to an abnormal method that has a corresponding declaration code segment but no corresponding implementation code segment. In other words, it determines whether the call relationship poses a call risk to a declared but unimplemented method, thus obtaining the risky call relationship. By identifying the call code segment corresponding to the risky call relationship in the code file, the server can identify risky code segments that pose a risk of calling a declared but unimplemented method. Based on this process, the risky code segment identification method no longer relies on manual investigation, thus improving investigation efficiency. Furthermore, manual investigation may lead to false positives and false negatives, resulting in a low accuracy rate in detecting call risks to declared but unimplemented methods. Therefore, the aforementioned risky code segment identification method also improves the investigation accuracy.

[0087] In some embodiments, step S202 above, extracting the call relationship between objects and methods in the code file, includes the following steps: extracting the call relationship corresponding to multiple objects from the code file according to a preset multiple call relationship extraction strategy.

[0088] Each call relationship extraction strategy is used to extract the call relationship corresponding to an object.

[0089] Among these, the multiple objects include at least non-proxy objects and protocol-based proxy objects; in practical applications, protocol-based proxy objects are proxy objects that have been declared under the protocol.

[0090] In this embodiment, the server adopts different call relationship extraction strategies to extract the first call relationship corresponding to the proxy object and the second call relationship corresponding to the non-proxy object from the code file.

[0091] In this embodiment, the server can extract the call relationships corresponding to the proxy object and the non-proxy object from the code file based on different call relationship extraction strategies.

[0092] In some embodiments, step S204 above, which involves performing risk call detection processing on the call relationship to identify risky call relationships, includes the following steps: for each type of object-related call relationship, based on the type of object corresponding to the call relationship, determining the corresponding target risk call detection strategy from a set of preset risk call detection strategies; and performing risk call detection processing on the call relationship according to the target risk call detection strategy to identify risky call relationships.

[0093] Each risk call detection strategy is used to perform risk call detection processing on the call relationship corresponding to an object.

[0094] Among these, the multiple objects include at least non-proxy objects and proxy objects under the protocol.

[0095] In this embodiment, the server adopts different risk call detection strategies to perform risk call detection processing on the first call relationship corresponding to the proxy object and the second call relationship corresponding to the non-proxy object, thereby obtaining the risk call relationship corresponding to the proxy object and the risk call relationship corresponding to the non-proxy object.

[0096] In practical applications, since failing to implement mandatory protocol methods will generate errors during code compilation, the risk of calling unimplemented methods by proxy objects can only exist when calling optional protocol methods. Furthermore, for proxy objects, a risky call relationship refers to a call relationship where the proxy object calls an optional protocol method under the corresponding protocol without performing a method response check beforehand. This method response check checks whether an object can respond to (i.e., call) a method; if the method is not implemented before calling it, the program will crash. Further, in the Objective-C environment, implicitly declared optional protocol methods will generate errors during code compilation. Therefore, for proxy objects in the Objective-C environment, the risk of calling unimplemented methods can only exist when calling explicitly declared optional protocol methods. Moreover, for proxy objects in the Objective-C environment, a risky call relationship further refers to a call relationship where the proxy object calls an explicitly declared optional protocol method under the corresponding protocol without performing a corresponding method response check beforehand.

[0097] In practical applications, since the declaration and implementation of system methods (non-custom methods) are guaranteed to be consistent by the system, for non-proxy objects, calls to declared but unimplemented methods can only exist in calls to custom methods; furthermore, for non-proxy objects, risky call relationships refer to the call relationships of non-proxy objects calling declared but unimplemented custom methods.

[0098] In this embodiment, the server can obtain the risk call relationships corresponding to the proxy object and the non-proxy object based on different risk call detection strategies.

[0099] In some embodiments, the above steps, which extract call relationships corresponding to multiple objects from the code file according to a preset multiple call relationship extraction strategy, include the following steps: determining all call relationships corresponding to all proxy objects under all protocols in the code file; filtering out the first call relationship under each protocol from all call relationships based on the proxy objects and optional protocol methods under each protocol; the first call relationship under each protocol is the call relationship between the proxy object and the optional protocol method under the protocol.

[0100] Among them, optional protocol methods under the protocol are optional protocol methods that have been declared under the protocol; optional protocol methods are methods that are declared in the protocol, but are not mandatory for classes or structs that conform to the protocol to implement.

[0101] There is at least one first invocation relationship, and each first invocation relationship corresponds to a proxy object calling an optional protocol method.

[0102] In this embodiment, firstly, the server determines all call relationships corresponding to all proxy objects in all protocols in the code file; then, for each protocol, the server determines each proxy object and each optional protocol method under that protocol; next, the server filters out the call relationships between the proxy objects and optional protocol methods under that protocol from all call relationships corresponding to all proxy objects in all protocols, and obtains at least one first call relationship.

[0103] For example, the naming format of the proxy object is id<{Protocol}>. The server determines the method called by the proxy object based on the naming format of the proxy object, thereby obtaining all the calling relationships corresponding to all proxy objects in all protocols.

[0104] In this embodiment, for each protocol, the server can filter out the first call relationship corresponding to that protocol from all call relationships based on the proxy object and optional protocol methods under that protocol.

[0105] In some embodiments, such as Figure 3 As shown, the above steps, based on the proxy objects and optional protocol methods under each protocol, filter out the first call relationship under each protocol from all call relationships, including the following steps:

[0106] Step S302: For each protocol, select candidate call relationships from all call relationships; the called method in the candidate call relationship is an optional protocol method under the protocol.

[0107] Step S304: Filter out the first call relationship under the protocol from the candidate call relationships; the proxy object in the first call relationship under the protocol is the proxy object under the protocol.

[0108] Each object has a corresponding object identifier; the object identifier is information that can uniquely identify the object, such as the object name.

[0109] Each method has a corresponding method identifier; the method identifier is information that can uniquely identify the method, such as the method name.

[0110] Each class has a corresponding class identifier; the class identifier is information that uniquely identifies the class, such as the class name. A class is a concept found in object-oriented programming languages.

[0111] In this embodiment, for each protocol, firstly, the server, based on the method identifier and class identifier of the called method in all call relationships, as well as the method identifier and class identifier of each optional protocol method under the protocol, filters out the call relationships in which the called method is any optional protocol method under the protocol, thus obtaining at least one candidate call relationship corresponding to the protocol; at this time, each candidate call relationship is a call relationship in which the called method is an optional protocol method under the protocol.

[0112] Next, based on the object identifier and class identifier of the proxy object in each candidate call relationship, as well as the object identifier and class identifier of each proxy object under the protocol, the server selects the corresponding proxy object as a candidate call relationship of any proxy object under the protocol from each candidate call relationship corresponding to the protocol, and obtains at least one first call relationship under the protocol; at this time, each first call relationship is the call relationship between the proxy object under the protocol and the optional protocol method under the protocol.

[0113] In practical applications, for each all-call relationship, the server records the method identifier and class identifier of the called method in the all-call relationship, as well as the object identifier and class identifier of the corresponding proxy object, as a data 1, thus obtaining dataset 1; for each protocol, the server records the method identifier and class identifier of each optional protocol method under the protocol as a data 2, thus obtaining dataset 2; and records the object identifier and class identifier of each proxy object under the protocol as a data 3, thus obtaining dataset 3.

[0114] For each all-call relationship, if there is a data 2 in dataset 2 that has the same method identifier of the called method and class identifier of the class as the data 1 corresponding to that all-call relationship, the server determines that all-call relationship as a candidate call relationship.

[0115] For each candidate call relationship, if there is a data 3 in dataset 3 that has the same object identifier and class identifier of the proxy object in data 1 as the candidate call relationship, the server determines the candidate call relationship as the first call relationship.

[0116] In this embodiment, the server can accurately determine the call relationship between the proxy object under a certain protocol and the optional protocol method from all the call relationships corresponding to all proxy objects under all protocols by using method identifier, object identifier and class identifier.

[0117] In some embodiments, the invocation relationship corresponding to the proxy object under each protocol is the first invocation relationship between the proxy object under the protocol and the optional protocol method under the protocol.

[0118] like Figure 4 As shown, the above steps, based on the target risk call detection strategy, perform risk call detection processing on the call relationships to determine the risk call relationships, including the following steps:

[0119] Step S402: For each protocol, determine the calling code segment corresponding to the first calling relationship under the protocol in the code file.

[0120] Step S404: Based on the calling code segment corresponding to the first calling relationship, perform a pre-method response judgment and detection process on the first calling relationship to obtain the pre-method response judgment and detection result of the first calling relationship.

[0121] Step S406: If the detection result of the preceding method response judgment indicates that the method response judgment code segment corresponding to the first call relationship does not exist, the first call relationship is determined to be a risky call relationship.

[0122] Among them, the pre-method response judgment and detection processing is used to determine whether there is a method response judgment code segment in the code file before the call code segment corresponding to the first call relationship.

[0123] The method response judgment code segment is used to judge the method response of the first call relationship. In practical applications, the method response judgment code segment refers to the code segment corresponding to the method response judgment.

[0124] In this embodiment, the server pre-collects different code implementations for method response judgment. For each protocol, the server traverses each first call relationship under that protocol. For each traversed first call relationship, the server first locates the call code segment corresponding to the first call relationship in the code file. Then, the server determines whether there is a method response judgment code segment in the code file before the call code segment corresponding to the first call relationship. If it does not exist, it means that the called optional protocol method in the first call relationship has not undergone method response judgment before being called, which indicates that the called optional protocol method in the first call relationship may have a calling risk. Therefore, the server determines the first call relationship as a risky call relationship.

[0125] In practical applications, a method response judgment code segment for judging the method response of the first call relationship is considered to exist before the call code segment corresponding to the first call relationship when the following conditions are met simultaneously:

[0126] (1) The calling code segment corresponding to the first calling relationship is inside the same method implementation as the method response judgment code segment;

[0127] (2) The method identifier of the called optional protocol method in the calling code segment corresponding to the first calling relationship is the same as the method identifier of the method to be judged in the method response judgment code segment;

[0128] (3) The line number of the method identifier of the method to be judged in the method response judgment code segment is less than the line number of the method identifier of the called optional protocol method in the call code segment corresponding to the first call relationship.

[0129] In this embodiment, for the first calling relationship, the server can determine whether there is a calling risk in the first calling relationship based on the existence of the preceding method response, and thus determine the risky calling relationship.

[0130] In some embodiments, the invocation relationship corresponding to the non-proxy object is a second invocation relationship between the non-proxy object and the custom method; the second invocation relationship is extracted from the .m implementation file in the code file. In practical applications, there is at least one second invocation relationship, and each second invocation relationship corresponds to a non-proxy object calling a custom method.

[0131] The above steps, based on the target risk call detection strategy, perform risk call detection processing on the call relationship to determine the risk call relationship from the call relationship, including the following steps: in the declaration file of the code file, determine the declared custom method, and in the implementation file, determine the implemented custom method; based on the declared custom method and the implemented custom method, perform risk call detection processing on the second call relationship to determine the risk call relationship from the second call relationship.

[0132] Among them, the declared custom method refers to the custom method that is declared, that is, the custom method that has corresponding declaration code.

[0133] Among them, the implemented custom method refers to the custom method that is implemented, that is, the custom method that has corresponding implementation code.

[0134] In this embodiment, the server determines at least one declared custom method in the .h declaration file of the code file, and at least one implemented custom method in the .m implementation file of the code file; then, the server performs risk call detection processing on each second call relationship based on each declared custom method and each implemented custom method, so as to determine the risk call relationship from the second call relationship.

[0135] In this embodiment, the server can determine the declared custom method based on the .h declaration file, and the implemented custom method based on the .m implementation file. Based on the declared custom method and the implemented custom method, the server can determine the risky call relationship from the second call relationship between the non-proxy object and the custom method.

[0136] In some embodiments, such as Figure 5 As shown, the above steps, based on the declared custom method and the implemented custom method, perform risk call detection processing on the second call relationship to determine the risk call relationship from the second call relationship, including the following steps:

[0137] Step S502: Determine whether the declared custom method is an exception method based on the method identifier of the declared custom method and the class identifier of the class to which it belongs, as well as the method identifier of the implemented custom method and the class identifier of the class to which it belongs.

[0138] Step S504: If the declared custom method is an exception method, determine whether there is a target call relationship in the second call relationship based on the method identifier and class identifier of the declared custom method, the method identifier of the called custom method in the second call relationship, and the class identifier of the class to which the non-proxy object belongs; the called method in the target call relationship matches the declared custom method.

[0139] Step S506: If the target call relationship exists, determine that the target call relationship is a risky call relationship.

[0140] In this embodiment, for each declared custom method, the server searches in the method identifier and class identifier of the class to which the implemented custom method belongs to see if there is a method identifier and class identifier that match the method identifier and class identifier of the declared custom method, thereby determining whether the declared custom method is an abnormal method.

[0141] Then, if the declared custom method is an exception method, the server searches in the method identifier of the called custom method and the class identifier of the class to which the non-proxy object belongs in each second call relationship to see if there is a method identifier and class identifier that match the method identifier and class identifier of the declared custom method and the class identifier of the class to which the non-proxy object belongs, and thus determines whether there is a target call relationship in the second call relationship.

[0142] Finally, if the target call relationship exists, the server identifies the target call relationship as a risky call relationship.

[0143] In this embodiment, the server can determine whether the declared custom method is a declared unimplemented custom method based on the method identifier and class identifier of the class to which the declared custom method belongs, as well as the method identifier and class identifier of the class to which the implemented custom method belongs. Based on the method identifier and class identifier of the declared custom method, as well as the method identifier of the called custom method and the class identifier of the non-proxy object in the second call relationship, the server can determine whether there is a call relationship in the second call relationship that calls a declared unimplemented custom method, thereby identifying risky call relationships.

[0144] In some embodiments, step S502 above, determining whether a declared custom method is an exception method based on the method identifier of the declared custom method and the class identifier of its class, and the method identifier of the implemented custom method and the class identifier of its class, includes the following steps: if there is a target class identifier in the class identifier of the class to which the implemented custom method belongs that matches the class identifier of the declared custom method, obtain a list of implementation method identifiers of the target class corresponding to the target class identifier; if there is no method identifier of the declared custom method in the list of implementation method identifiers of the target class, determine that the declared custom method is an exception method.

[0145] The target class's implementation method identifier list includes the method identifiers of the implemented custom methods within the target class. This list is constructed based on the method identifiers of the implemented custom methods and the class identifier of their respective classes. In practice, the server constructs a list of implementation method identifiers for classes with the same class identifier, based on the method identifiers of the implemented custom methods that share the same class identifier.

[0146] In this context, matching the class identifier of the class to which the implemented custom method belongs with the class identifier of the class to which the declared custom method belongs means that the class identifier of the class to which the implemented custom method belongs is the same as the class identifier of the class to which the declared custom method belongs.

[0147] Among them, object-oriented programming languages ​​have the feature of inheritance. Therefore, the target class corresponding to the target class identifier includes the class corresponding to the target class identifier, as well as the subclasses of the class corresponding to the target class identifier and the subclasses of the subclasses.

[0148] In this embodiment, for each declared custom method, if the server finds a target class identifier in the class identifier of each implemented custom method that is identical to the class identifier of the class to which the declared custom method belongs, it obtains the class corresponding to the target class identifier and the list of implementation method identifiers of the class.

[0149] Then, the server searches for the method identifier of the declared custom method in the list of implementation method identifiers of the current class. If the method identifier of the declared custom method is found, that is, the method identifier of the declared custom method exists in the list of implementation method identifiers of the current class, it means that the declared custom method is implemented in the current class, and therefore it cannot be a declared but unimplemented method. If the method identifier of the declared custom method is not found, that is, the method identifier of the declared custom method does not exist in the list of implementation method identifiers of the current class, it means that the declared custom method is not implemented in the current class, but it is not ruled out that the declared custom method is implemented in a subclass of the current class. Therefore, the server obtains the next subclass of the current class and the list of implementation method identifiers of the next subclass.

[0150] Next, the server searches for the method identifier of the declared custom method in the implementation method identifier list of the subclass. If the method identifier of the declared custom method is found, that is, the method identifier of the declared custom method exists in the implementation method identifier list of the subclass, it means that the declared custom method is implemented in the subclass, and therefore cannot be a declared unimplemented method. If the method identifier of the declared custom method is not found, that is, the method identifier of the declared custom method does not exist in the implementation method identifier list of the subclass, it means that the declared custom method is not implemented in the subclass, but it is not ruled out that the declared custom method is implemented in the next subclass of the subclass. Therefore, the server continues to obtain the next subclass of the subclass and the implementation method identifier list of the next subclass, and so on, until the Nth subclass (N can be set according to actual needs) is found, or the last subclass is found. If the method identifier of the declared custom method is not found in the corresponding implementation method identifier list when the Nth subclass or the last subclass is found, then the declared custom method is determined to be an exception method declared unimplemented.

[0151] In practical applications, for each declared custom method, the server records the method identifier of the declared custom method and the class identifier of its class as a data entry 4, thus obtaining dataset 4; for each implemented custom method, the server records the method identifier of the implemented custom method and the class identifier of its class as a data entry 5, thus obtaining dataset 5; for each second call relationship, the server records the method identifier of the called method in the second call relationship and the class identifier of the class of the non-proxy object as a data entry 6, thus obtaining dataset 6.

[0152] For each data entry 4, if a class identifier with the same name as the class identifier of the class to which data entry 4 belongs exists in data entry 5, the server retrieves the list of implementation method identifiers of the class corresponding to the class with the same name. If the method identifier of data entry 4 does not exist in the list of implementation method identifiers, the server continues to search the list of implementation method identifiers of the next subclass of the class corresponding to the class with the same name... until the Nth subclass is found, or the last subclass is found. If the method identifier of data entry 4 is not found in the list of implementation method identifiers of the Nth subclass or the last subclass, it is determined that the declared custom method corresponding to the method identifier of data entry 4 is not implemented, that is, the declared custom method corresponding to data entry 4 is a declared unimplemented method.

[0153] In this embodiment, on the one hand, the server can determine whether the declared custom method is implemented based on the method identifier of the declared custom method and the class identifier of its class, as well as the method identifier of the implemented custom method and the class identifier of its class; on the other hand, by recursively querying the class, the inheritance characteristics in the programming language can be fully considered, and the server can accurately determine whether the declared custom method is a declared unimplemented method based on the inheritance characteristics.

[0154] In some embodiments, step S504 above, determining whether a target call relationship exists in the second call relationship based on the method identifier of the declared custom method and the class identifier of its class, as well as the method identifier of the called custom method and the class identifier of the non-proxy object in the second call relationship, includes the following steps: In the second call relationship, if there exists a second call relationship in which the method identifier of the corresponding called method matches the method identifier of the declared custom method, and the class identifier of the corresponding non-proxy object matches the class identifier of the declared custom method, then the corresponding second call relationship is determined as the target call relationship.

[0155] In this context, "the method identifier of the called method matches the method identifier of the declared custom method" means that the method identifier of the called method is the same as the method identifier of the declared custom method.

[0156] In object-oriented programming languages, inheritance is a feature. Therefore, the class identifier of the class to which the non-proxy object belongs must match the class identifier of the class to which the declared custom method belongs. There are two cases: one is that the class identifier of the class to which the non-proxy object belongs is the same as the class identifier of the class to which the declared custom method belongs; the other is that the class identifier of the class to which the non-proxy object belongs is the same as the class identifier of the subclass of the class to which the declared custom method belongs. That is, the class to which the class identifier of the class to which the non-proxy object belongs is a subclass of the class to which the class identifier of the declared custom method belongs. In practical applications, it can be the next subclass or the Mth subclass (M can be set according to actual needs).

[0157] In this embodiment, for each declared custom method identified as an unimplemented method, the server searches for a second call relationship in each second call relationship where the method identifier of the called custom method is the same as the method identifier of the declared custom method, and the class identifier of the class to which the corresponding non-proxy object belongs is the same as the class identifier of the class to which the declared custom method belongs. If a second call relationship satisfying the above conditions is found, the found second call relationship is determined as the target call relationship. The found second call relationship indicates that the declared custom method is called by a non-proxy object under the same class, and the declared custom method is an unimplemented method. Therefore, the target call relationship is determined as a risky call relationship that calls an unimplemented method. If no second call relationship satisfying the above conditions is found, it indicates that the declared custom method is not called by a non-proxy object under the same class, but it does not rule out that the declared custom method is called by a non-proxy object under a subclass of the same class. Therefore, the server obtains the class identifier of the next subclass of the same class corresponding to the class identifier of the class to which the declared custom method belongs.

[0158] Next, the server searches for second call relationships in each second call relationship where the method identifier of the called custom method is the same as the method identifier of the declared custom method, and the class identifier of the class to which the corresponding non-proxy object belongs is the same as the class identifier of the subclass. If a second call relationship satisfying the above conditions is found, it is determined as the target call relationship. The found second call relationship indicates that the declared custom method is called by the non-proxy object under the subclass, and the declared custom method is a declared but not implemented method. Therefore, the target call relationship is determined as a risky call relationship that calls a declared but not implemented method. If no second call relationship satisfying the above conditions is found, then... This indicates that the declared custom method was not called by a non-proxy object under this subclass. However, it does not preclude the possibility that the declared custom method could be called by a non-proxy object under the next subclass of this subclass. Therefore, the server obtains the class identifier of the next subclass of this subclass... until the Mth subclass is found, or the last subclass is found. If no corresponding second calling relationship is found when the Mth subclass or the last subclass is found, it means that the declared custom method that was declared not implemented was not called. Therefore, it is determined that there is no second calling relationship that called the declared custom method that was declared not implemented, that is, there is no risky calling relationship that called the declared custom method that was declared not implemented.

[0159] In practical applications, for each second call relationship, the server records the method identifier of the called method and the class identifier of the class to which the non-proxy object belongs as a data 6, thus obtaining dataset 6.

[0160] For each data 4 where the declared custom method is a declared unimplemented method, the server searches in dataset 6 for data 6 where the method identifier of the called custom method is the same as the method identifier in data 4, and the class identifier of the class to which the corresponding non-proxy object belongs is the same as the class identifier in data 4. If found, the second call relationship corresponding to the found data 6 is determined to be the target call relationship, thus obtaining the risk call relationship; if not found, the class identifier of the next subclass of the class corresponding to the class identifier in data 4 is obtained, and the search continues in dataset 6 for data 6 where the method identifier of the called custom method is the same as the method identifier in data 4, and the class identifier of the class to which the corresponding non-proxy object belongs is the same as the class identifier of the subclass, ... until the Mth subclass is found, or the last subclass is found.

[0161] In this embodiment, on the one hand, the server can determine whether a declared custom method that is declared but not implemented is called based on the method identifier of the declared custom method and the class identifier of its class, as well as the method identifier of the called method and the class identifier of the non-proxy object in the second call relationship; on the other hand, by recursively querying the class, the inheritance characteristics in the programming language can be fully considered, and the determination of whether a declared custom method that is declared but not implemented is called can be accurately made based on the inheritance characteristics.

[0162] In some embodiments, after obtaining the risky code segment in the code file, the method further includes the following steps: generating a warning message for the risky code segment; and providing a risk warning for the risky code segment through the warning message.

[0163] In this embodiment, for each risky code segment, the server generates a warning message for that risky code segment and sends the warning message to the terminal; the terminal displays the warning message for that risky code segment to provide a risk warning.

[0164] In practical applications, the warning information includes the reason for the risk, the file identifier (such as the file name) of the code file where the risky code segment is located, and the line number of the risky code segment in that code file.

[0165] In practical applications, the terminal can locate the risky code segment in the corresponding code file based on the prompt information and highlight the risky code segment.

[0166] In some embodiments, the risky code segment identification method provided in this application is applied in an iOS development environment.

[0167] In some embodiments, the risky code segment identification method provided in this application can be encapsulated into a running script and added to the configuration file of the code project to achieve automatic execution during the code compilation stage.

[0168] In this embodiment, the server can provide risk warnings for risky code segments, so that users can quickly understand the risk situation of these code segments.

[0169] To more clearly illustrate the risky code segment identification method provided in the embodiments of this application, the following specific embodiment is used to describe the risky code segment identification method in detail. However, it should be understood that the embodiments of this application are not limited thereto. In some embodiments, this application also provides a static testing method for crashes that call unimplemented methods, specifically including the following steps:

[0170] 1. For example Figure 6 The diagram illustrates a test performed on a proxy object that may call an optional protocol method that is not declared to be implemented.

[0171] (1) Determine all call relationships corresponding to all declared proxy objects under all protocols in the code file. Based on the declared proxy objects and declared optional protocol methods under each protocol, filter out the first call relationship between the proxy object and the optional protocol method under each protocol from all call relationships.

[0172] (2) The code for pre-collecting response judgments;

[0173] (2) Determine the calling code segment corresponding to the first calling relationship in the code file, and determine whether there is a method response judgment code segment in the code file before the calling code segment for judging the method response of the first calling relationship; if there is no method response judgment code segment corresponding to the first calling relationship, determine the first calling relationship as the first problem structure.

[0174] 2. For example Figure 7 The diagram illustrates a test performed on a non-proxy object when a custom method that is declared but not implemented is called.

[0175] (1) In the declaration file of the code file, determine the declared custom method; in the implementation file, determine the implemented custom method; and determine the second calling relationship between the non-proxy object and the custom method.

[0176] (2) In the class identifier of the class to which the custom method is implemented, find the target class identifier that matches the class identifier of the class to which the custom method is declared; if the target class identifier is found, obtain the list of implementation method identifiers of the target class corresponding to the target class identifier; if the method identifier of the custom method is not found in the list of implementation method identifiers of the target class, determine that the custom method is a declared unimplemented method.

[0177] (3) In the second call relationship, find the target call relationship where the method identifier of the corresponding called method matches the method identifier of the declared custom method that is determined to be a declared custom method, and the class identifier of the class to which the corresponding non-proxy object belongs matches the class identifier of the class to which the declared custom method is determined to be a declared custom method; if the target call relationship is found, the found target call relationship is determined as the second problem structure.

[0178] In this embodiment, firstly, it improves the ability to detect problems early. It provides a deterministic testing scheme that can identify crash risks caused by proxy objects calling unimplemented optional protocol methods due to a lack of pre-processor response checks, as well as crash risks caused by non-proxy objects calling unimplemented methods. Furthermore, by adding corresponding execution scripts to the code project configuration file, the problem detection phase can be moved from the runtime phase to the compilation phase, effectively reducing the number of crashes after product launch and minimizing R&D resource consumption. Secondly, it improves testing efficiency and saves on manual testing costs. The scanning script can be triggered by code submission, and an automatic order and notification to the executor are generated upon task completion. Thirdly, it has strong versatility. This embodiment is applicable to all iOS projects using Objective-C as the development language; simply adding the corresponding execution script to the configuration file is sufficient.

[0179] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages in other steps. It is understood that the steps in different embodiments can be freely combined as needed, and all non-contradictory solutions formed by such combinations are within the scope of protection of this application.

[0180] Based on the same inventive concept, this application also provides a risk code segment identification device for implementing the risk code segment identification method described above. The solution provided by this device is similar to the implementation described in the above method; therefore, the specific limitations in one or more risk code segment identification device embodiments provided below can be found in the limitations of the risk code segment identification method described above, and will not be repeated here.

[0181] In some embodiments, such as Figure 8 As shown, a risky code segment identification device is provided, including: a call relationship extraction module 802, a risky call detection module 804, and a code segment determination module 806, wherein:

[0182] The call relationship extraction module 802 is used to extract the call relationship between objects and methods in the code file; the call relationship is used to represent the call of an object to a method.

[0183] The risk call detection module 804 is used to perform risk call detection processing on the call relationship in order to identify risky call relationships with call risks. The call risk is the risk of calling an abnormal method. An abnormal method is a method that has a corresponding declaration code segment in the code file but no corresponding implementation code segment.

[0184] The code segment determination module 806 is used to determine the calling code segment corresponding to the risk calling relationship in the code file, and obtain the risk code segment in the code file.

[0185] In one embodiment, the call relationship extraction module 802 is further configured to extract call relationships corresponding to multiple objects from the code file according to a preset multiple call relationship extraction strategy; each call relationship extraction strategy is used to extract the call relationship corresponding to one object; the multiple objects include at least non-proxy objects and proxy objects under the protocol;

[0186] The risk call detection module 804 is also used to determine the corresponding target risk call detection strategy from a variety of preset risk call detection strategies based on the type of object corresponding to each type of object call relationship; each risk call detection strategy is used to perform risk call detection processing on the call relationship corresponding to one type of object; and risk call detection processing is performed on the call relationship according to the target risk call detection strategy to determine the risk call relationship from the call relationship.

[0187] In one embodiment, the call relationship extraction module 802 is further configured to determine all call relationships corresponding to all proxy objects under all protocols in the code file; based on the proxy objects and optional protocol methods under each protocol, filter out the first call relationship under each protocol from all call relationships; the first call relationship under each protocol is the call relationship between the proxy object and the optional protocol method under the protocol.

[0188] In one embodiment, the call relationship extraction module 802 is further configured to, for each protocol, filter out candidate call relationships from all call relationships; the called method in the candidate call relationship is an optional protocol method under the protocol; filter out the first call relationship under the protocol from the candidate call relationships; the proxy object in the first call relationship under the protocol is a proxy object under the protocol.

[0189] In one embodiment, the invocation relationship corresponding to the proxy object under each protocol is the first invocation relationship between the proxy object under the protocol and the optional protocol method under the protocol.

[0190] The risk call detection module 804 is further configured to, for each protocol, determine the call code segment corresponding to the first call relationship under the protocol in the code file; perform pre-call response judgment detection processing on the first call relationship based on the call code segment corresponding to the first call relationship, and obtain the pre-call response judgment detection result of the first call relationship; the pre-call response judgment detection processing is used to determine whether there is a method response judgment code segment before the call code segment corresponding to the first call relationship in the code file; the method response judgment code segment is used to perform method response judgment on the first call relationship; if the pre-call response judgment detection result indicates that the method response judgment code segment corresponding to the first call relationship does not exist, the first call relationship is determined to be a risk call relationship.

[0191] In one embodiment, the invocation relationship corresponding to the non-proxy object is a second invocation relationship between the non-proxy object and the custom method; the second invocation relationship is extracted from the implementation file in the code file.

[0192] The risk call detection module 804 is also used to identify the declared custom method in the declaration file of the code file and the implemented custom method in the implementation file; based on the declared custom method and the implemented custom method, risk call detection processing is performed on the second call relationship to identify the risk call relationship from the second call relationship.

[0193] In one embodiment, the risk call detection module 804 is further configured to determine whether the declared custom method is an abnormal method based on the method identifier of the declared custom method and the class identifier of its class, as well as the method identifier of the implemented custom method and the class identifier of its class; if the declared custom method is an abnormal method, it is configured to determine whether a target call relationship exists in the second call relationship based on the method identifier of the declared custom method and the class identifier of its class, as well as the method identifier of the called custom method in the second call relationship and the class identifier of the class to which the non-proxy object belongs; the called method in the target call relationship matches the declared custom method; if the target call relationship exists, the target call relationship is determined to be a risky call relationship.

[0194] In one embodiment, the risk call detection module 804 is further configured to, if a target class identifier exists in the class identifier of the class to which the implemented custom method belongs, obtain a list of implementation method identifiers of the target class corresponding to the target class identifier; the target class identifier matches the class identifier of the class to which the declared custom method belongs; the list of implementation method identifiers of the target class includes the method identifiers of the implemented custom methods under the target class, and the list of implementation method identifiers of the target class is constructed based on the method identifiers of the implemented custom methods and the class identifier of the class to which the target class belongs; if the method identifier of the declared custom method does not exist in the list of implementation method identifiers of the target class, determine that the declared custom method is an abnormal method.

[0195] In one embodiment, the risk call detection module 804 is further configured to determine the corresponding second call relationship as the target call relationship when there is a second call relationship in which the method identifier of the corresponding called method matches the method identifier of the declared custom method and the class identifier of the class to which the corresponding non-proxy object belongs matches the class identifier of the class to which the declared custom method belongs.

[0196] In one embodiment, the risk code segment identification device further includes a risk information prompting module for generating prompting information for the risk code segment; and providing risk warnings for the risk code segment through the prompting information.

[0197] Each module in the aforementioned risk code segment identification device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the memory of a computer device as software, so that the processor can call and execute the operations corresponding to each module.

[0198] In some embodiments, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 9As shown, this computer device includes a processor, memory, input / output interfaces (I / O), and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides the environment for the operating system and computer programs stored in the non-volatile storage media. The database stores the code for different response and judgment methods. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communicating with external terminals via a network connection. When executed by the processor, the computer program implements a risk code segment identification method.

[0199] Those skilled in the art will understand that Figure 9 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0200] In some embodiments, a computer device is also provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above method embodiments.

[0201] In some embodiments, a computer-readable storage medium is provided having a computer program stored thereon that, when executed by a processor, implements the steps in the above method embodiments.

[0202] In some embodiments, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above method embodiments.

[0203] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0204] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0205] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A method for identifying risky code segments, characterized in that, The method includes: Extract the call relationships between objects and methods in the code file; the call relationships are used to represent the calls made by the objects to the methods; Risk call detection processing is performed on the call relationships to identify risky call relationships with call risks; the call risk is the risk of calling an abnormal method, and the abnormal method is a method that has a corresponding declaration code segment in the code file but no corresponding implementation code segment; The risk code segment in the code file is obtained by determining the calling code segment corresponding to the risk calling relationship in the code file.

2. The method according to claim 1, characterized in that, The extraction of the call relationships between objects and methods in the code file includes: Based on multiple preset call relationship extraction strategies, call relationships corresponding to multiple objects are extracted from the code file; each call relationship extraction strategy is used to extract the call relationship corresponding to one object; the multiple objects include at least non-proxy objects and proxy objects under the protocol; The step of performing risk call detection processing on the call relationships to determine risky call relationships with call risks includes: For each type of object and its corresponding call relationship, based on the type of the object corresponding to the call relationship, a target risk call detection strategy is determined from a set of preset risk call detection strategies; each risk call detection strategy is used for risk call detection processing for a call relationship corresponding to one type of object. According to the target risk call detection strategy, the call relationship is subjected to risk call detection processing in order to determine the risk call relationship from the call relationship.

3. The method according to claim 2, characterized in that, The step of extracting call relationships corresponding to multiple objects from the code file based on preset multiple call relationship extraction strategies includes: Determine all call relationships corresponding to all proxy objects under all protocols in the code file; Based on the proxy object and optional protocol method under each protocol, the first call relationship under each protocol is selected from all the call relationships; the first call relationship under each protocol is the call relationship between the proxy object and the optional protocol method under the protocol.

4. The method according to claim 3, characterized in that, The step of selecting the first call relationship under each protocol from all call relationships based on the proxy object and optional protocol method under each protocol includes: For each protocol, candidate call relationships are selected from all the call relationships; the called method in the candidate call relationship is the optional protocol method under the protocol. From the candidate call relationships, the first call relationship under the protocol is selected; the proxy object in the first call relationship under the protocol is the proxy object under the protocol.

5. The method according to claim 2, characterized in that, The invocation relationship corresponding to the proxy object under each protocol is the first invocation relationship between the proxy object under the protocol and the optional protocol method under the protocol. The step of performing risk call detection processing on the call relationships according to the target risk call detection strategy, in order to determine the risk call relationships from the call relationships, includes: For each protocol, in the code file, determine the call code segment corresponding to the first call relationship under the protocol; Based on the calling code segment corresponding to the first calling relationship, a pre-method response judgment and detection process is performed on the first calling relationship to obtain the pre-method response judgment and detection result of the first calling relationship; the pre-method response judgment and detection process is used to determine whether there is a method response judgment code segment before the calling code segment corresponding to the first calling relationship in the code file; the method response judgment code segment is used to perform method response judgment on the first calling relationship; If the detection result of the preceding method response indicates that the method response judgment code segment corresponding to the first call relationship does not exist, the first call relationship is determined to be the risky call relationship.

6. The method according to claim 2, characterized in that, The invocation relationship corresponding to the non-proxy object is a second invocation relationship between the non-proxy object and the custom method; the second invocation relationship is extracted from the implementation file in the code file; The step of performing risk call detection processing on the call relationships according to the target risk call detection strategy, in order to determine the risk call relationships from the call relationships, includes: In the declaration file of the code file, the declared custom method is identified; in the implementation file, the implemented custom method is identified. Based on the declared custom method and the implemented custom method, risk call detection processing is performed on the second call relationship to determine the risk call relationship from the second call relationship.

7. The method according to claim 6, characterized in that, The step of performing risk call detection processing on the second call relationship based on the declared custom method and the implemented custom method, in order to determine the risk call relationship from the second call relationship, includes: Based on the method identifier and class identifier of the declared custom method, and the method identifier and class identifier of the implemented custom method, determine whether the declared custom method is the exception method; In the case where the declared custom method is the exception method, based on the method identifier and class identifier of the declared custom method, as well as the method identifier of the called custom method in the second call relationship and the class identifier of the class to which the non-proxy object belongs, it is determined whether a target call relationship exists in the second call relationship; the called method in the target call relationship matches the declared custom method. If the target call relationship exists, the target call relationship is determined to be the risky call relationship.

8. The method according to claim 7, characterized in that, The step of determining whether the declared custom method is an exception method based on the method identifier and class identifier of the declared custom method, and the method identifier and class identifier of the implemented custom method, includes: If a target class identifier exists in the class identifier of the class to which the implemented custom method belongs, obtain the list of implementation method identifiers of the target class corresponding to the target class identifier; the target class identifier matches the class identifier of the class to which the declared custom method belongs; the list of implementation method identifiers of the target class includes the method identifiers of the implemented custom methods under the target class, and the list of implementation method identifiers of the target class is constructed based on the method identifiers of the implemented custom methods and the class identifier of the class to which the class belongs; If the method identifier of the declared custom method does not exist in the implementation method identifier list of the target class, the declared custom method is determined to be the exception method.

9. The method according to claim 7, characterized in that, The step of determining whether a target invocation relationship exists in the second invocation relationship based on the method identifier and class identifier of the declared custom method, and the method identifier of the called custom method and the class identifier of the non-proxy object in the second invocation relationship includes: In the second invocation relationship, if there exists a second invocation relationship in which the method identifier of the called method matches the method identifier of the declared custom method, and the class identifier of the class to which the corresponding non-proxy object belongs matches the class identifier of the class to which the declared custom method belongs, then the corresponding second invocation relationship is determined as the target invocation relationship.

10. The method according to any one of claims 1 to 9, characterized in that, After obtaining the risky code segment from the code file, the following is also included: Generate a warning message for the risk code segment; The aforementioned prompt information serves as a risk warning for the risky code segment.

11. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 10.

12. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 10.

13. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 10.

Images