A method and system for detecting application program interface misuse

Abstract

The application discloses a kind of method and system for detecting application program interface misuse, belong to computer software technical field.The present application is to solve the technical problems that the API use specification depends on manual writing, the coverage is insufficient, the misuse detection capability is limited, mainly using the call chain analysis based on seed specification, key variable flow tracking, data flow verification and iteration expansion mechanism, automatically generating API use specification, and being used for static detection program API calling behavior not following specification.The present application can realize the efficient identification and accurate report of API misuse behavior, improve the security and reliability of software system.

Description

Technical Field

[0001] This invention belongs to the field of computer software technology, and specifically relates to a method and system for detecting misuse of application programming interfaces. Background Technology

[0002] Modern software development is becoming increasingly complex, and APIs (Application Programming Interfaces) play a crucial role in achieving modularity and diverse functionality. However, proper use of APIs typically requires adherence to specific specifications, such as resource release and error checking. Failure to comply with these specifications can lead to problems like memory leaks, unbalanced reference counts, and system crashes, seriously threatening system stability and security. Existing methods primarily extract API specifications through documentation, code usage patterns, or historical patches, but these methods have significant limitations in practical applications.

[0003] Methods for extracting specifications through documentation rely on the completeness of API documentation. However, in reality, API documentation is often incomplete or lacks clear follow-up instructions, providing only high-level descriptions and failing to cover complex scenarios. Usage pattern-based mining methods attempt to extract specifications by analyzing frequent API call patterns in the code. However, some APIs have limited usage scenarios, resulting in insufficient data samples to form reliable patterns, and may even lead to misleading results due to frequent misuse. Methods relying on patches for specification extraction are limited by patch quality, only covering fixed or identified issues and struggling to extend to unidentified or unfixed potential error scenarios. Summary of the Invention

[0004] The purpose of this invention is to address the problems of existing API specification generation methods relying on external information and having insufficient coverage. It proposes a method and system for detecting misuse of application programming interfaces (APIs) to expand the coverage of API specifications and detect errors in programs. This method can identify API calls that do not follow the specifications, significantly improving the efficiency and accuracy of error detection.

[0005] To achieve the above objectives, the present invention adopts the following technical solution.

[0006] A method for detecting misuse of application programming interfaces (APIs) includes the following steps: Based on the initial application interface usage specification, the key variable flow path of the target application interface call chain in the target program is extracted through static analysis. Based on the flow path of the key variables, the caller and callee are analyzed to identify candidate interfaces that meet the conditions for standardized propagation and their predecessor or successor operations. Data flow verification is performed on the candidate interfaces and their associated operations to generate a new application programming interface (API) usage specification in the form of triples; The specification generation process is repeatedly executed using the new application programming interface specification as iterative input until a preset stopping condition is met to build the target specification library. The target program is statically scanned using the target specification library to identify non-compliant calling behaviors and output misuse detection results.

[0007] Furthermore, by static analysis, the key variable flow paths of the target application interface call chain in the target program are extracted, including: Obtain the initial application interface usage specification, which includes the target application interface, key variables, and subsequent operations; Static analysis is performed on the target program to identify upstream and downstream interface sequences that have a calling relationship with the target application interface; Track the parameter transmission path, return value usage path, and variable state evolution of the key variables in the upstream and downstream interface sequence.

[0008] Furthermore, candidate interfaces that meet the canonical propagation conditions are identified, including: Locate the subsequent interface that directly calls the target application interface and has a clear call path relationship; Verify whether the key variable is propagated from the target application interface to the subsequent interface as a parameter or return value; Detect the semantic state of the key variable in the propagation path and determine whether the key variable has been modified or damaged by other interface calls; Subsequent interfaces that satisfy the conditions of path relationship, variable propagation, and semantic preservation are identified as candidate interfaces.

[0009] Furthermore, identify the preceding or succeeding operations that meet the canonical propagation conditions, including: The predecessor interface of the target application interface is identified using control flow graph analysis techniques. The source path of the key variables in the predecessor interface is traced using data stream tracing technology; Analyze the initialization, configuration, or pre-call operations of the key variables before the target application interface is invoked to determine the preceding operations.

