Method and apparatus for analyzing bytecode call sequences for trustworthiness

Abstract

The application provides a method and device for analyzing whether a bytecode call sequence is credible, the method comprising: obtaining stack information through a preset monitoring point, determining external parameters and a bytecode file call sequence according to the stack information, wherein the external parameters represent externally input parameters, and the bytecode file call sequence represents the order in which bytecode files are called and executed; executing the bytecode files according to the external parameters and the bytecode file call sequence to simulate the processing procedure of the external parameters, and obtaining the processing result output after the execution of the last called bytecode file; and determining whether the bytecode file call sequence is credible according to whether the output processing result is a dangerous instruction. The bytecode file call sequence can be used to distinguish safe bytecode file call sequences from the running principle, and unknown vulnerabilities can be protected, so that the protection capability is stronger.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a method and apparatus for analyzing the reliability of bytecode call sequences. Background Technology

[0002] Most Java attacks achieve their objectives by executing specified commands through unsafe call sequences. Furthermore, most protection tools rely on detecting specific dangerous instructions, offering only limited protection against known attack methods. For example, openRASP technology scans monitoring points based on existing vulnerability rules, alerting users to attacks matching those rules. This only defends against known vulnerabilities, and requires re-analysis every time a monitoring point is accessed, which is time-consuming and labor-intensive. Summary of the Invention

[0003] This invention provides a method for analyzing the reliability of bytecode call sequences, comprising:

[0004] Stack information is obtained through preset monitoring points, and external parameters and bytecode file call sequence are determined based on the stack information. The external parameters represent externally input parameters, and the bytecode file call sequence represents the order in which bytecode files are executed.

[0005] The bytecode file is executed according to the external parameters and the bytecode file call sequence to simulate the processing of the external parameters, and the processing result output after the last called bytecode file is executed is obtained;

[0006] Whether the bytecode file call sequence is trustworthy is determined based on whether the processing result of the output is a dangerous instruction.

[0007] Optionally, before obtaining the stack information through preset monitoring points, the method further includes:

[0008] Scan the loaded classes to obtain the set of bytecode files corresponding to the classes.

[0009] Optionally, the stack information includes request information, and determining external parameters and bytecode file call sequences based on the stack information includes:

[0010] Parse the request information to obtain the external parameters and the first bytecode file information. The first bytecode file information is used to obtain the first bytecode file for processing the external parameters. The first bytecode file is the first bytecode file called in the bytecode file call sequence.

[0011] By popping and pushing the output results of each bytecode file except the last one being called, information about the next bytecode file to be called can be obtained.

[0012] The bytecode file call sequence is determined based on the bytecode file information of each of the next calls.

[0013] Optionally, the processing of the external parameters is simulated based on the external parameters and the bytecode file call sequence, including:

[0014] Based on the bytecode file call sequence, external parameters are input into the first bytecode file in the first call order to obtain the first processing result after the first bytecode file is executed.

[0015] The first processing result is input into the next bytecode file to be called after the first bytecode file to obtain the second processing result;

[0016] Similarly, the processing result of the currently executed bytecode file is input into the next bytecode file to be executed, and the corresponding processing result is obtained.

[0017] Repeat the above process until the processing result of the last bytecode file in the bytecode file call sequence is obtained.

[0018] Optionally, determining whether the bytecode file call sequence is trustworthy based on whether the output processing result is a dangerous instruction includes:

[0019] Determine whether the output processing result is a dangerous instruction;

[0020] If the output processing result is not a dangerous command, then the bytecode file call sequence is trustworthy, and the bytecode file call sequence is stored in the database;

[0021] If the processing result of the output is a dangerous command, then the bytecode file call sequence is untrusted, and an alarm message is generated.

[0022] Optionally, before executing the bytecode file according to the external parameters and the bytecode file call sequence to simulate the processing of the external parameters, the method further includes:

[0023] The bytecode file call sequence is matched with a preset trusted bytecode file call sequence in the database. If the match is successful, the bytecode file call sequence is determined to be trusted.

[0024] Optionally, obtaining stack information through preset monitoring points includes:

[0025] The checkExec method of SecurityManager calls preset monitoring points to obtain stack information.

[0026] Optionally, before obtaining stack information through preset monitoring points, the method includes:

[0027] Monitoring points are preset by using a custom monitoring program, which is triggered based on predetermined system behaviors.

[0028] The present invention also provides an apparatus for analyzing whether a bytecode call sequence is trustworthy, comprising:

