Code detection method and device, storage medium and computer program product
By introducing a code detection method driven by a large language model (LLM), an adaptive malicious sample analysis framework is constructed, which solves the problem of inflexibility in existing tools, achieves high efficiency and flexibility in code detection, and improves the accuracy and efficiency of malicious code detection.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-12-04
- Publication Date
- 2026-04-07
AI Technical Summary
Existing code analysis tools cannot flexibly handle different code samples, resulting in inflexible analysis, high maintenance costs, and slow response.
We employ a code detection method based on Large Language Model (LLM), which constructs an intelligent and adaptive malicious sample analysis framework by dynamically generating and executing script files. This enables bidirectional asynchronous communication between the code detection model and the analysis tools, and supports deep static analysis of disassembly and online self-evolution of script files.
It improves the flexibility and efficiency of code analysis, reduces manual intervention, shortens the analysis cycle, and enhances the accuracy and flexibility of detection.
Smart Images
Figure CN121808771A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of security technology, specifically to the field of static analysis of malicious code, and particularly to a code detection method, apparatus, storage medium, and computer program product. Background Technology
[0002] In existing technologies, in order to detect whether code is malicious, it is usually necessary to input the code into a code detection tool so that the tool can analyze whether the input code is malicious.
[0003] However, existing code analysis tools can only execute analysis paths that are "hard-coded and have fixed interfaces," making code analysis inflexible. Summary of the Invention
[0004] Embodiments of the present invention provide a code detection method, apparatus, storage medium, and computer program product for flexibly detecting code.
[0005] To achieve the above objectives, the embodiments of the present invention adopt the following technical solutions:
[0006] Firstly, a code detection method is provided. This method includes: acquiring the code to be detected and its context information; inputting the code to be detected and the context information into a code detection model to obtain detection information corresponding to the code to be detected, including a target script file corresponding to the code to be detected; running the target script file using an analysis tool to obtain analysis results; the analysis results including the execution results of the target script file and the execution results of the API; using the code detection model to detect whether the analysis results meet the detection conditions; and if the analysis results do not meet the detection conditions, adjusting the target script file and running the adjusted target script file using the analysis tool until the analysis results output by the analysis tool meet the detection conditions.
[0007] Based on the first aspect of the technical solution, after obtaining the code to be tested and its context information, the code to be tested and its context information can be input into the code detection model to obtain the detection information of the code to be tested. Then, the script file included in the information to be tested can be loaded into the analysis tool for execution. After the analysis results are input into the analysis tool, the analysis results are input into the code detection model to check whether the analysis results meet the detection conditions. If the detection conditions are not met, the script file is adjusted, and the adjusted script file is loaded into the analysis tool so that the analysis tool re-analyzes the adjusted script file. This process is repeated until an analysis result that meets the detection conditions is obtained, and then the analysis result determines whether the code to be tested is malicious code. In this application, the code detection model and analysis tool perform dynamic and cyclical detection of the code to be tested, and the script file containing the code to be tested can be adjusted according to the analysis results, making it more flexible.
[0008] Secondly, a code detection device is provided, which may include a communication unit, a processing unit, and a detection unit. The communication unit is used to acquire the code to be detected and its context information. The processing unit is used to input the code to be detected and its context information into a code detection model to obtain detection information corresponding to the code to be detected, including a target script file corresponding to the code to be detected. The processing unit is also used to run the target script file through an analysis tool to obtain analysis results. The analysis results include the execution results of the target script file and the execution results of the API. The detection unit is used to detect whether the analysis results meet the detection conditions through the code detection model. If the analysis results do not meet the detection conditions, the processing unit is also used to adjust the target script file and run the adjusted target script file through the analysis tool until the analysis results output by the analysis tool meet the detection conditions.
[0009] Thirdly, a computer-readable storage medium is provided that stores computer instructions or programs that, when executed on a computer, cause the computer to perform the code detection method of the first aspect.
[0010] Fourthly, a code detection device includes: a processor and a memory; wherein the memory is used to store one or more programs, the one or more programs including computer execution instructions, and when the user device is running, the processor executes the computer execution instructions stored in the memory to cause the user device to perform the code detection method as described in the first aspect.
[0011] Fifthly, a computer program product containing instructions is provided, which, when executed on a computer, causes the computer to perform the code detection method of the first aspect.
[0012] The code detection device, computer-readable storage medium, or computer program product provided above are all used to execute the corresponding methods provided above. Therefore, the beneficial effects they can achieve can be referred to the beneficial effects of the corresponding solutions in the corresponding methods provided above, and will not be repeated here. Attached Figure Description
[0013] Figure 1 A schematic diagram of a code detection device provided in an embodiment of this application;
[0014] Figure 2 A schematic diagram of another code detection device provided in an embodiment of this application;
[0015] Figure 3 This is a schematic diagram of the structure of another code detection device 300 provided in an embodiment of this application;
[0016] Figure 4 A flowchart illustrating a code detection method provided in an embodiment of this application;
[0017] Figure 5 A flowchart illustrating a code detection method provided in an embodiment of this application;
[0018] Figure 6 A schematic diagram of the structure of another code detection device 60 provided in an embodiment of the present invention. Detailed Implementation
[0019] To facilitate a clear description of the technical solutions in the embodiments of this application, the terms "first" and "second" are used in the embodiments of this application to distinguish identical or similar items with essentially the same function and purpose. For example, "first terminal" and "second terminal" are merely used to distinguish different terminals and do not limit their order. Those skilled in the art will understand that the terms "first" and "second" do not limit the quantity or execution order, and that "first" and "second" do not necessarily imply that they are different.
[0020] It should be noted that, in this application, the terms "exemplary" or "for example" are used to indicate that something is being described as an example, illustration, or illustration. Any embodiment or design described as "exemplary" or "for example" in this application should not be construed as being more preferred or advantageous than other embodiments or design solutions. Specifically, the use of terms such as "exemplary" or "for example" is intended to present the relevant concepts in a concrete manner.
[0021] In this application, "at least one" means one or more, and "more than one" means two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can mean: A alone, A and B simultaneously, or B alone, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c can mean: a, b, c, ab, ac, bc, or abc, where a, b, and c can be single or multiple. The terms "first," "second," etc., do not limit the quantity or order of execution, and "first," "second," etc., do not necessarily imply that they are different.
[0022] Before introducing the embodiments of this application, some terms involved in the embodiments of this application will be explained:
[0023] Interactive disassembler (IDA): A type of disassembler software. IDA supports static analysis of multi-architecture binaries and can load Python or IDA command language (IDC) scripts for secondary development.
[0024] Large Language Model (LLM): A speech generation model based on the Transformer architecture and pre-trained on massive amounts of text. LLM can generate code, natural speech, etc., based on prompts. Of course, LLM can also generate scripts.
[0025] Prompt Engineering is a set of methods designed for high-quality input prompts in LLM task scenarios, used to constrain output format and improve the accuracy of generated prompts.
[0026] Import Table: A table structure in executable files such as portable executable (PE) and executable and linkable format (ELF) records the dependencies of external functions and dynamic link libraries (DLLs). It can be used to quickly infer the relationship between the functions of malicious samples and application programming interface (API) calls.
[0027] A control-flow graph (CFG) is a directed graph consisting of basic function blocks and jump edges, used to describe the execution flow of a program. CFGs are an important foundational structure for static analysis and vulnerability discovery.
[0028] JSON Remote Procedure Call (RPC): is a remote procedure call protocol based on JSON.
[0029] As mentioned in the background, existing code analysis tools can only execute analysis paths that are "pre-written and have fixed interfaces," and cannot generate and distribute logic in a timely manner based on code or samples, resulting in high script maintenance costs and slow response to new shells or location obfuscation.
[0030] One possible implementation involves static feature extraction (instruction sequence, import table, file header information, etc.) of the executable file, followed by machine learning modeling for malicious / benign classification. For example, the PE file could be split into several equal-length n-grams, and a support vector machine (SVM) could be used to classify the feature vectors. The result would then be a binary classification.
[0031] However, this method does not involve disassembly-level code recovery.
[0032] Another possible implementation is to analyze the code using the IDC plugin (GitHub mrexodia / ida-pro-mcp).
[0033] For example, a pipeline (Message Communication Protocol, MCP) can be established between IDA and an external script or program to enable external control of IDA to execute Python scripts and obtain the results.
[0034] This implementation allows ida_mcp_server.py to listen on a local port and wait for JSON-RPC instructions; it supports basic disassembly queries, name modification, and flag setting instructions; it focuses on "remote control" capabilities and does not handle the generation or evolution of the script itself.
[0035] However, this implementation method cannot inject / execute scripts online, has limited interfaces, and has high costs for expanding functionality.
[0036] In addition, traditional static code analysis processes suffer from high labor costs, difficult script maintenance, and slow response due to rigid analysis logic and inability to dynamically adapt to new or unknown threats.
[0037] Therefore, in this embodiment, LLM is introduced to determine the dynamic script generation and execution capabilities, constructing an intelligent and adaptive malicious sample analysis framework, thereby reducing manual intervention and improving analysis efficiency and accuracy. Simultaneously, through the LLM-driven "generation-execution-feedback-regeneration" closed loop, scripts can be self-evolved online without manual maintenance, thus shortening the code analysis cycle and making it more flexible.
[0038] Furthermore, the solution provided in this application can support deep static analysis via disassembly. Through mechanisms such as extended interfaces, LLM generation scripts, and bidirectional feedback, analysis solutions can be customized for different samples or code, and the code can be rewritten and adapted to different samples in real time based on the analysis results.
[0039] The technical solutions of the present invention will now be described with reference to the accompanying drawings in the embodiments of this application.
[0040] like Figure 1 The diagram shown is a structural schematic of a code detection device provided in an embodiment of this application. The code detection device may include a model terminal and an analysis tool. The model terminal and the analysis tool are communicatively connected.
[0041] The model can be configured with a code detection model. This model can be used to generate and optimize script files. For example, the code detection model can be the LLM mentioned above. The analysis tool can be used to run the script file and output the execution results. For example, the analysis tool can be the IDA static analysis tool mentioned above, or any other tool capable of running script files; there are no restrictions.
[0042] One possible implementation is, such as Figure 2 As shown, a Message Control Proxy (MCP) layer can be set up between the model and the analysis tool. The MCP layer is used to transmit scripts, execution results, and context data between the model and the analysis tool, enabling bidirectional asynchronous communication between the model and the analysis tool.
[0043] In this embodiment of the application, the model and the analysis tool can be independent devices or integrated into one device.
[0044] In practical implementation, Figure 1 The code detection device in the middle can adopt Figure 3 The shown composition structure, or including Figure 3 The components shown. Figure 3 This is a schematic diagram of the composition of a code detection device 300 provided in an embodiment of this application. The detection device 300 can be a chip or a system-on-a-chip in the code detection device.
[0045] like Figure 3 As shown, the code detection device 300 includes a processor 301, a communication interface 302, and a communication line 303.
[0046] Furthermore, the code detection device 300 may also include a memory 304. The processor 301, memory 304, and communication interface 302 can be connected via a communication line 303.
[0047] The processor 301 can be a central processing unit (CPU), a network processor (NP), a digital signal processor (DSP), a microprocessor, a microcontroller, a programmable logic device (PLD), or any combination thereof. The processor 301 can also be other devices with processing capabilities, such as circuits, devices, or software modules, without limitation.
[0048] Communication interface 302 is used to communicate with other devices or other communication networks. These other communication networks can be Ethernet, radio access network (RAN), wireless local area networks (WLAN), etc. Communication interface 302 can be a module, circuit, communication interface, or any device capable of enabling communication.
[0049] Communication line 303 is used to transmit information between the components included in the code detection device 300.
[0050] Memory 304 is used to store instructions. These instructions can be computer programs.
[0051] The memory 304 can be a read-only memory (ROM) or other type of static storage device that can store static information and / or instructions; it can also be a random access memory (RAM) or other type of dynamic storage device that can store information and / or instructions; it can also be an electrically erasable programmable read-only memory (EEPROM), a compact disc read-only memory (CD-ROM) or other optical disc storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital universal optical discs, Blu-ray discs, etc.), magnetic disk storage media or other magnetic storage devices, etc., without limitation.
[0052] It should be noted that the memory 304 can exist independently of the processor 301 or can be integrated with the processor 301. The memory 304 can be used to store instructions, program code, or some data, etc. The memory 304 can be located inside or outside the code detection device 300, without limitation. The processor 301 is used to execute the instructions stored in the memory 304 to implement the code detection method provided in the following embodiments of this application.
[0053] In one example, processor 301 may include one or more CPUs, for example Figure 3 CPU0 and CPU1 in the CPU.
[0054] As an optional implementation, the code detection device 300 includes multiple processors, for example, besides Figure 3 In addition to processor 301, it may also include processor 307.
[0055] As an optional implementation, the code detection device 300 also includes an output device 305 and an input device 306. For example, the input device 306 is a device such as a keyboard, mouse, microphone, or joystick, and the output device 305 is a device such as a display screen or speaker.
[0056] It should be noted that the code detection device 300 can be a desktop computer, laptop computer, network server, mobile phone, tablet computer, wireless terminal, embedded device, chip system, or other device. Figure 3 Equipment with a similar structure. Furthermore... Figure 3 The structural composition shown does not constitute a limitation on this terminal device, except... Figure 3 In addition to the components shown, the terminal device may include more or fewer components than illustrated, or combine certain components, or have different component arrangements.
[0057] In this embodiment of the application, the chip system may be composed of chips or may include chips and other discrete devices.
[0058] Furthermore, the actions, terms, etc., involved in the various embodiments of this application can be referenced interchangeably without limitation. The message names or parameter names in the messages between the various devices in the embodiments of this application are merely examples, and other names may be used in specific implementations without limitation.
[0059] The following is combined with Figure 2 The system shown describes the code detection method provided in the embodiments of this application. The actions, terminology, etc., involved in the various embodiments of this application can be referenced interchangeably without limitation. The message names or parameter names in the messages exchanged between devices in the embodiments of this application are merely examples; other names can be used in specific implementations without limitation. The actions involved in the various embodiments of this application are merely examples; other names can be used in specific implementations. For example, "carried on" in the embodiments of this application can be replaced with "included in" or "carried in," etc.
[0060] like Figure 4 As shown, this is a code detection method provided in an embodiment of the present application, which may include S401 to S405.
[0061] S401. Obtain the code to be detected and its context information.
[0062] The code to be detected can be code in target software or a target file. For example, it can be the code in an EXE file. The context information of the code to be detected refers to information related to the code that can affect its meaning, function, or execution logic. For example, the context information of the code to be detected may include one or more of the following: the scope of the code to be detected, the definitions and references of variables and functions in the code to be detected, dependencies, business logic background, execution environment information, etc.
[0063] In one possible implementation, the code detection device can acquire the code to be detected in response to an input operation. The input operation can be a worker providing instructions to the code detection device.
[0064] In another possible implementation, the code detection device can be an application or an application containing the code to be detected. The code detection device can parse the application to obtain the code to be detected.
[0065] In this embodiment of the application, when the code to be detected does not carry context information (such as code comments), the context information of the code to be detected can also be information configured by the staff based on experience. For example, information such as the impact of the code to be detected on the electronic device and the applications installed on the electronic device during its operation. For example, when the electronic device runs the code to be detected, the files stored on the electronic device or the applications installed on the electronic device will be encrypted, then the function of the code to be detected is encryption.
[0066] S402. Input the code to be detected and the context information into the code detection model to obtain the detection information corresponding to the code to be detected.
[0067] The code detection model can be the LLM mentioned above. Of course, other speech models can also be used; this application does not impose any restrictions. The code detection model has a script file generation function. For example, it can generate and output a script file of the code to be detected based on the input code and context information.
[0068] In this embodiment, the detection information may include the target script file of the code to be detected. Of course, the detection information may also include other information, such as instructions for analyzing and detecting the code. The target script file may include information such as the decision analysis path, script path, and the code to be detected. The target script file may be a Python script file, an IDA-Python script file, a Shell script file, or a JavaScript script file, etc.
[0069] The decision analysis path of the code to be detected, also known as the conditional branch path or logical judgment path in the code, refers to the set of different execution branches generated by conditional judgments (such as if-else, switch-case, loop conditions, etc.) during the execution of the code.
[0070] S403. Run the target script file using the analysis tool to obtain the analysis results.
[0071] The analysis tool can be the aforementioned IDA static analysis tool. Of course, other analysis tools capable of analyzing script files can also be used; this application does not impose any restrictions. The analysis results may include the execution results of the target script file and the execution results of the API.
[0072] In one possible implementation, after generating the target script file for the code to be detected on the model side, the target script file can be sent to the analysis tool. Correspondingly, upon receiving the target script file, the analysis tool can load and run it.
[0073] In one example, if an MCP layer is set up between the model and the analysis tool, the model can send the generated detection information to the analysis tool through the MCP layer. After receiving the detection information from the model, the MCP layer can route to the executor corresponding to the target script file based on the detection information and send first instruction information to the analysis tool. The first instruction information may include the target script file and the executor corresponding to the target script file.
[0074] In this embodiment, the analysis tool can be configured with one or more executors. The analysis tool can use static disassembly to identify key functions (such as entry points, encryption functions, network communication functions, etc.) and conditional branch paths in the code to be analyzed, thus providing analysis targets for dynamic execution. The executor is responsible for executing the code, making it run in a specific environment. Through the executor, the runtime state of the code can be observed (such as register values, memory changes, dynamically loaded data, input / output interactions, etc.), thereby obtaining dynamic information that static analysis tools cannot obtain.
[0075] In one possible implementation, after receiving the target script file, the MCP layer can determine the corresponding executor based on the function or information carried in the target script file, and send the target script file and information indicating the executor to the analysis tool. Upon receiving the target script file, the analysis tool can first perform static analysis on the code in the target script file, and then run the code to be tested through the executor. In this way, the executor can assist the analysis tool in correcting deviations in the static analysis, ensuring the accuracy of the analysis results.
[0076] For analysis tools, upon receiving a script path, the tool can query and load the target script file. After loading the target script file, it can run the script file and output the analysis results.
[0077] In one example, the analysis tool can obtain the imported modules of a target script file and iterate through them to obtain their function information. The analysis tool can then use the identifier (such as the name) of the imported module as the key and the function information as the value to obtain the execution result of the target script file's API.
[0078] The imported modules in the target script file can refer to external libraries that the code depends on at runtime (such as kernel32.dll, user32.dll, libc.so under Linux, etc.). The function information of the imported modules can include the APIs called by the imported modules.
[0079] Furthermore, to ensure the normal operation of the target script file, the analysis tool can execute the target script file in an independent, controlled process and set the execution duration. Specifically, please refer to the description of the following embodiments.
[0080] S404. Use the code detection model to check whether the analysis results meet the detection conditions.
[0081] The detection criteria can refer to whether the analysis results include a valid script file. A valid script file is one that can identify the code to be detected. For example, a valid script file can include specific functional information, input / output, author information, and source information of the code to be detected. In other words, a valid script file can accurately determine whether the code to be detected is malicious code.
[0082] In one example, if a valid script file indicates that the code to be detected has explicit information (such as explicit input / output, author information, source information), then the analysis result has a valid script file; if a valid script file indicates that the code to be detected does not have explicit information (such as no input / output, author information, source information, etc. are indicated), then the analysis result does not have a valid script file.
[0083] Furthermore, if the analysis results do not meet the detection conditions, the code detection device can execute S405.
[0084] S405. Adjust the target script file and run the adjusted target script through the analysis tool until the analysis results output by the analysis tool meet the detection conditions.
[0085] Adjusting the target script file can include modifying and thoroughly analyzing it to obtain a revised version. Modifying the target script file refers to fixing and optimizing errors, defects, or unexpected aspects to ensure proper functionality, reasonable performance, or compliance with specifications.
[0086] In this embodiment of the application, modifying the script file may include at least one of the following:
[0087] 1-1. Correction of grammatical errors.
[0088] Syntax error correction can be used to resolve errors caused by syntax violations during script file runtime. Examples include indentation errors and mismatched parentheses in Python scripts, and spelling errors and variable reference errors in Shell scripts.
[0089] 1-2. Logical error repair.
[0090] Logical error repair can refer to correcting logical issues such as the execution flow, conditional statements, and loop control of a script file. For example, if the if-else branch condition in a Python script file is reversed, resulting in an incorrect result, or if the loop termination condition is improperly set, leading to an infinite loop, the logic needs to be re-examined and the code adjusted.
[0091] 1-3. Function completion and optimization.
[0092] Among them, feature completion and optimization refers to supplementing the missing functional details in the script file (such as missing boundary condition handling, such as exception handling when the input is empty), or optimizing performance (such as replacing inefficient loops with built-in functions, reducing redundant calculations), and improving readability (such as adding comments, standardizing variable naming).
[0093] 1-4. Compatibility and security fixes.
[0094] Among them, compatibility and security fixes can be used to resolve compatibility issues of scripts in different environments (such as different versions of interpreters and operating systems) (such as the syntax differences between Python 2 and Python 3); and to fix security vulnerabilities (such as the risk of command injection in shell scripts and the problem of malicious data processing caused by the lack of input validation in Python scripts).
[0095] In this embodiment of the application, in-depth analysis of script files can refer to the use of technical means to conduct in-depth analysis of the script's function, logic, hidden information, or potential impact. The aim is to fully understand the script's role, behavior, or underlying intent. In-depth analysis of script files may include at least one of the following:
[0096] 2-1. Functional and logical reverse analysis.
[0097] When a script lacks documentation or its source code is obscure (such as obfuscated JavaScript or encrypted Python scripts), its actual functionality can be restored by parsing it line by line, tracing the flow of variables, and sorting out the function call relationships (for example, a shell script file may seem simple, but after in-depth investigation, it is found that it secretly performs system information collection operations).
[0098] 2-2. Hidden Behaviors and Dependency Discovery.
[0099] This includes analyzing script files for undeclared hidden behaviors (such as secretly calling external commands, reading or writing sensitive files, or network communication) or dependencies on external resources (such as undeclared libraries, environment variables, or configuration files). For example, it might investigate whether a Python script file executes hidden system commands through the subprocess module or depends on a specific version of a third-party library.
[0100] 2-3. Extraction of sensitive information.
[0101] Sensitive information extraction can refer to: mining potentially sensitive data from script files. This could include hard-coded account passwords, API keys, path information, or obtaining hidden business rules through logical deduction (such as the algorithm details for calculating discounts in an e-commerce script).
[0102] 2-4. Vulnerability and Risk Discovery.
[0103] Vulnerability and risk discovery can refer to: performing security audits on script files to uncover potential vulnerabilities (such as injection vulnerabilities due to lax input validation, or access control flaws) or runtime risks (such as resource leaks or crashes caused by infinite recursion). For example, analyzing a Lua script that processes user input to uncover whether it contains command injection risks caused by string concatenation.
[0104] 2-5. Code source tracing and version evolution analysis.
[0105] Code tracing and version evolution analysis can refer to tracing the developers and referenced open-source projects of a script file by examining its style, the libraries used, or specific code snippets, or analyzing the evolution of the code by combining version control history (such as Git) to understand the logic of feature iteration.
[0106] It should be noted that, in this embodiment, modifying the target script file can make it more reliable and compliant. In-depth analysis of the target script file allows for a comprehensive understanding of its functionality, behavior, and potential risks. These two approaches can be combined; for example, first, the logic of the target script file can be understood through in-depth analysis, and then errors or vulnerabilities can be specifically corrected, making the adjusted target script file more reasonable and reliable.
[0107] In this embodiment, if the code detection model cannot identify a valid script file from the analysis results, it can adjust the target script file in response to an adjustment operation, and then input the adjusted target script file into the analysis tool so that the analysis tool can run the adjusted target script file again. This process is repeated until the analysis results input by the analysis tool contain a valid script file.
[0108] based on Figure 4The proposed technical solution, after obtaining the code to be tested and its context information, inputs the code to be tested and its context information into a code detection model to obtain detection information for the code to be tested. Then, the script file included in the test information can be loaded into an analysis tool for execution. After the analysis results are input into the analysis tool, they are input into the code detection model to check whether the analysis results meet the detection conditions. If the detection conditions are not met, the script file is adjusted, and the adjusted script file is loaded into the analysis tool so that the analysis tool re-analyzes the adjusted script file. This process is repeated until an analysis result that meets the detection conditions is obtained, and then the analysis result determines whether the code to be tested is malicious code. In this application, the code detection model and analysis tool perform dynamic and iterative detection of the code to be tested, and the script file containing the code to be tested can be adjusted according to the analysis results, making it more flexible.
[0109] In some embodiments of this application, to avoid the analysis tool encountering abnormalities while running the target script file, a corresponding execution duration (such as timeout) can be set for the target script file. Specifically, in S403 above, running the target script file with the analysis tool to obtain the analysis results may include: if the execution duration of the target script file does not exceed the corresponding execution duration, using the result output by the analysis tool as the analysis result corresponding to the target script file.
[0110] Furthermore, if the execution time of the target script file exceeds the corresponding execution time limit, the analysis tool can stop running the target script text. And / or, if the analysis tool encounters an error while running the target script file, the code detection device can also input initial information.
[0111] The first information can be used for at least one of the following:
[0112] 3-1. Types of exceptions encountered in the target script file.
[0113] The types of exceptions that occur in the target script file can include syntax exceptions (such as punctuation errors, keyword misuse, syntax format errors, etc.), runtime exceptions (such as type errors, value errors, name errors, index / key errors, attribute errors, etc.), logic exceptions, input / interaction exceptions, etc.
[0114] 3-2. The location where the exception occurs in the target script file.
[0115] 3-3. The analysis tool encountered a stack error while running the target script file.
[0116] The call stack is a data structure that records the current execution path of a program, used to trace the call relationships between functions (or methods). When a function in a script file is called, the system pushes the function's execution context (such as parameters, local variables, return address, etc.) onto the stack; when the function finishes execution (returns), its context is popped from the stack. Through the call stack, developers can clearly understand the execution process of the target script. For example, they can see which function the target script file is currently executing, which parent function called that function, and where the initial entry point is.
[0117] Based on the technical solution of this embodiment, if the analysis tool runs the target script file for longer than the execution time or encounters an error, the execution of the target script file can be paused to avoid affecting the execution of other files. Furthermore, a prompt message indicating the cause of the error can be output, allowing staff to determine the reason for the target script's error based on this prompt message.
[0118] In some embodiments, the method provided in this application may further include: adjusting the target script file based on first information when the analysis result does not meet the detection conditions, to obtain an adjusted target script file.
[0119] Adjusting the target script file based on the first piece of information can refer to correcting any abnormal syntax, logic, or call stack entries in the target script file based on that first piece of information. This reduces the likelihood of errors occurring when analysis tools run the target script file.
[0120] Furthermore, in S405 above, rerunning the adjusted target script file through the analysis tool may include: inputting the adjusted target script file into the code detection model to obtain new detection information of the code to be detected, inputting the new detection information into the analysis tool through the MCP layer, and then running the adjusted target script file through the analysis tool.
[0121] In this way, through the process of "analysis-execution-adjustment-reanalysis-reexecution", the code to be detected can be accurately detected to determine whether the code to be detected is malicious code or abnormal code.
[0122] In some embodiments, the method provided in this application may further include: obtaining the execution status of the target script file in an analysis tool.
[0123] The execution status of the target script file in the analysis tool can include: execution successful, execution failed, execution timed out, etc.
[0124] In S403 above, the code detection model can be used to detect whether the analysis results meet the detection conditions. This can include: encapsulating the obtained execution status and analysis results through the MCP layer to obtain a target JSON file, and inputting the target JSON file into the code detection model to detect whether the target JSON file has a valid script file.
[0125] In this embodiment, the execution status and analysis results of the target script file are encapsulated into a JSON file. JSON files offer simplicity, cross-language compatibility, and flexibility. Therefore, using JSON files makes the transmission between the analysis tool and the model more efficient and convenient.
[0126] In some embodiments, the method provided in this application further includes: configuring script metadata for the target script file when the target JSON file has a valid script file, obtaining the configured script file, and storing the configured script file in the script repository of the MCP layer.
[0127] The script metadata can be used to indicate at least one of the following: the function of the target script, the parameters required during the execution of the target script file, the output analysis results, and the source information.
[0128] Based on the technical solution of this embodiment, if the target JSON file contains a valid script file, it indicates that the analysis tool can correctly identify the code to be detected. That is, the target script file can correctly provide information about the code to be detected (such as called functions, logical relationships between functions, etc.). Therefore, script metadata can be configured for the target script file to facilitate subsequent retrieval and automated scheduling.
[0129] The following example illustrates the technical solution provided in this application embodiment, with the model, analysis tools, and MCP layer located on different servers.
[0130] like Figure 5 As shown, the method provided in the embodiments of this application may include S501 to S509.
[0131] S501: The model obtains the code to be detected and its context information, and generates a script file based on the code to be detected and its context information.
[0132] In one example, after obtaining the code to be detected, the model can understand and analyze the code, and then formulate an initial plan.
[0133] Among them, understanding and analyzing the task refers to the model determining the core objectives, requirements, constraints, and potential background of the detection task by analyzing the input code and contextual information.
[0134] For example, the model can clearly define the results to be achieved by the detection task (such as analyzing whether the code to be detected is malicious or abnormal code), and break down the key elements of the detection task (such as code function, source, author, etc.), while identifying implicit requirements (such as obtaining necessary information that is not explicitly stated in the detection task, such as the included sub-tasks, etc.).
[0135] In this way, the model can use capabilities such as Natural Language Understanding (NLU) and contextual semantic parsing to transform ambiguous task instructions into clear target definitions, laying the foundation for subsequent processing.
[0136] Furthermore, the model can also break down detection tasks. For example, a complex detection task can be decomposed into several executable and manageable sub-tasks, thereby reducing the complexity of the detection task.
[0137] In this embodiment, after the model obtains the code, it can perform in-depth analysis of the existing code, combining the code's function, structure, and potential goals to clarify the core problem to be solved, then break down the overall task into executable steps, and plan specific action plans. In one possible implementation, the model can use the code to be detected to deduce the goal and constraints, break down the goal into multiple sub-tasks, and plan the execution logic and resources of the sub-tasks.
[0138] In one example, after obtaining the code to be detected, the model can determine the function, applicable scenarios, potential problems, and core objectives of the current detection task (such as optimizing code, fixing vulnerabilities, identifying malicious code, etc.).
[0139] In one possible implementation, the model can determine what the code is doing (e.g., whether a piece of Python code is used to process CSV data cleaning or to implement a certain algorithm calculation) by statically analyzing the logic of the code (such as function calls, conditional branches, and data processing flow), and identify the task objectives and analyze constraints and limitations.
[0140] For example, the model can combine the contextual information of the code to be detected (such as user requirements, code comments, and business scenarios) to clarify the purpose of the current task (e.g., if the user provides a sorting code with performance issues, the task goal might be "optimize code execution efficiency"; if the user provides a crawler code with errors, the task goal might be "fix the bug that caused the crawling failure"). Then, the model can identify the code's runtime environment (such as Python 3.8, dependency library versions), potential defects (such as unhandled exceptions, redundant logic), and business rules (such as data format requirements, permission restrictions), thus defining the boundaries for subsequent processing.
[0141] Furthermore, after clarifying the task objectives, the model can break down complex overall tasks (such as code optimization, bug fixing, and malware identification) into several actionable and logically related subtasks, reducing the processing difficulty. The model can also formulate specific execution plans for the decomposed subtasks, including: the order of steps, required tools, and expected results.
[0142] Among them, subtasks must be able to be executed independently and can be combined to achieve the overall goal.
[0143] S502, the model determines the script path of the script file and sends the detection information to the MCP layer. Correspondingly, the MCP layer receives the detection information from the model.
[0144] The detection information may include the script file and the script path.
[0145] The S503 and MCP layers determine the executor corresponding to the script file based on the script path.
[0146] S504, the MCP layer sends the first instruction information to the analysis tool. Correspondingly, the analysis tool receives the first instruction information from the MCP layer.
[0147] The first instruction information can specify the analysis script file. For example, the first instruction information may include the script file and its path. In this way, the analysis tool can load the script file based on the script path.
[0148] In one possible implementation, the code detection device can be configured with a dynamic script executor. This dynamic script executor, as a core extension of the MCP layer, is responsible for receiving and safely executing script files generated by the model.
[0149] In one example, the dynamic script executor has at least one of the following functions:
[0150] 4-1. Script path and timeout for receiving script files.
[0151] 4-2. Execute the script file in a separate namespace that is isolated from the IDA main process.
[0152] 4-3. Monitor the execution time of the script file, and stop running the script file if the execution time exceeds the timeout. This can prevent the process from appearing to freeze.
[0153] 4-4. Obtain the output data of the script file.
[0154] The output data includes standard output (stdout), standard error (stderr), and predefined payload.
[0155] 4-5. Encapsulate the execution status (success, failure, timeout) and output data of the script file into a JSON file, and output the JSON file.
[0156] S505: The analysis tool runs the script file and outputs the analysis results. Correspondingly, the MCP layer receives the analysis results.
[0157] In one example, the analysis tool can be configured with a script execution interface and a fixed API plugin.
[0158] The script execution interface can call script execution functions to run script files.
[0159] For example, the script execution function can be `run_script(script_path:str,timeout:int)`. This function can safely execute a local IDA-Python script file. For instance, it can execute load or dynamic scripts generated from large models.
[0160] The inputs to this script execution function are: `script_path:str` (representing the absolute path of the script to be executed) and `timeout:int` (representing the script execution timeout in seconds, defaulting to 60). The processing steps of this script execution function are as follows:
[0161] Step a: Determine if the script file corresponding to the script path exists.
[0162] Step b: Execute the script file in a separate, controlled process and impose a timeout limit.
[0163] Step c: Obtain the standard output, standard error, and analysis results returned after the script file is executed.
[0164] The output of the function executed by this script is:
[0165]
[0166] In another possible implementation, the analysis tool is also configured with an import module retrieval function. For example, this import retrieval function could be `get_list_import()`. This function can retrieve a list of modules (or dependencies) imported in the script file. That is, it extracts all external modules, libraries, or local modules imported using the `import` statement in the script file.
[0167] In one application scenario, within static code analysis, dependency management, or automation tools, this function can be used to identify which external resources a piece of code depends on. For example, this function can be used to analyze which third-party libraries (requests, pandas) a Python script depends on, enabling automatic dependency installation and checking for unauthorized or insecure modules imported into the script file, thereby generating a dependency list for the project (such as requirements.txt).
[0168] In one example, the processing steps of get_list_import() may include:
[0169] Step a1: Initialize an empty import_table dictionary.
[0170] Step b1: Call idaapi.get_import_module_qty() to get the number of imported modules in the script file.
[0171] Step c1: Iterate through each import module and the import functions within each import module.
[0172] Step d1: Fill the import_table dictionary with the module name of the imported model as the key and the list of function information (such as name and address) as the value.
[0173] In another example, the output of get_list_import() could be:
[0174]
[0175] The S506 and MCP layers encapsulate the analysis results into a JSON file and return the JSON file to the model.
[0176] In this embodiment, the MCP layer can return the analysis results to the model in a structured format (standard output, standard error, execution status, and custom loads), thereby providing accurate data support for subsequent decisions of the large language model (such as script correction and deep mining).
[0177] S507. Does the detection and analysis result of the model meet the detection conditions?
[0178] If the analysis results meet the detection conditions, execute S508; if the analysis results do not meet the detection conditions, execute S509.
[0179] S508, the model side stores script files to the MCP script repository through the MCP layer.
[0180] The script repository can persistently store, manage, and reuse the stored script files for analysis.
[0181] In one example, the script repository can have a local file target structure. This target structure can be:
[0182]
[0183] In this embodiment of the application, the top of the script files stored in the script repository may include a metadata block for describing information such as script function, input, output, and author.
[0184] For example, a metadata block can be:
[0185]
[0186] In this embodiment, efficient script files can be stored in a script repository by persisting the script files and configuring metadata for them. This allows for direct retrieval from the script repository when similar code or detection tasks are encountered again, thus enabling high-speed reuse of analytical capabilities.
[0187] S509: The model adjusts the script file and generates new detection information based on the adjusted script file.
[0188] based on Figure 5 The technical solution allows the model to generate script files in real time based on the characteristics of the detection task and the code to be detected, and then deliver them to the IDA environment for execution. This enables the analysis logic to dynamically change with the code and the task. By leveraging the dynamic script generation and execution capabilities driven by a large language model, an intelligent and adaptive malicious sample analysis framework is built, significantly reducing manual intervention and improving analysis efficiency and accuracy.
[0189] In some embodiments, the MCP layer can directly output structured import table data, which facilitates the creation of API behavior profiles.
[0190] Thus, by performing heuristic analysis on the import table, program attributes can be efficiently determined at the static stage without parsing the complete executable file, reducing computational resources and time overhead. Simultaneously, based on the call characteristics represented by the import table, potential malicious code can be accurately identified in the early stages, thereby improving the timeliness and accuracy of malware detection.
[0191] In some embodiments, the analysis tool may be configured with the Dynamic-IDAPython API.
[0192] The Dynamic-IDAPythonAPI supports IDA Python code, thus breaking the limitations of fixed interface calls in the MCP layer and enabling real-time deployment and execution at the script level.
[0193] In one example, the Dynamic-IDAPython API can be used as an IDA-Python interface for dynamic debugging scenarios. That is, it allows interaction with the IDA debugger via Python script files, enabling automated operations such as debug control, memory / register read / write, and breakpoint management. This compensates for the inefficiencies of manual debugging and is particularly suitable for automating complex debugging processes (such as batch breakpoint setting, exception monitoring, and dynamic data extraction).
[0194] Based on the technical solution of this embodiment, the capabilities of ADQ-MCP can be extended using this API, enabling upper-layer artificial intelligence (AI) or other components to generate custom IDA-Python code on demand. Remote execution via the interface, combined with the MCP file system plugin, allows for the persistence of overtime files to the local machine, thereby achieving cross-task reuse.
[0195] Furthermore, testing has confirmed that this API can automatically generate program control flow graphs (CFGs) and perform complex reverse analysis operations with sample-specific characteristics, such as OLLVM obfuscation and junk instruction stripping.
[0196] The various solutions in the above embodiments of this application can be combined without contradiction.
[0197] This application embodiment can divide IoT devices into functional modules or functional units according to the above method examples. For example, each function can be divided into a separate functional module or functional unit, or two or more functions can be integrated into one processing module. The integrated module can be implemented in hardware or as a software functional module or functional unit. The module or unit division in this application embodiment is illustrative and represents only one logical functional division; other division methods may be used in actual implementation.
[0198] When dividing each function into modules according to its corresponding function. Figure 6 A schematic diagram of a code detection device 60 is shown, which can be used to perform the functions of the code detection device involved in the above embodiments. Figure 6 The code detection device 60 shown may include: a communication unit 601, a processing unit 602, and a detection unit 603.
[0199] In one embodiment, a communication unit 601 is used to acquire the code to be detected and its context information. A processing unit 602 is used to input the code to be detected and its context information into a code detection model to obtain detection information corresponding to the code to be detected, including a target script file corresponding to the code to be detected. The processing unit 602 is also used to run the target script file using an analysis tool to obtain analysis results. These analysis results include the execution results of the target script file and the execution results of the API. A detection unit 603 is used to detect whether the analysis results meet the detection conditions using the code detection model. The processing unit 602 is also used to adjust the target script file if the analysis results do not meet the detection conditions, and run the adjusted target script file using the analysis tool until the analysis results output by the analysis tool meet the detection conditions.
[0200] In one possible implementation, the processing unit 602 is specifically used to: obtain and load the script file in the analysis tool based on the script path corresponding to the target script file; execute the target script file in the target runtime environment of the analysis tool; and, if the execution time of the target script file does not exceed the execution time corresponding to the target script file, use the result output by the analysis tool as the analysis result corresponding to the target script file.
[0201] In one possible implementation, the processing unit 602 is further configured to: stop running the target script file if the duration of the analysis tool running the target script file exceeds the corresponding execution duration of the target script file; and / or, output first information if the analysis tool encounters an exception while running the target script file; the first information is configured to indicate at least one of the following: the type of exception encountered in the target script file; the location of the exception encountered in the target script file; and the call stack of the analysis tool while running the target script file.
[0202] In one possible implementation, the processing unit 602 is specifically used to: adjust the target script file based on the first information when the analysis result does not meet the detection conditions, to obtain the adjusted target script file; input the adjusted target script file into the code detection model to obtain new detection information for the code to be detected; and input the new detection information into the analysis tool through the message control agent layer (MCP layer) so that the analysis tool runs the adjusted target script file.
[0203] In one possible implementation, the processing unit 602 is specifically used to: obtain the import module of the target script file through an analysis tool; traverse the import module to obtain the function information of the import module; the function information includes the function name called by the import module and the API of the import module; and use the identifier of the import module as the key and the function information as the value to obtain the execution result of the API of the target script file.
[0204] In one possible implementation, the communication unit 601 is further configured to: obtain the execution status of the target script file in the analysis tool. The detection unit 603 is specifically configured to: encapsulate the execution status and analysis results through the MCP layer to obtain a target JSON file; input the target JSON file into the code detection model to detect whether the target JSON file has a valid script file; a valid script file is a script file capable of recognizing the code to be detected.
[0205] In one possible implementation, the processing unit 602 is further configured to: configure script metadata for the target script file if the target JSON file has a valid script file, thereby obtaining the configured script file; the script metadata is used to indicate at least one of the following: the function of the target script file, the parameters required during the execution of the target script file, the output analysis results, and the source information; and store the configured script file in the script repository of the MCP layer.
[0206] As another feasible approach Figure 6 The processing unit 602 can be replaced by a processor that can integrate the functions of the processing unit 602. Figure 6 The communication unit 601 can be replaced by a transceiver or transceiver unit, which can integrate the functions of the communication unit 601.
[0207] Furthermore, when the processing unit 602 is replaced by a processor and the communication unit 601 is replaced by a transceiver or transceiver unit, the code detection device 60 involved in the embodiments of this application can be... Figure 2 The apparatus shown.
[0208] This application also provides a computer-readable storage medium. All or part of the message flow in the above method embodiments can be implemented by a computer program instructing related hardware. This program can be stored in the aforementioned computer-readable storage medium. When executed, the program can include the message flow as described in the above method embodiments. The computer-readable storage medium can be the detection device of any of the foregoing embodiments.
[0209] The internal storage unit (including the data sending end and / or data receiving end) can be, for example, the hard disk or memory of the detection device. The aforementioned computer-readable storage medium can also be an external storage device of the detection device, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the detection device. Furthermore, the aforementioned computer-readable storage medium can include both internal storage units and external storage devices of the detection device. The aforementioned computer-readable storage medium is used to store the aforementioned computer program and other programs and data required by the detection device. The aforementioned computer-readable storage medium can also be used to temporarily store data that has been output or will be output.
[0210] It should be noted that the terms "first" and "second," etc., in the specification, claims, and drawings of this application are used to distinguish different objects, not to describe a specific order. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or apparatuses.
[0211] It should be understood that in this application, "at least one (item)" means one or more, "more than one" means two or more, "at least two (items)" means two or three or more, and "and / or" is used to describe the relationship between related objects, indicating that there can be three relationships. For example, "A and / or B" can mean: only A exists, only B exists, and A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the related objects before and after are in an "or" relationship. "At least one (item) of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one (item) of a, b, or c can mean: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.
[0212] Through the above description of the embodiments, those skilled in the art can clearly understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.
[0213] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another device, or some features may be ignored or not executed. Furthermore, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.
[0214] The units described as separate components may or may not be physically separate. A component shown as a unit can be one or more physical units; that is, it can be located in one place or distributed in multiple different locations. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.
[0215] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.
[0216] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, essentially, or the parts that contribute to the prior art, or all or part of the technical solutions, can be embodied in the form of a software product. This software product is stored in a storage medium and includes several instructions to cause a device (which may be a microcontroller, chip, etc.) or processor to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, ROM, RAM, magnetic disks, or optical disks.
[0217] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.
Claims
1. A code detection method, characterized in that, The method includes: Obtain the code to be detected and the context information of the code to be detected; The code to be detected and the context information are input into the code detection model to obtain the detection information corresponding to the code to be detected; the detection information includes the target script file corresponding to the code to be detected. The target script file is run using an analysis tool to obtain analysis results; the analysis results include the execution results of the target script file and the execution results of the application programming interface (API); The code detection model is used to determine whether the analysis results meet the detection conditions. If the analysis results do not meet the detection conditions, the target script file is adjusted, and the adjusted target script file is run through the analysis tool until the analysis results output by the analysis tool meet the detection conditions.
2. The method according to claim 1, characterized in that, The process of running the script file using an analysis tool to obtain analysis results includes: Based on the script path corresponding to the target script file, obtain and load the script file in the analysis tool; The target script file is executed in the target runtime environment of the analysis tool; If the execution time of the target script file does not exceed the execution time corresponding to the target script file, the result output by the analysis tool shall be taken as the analysis result corresponding to the target script file.
3. The method according to claim 2, characterized in that, The method further includes: If the analysis tool runs the target script file for a duration exceeding the corresponding execution time of the target script file, the execution of the target script file will be stopped; and / or, If the analysis tool encounters an error while running the target script file, it outputs a first message; the first message indicates at least one of the following: The target script file exhibits the following type of error: The location in the target script file where the anomaly occurs; The analysis tool runs the call stack of the target script file.
4. The method according to claim 3, characterized in that, The step of adjusting the target script file when the analysis results do not meet the detection conditions includes: If the analysis results do not meet the detection conditions, the target script file is adjusted based on the first information to obtain the adjusted target script file. The step of rerunning the adjusted target script file using the analysis tool includes: The adjusted target script file is input into the code detection model to obtain new detection information for the code to be detected; The new detection information is input into the analysis tool through the Message Control Proxy (MCP) layer, so that the analysis tool can run the adjusted target script file.
5. The method according to any one of claims 1-4, characterized in that, The process of running the target script file using an analysis tool to obtain analysis results includes: The import module of the target script file is obtained through the analysis tool; The importing modules are traversed to obtain their function information; the function information includes the function names called by the importing modules and the API of the importing modules. Using the identifier of the imported module as the key and the function information as the value, the execution result of the API of the target script file is obtained.
6. The method according to any one of claims 1-4, characterized in that, The method further includes: Obtain the execution status of the target script file in the analysis tool; The step of detecting whether the analysis results meet the detection conditions using the code detection model includes: The execution status and analysis results are encapsulated through the MCP layer to obtain the target JSON file; The target JSON file is input into the code detection model to detect whether the target JSON file has a valid script file; the valid script file is a script file that can identify the code to be detected.
7. The method according to claim 6, characterized in that, The method further includes: If the target JSON file contains the valid script file, configure script metadata for the target script file to obtain the configured script file; the script metadata is used to indicate at least one of the following: the function of the target script file, the parameters required during the execution of the target script file, the output analysis results, and source information; The configured script file is stored in the script repository of the MCP layer.
8. A code detection device, characterized in that, The code detection device includes: A communication unit is used to acquire the code to be detected and the context information of the program code to be detected; The processing unit is configured to input the code to be detected and the context information into the code detection model to obtain detection information corresponding to the code to be detected; the detection information includes the target script file corresponding to the code to be detected. The processing unit is further configured to run the target script file using an analysis tool to obtain analysis results; the analysis results include the execution results of the target script file and the execution results of the application node API; The detection unit is used to detect whether the analysis results meet the detection conditions through the code detection model; The processing unit is further configured to adjust the target script file if the analysis result does not meet the detection conditions, and run the adjusted target script file through the analysis tool until the analysis result output by the analysis tool meets the detection conditions.
9. A code detection device, characterized in that, include: Memory and processor; Memory and processor are coupled; The memory is used to store instructions that can be executed by the processor; When the processor executes the instructions, it performs the method as described in any one of claims 1-7.
10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions or programs that, when executed on a computer, cause the computer to perform the code detection method as described in any one of claims 1-7.
11. A computer program product, characterized in that, The computer program product includes computer program instructions that, when executed, implement the method as described in any one of claims 1-7.