[0010] Furthermore, data flow verification is performed on the candidate interfaces and their associated operations, including: Static data flow analysis is performed on the call chain of the candidate interface to retrieve the assignment, release, and reference operations of the key variables; Compare the operation sequence with the preset logical integrity criteria to verify whether there are any omissions or abnormalities in the variable transfer process; Eliminate propagation paths that fail logical integrity checks or whose critical variables are corrupted.

[0011] Furthermore, a new application programming interface (API) specification in the form of triples is generated, including: Based on the propagation path between the candidate interface and the target application interface, the corresponding key variables and operation sequences are associated; Using the candidate interface as the new target object, and combining it with the verified operation sequence, construct a logical relationship description that conforms to the triple structure of target interface, key variables, and subsequent operations.

[0012] Furthermore, the specification generation process is repeatedly executed using the specification as iterative input for the new application programming interface, including: The generated new application programming interface is injected into the seed specification pool using the specification. Starting with the newly injected specification, the analysis, identification, verification, and generation steps are triggered cyclically. Monitor the update status of the specification pool, and stop iterating when the traversal depth reaches a preset threshold or no new specifications are generated.

[0013] Furthermore, identify non-compliant calling behaviors, including: Match the actual interface call sequence in the target program with the triplet logic in the target specification library; Detect whether there are any missing operations, incorrect call order, or improper references in the call sequence; Calling behavior exhibiting the aforementioned situation is determined to be an interface misuse behavior.

[0014] Furthermore, the misuse detection results are output, including: Extract the specific location and contextual code information of the interface misuse behavior in the source code; Tracing back and recording the key variable flow paths that led to misuse; Based on the subsequent operation definitions in the target specification library, match and generate targeted remedial measures suggestions.

[0015] A system for detecting misuse of application programming interfaces (APIs), comprising: The propagation analysis module is used to extract the key variable flow path of the target application interface call chain in the target program through static analysis based on the initial application interface usage specification, and to analyze the caller and callee according to the key variable flow path, and identify candidate interfaces and their predecessor or successor operations that meet the specification propagation conditions. The specification generation module is used to perform data flow verification on the candidate interfaces and their associated operations, generate new application interface usage specifications in the form of triples, and repeatedly execute the specification generation process with the new application interface usage specifications as iterative input until a preset stopping condition is met to build the target specification library. The error detection module is used to perform static scanning of the target program using the target specification library, identify non-compliant calling behaviors, and output misuse detection results.

[0016] The present invention has achieved the following beneficial effects.

[0017] 1. Based on the flow path and operational consistency of key variables in the API call chain, this invention automatically realizes the propagation and inheritance of API specifications, and can expand and generate new API specifications with a wider coverage from a small number of seed specifications.

[0018] 2. This invention does not rely on high-quality documentation or complete API usage patterns, but only utilizes the call chain relationship of the program itself for analysis. It is suitable for scenarios that lack complete comments or external specification documentation, and has stronger adaptability and practicality.

[0019] 3. This invention uses data-driven and propagation analysis techniques to extract upstream and downstream relationships in the call chain, uncover the flow paths and operational characteristics of key variables, and improve the accuracy and completeness of API usage specifications extraction.

[0020] 4. The API specification generated by this invention can be directly used to verify API call behavior in programs, effectively detecting potential errors caused by specification violations, including reference counting leaks, memory leaks, and null pointer dereferences.

[0021] 5. This invention has good scalability and can be integrated with other static analysis tools and error detection tools to further enhance the error detection capability and analysis depth of the software system.

[0022] 6. This invention can improve the automation level of program analysis and the coverage of error detection, effectively enhancing the security and reliability of software systems. Attached Figure Description

[0023] Figure 1 This is a flowchart illustrating a method for detecting misuse of an application programming interface (API) as provided in an embodiment.

[0024] Figure 2 Example diagram of API specification propagation model.

[0025] Figure 3 This is an example diagram illustrating the workflow of the system of the present invention. Detailed Implementation

[0026] To make the various technical features, advantages, or effects of the present invention more apparent and understandable, detailed descriptions are provided below through embodiments.