[0029] The stack information processing module is used to acquire stack information through preset monitoring points, and determine external parameters and bytecode file call sequence based on the stack information. The external parameters represent externally input parameters, and the bytecode file call sequence represents the order in which bytecode files are executed.

[0030] The bytecode file execution module is used to execute the bytecode file according to the external parameters and the bytecode file call sequence to simulate the processing of the external parameters, and to obtain the processing result output after the last called bytecode file is executed;

[0031] The trustworthiness determination module is used to determine whether the bytecode file call sequence is trustworthy based on whether the output processing result is a dangerous instruction.

[0032] The present invention provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the aforementioned method for analyzing whether a bytecode call sequence is trustworthy.

[0033] The present invention provides a non-transitory computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the aforementioned method for analyzing whether a bytecode call sequence is trustworthy.

[0034] This invention provides a method for analyzing the trustworthiness of bytecode call sequences. The method of analyzing call sequences based on bytecode can distinguish secure call sequences from the perspective of operating principles. Identical sequences do not need to be judged again, resulting in low performance loss and stronger protection against unknown vulnerabilities. Attached Figure Description

[0035] To more clearly illustrate the technical solutions in this invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0036] Figure 1 This is a flowchart illustrating the method for analyzing the reliability of bytecode call sequences provided by the present invention;

[0037] Figure 2 This is a schematic diagram illustrating an application scenario of the method for analyzing the reliability of bytecode call sequences provided by this invention;

[0038] Figure 3 This is a schematic diagram of the device provided by the present invention for analyzing whether a bytecode call sequence is trustworthy;

[0039] Figure 4 This is a schematic diagram of the structure of the electronic device provided by the present invention. Detailed Implementation

[0040] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this invention. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without creative effort are within the scope of protection of this invention.

[0041] Please see Figure 1 , Figure 1 This is a flowchart illustrating an embodiment of the method for analyzing the reliability of bytecode call sequences according to the present invention. Figure 1 As shown, the method for analyzing the reliability of bytecode call sequences includes the following steps:

[0042] Step 101: Obtain stack information through preset monitoring points, and determine external parameters and bytecode file call sequence based on the stack information. The external parameters represent externally input parameters, and the bytecode file call sequence represents the order in which bytecode files are executed sequentially.

[0043] Bytecode files are .class files. After a .java file is compiled, a .class file is generated. Then the compiler loads the bytecode file, and the class loader loads the bytecode file of the corresponding class according to the class name, which is used to execute the entry point main method or other methods.

[0044] The stack is used to store instances of basic classes and calling classes; in other words, the stack stores the calls to class objects, specifically the starting address of the instance object in the heap. Because the stack is thread-specific, each thread has its own thread stack.

[0045] The storage order in the stack is fixed, and the space allocated by the JVM (Java Virtual Machine) is fixed and cannot be changed. Local variables reside in the stack memory. The JVM allocates a stack frame for each class, and then the local variables referencing the class point to addresses in the heap memory. When a local variable is no longer needed, the JVM will clean it up (i.e., pop it from the stack).

[0046] This application utilizes the aforementioned characteristics of the stack to obtain external parameters and local variables of the referenced class using the stack's push and pop information, thereby determining the bytecode file call sequence.

[0047] In essence, stack trace information includes an index of the bytecode file. The corresponding bytecode file is determined based on this index, and the push and pop information of the bytecode file during execution records the entire execution process of the call.

[0048] Generally, the heap is used to store dynamically generated data. Instances of objects created with `new` are stored in the heap, but only instance variables are stored there; the values ​​of these instance variables are stored in the constant pool. Member methods are shared by instances of a certain class, and not every `new` creates a member method. Therefore, member methods are stored in the method area, not in the first created object, because if they were, the first object would be garbage collected, and subsequent objects would have no method references. Static variables corresponding to generic classes are also stored in the method area. The method area (non-deap, a portion of memory allocated within the heap) stores class loading information (i.e., the `Class` parameter after `class` in reflection), used to store information about classes loaded by the virtual machine, constants, static variables, etc. Like the heap, it is a shared memory area for threads. Local variables reside in the stack memory. The JVM allocates a stack frame for each class and then calls the local variables of a particular class to point to addresses in the heap memory. Therefore, by setting up monitoring points, class loading information and / or member method information in the heap can be obtained, thereby determining the call sequence of the bytecode file.