[0027] An embodiment of the present invention provides a method for detecting misuse of application programming interfaces, such as... Figure 1 As shown, to extend the coverage of API usage specifications and detect non-compliant calling behaviors in programs, thereby improving the security and reliability of software systems, the following steps are included: Step S1: Based on the initial application interface usage specification, extract the key variable flow path of the target application interface call chain in the target program through static analysis; Specifically, the initial application programming interface (API) is represented in the form of a triple, defined as <target API, key variable, subsequent operation>. By analyzing the upstream and downstream relationships of the API call chain in the program, the flow path of the key variable in the call chain is extracted.

[0028] The key variable flow path extraction includes: Step S11: Obtain the initial application interface usage specification, which includes the target API, key variables, and subsequent operations; Step S12: Perform static analysis on the target program to identify the upstream and downstream interface sequences that have a calling relationship with the target API; Step S13: Track the parameter transmission path, return value usage path, and variable state evolution of the key variables in the upstream and downstream interface sequence.

[0029] Step S2: Analyze the caller and callee based on the key variable flow path, and identify candidate interfaces and their predecessor or successor operations that meet the standard propagation conditions. Specifically, by analyzing the callers of the target API, we identify its successor APIs and verify whether they meet the canonical propagation conditions. If the conditions are met, the successor APIs are included in the candidate set and the propagation path is recorded. At the same time, we identify the predecessor APIs and the source paths of key variables through control flow graph analysis and data flow tracing to determine whether they conform to the logical order.

[0030] Among them, the candidate interfaces that meet the canonical propagation conditions include: Step S21: Locate the subsequent interface that directly calls the target API and has a clear call path relationship; Step S22: Verify whether the key variable is propagated from the target API to the subsequent interface as a parameter or return value; Step S23: Detect the semantic state of the key variable in the propagation path and determine whether the key variable has been modified or damaged by other interface calls; Step S24: The successor interface that satisfies the conditions of path relationship, variable propagation and semantic preservation is determined as the candidate interface.

[0031] Identifying predecessor or successor operations that meet the canonical propagation conditions includes: Step S25: Identify the predecessor interface of the target API using control flow graph analysis technology; Step S26: Trace the source path of the key variable in the predecessor interface using data flow tracing technology; Step S27: Analyze the initialization operation, configuration operation, or pre-call operation of the key variables before the target API is called to determine the preceding operation.

[0032] Step S3: Perform data flow verification on the candidate interfaces and their associated operations to generate a new application programming interface (API) usage specification in the form of a triple; Specifically, data flow analysis is used to verify the flow process and operation sequence of key variables in the call chain, ensuring that the newly generated API specification has logical integrity and semantic correctness.

[0033] The data flow verification of the candidate interfaces and their associated operations includes: Step S31: Perform static data flow analysis on the call chain where the candidate interface is located, and retrieve the assignment, release and reference operations of the key variables; Step S32: Compare the operation sequence with the preset logical integrity criteria to verify whether there are any omissions or abnormalities in the variable transfer process; Step S33: Eliminate propagation paths that fail the logical integrity check or whose critical variables are corrupted.

[0034] The new application programming interface (API) specification for generating triples includes: Step S34: Based on the propagation path between the candidate interface and the target API, associate the corresponding key variables with the operation sequence; Step S35: Take the candidate interface as the new target object, and combine it with the verified operation sequence to construct a logical relationship description that conforms to the triple structure of target API, key variables and subsequent operations.

[0035] Step S4: Use the new application interface specification as iterative input to repeatedly execute the specification generation process until the preset stopping condition is met to build the target specification library; Specifically, the generated new specification is used as a new seed specification, and the analysis process is repeated iteratively to expand the coverage of the API specification.

[0036] The process of generating repeated execution specifications includes: Step S41: Inject the generated new application programming interface into the seed specification pool using the specification. Step S42: Starting with the newly injected specification, the analysis, identification, verification, and generation steps are triggered cyclically. Step S43: Monitor the update status of the specification pool. Stop the iteration when the traversal depth reaches the preset threshold, the set number of iterations is reached, or no new specifications are generated.

[0037] Step S5: Perform a static scan on the target program using the target specification library to identify non-compliant calling behaviors and output misuse detection results; Specifically, it detects API call behaviors that do not follow specifications, identifies misuse behaviors such as reference counting leaks, memory leaks, and null pointer dereferences, and generates detailed error reports.

[0038] Identifying non-compliant calling behaviors includes: Step S51: Match the actual interface call sequence in the target program with the triple logic in the target specification library; Step S52: Detect whether there are any missing operations, incorrect call order, or improper references in the call sequence; Step S53: Determine that the calling behavior with the above situation is an interface misuse behavior.

[0039] The output of misuse detection results includes: Step S54: Extract the specific location and context code information of the interface misuse behavior in the source code; Step S55: Backtrack and record the flow path of the key variables that led to the misuse; Step S56: Match and generate targeted remedial measures suggestions based on the subsequent operation definitions in the target specification library.

[0040] Another embodiment of the present invention provides a system for detecting misuse of application programming interfaces, comprising the following modules: The propagation analysis module is used to extract the key variable flow path of the target application interface call chain in the target program through static analysis based on the initial application interface usage specification, and to analyze the caller and callee according to the key variable flow path, and identify candidate interfaces and their predecessor or successor operations that meet the specification propagation conditions. The specification generation module is used to perform data flow verification on the candidate interfaces and their associated operations, generate new application interface usage specifications in the form of triples, and repeatedly execute the specification generation process with the new application interface usage specifications as iterative input until a preset stopping condition is met to build the target specification library. The error detection module is used to perform static scanning of the target program using the target specification library, identify non-compliant calling behaviors, and output misuse detection results.

[0041] In one embodiment of the present invention, the propagation analysis module includes: The caller analysis submodule is used to identify the successor interfaces of the target application interface and determine whether the canonical propagation conditions are met. These canonical propagation conditions include whether key variables are successfully passed as parameters or return values, and whether the key variables retain their original semantics and state during the propagation process.

[0042] Callee Analysis Submodule: Used to identify the predecessor interface of the target application interface and to trace the initialization path, configuration path and pre-operation of key variables through control flow analysis technology.

[0043] The propagation condition verification submodule is used to ensure that the propagation path meets the specification requirements, and to verify the call relationship, variable consistency and sequential logic in order to determine the candidate interface.

[0044] In one embodiment of the present invention, the specification generation module includes: Specification generation submodule: Used to automatically generate application interface usage specifications in the form of triples based on the call chain relationship. The triple form is represented as <target application interface, key variable, subsequent operation>.

[0045] Data Flow Validation Submodule: Used to perform static data flow analysis on the generated specification to ensure its semantic rationality and logical integrity in actual programs.

[0046] Iteration Control Submodule: Used to control the iterative execution of the specification generation process. It gradually expands the specification coverage by using newly generated specifications as seed specifications until the iteration limit is reached or no new specifications are generated.

[0047] In one embodiment of the present invention, the error detection module includes: Misuse Identification Submodule: Used to scan application interface calls in the target program and identify non-compliant call behaviors, including but not limited to missing operations, incorrect ordering, improper references, reference count leaks, memory leaks, or null pointer dereferences.

[0048] Error Report Generation Submodule: This module outputs detailed misuse detection results, specifically a misuse report. The misuse report identifies the exact location of the illegal call, the path of key variable transfers, context information, and provides remediation suggestions.

[0049] This system can be deployed independently or embedded in existing static analysis toolchains. By starting with a small number of seed application programming interfaces (APIs) and automatically discovering and expanding API usage specifications, it not only improves the efficiency and accuracy of error detection but also reduces reliance on external documentation and human experience, demonstrating strong practical value and promising prospects for widespread adoption.

[0050] Two specific examples are provided below.

[0051] Example 1: Example of API specification propagation model.

[0052] Figure 2 This demonstrates a typical application programming interface (API) specification propagation path, the core of which lies in the initial use of the API specification.<get_device, dev, put_device> Starting from this point, we analyze the calling context and key variable flow in the bus_find_device function. The specific process is as follows.