[0049] Generally, when executing a member method, the parameters of the first bytecode file that is input are used as external parameters. External parameters are often manually entered, and based on the premise that all inputs may be harmful, external parameters are unreliable.

[0050] Step 102: Execute the bytecode file according to the external parameters and the bytecode file call sequence to simulate the processing of the external parameters, and obtain the processing result output after the last called bytecode file is executed.

[0051] In some embodiments, the bytecode file is simulated and executed in the JVM based on the external parameters and the bytecode file call sequence to obtain the processing of the external parameters.

[0052] Each member method sequentially calls and executes a series of bytecode files. During the execution of each bytecode file, a corresponding processing result is generated. The processing result output by the currently called bytecode file serves as the input for the next called bytecode file, until the last bytecode file called by the corresponding member method is executed, outputting the final processing result. The processing results output by each bytecode file can be used to trace and discover the process of external parameter contamination propagation.

[0053] Based on the bytecode file call sequence, external parameters are input into the first bytecode file in the first call order to obtain the first processing result after the first bytecode file is executed.

[0054] The first processing result is input into the next bytecode file to be called after the first bytecode file to obtain the second processing result;

[0055] Similarly, the processing result of the currently executed bytecode file is input into the next bytecode file to be executed, and the corresponding processing result is obtained.

[0056] Repeat the above process until the processing result of the last bytecode file called in the bytecode file call sequence is obtained.

[0057] Step 103: Determine whether the bytecode file call sequence is trustworthy based on whether the processing result of the last called bytecode file output is a dangerous command.

[0058] This invention discloses a method for analyzing the trustworthiness of bytecode call sequences in some embodiments. This method acquires stack information through preset monitoring points, determines external parameters and a bytecode file call sequence based on the stack information, where the external parameters represent externally input parameters and the bytecode file call sequence represents the order in which bytecode files are executed. The method executes bytecode files according to the external parameters and the bytecode file call sequence to simulate the processing of the external parameters, and obtains the processing results output after each bytecode file execution. The trustworthiness of the bytecode file call sequence is determined based on whether the output processing results are contaminated. This invention, through the bytecode file call sequence, can distinguish secure bytecode file call sequences from the perspective of operational principles and can protect against unknown vulnerabilities, thus providing stronger protection capabilities.

[0059] The JVM loads class description data from the Class file into memory, performs verification, conversion, parsing, and initialization of the data, ultimately forming a Java type that can be directly used by the virtual machine. This is the virtual machine's class loading mechanism. In the Java language, the loading, linking, and initialization of types are all completed during program execution. In this invention, before obtaining stack information through preset monitoring points, the process further includes scanning the loaded classes to obtain the set of bytecode files corresponding to the classes. In some embodiments, when a command is executed in the JVM, the corresponding class is loaded. The preprocessing module can be used to call the loaded classes in the JVM to obtain the bytecode files corresponding to the classes.

[0060] This embodiment obtains the bytecode file call sequence corresponding to a member method by calling an already loaded class, preparing for subsequent bytecode execution simulation. This invention, by simulating bytecode file execution, can achieve stronger protection against unknown vulnerabilities.

[0061] In some optional implementations, before obtaining stack information based on preset monitoring points, the method includes: preset monitoring points based on the checkExec method of SecurityManager.

[0062] As an example, monitoring points can be pre-installed and triggered by the JVM to start monitoring. When a JavaScript script is executed in the JVM, class loading is a necessary prerequisite for the script to be executed. The preprocessing module can scan the classes already loaded in the JVM. If the scanned classes involve sensitive operations such as modification or deletion, the Java system will automatically call monitoring methods, such as the `checkExec` method of the Java system's built-in `SecurityManager`. When the monitoring method is called, stack information is automatically obtained. As a specific implementation, monitoring code for analyzing the bytecode file call sequence is inserted into the `checkExec` method of `SecurityManager`, thus pre-installing monitoring points so that Java can additionally execute methods to analyze the trustworthiness of the bytecode call sequence when the monitoring method is automatically called.

[0063] Monitoring points are preset by using a custom monitoring program, which is triggered based on predetermined system behaviors.

[0064] This embodiment uses the SecurityManager's checkExec method or a custom method to set monitoring points, thus enabling the monitoring of suspicious operations.

[0065] In some optional implementations, the stack information includes request information, and determining the external parameters and bytecode file call sequence based on the stack information includes: parsing the request information to obtain the external parameters and the first bytecode file information of the first call, wherein the first bytecode file information is used to obtain the first call bytecode file for processing the external parameters.