[0053] Step S1: Based on the initial application interface usage specification, extract the key variable flow path of the target application interface call chain in the target program through static analysis; Specifically, the system obtains the initial specifications.<get_device, dev, put_device> Static analysis was performed on the target program's `bus_find_device` function. It was identified that `get_device(dev)` was called within the function's loop to increment the reference count of the device object `dev`, thus determining the starting point of the critical variable `dev` in the call chain.

[0054] Step S2: Analyze the caller and callee based on the key variable flow path, and identify candidate interfaces and their predecessor or successor operations that meet the standard propagation conditions. Specifically, analysis of the callee confirmed that the behavior of bus_find_device depends on the execution effect of the predecessor interface get_device; analysis of the caller revealed that bus_find_device returns the key variable dev as a return value, causing the variable to propagate upwards along the call chain, which satisfies the standard propagation condition for key variables to be passed as return values.

[0055] Step S3: Perform data flow verification on the candidate interfaces and their associated operations to generate a new application programming interface (API) usage specification in the form of a triple; Specifically, the system verifies that the variable `dev` has not been reassigned, released, or modified by other interfaces after its self-initialization within `bus_find_device`, maintaining a stable reference state and satisfying the semantic consistency preservation condition. Based on this propagation path, the system automatically generates a new application programming interface usage specification in the form of a triple.<bus_find_device, retval, put_device> That is, after calling bus_find_device, the device object pointed to by the return value retval needs to perform the subsequent operation put_device.

[0056] Step S4: Use the new application interface specification as iterative input to repeatedly execute the specification generation process, and so on to build the target specification library; Specifically, the newly generated specifications<bus_find_device, retval, put_device> As a new seed specification, it is injected into the specification pool to continue triggering subsequent analysis and identification processes. Through continuous iteration and expansion, a complete specification library covering the target program is eventually formed.

[0057] Step S5: Perform a static scan on the target program using the target specification library to identify non-compliant calling behaviors and output misuse detection results; Specifically, based on the specification library generated in Example 1, the system performs a static scan of other modules of the target program. If, in a function call sequence, a call to `bus_find_device` is found to retrieve the device object `retval`, but the corresponding `put_device(retval)` operation is not detected in any subsequent control flow branches, then it is determined that there is a non-compliant interface misuse behavior at that point. The process of outputting the misuse detection result includes: the system automatically locating the source code line number of the illegal call, marking the complete flow path of the key variable `retval` from the return of `bus_find_device` to the end of the function, and identifying the misuse type as "reference counting leak". Finally, the system generates an error report and provides a repair suggestion, prompting developers to complete the `put_device` call before the function returns to ensure the reference balance of the device object.

[0058] Example 2: System workflow example.

[0059] Figure 3 The system of the present invention is demonstrated in actual program operation, covering three stages: data collection, specification generation and misuse detection. The specific process is as follows.

[0060] Step S1: Based on the initial application interface usage specification, extract the key variable flow path of the target application interface call chain in the target program through static analysis; Specifically, the system sets the initial specifications as follows:<get_device, dev, put_device> This indicates that after calling `get_device` to increment the device object reference count, `put_device` must be called to release it. The system identifies a call to `get_device(dev)` in the `class_find_device` function through static analysis and extracts the flow path of the key variable `dev` being passed upwards via the return value.

[0061] Step S2: Analyze the caller and callee based on the key variable flow path, and identify candidate interfaces and their predecessor or successor operations that meet the standard propagation conditions. Specifically, through caller analysis, it was identified that `class_find_device` inherits the semantics of `get_device`, satisfying the propagation condition for passing variables as return values. Simultaneously, callee analysis traced back to the kernel reference counting management function `kobject_get`. Control flow graph verification confirmed that `get_device` indeed performed the initialization operation of incrementing the reference count, supporting the rationality of the specification.