[0066] By popping and pushing the output results of each bytecode file except the last one being called, information about the next bytecode file to be called can be obtained.

[0067] The bytecode file call sequence is determined based on the bytecode file information of each of the next calls.

[0068] This invention can distinguish between trusted and untrusted bytecode file call sequences by analyzing the execution process of each bytecode file. This overcomes the limitations of existing technologies that can only detect known vulnerability types and achieves protection against unknown vulnerabilities.

[0069] In some optional implementations, determining whether the bytecode file call sequence is trustworthy includes: determining whether the processing result of the last bytecode file is a dangerous command; if the processing result of the last bytecode file is not a dangerous command, then the bytecode file call sequence is trustworthy, and the bytecode file call sequence is stored in the database; if the processing result of the last bytecode file is a dangerous command, then the bytecode file call sequence is untrustworthy, and an alarm message is generated.

[0070] In some embodiments, alarm information can be displayed on the computer interface in any format.

[0071] This invention does not limit the type of database.

[0072] This embodiment stores the bytecode file call sequence in a database in a reliable manner, which avoids the subsequent simulation and execution of the same type of bytecode file call sequence. This helps to save computing power and improve the efficiency of analyzing whether the bytecode call sequence is reliable.

[0073] In some optional implementations, before simulating the processing of the external parameters based on the external parameters and the bytecode file call sequence, the method further includes: matching the bytecode file call sequence with a preset trusted bytecode file call sequence in the database; if the match is successful, the bytecode file call sequence is determined to be trusted.

[0074] This embodiment matches the bytecode file call sequence with a preset trusted bytecode file call sequence in the database to determine whether the bytecode file call sequence is trusted. This eliminates the need to simulate the execution of the same bytecode file call sequence, reducing performance overhead and improving the efficiency of analyzing whether the bytecode call sequence is trusted.

[0075] As one specific implementation method, such as Figure 2 As shown, the method for analyzing the reliability of bytecode call sequences provided by this invention includes the following steps:

[0076] (1) Add monitoring and analysis points to the software code of the SecurityManager checkExec method when the JVM execution command involves sensitive commands such as modifying or deleting files. The monitoring and analysis points are additionally defined verification rules.

[0077] (2) When the JVM calls the checkExec method, the corresponding stack information is naturally generated.

[0078] (3) Obtain the JVM stack information through the monitoring and analysis points, intercept the stack entry and exit information of a member method and match each bytecode file, and determine the bytecode file call sequence based on the matched bytecode files.

[0079] (4) Simulate the execution process of the bytecode corresponding to each member method on the stack in the JVM, analyze whether the dangerous variables input from the outside will affect the command to be executed. If they do not affect the command, the call sequence (or bytecode call sequence) is safe and subsequent identical call sequences can be directly judged as safe without testing. Otherwise, the command to be executed may be dangerous and an alarm should be issued.

[0080] Based on the safety principle that all inputs are harmful, the parameters of the entry method of the JVM execution call sequence are marked as suspicious variables. Starting from the entry method, the bytecode file of the corresponding method is obtained, and the execution process of the member method is simulated. The parameters generated by each bytecode file are popped and pushed onto the execution stack. The analysis is iterated until the execution point of the target method is reached, and the final output result is judged to determine whether the call chain is safe.

[0081] As discussed above, existing methods for detecting specific instructions only protect against known and limited vulnerabilities, failing to protect against unknown and dangerous instructions. Furthermore, the need for detection with each execution significantly impacts performance. By simulating the bytecode file of the execution stack, we can trace whether dangerous external input parameters affect the final executed instructions to determine the trustworthiness of the call sequence. This allows us to identify safe call sequences, eliminating the need for subsequent detection of identical sequences and reducing performance overhead. Simultaneously, it can also generate alerts for vulnerabilities in the execution of unknown instructions.

[0082] Please see Figure 3 , Figure 3 The diagrams above illustrate some embodiments of the apparatus for analyzing the trustworthiness of bytecode call sequences according to the present invention. As an implementation of the methods shown in the diagrams, the present invention also provides some embodiments of a protective apparatus for analyzing the trustworthiness of bytecode call sequences. These apparatus embodiments are similar to... Figure 1 The embodiments of some of the methods shown correspond to this, and the device can be applied to a variety of electronic devices.

[0083] like Figure 3 As shown, an apparatus 300 for analyzing the trustworthiness of bytecode call sequences in some embodiments includes a stack information processing module 301, used to acquire stack information through preset monitoring points, and determine external parameters and bytecode file call sequences based on the stack information. The external parameters represent externally input parameters, and the bytecode file call sequence represents the call order of bytecode files executed sequentially. A bytecode file execution module 302 is used to execute bytecode files according to the external parameters and bytecode file call sequence to simulate the processing of the external parameters, and obtain the processing result output after the last called bytecode file is executed. A trustworthiness judgment module 303 is used to determine whether the bytecode file call sequence is trustworthy based on whether the output processing result is a dangerous instruction.

[0084] In some optional implementations of the embodiments, the apparatus further includes a preprocessing module for: scanning the loaded classes to obtain a set of bytecode files corresponding to the classes.

[0085] The stack information processing module 301 is further configured to: parse the request information to obtain the external parameters and the first bytecode file information of the first call in the member method.

[0086] The bytecode file execution module 302 is further configured to: call a first bytecode file in the bytecode file set according to the first bytecode file information; execute the first bytecode file as input with the external parameters to obtain a first processing result and second bytecode file information, call a second bytecode file corresponding to the second bytecode file information, and execute the second bytecode file information with the first processing result as input; and iterate in this way until the last bytecode file is called and executed to obtain the final processing result.

[0087] The trust judgment module 303 is used to: determine whether the processing result of the last bytecode file is a dangerous command; if the processing result of the last bytecode file is not a dangerous command, then the bytecode file call sequence is trustworthy, and the trustworthy bytecode file call sequence is stored in the database; if the processing result of the last bytecode file is a dangerous command, then the bytecode file call sequence is untrustworthy, and an alarm message is generated.

[0088] In some optional implementations of the embodiments, the device further includes a bytecode file call sequence matching module, which is used to match the bytecode file call sequence with a preset trusted bytecode file call sequence in the database. If the match is successful, the bytecode file call sequence is determined to be trusted.

[0089] It is understandable that the modules described in the device 300 are related to... Figure 1 The steps in the described method correspond to each other. Therefore, the operations, features, and beneficial effects described above for the method also apply to the device 300 and the modules and units contained therein, and will not be repeated here.

[0090] Figure 4 An example is a schematic diagram of the physical structure of an electronic device, such as... Figure 4 As shown, the electronic device may include a processor 410, a communications interface 420, a memory 430, and a communication bus 440, wherein the processor 410, communications interface 420, and memory 430 communicate with each other via the communication bus 440. The processor 410 can invoke logical instructions in the memory 430 to execute a method for analyzing the reliability of a bytecode call sequence. This method includes: acquiring stack information through preset monitoring points; determining external parameters and a bytecode file call sequence based on the stack information, where the external parameters represent externally input parameters and the bytecode file call sequence represents the order in which bytecode files are executed; executing bytecode files according to the external parameters and the bytecode file call sequence to simulate the processing of the external parameters, and iteratively executing each bytecode file until the last called bytecode file outputs a processing result; and determining whether the bytecode file call sequence is reliable based on whether the output processing result contains dangerous instructions.

[0091] Furthermore, the logical instructions in the aforementioned memory 430 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, essentially, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0092] On the other hand, the present invention also provides a computer program product, which includes a computer program that can be stored on a non-transitory computer-readable storage medium. When the computer program is executed by a processor, the computer can execute the method provided by the above methods for analyzing whether a bytecode call sequence is trustworthy. The method includes: acquiring stack information through preset monitoring points; determining external parameters and a bytecode file call sequence based on the stack information, wherein the external parameters represent externally input parameters and the bytecode file call sequence represents the order in which bytecode files are executed; executing bytecode files according to the external parameters and the bytecode file call sequence to simulate the processing of the external parameters, and obtaining the processing results output after the execution of each bytecode file; and determining whether the bytecode file call sequence is trustworthy based on whether the output processing results are contaminated.

[0093] The present invention also provides a non-transitory computer-readable storage medium storing a computer program thereon. When executed by a processor, the computer program implements a method for analyzing the reliability of bytecode call sequences provided by the above methods. The method includes: acquiring stack information through preset monitoring points; determining external parameters and a bytecode file call sequence based on the stack information, wherein the external parameters represent externally input parameters and the bytecode file call sequence represents the order in which bytecode files are executed; executing bytecode files according to the external parameters and the bytecode file call sequence to simulate the processing of the external parameters, and obtaining the processing results output after the execution of each bytecode file; and determining whether the bytecode file call sequence is reliable based on whether the output processing results are contaminated.