[0062] Step S3: Perform data flow verification on the candidate interfaces and their associated operations to generate a new application programming interface (API) usage specification in the form of a triple; Specifically, the system analyzes the flow of the key variable `dev` within the function body, verifying that it is not corrupted by intermediate operations, thereby ensuring the semantic consistency of the specification. Based on this, multiple new specifications in the form of triples are generated, for example...<class_find_device, retval, put_device> as well as<nfc_get_device, dev, nfc_put_device> wait.

[0063] Step S4: Use the new application interface specification as iterative input to repeatedly execute the specification generation process, and so on to build the target specification library; Specifically, existing specifications (such as those related to nfc_get_device) are used as new seed specifications, and the downstream function nfc_genl_vendor_cmd is analyzed along the call chain. This process is continuously iterated, expanding the scope of the specifications until a set number of iterations is reached or no new specifications are generated, ultimately building a complete target specification library.

[0064] Step S5: Perform a static scan on the target program using the target specification library to identify non-compliant calling behaviors and output misuse detection results; Specifically, in the `nfc_genl_vendor_cmd` function, the system detected a call to `nfc_get_device` to acquire a device object, but failed to call `nfc_put_device` to release resources before the function ended. Based on the constraints in the specification library, the system identified this as a violation of the reference management specification and output a detailed detection report.

[0065] The output of misuse detection results includes: Location of violation: The violation was found in the `nfc_genl_vendor_cmd` function in the `net / nfc / netlink.c` file. Violation description: The call to nfc_get_device is followed by the missing nfc_put_device release operation; Recommended fix: It is recommended to add an nfc_put_device(dev) call to the end of the nfc_genl_vendor_cmd logic to avoid resource leaks.

[0066] The following experiments verify the effectiveness of the method of the present invention in API usage specification generation and defect detection.

[0067] I. Performance testing of the method of this invention.

[0068] 1. API Usage Specification Generation Results: Using 6 seed specifications as input, this invention generated a total of 7332 new API usage specifications. Of the 763 extracted results, manual verification showed that all were correct, demonstrating the accuracy and reliability of this method in specification generation.

[0069] 2. Defect Detection Results: Based on the generated API usage specifications, the target program was scanned, and a total of 186 new defects were identified. Among them, 8 defects were officially included and assigned CVE numbers, indicating that this method has strong practical application value.

[0070] 3. The correspondence between API usage specifications and detection results is shown in Table 1: Table 1 API Usage Specifications and Testing Results As shown in Table 1, the method of the present invention can not only efficiently extend the API usage specifications, but also has significant effects in defect detection.

[0071] II. Comparative Experiment.

[0072] To further verify the advantages of the method of this invention, it was compared with four existing representative detection methods: Advance, IPPO, SinkFinder, and APHP. In the experiment, the defects detected by the method of this invention (APISpecGen) and their corresponding usage specifications were used as the ground truth for comparison. The performance of the above methods in terms of specification coverage and defect coverage was statistically analyzed, and the results are shown in Table 2. Specifically, the SinkFinder method discovers suspicious API function pairs by applying frequent pattern mining based on seed pairs, and then filters them, retaining only function pairs semantically similar to the seed pairs. Since the comparison experiment focuses on specifications and defects related to function pairs, 11 specifications that do not involve function pairs and their corresponding 11 defects were excluded.

[0073] Table 2 Comparison of specification coverage and defect coverage for each method As can be seen from the results in Table 2, the method of the present invention is significantly better than the existing methods in terms of both specification coverage and defect coverage, verifying its effectiveness and advancement in actual detection scenarios.

[0074] Although the present invention has been disclosed above with reference to embodiments, it is not intended to limit the present invention. Appropriate modifications or equivalent substitutions made by those skilled in the art to the technical solutions of the present invention should be covered within the protection scope of the present invention, which is defined by the claims.

Claims

1. A method for detecting misuse of application programming interfaces (APIs), characterized in that, Includes the following steps: Based on the initial application interface usage specification, the key variable flow path of the target application interface call chain in the target program is extracted through static analysis. Based on the flow path of the key variables, the caller and callee are analyzed to identify candidate interfaces that meet the conditions for standardized propagation and their predecessor or successor operations. Data flow verification is performed on the candidate interfaces and their associated operations to generate a new application programming interface (API) usage specification in the form of triples; The specification generation process is repeatedly executed using the new application programming interface specification as iterative input until a preset stopping condition is met to build the target specification library. The target program is statically scanned using the target specification library to identify non-compliant calling behaviors and output misuse detection results.