[0094] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0095] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0096] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for analyzing the reliability of bytecode call sequences, characterized in that, include: Stack information is obtained through preset monitoring points, and external parameters and bytecode file call sequence are determined based on the stack information. The external parameters represent externally input parameters, and the bytecode file call sequence represents the order in which bytecode files are executed. The bytecode file is executed according to the external parameters and the bytecode file call sequence to simulate the processing of the external parameters, and the processing result output after the last called bytecode file is executed is obtained; The reliability of the bytecode file call sequence is determined based on whether the output processing result is a dangerous instruction, and the reliable bytecode file call sequence is stored in the database; The subsequently obtained bytecode file call sequence is matched with the trusted bytecode file call sequence stored in the database. If the match is successful, the trusted bytecode file call sequence is directly determined.

2. The method for analyzing the reliability of bytecode call sequences according to claim 1, characterized in that, Before obtaining stack information through preset monitoring points, the process also includes: Scan the loaded classes to obtain the set of bytecode files corresponding to the classes.

3. The method for analyzing the reliability of bytecode call sequences according to claim 2, characterized in that, The stack information includes request information. Based on the stack information, external parameters and the bytecode file call sequence are determined, including: Parse the request information to obtain the external parameters and the first bytecode file information. The first bytecode file information is used to obtain the first bytecode file for processing the external parameters. The first bytecode file is the first bytecode file called in the bytecode file call sequence. By popping and pushing the output results of each bytecode file except the last one being called, information about the next bytecode file to be called can be obtained. The bytecode file call sequence is determined based on the bytecode file information of each of the next calls.

4. The method for analyzing the reliability of bytecode call sequences according to claim 3, characterized in that, The process of simulating the processing of the external parameters based on the external parameters and the bytecode file call sequence includes: Based on the bytecode file call sequence, external parameters are input into the first bytecode file in the first call order to obtain the first processing result after the first bytecode file is executed. The first processing result is input into the next bytecode file to be called after the first bytecode file to obtain the second processing result; Similarly, the processing result of the currently executed bytecode file is input into the next bytecode file to be executed, and the corresponding processing result is obtained. Repeat the above process until the processing result of the last bytecode file called in the bytecode file call sequence is obtained.

5. The method for analyzing the reliability of bytecode call sequences according to claim 4, characterized in that, Determining the trustworthiness of the bytecode file call sequence based on whether the output processing result is a dangerous instruction includes: Determine whether the output processing result is a dangerous instruction; If the output processing result is not a dangerous command, then the bytecode file call sequence is trustworthy, and the bytecode file call sequence is stored in the database; If the output processing result is a dangerous command, then the bytecode file call sequence is untrusted, and an alarm message is generated.

6. The method for analyzing the reliability of bytecode call sequences according to claim 1, characterized in that, Before executing the bytecode file according to the external parameters and the bytecode file call sequence to simulate the processing of the external parameters, the process further includes: The bytecode file call sequence is matched with a preset trusted bytecode file call sequence in the database. If the match is successful, the bytecode file call sequence is determined to be trusted.

7. The method for analyzing the reliability of bytecode call sequences according to claim 1, characterized in that, Obtaining stack information through preset monitoring points includes: The checkExec method of SecurityManager calls preset monitoring points to obtain stack information.

8. The method for analyzing the reliability of bytecode call sequences according to claim 1, characterized in that, Before obtaining stack information through preset monitoring points, the method includes: Monitoring points are preset by using a custom monitoring program, which is triggered based on predetermined system behaviors.

9. An apparatus for analyzing the reliability of bytecode call sequences, characterized in that, The method for implementing any one of claims 1-8 includes: The stack information processing module is used to acquire stack information through preset monitoring points, and determine external parameters and bytecode file call sequence based on the stack information. The external parameters represent externally input parameters, and the bytecode file call sequence represents the order in which bytecode files are executed. The bytecode file execution module is used to execute the bytecode file according to the external parameters and the bytecode file call sequence to simulate the processing of the external parameters, and to obtain the processing result output after the last called bytecode file is executed; The trustworthiness determination module is used to determine whether the bytecode file call sequence is trustworthy based on whether the output processing result is a dangerous instruction.

10. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the method for analyzing whether a bytecode call sequence is trustworthy as described in any one of claims 1 to 8.

11. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method for analyzing whether a bytecode call sequence is trustworthy as described in any one of claims 1 to 8.

Images