2. The method as described in claim 1, characterized in that, Static analysis is used to extract key variable flow paths from the target application's interface call chain in the target program, including: Obtain the initial application interface usage specification, which includes the target application interface, key variables, and subsequent operations; Static analysis is performed on the target program to identify upstream and downstream interface sequences that have a calling relationship with the target application interface; Track the parameter transmission path, return value usage path, and variable state evolution of the key variables in the upstream and downstream interface sequence.

3. The method as described in claim 1, characterized in that, Identify candidate interfaces that meet the canonical propagation conditions, including: Locate the subsequent interface that directly calls the target application interface and has a clear call path relationship; Verify whether the key variable is propagated from the target application interface to the subsequent interface as a parameter or return value; Detect the semantic state of the key variable in the propagation path and determine whether the key variable has been modified or damaged by other interface calls; Subsequent interfaces that satisfy the conditions of path relationship, variable propagation, and semantic preservation are identified as candidate interfaces.

4. The method as described in claim 1, characterized in that, Identify predecessor or successor operations that satisfy the canonical propagation conditions, including: The predecessor interface of the target application interface is identified using control flow graph analysis techniques. The source path of the key variables in the predecessor interface is traced using data stream tracing technology; Analyze the initialization, configuration, or pre-call operations of the key variables before the target application interface is invoked to determine the preceding operations.

5. The method as described in claim 1, characterized in that, Data flow verification is performed on the candidate interfaces and their associated operations, including: Static data flow analysis is performed on the call chain of the candidate interface to retrieve the assignment, release, and reference operations of the key variables; Compare the operation sequence with the preset logical integrity criteria to verify whether there are any omissions or abnormalities in the variable transfer process; Eliminate propagation paths that fail logical integrity checks or whose critical variables are corrupted.

6. The method as described in claim 1, characterized in that, The new application programming interface (API) specification for generating triples includes: Based on the propagation path between the candidate interface and the target application interface, the corresponding key variables and operation sequences are associated; Using the candidate interface as the new target object, and combining it with the verified operation sequence, construct a logical relationship description that conforms to the triple structure of target interface, key variables, and subsequent operations.

7. The method as described in claim 1, characterized in that, The specification generation process is repeatedly executed using the specification as iterative input for the new application programming interface, including: The generated new application programming interface is injected into the seed specification pool using the specification. Starting with the newly injected specification, the analysis, identification, verification, and generation steps are triggered cyclically. Monitor the update status of the specification pool, and stop iterating when the traversal depth reaches a preset threshold or no new specifications are generated.

8. The method as described in claim 1, characterized in that, Identify non-compliant calling behaviors, including: Match the actual interface call sequence in the target program with the triplet logic in the target specification library; Detect whether there are any missing operations, incorrect call order, or improper references in the call sequence; Calling behavior exhibiting the aforementioned situation is determined to be an interface misuse behavior.

9. The method as described in claim 1, characterized in that, Output the misuse detection results, including: Extract the specific location and contextual code information of the interface misuse behavior in the source code; Tracing back and recording the key variable flow paths that led to misuse; Based on the subsequent operation definitions in the target specification library, match and generate targeted remedial measures suggestions.

10. A system for detecting misuse of application programming interfaces (APIs), characterized in that, include: The propagation analysis module is used to extract the key variable flow path of the target application interface call chain in the target program through static analysis based on the initial application interface usage specification, and to analyze the caller and callee according to the key variable flow path, and identify candidate interfaces and their predecessor or successor operations that meet the specification propagation conditions. The specification generation module is used to perform data flow verification on the candidate interfaces and their associated operations, generate new application interface usage specifications in the form of triples, and repeatedly execute the specification generation process with the new application interface usage specifications as iterative input until a preset stopping condition is met to build the target specification library. The error detection module is used to perform static scanning of the target program using the target specification library, identify non-compliant calling behaviors, and output misuse detection results.

Images