Vulnerability mining method, device and equipment of application program and storage medium

Abstract

The application discloses a vulnerability mining method and device of an application program, equipment and a storage medium, and relates to the technical field of computers and the Internet. The method comprises the following steps: performing mutation on first basic test data of an application program to obtain first mutated test data; based on first snapshot information of the application program, the application program is restored to a first running state, and the first snapshot information records state data of the first running state in which the application program is located before processing the first basic test data; after the application program is restored to the first running state, the application program processes the first mutated test data in a real hardware environment to obtain a first running result; and according to the first running result, a vulnerability mining result of the application program is determined. By running the application program in the real hardware environment, the problem that the application program cannot be subjected to vulnerability mining due to carrying a protection scheme can be avoided, so that the application scene of vulnerability mining is expanded.

Description

Technical Field

[0001] This application relates to the fields of computer and internet technology, and in particular to a method, apparatus, device, and storage medium for vulnerability discovery in game applications. Background Technology

[0002] With the development of internet technology, applications with vulnerabilities are easily attacked by viruses, Trojans, and other malware, leading to losses. Therefore, discovering application vulnerabilities is extremely important.

[0003] In related technologies, vulnerability discovery for applications typically employs dual-machine debugging techniques. A debugger is used to modify the base test data to obtain mutated test data, which is then sent to a virtual machine. After receiving the mutated test data, the virtual machine processes it through the application, and finally, based on the application's execution results, the application's vulnerabilities are discovered.

[0004] However, related technologies require that applications not have anti-virtual machine protection schemes for vulnerability discovery. If an application has a protection scheme, it cannot run on a virtual machine, and dual-machine debugging technology cannot be used to discover vulnerabilities in the application. Summary of the Invention

[0005] This application provides a method, apparatus, device, and storage medium for vulnerability discovery in applications. The technical solution is as follows:

[0006] According to one aspect of the embodiments of this application, a method for vulnerability discovery in an application is provided, the method comprising:

[0007] The first basic test data of the application is mutated to obtain the first mutated test data;

[0008] Based on the first snapshot information of the application, the application is restored to the first running state. The first snapshot information records the state data of the first running state that the application was in before processing the first basic test data.

[0009] After the application is restored to the first running state, the first mutation test data is processed by the application in a real hardware environment to obtain the first running result;

[0010] Based on the first running result, the vulnerability discovery results of the application are determined.

[0011] According to one aspect of the embodiments of this application, an application vulnerability discovery apparatus is provided, the apparatus comprising:

[0012] The data mutation module is used to mutate the first basic test data of the application to obtain the first mutated test data.

[0013] The state recovery module is used to restore the application to a first running state based on the first snapshot information of the application. The first snapshot information records the state data of the first running state that the application was in before processing the first basic test data.

[0014] The data processing module is used to process the first mutation test data through the application in a real hardware environment after the application is restored to the first running state, and obtain the first running result.

[0015] The result determination module is used to determine the vulnerability discovery results of the application based on the first running result.

[0016] According to one aspect of the embodiments of this application, a computer device is provided, the computer device including a processor and a memory, the memory storing a computer program, the computer program being loaded and executed by the processor to implement the above-described method.

[0017] According to one aspect of the embodiments of this application, a computer-readable storage medium is provided, wherein a computer program is stored in the storage medium, the computer program being loaded and executed by a processor to implement the above-described method.

[0018] According to one aspect of the embodiments of this application, a computer program product is provided, the computer program product including a computer program stored in a computer-readable storage medium. A processor of a computer device reads the computer program from the computer-readable storage medium, and the processor executes the computer program, causing the computer device to perform the method described above.

[0019] The technical solutions provided in this application embodiment may have the following beneficial effects:

[0020] On one hand, by mutating the application's basic test data, the application is restored to its running state before processing the basic test data based on snapshot information. Then, the restored application is used in a real hardware environment to process the mutated test data, obtaining the running results. The vulnerability discovery results of the application are then determined based on these results. Since vulnerability discovery for applications is typically performed in virtual machines in related technologies, this requires that the application cannot have any protection schemes. If the application includes protection schemes similar to anti-virtual machine technologies, vulnerability discovery cannot be performed in a virtual machine. However, the technical solution provided in this application, by running the application in a real hardware environment, avoids the problem of being unable to perform vulnerability discovery due to the application carrying protection schemes, thereby expanding the application scenarios of vulnerability discovery.

[0021] On the other hand, restoring the application's running state using snapshot information allows for vulnerability discovery by starting from that state and modifying the base test data. This means that the desired running state can be flexibly determined, and different running results can be obtained based on different input data, thus enabling vulnerability discovery. Therefore, this effectively reduces the time required for vulnerability discovery testing, accelerates the application testing process, and improves the efficiency of application vulnerability discovery. Attached Figure Description

[0022] Figure 1 This is a schematic diagram of the implementation environment of a solution provided in one embodiment of this application;

[0023] Figure 2 This is a schematic diagram illustrating an application scenario of a solution provided in one embodiment of this application;

[0024] Figure 3 This is a flowchart of a vulnerability discovery method for an application provided in one embodiment of this application;

[0025] Figure 4 This is a flowchart of a vulnerability discovery method for an application provided in another embodiment of this application;

[0026] Figure 5 This is a flowchart of a vulnerability discovery method for an application provided in another embodiment of this application;

[0027] Figure 6 This is a block diagram of a snapshot information saving method provided in one embodiment of this application;

[0028] Figure 7 This is a block diagram of a vulnerability testing method provided in one embodiment of this application;

[0029] Figure 8 This is a block diagram of an application vulnerability discovery apparatus provided in one embodiment of this application;

[0030] Figure 9 This is a block diagram of an application vulnerability discovery apparatus provided in another embodiment of this application;

[0031] Figure 10 This is a structural block diagram of a computer device provided in one embodiment of this application. Detailed Implementation

[0032] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0033] Before introducing the technical solutions of this application, some terms involved in this application will be explained. The following related explanations are optional solutions and can be arbitrarily combined with the technical solutions of the embodiments of this application, all of which fall within the protection scope of the embodiments of this application. The embodiments of this application include at least some of the following contents.

[0034] Vulnerability discovery: The process of finding and discovering logical vulnerabilities in a target system using technical means.

[0035] Fuzzing is a tool used for fuzzing testing. It's a crucial step in the vulnerability discovery process. Fuzz testing is a type of security testing that falls between fully manual penetration testing and fully automated testing. It can alert testers to potential attack channels that should be blocked before a product is released to the market. Both fuzz testing and penetration testing are security testing methods, but they share similarities and differences. Penetration testing typically simulates malicious hacking, requiring high levels of skill from the tester, is costly, and difficult to scale. Fuzz testing, on the other hand, fully utilizes the machine itself to randomly generate and send data; simultaneously, it incorporates security advice from industry security experts. Fuzz testing data is uncertain and lacks clear targeting; simply put, it lacks logic and common sense. Testers simply insert prepared, seemingly random programs and wait for bugs (vulnerabilities) to appear—vulnerabilities that were previously unpredictable. The fuzzing process is as follows: 1. Prepare randomly or semi-randomly generated data; 2. Import the prepared data into the system under test; 3. Open the file with a program to observe the status of the system under test; 4. Determine whether there are vulnerabilities based on the status.

[0036] The mutation strategies include: 1. Random: By default, a maximum of 6 elements are randomly selected (this can be set via the MaxFieldsToMutate parameter) and mutated using random mutators. 2. Sequential: Peach (a server) sequentially mutates each element using all available mutators. 3. Random Deterministic: Peach's default rule. This rule applies mutators to elements in the pit.xml file.

[0037] Virtual machine: A complete computer system simulated by software, with full hardware system functionality, running in a completely isolated environment.

[0038] Dual-machine debugging technology: One computer acts as the host, displaying the debugger window, while the other computer acts as the client, displaying the output values ​​of the program being debugged. First, the directory containing the program to be debugged is shared on the host so that the client can see the program being debugged. Then, the program to be debugged is opened on the host, and Msvcmon.exe is run on the client to start the debugger program, waiting for the host to launch the debugger. This allows debugging to begin on the host.

[0039] Snapshot: A description file of the state of a target object at a certain point in time. An ideal snapshot can restore all the states of the target object at the corresponding point in time based on the information saved in the snapshot.

[0040] Memory snapshot information: Saving all the memory data of a program at a certain point in time is like taking a picture of the program; this process is called taking a snapshot. The saved memory data state file can be considered as memory snapshot information or a memory snapshot file. In some embodiments, memory data includes the program's global variable data.

[0041] Register snapshot information: The operation of saving the data in all registers of a program at a certain moment can also be regarded as a snapshot. The data status file in the saved registers can be regarded as register snapshot information or register snapshot file.

[0042] Function hijacking: The principle of hijacking is to modify the pointer of the target function to point to the address of a user-defined function. Functions reside in the code segment of memory, so hijacking is closely related to the code segment. Implementing hijacking requires the use of the detours tool.

[0043] A process / thread (the currently executing program) occupies a certain amount of memory, which may be used to store program code loaded from disk, data taken from user input, etc. However, the way a process manages this memory varies depending on the purpose of the memory. Some memory is statically allocated and uniformly reclaimed in advance, while some is dynamically allocated and reclaimed as needed. For any ordinary process, it involves five different data segments. The five different data areas contained in the memory space corresponding to a process are as follows.

[0044] The BSS segment (Block Started by Symbol segment) typically refers to a memory area used to store uninitialized global variables in a program. The BSS segment belongs to static memory allocation.

[0045] Data segment: This typically refers to a memory area used to store initialized global variables in a program. The data segment belongs to static memory allocation.

[0046] Code segment (or text segment): This typically refers to a memory area used to store the program's executable code. The size of this area is determined before the program runs, and the memory area is usually read-only. Some architectures also allow the code segment to be writable, meaning that modification of the program is permitted. The code segment may also contain read-only constant variables, such as string literals.

[0047] Heap: The heap is used to store dynamically allocated memory segments during process execution. Its size is not fixed and can dynamically expand or shrink. When a process calls functions such as malloc to allocate memory, the newly allocated memory is dynamically added to the heap (the heap expands); when memory is released using functions such as free, the released memory is removed from the heap (the heap shrinks).

[0048] Stack: Also known as a memory access stack, the stack is a place where users store temporarily created local variables, that is, variables defined within function brackets "{}" (excluding variables declared with `static`, which means the variable is stored in the data segment). In addition, when a function is called, its parameters are pushed onto the calling process's stack, and after the call ends, the function's return value is also stored back on the stack. Due to the stack's Last-In-First-Out (LIFO) characteristic, it is particularly convenient for saving and restoring the calling context. In this sense, we can view the stack as a memory area for storing and exchanging temporary data.

[0049] Of the five different data areas mentioned above, the data segment, code segment, and stack space contain variable data. The data segment, as a static storage area, contains static variables and global variables. The code segment may contain static constant variables, such as string literals. The stack space contains dynamic local variables. Therefore, in some embodiments, memory snapshot information includes variable data from the data segment, code segment, and stack space.

[0050] Please refer to Figure 1 This diagram illustrates an implementation environment for a solution provided in one embodiment of this application. The implementation environment may include: a terminal device 10 and a server 20.

[0051] Terminal device 10 includes, but is not limited to, mobile phones, tablets, smart voice interaction devices, game consoles, wearable devices, multimedia playback devices, PCs (Personal Computers), in-vehicle terminals, smart home appliances, and other electronic devices. The client for the target application can be installed on terminal device 10.

[0052] In this embodiment, the target application can be any application capable of vulnerability discovery. Typically, this application is a vulnerability discovery application for game applications. Of course, besides game application vulnerability discovery applications, other types of applications can also provide vulnerability discovery services. For example, vulnerability discovery applications for music applications, social applications, browser applications, virtual reality (VR) applications, augmented reality (AR) applications, etc., are not limited in this embodiment. Furthermore, the type of application performing vulnerability discovery differs for different applications; it can be a game application or other types. Besides the application category, it can also be system vulnerability discovery, database vulnerability discovery, etc., which are not limited in this embodiment. Optionally, the terminal device 10 runs a client of the aforementioned application.

[0053] Server 20 is used to provide backend services for the client of the target application in terminal device 10. For example, server 20 can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN (Content Delivery Network), and big data and artificial intelligence platforms, but it is not limited to these.

[0054] Terminal device 10 and server 20 can communicate with each other via a network. This network can be a wired network or a wireless network.

[0055] The method provided in this application embodiment can be executed by a computer device in each step. The computer device can be any electronic device capable of data storage and processing. For example, the computer device can be... Figure 1 Server 20 in the middle can be Figure 1 The terminal device 10 can also be another device other than the terminal device 10 and the server 20.

[0056] Please refer to Figure 2 The diagram illustrates an application scenario of the vulnerability discovery method for an application provided in one embodiment of this application.

[0057] like Figure 2 As shown, in the real hardware environment 200, the application process is represented as 210. In the figure, t0, t1, t2, and tn represent the times when the application's state data is saved.

[0058] The snapshot-based fuzzing scheme in related technologies requires first running the fuzzed process on a Hyper-V virtual machine, then using dual-machine debugging technology to set breakpoints at the fuzzed points. When a breakpoint is triggered, a debugger script saves a snapshot of the entire operating system state and the state of the fuzzed process at the time of the breakpoint. After the state snapshot is created, simulation execution technology is used to simulate the execution of the fuzzed logic based on the snapshot state, thus realizing the snapshot-based fuzzing scheme. In the aforementioned related technologies, the snapshot-based fuzzing scheme using a virtual machine includes process state information and system state information. This scheme is highly dependent on the virtual machine and requires specific tools to parse the information according to a specific format. That is, this scheme can only run on a virtual machine and cannot run in a real hardware environment.

[0059] Taking a game application as an example, game applications usually come with game protection schemes. Anti-virtual machine and anti-debugger technologies are standard game protection schemes. This means that when an application has a game protection scheme, it cannot be run on a virtual machine, and therefore the aforementioned snapshot-based fuzzing scheme cannot be used. This renders the relevant technologies unusable in protected game applications.

[0060] This application performs fuzz testing on the application in a real hardware environment, such as... Figure 2The actual hardware environment 200 shown can be the aforementioned computer devices, including mobile phones, tablets, smart voice interaction devices, game consoles, wearable devices, multimedia playback devices, PCs, in-vehicle terminals, smart home appliances, and other electronic devices. In some embodiments, a tablet is used as an example of the actual hardware environment 200. First, the application is run completely once on the actual hardware environment 200. While acquiring the basic test data sent to the tablet by the server each time, a snapshot of the application's state information within the tablet is taken. Therefore, when the entire application is run, multiple snapshots can be obtained corresponding to multiple sets of basic test data. For example, such as... Figure 2 As shown, snapshot information is obtained by recording the application's state information at times t0, t1, t2, and tn. In some embodiments, the basic test data includes health, attack power, mana, location information, etc., and this application does not limit this.

[0061] Specifically, during testing, the first step is to determine the location of the application to be tested, specifically which part of the application's processing logic corresponds to the basic test data. Generally, different input basic test data correspond to different processing logics. For example, for health values, the application's processing logic is addition and subtraction. For attack values, the application's processing logic is multiplication. Therefore, after determining the processing logic to be tested, the application is modified based on the original basic test data corresponding to that logic; that is, the input basic test data is changed. A snapshot is then taken to restore the application to the running state corresponding to that basic test data, and the thread is restarted. Whether the application runs normally is then used to determine if there is a vulnerability in the application's processing logic.

[0062] The technical solution provided in this application adopts a fuzzing scheme based on a real hardware environment, avoiding reliance on virtual machine technology and debugger technology, thereby improving the applicability and testing efficiency of the fuzzing-based vulnerability discovery method. Simultaneously, before each test, a memory snapshot restoration technique is used to restore the running state of the process being fuzzed to its initial state, avoiding interference between results from multiple fuzzing tests and improving the accuracy of the test results.

[0063] Please refer to Figure 3 The diagram illustrates a flowchart of a vulnerability discovery method for an application provided in one embodiment of this application. The entity executing each step of this method may be... Figure 1 The terminal device 10 or server 20 in the implementation environment of the illustrated scheme. In the following method embodiments, for ease of description, only the execution subject of each step is described as a "computer device". The method may include at least one of the following steps (320-380):

[0064] Step 320: Mutate the first basic test data of the application to obtain the first mutated test data.

[0065] An application is a computer program designed to perform one or more specific tasks. It runs in user mode, interacts with the user, and has a visual user interface. Each application runs in an independent process and has its own independent address space. The boundary between different applications is called a process boundary. In some embodiments, an application can refer to a single executable file or a single program, such as Word or Photoshop. In some embodiments, an application is a game application. Game applications are characterized by being difficult to restart; that is, when testing for vulnerabilities in a game, restarting the game client program is necessary if testing is to begin from scratch. Restarting the game client program requires first starting the game platform program, then the platform program starts the game login process, and after successful login, the login process starts the game lobby process. Only when the lobby process restarts the game will the game match process be started. This is a very lengthy process that requires manual intervention (e.g., clicking the login button). In related technologies, vulnerability mining for game applications typically requires restarting the game process every time basic test data is constructed, which is not user-friendly for testers. In other embodiments, the application is a file parsing application (Office), an open-source license application (HTTP), or a harness program, etc. These types of applications have shorter process times compared to game applications, making it easy to start the process and move it to the desired testing location, regardless of which node is being tested. This application does not limit the type of application; it can be an application with the characteristic of being easy to start or an application with the characteristic of being difficult to start.

[0066] The first set of basic test data can be considered as data provided by other devices / servers / clients to the computer device / client where the application resides, and then passed to the application for processing. The application uses specific logic to process this basic test data. Taking a game application as an example, during a game match, a large amount of game data is generated. For instance, virtual object A attacks virtual object B. Virtual object A has an attack value, and its mana bar decreases. Correspondingly, virtual object B's health decreases. Virtual object A and virtual object B belong to different game factions. Virtual object A is controlled by a first client, and virtual object B is controlled by a second client. The first client runs on a first terminal device, and the second client runs on a second terminal device. When the first user uses the first terminal device to control virtual object A to attack virtual object B, the first client sends virtual object A's attack value, virtual object A's mana bar decrease value, and virtual object B's health decrease value to the server. After receiving the values, the server sends the three values ​​to the second client, which then processes them. At this point, the three values—the attack value of virtual object A, the decrease in the mana bar of virtual object A, and the decrease in the health of virtual object B—can all be considered as basic test data. They can also be considered as input data during normal application operation; this application does not impose any limitations on this. This application does not limit the type of basic test data; it can be specific numerical values ​​or text, etc. The first set of basic test data is one or more sets of basic test data.

[0067] First variant test data: This is derived from the first base test data. The mutation does not deviate from the data type itself. For example, if the original base test data is numerical, then the mutated first variant data should also be numerical. For instance, if the base test data is a health decrease of 200, the mutated first variant data should also reflect the health decrease / increase. Therefore, the first variant data should also be numerical and cannot mutate from numerical to text.

[0068] Step 340: Based on the first snapshot information of the application, restore the application to the first running state. The first snapshot information records the state data of the first running state that the application was in before processing the first basic test data.

[0069] First snapshot information: A snapshot information corresponding to the first basic test data. In some embodiments, after the computer device receives the first basic test data, but before processing the first basic test data, a snapshot of the current application's running state is taken and recorded to obtain the first snapshot information. The first snapshot information records the state data of the application's first running state. This application does not limit the type of state data; correspondingly, the state data can be at least one or more of variables, constants, etc.

[0070] First running state: The state that can be recovered from the first snapshot information, corresponding to the first snapshot information. In some embodiments, taking a game application as an example, the application has already reached the game lobby process and received the message "Hello xxxxx" from user 11 in the lobby's general channel. The next message is "Goodbye xxx" from user 22. At this time, both "Hello xxxxx" from user 11 and "Goodbye xxx" from user 22 can be considered as basic test data (input data). Before processing the second set of input data—"Goodbye xxx" from user 22—the application has already processed the first set of input data—"Hello xxxxx" from user 11, and saves the running state at this time. The running state at this time can be that "Hello xxxxx" from user 11 is displayed in the lobby of the client where the current application is located. The first running state can be that "Hello xxxxx" from user 11 is displayed, but "Goodbye xxx" from user 22 is not displayed. In other embodiments, the first running state can be teaming up in a virtual room; that is, the first basic test data can be the data of the matched opponents. Before being matched with opponents, the application is in the running state of teaming up in a virtual room. The first snapshot information records the current state data of teaming up in a virtual room.

[0071] Based on the first snapshot information, the application can be restored to its first running state, that is, the state before the first basic test data was processed.

[0072] Step 360: After the application is restored to the first running state, the first mutation test data is processed by the application in a real hardware environment to obtain the first running result.

[0073] Real hardware environment: As explained above, the real hardware environment can be considered as the environment in which an application actually operates. For example, when running the application "Honor of Kings" on a mobile phone, the mobile phone can be considered the real hardware environment of that application. When running "Peacekeeper Elite" on a computer, the computer can be considered the real hardware environment of that application. Optionally, the real hardware environment includes hardware such as processors, registers, and memory. This application does not limit the specific hardware architecture. In the embodiments of this application, the real hardware environment is the real computer system relative to the virtual computer system where the virtual machine resides. This application does not limit the specific type of real hardware environment.

[0074] First execution result: The result of the application running based on the first mutation test data as input data. The execution result can be at least one of normal operation and abnormal operation. Normal operation means that the application can fully utilize its own processing logic to process the first mutation data, unaffected by the mutation test data. Abnormal operation means that the application cannot use its own processing logic to process the first mutation data, resulting in an abnormal crash of the application, such as screen delay, screen disappearance, etc. This application does not limit the specific execution result.

[0075] Optionally, the application is restored to its running state before processing the first basic test data, and the first mutated test data is given to the application for processing to obtain the running result based on the application's response to the first mutated test data. In some embodiments, the first basic test data is that the health of virtual object a decreases by 100. Before processing this first basic test data, the health of virtual object a is 2000, so the health of virtual object a in the restored first running state is 2000. By mutating the first basic test data—the health decrease of virtual object a being 100—optionally, the first mutated test data is that the health decrease of virtual object a is 30000. Then, the health of virtual object a in the first running state is only 2000. When the health decreases to 30000, the application processes this data, i.e., performs addition and subtraction operations, resulting in a health value of -28000 for virtual object a. The application is likely to crash. The first running result may be an abnormal running result.

[0076] Step 380: Based on the first running result, determine the vulnerability discovery results of the application.

[0077] Vulnerability discovery results: Results used to characterize application vulnerabilities. These results can indicate the presence or absence of vulnerabilities, the specific type of vulnerability, etc. This application does not limit the specific format.

[0078] In some embodiments, step 380 includes steps 380-1 to 380-2.

[0079] In some embodiments, the application includes multiple processing logics, and the application uses a first processing logic among the multiple processing logics to process the first basic test data or the first variant test data.

[0080] The processing logic has been discussed in the examples above. In short, the application will use different processing methods depending on the input data. For numerical data, the processing logic may involve mathematical operations such as addition, subtraction, multiplication, division, integration, and differentiation. For non-numerical data, the processing logic may involve merging or deleting data. In some embodiments, for game applications, for example, when a user sends text messages to teammates in a chat channel during a game, this text is the input data for the client receiving it. The client needs to process this text information using the application, such as adding it to the display area of ​​the interactive interface. Generally speaking, the specific actions taken by the application to process this input data can be called the processing logic.

[0081] Step 380-1: If the first running result is normal operation, determine that the vulnerability discovery results of the application include that the first processing logic does not have any vulnerabilities.

[0082] In some embodiments, the first basic test data is the decrease in the health of a virtual object. The corresponding first processing logic is to subtract the original health value, and the minimum display result is 0, meaning that even if the calculated result is less than 0, 0 is still displayed. Therefore, based on the first mutation test data, even if the health value calculated by subtraction is much less than 0, according to the processing of the first processing logic, the final displayed health value is 0. At this time, the application runs normally and will not trigger a crash. Therefore, the first running result can be considered as normal operation, and the first processing logic corresponding to the first basic test data does not have any vulnerabilities.

[0083] Step 380-2: If the first running result is abnormal, determine that the vulnerability discovery results of the application include a vulnerability in the first processing logic.

[0084] In some embodiments, the first basic test data is text sent by the user in the chat channel. The corresponding processing logic is to display all text completely, without limiting the number of characters. For example, if the original first basic test data contains 15 characters, and the mutated first test data contains 200 characters, the first processing logic requires displaying all text completely, meaning 200 characters need to be displayed in a very small window. This could easily lead to screen lag or incomplete display. In this case, the first running result can be considered abnormal, and correspondingly, the first processing logic for displaying all text as the first basic test data is considered flawed. With a large number of characters, this could easily lead to incomplete display. Therefore, after identifying the flaw in the first processing logic, it can be adjusted, for example, by changing it to "display all text completely when the number of characters is less than 20, and only display the first 20 characters when the number of characters is greater than 20."

[0085] By categorizing runtime results into abnormal and normal scenarios, the system refines the outcome and determines the vulnerability findings for different applications based on these varying results. Furthermore, by linking processing logic to input data, vulnerabilities can be identified by altering the input data. This allows for further refinement of vulnerability discovery targets, enabling more targeted and efficient vulnerability detection.

[0086] The technical solution provided in this application, on the one hand, involves modifying the basic test data of an application in a real hardware environment, restoring the application to its running state before processing the basic test data based on snapshot information, and then using the restored application to process the modified test data to obtain the running results. The vulnerability discovery results of the application are then determined based on these results. By running the application in a real hardware environment, the problem of being unable to perform vulnerability discovery due to application-borne protection schemes can be avoided, thereby expanding the application scenarios of vulnerability discovery.

[0087] On the other hand, by using snapshot information to track the application's running state, vulnerabilities can be discovered starting from that state and by modifying the basic test data. This effectively reduces the time required for vulnerability discovery testing, avoids potential manual costs, speeds up the application testing process, and improves the efficiency of application vulnerability discovery.

[0088] Please refer to Figure 4 This illustrates a flowchart of a vulnerability discovery method for an application provided in another embodiment of this application. The entity executing each step of this method may be... Figure 1 The terminal device 10 or server 20 in the implementation environment of the illustrated scheme. In the following method embodiments, for ease of description, only the execution subject of each step is described as a "computer device". The method may include at least one of the following steps (320-390):

[0089] Step 320: Mutate the first basic test data of the application to obtain the first mutated test data.

[0090] Step 340: Based on the first snapshot information of the application, restore the application to the first running state. The first snapshot information records the state data of the first running state that the application was in before processing the first basic test data.

[0091] Step 360: After the application is restored to the first running state, the first mutation test data is processed by the application in a real hardware environment to obtain the first running result.

[0092] Step 380: Based on the first running result, determine the vulnerability discovery results of the application.

[0093] Step 390: The application has multiple different snapshot information. The different snapshot information records the state data of the application's running state before processing the basic test data of different protocol types. According to the priority relationship of different protocol types, the first snapshot information is selected from multiple different snapshot information. The priority relationship is related to the number of basic test data belonging to the protocol type.

[0094] When a computer device runs an application, taking a game application as an example, different processing logic applies to data of different protocol types during a game. For instance, during a game, the health value may change many times, resulting in hundreds of health value input data entries. Generally, the application processes health value input data in the same way, such as performing addition and subtraction operations. Therefore, basic test data of the same protocol type is only recorded briefly, saving a snapshot.

[0095] Specifically, after a match begins, when the health bar changes for the first time, the client receives the health decrease data sent by the server. The client then determines whether this input data belongs to a new protocol type—a data type that hasn't been snapshotted before. Because it's the first health change, the client considers this input data a new protocol type, thus requiring a snapshot of the current application's running state. After capturing this snapshot, the client processes the health decrease data through the application. Subsequent times health decrease data is received, since the running state has already been captured for the same protocol type, it's unnecessary to capture another snapshot. In other words, each time new protocol type input data is received, the current application's running state is captured and saved; if the input data is determined not to belong to a new protocol type, the application's running state is not captured again. Input data is only processed after a snapshot of the same protocol type has been captured or already stored. Therefore, after running the application once completely, multiple snapshots of basic test data corresponding to various protocol types can be obtained. This snapshot information reflects the running state of the application before the basic test data was processed.

[0096] In related technologies, taking game applications as an example, games typically have server-side protocol verification. This means that if the server detects an anomaly during testing, it will disconnect the network connection between the game client and the server. Once the network connection is lost, if the protocol needs to be reconstructed for simulation testing, the game client program needs to be restarted. Since the game applications described above are not easily restarted, this application introduces a snapshot restoration method for vulnerability discovery simulation testing. During the entire operation of the game application, the entire game process is only restarted once, and multiple snapshots are recorded, avoiding potential network connection drops. In subsequent tests, the running state only needs to be restored based on the snapshot information, and vulnerability discovery is performed by modifying the test data, without needing to interact with the server again.

[0097] In some embodiments, the game client and server communicate via protocols. A single game may involve numerous game protocols, each corresponding to different processing logic within the game. These protocols coordinate their states through global variables and other methods. When the server program receives and processes a protocol, the processing may affect the values ​​of the program's global variables. If the processing logic of a subsequent protocol depends on the global variables affected by a previous protocol, then the previous protocol will influence the processing result of the subsequent protocol. To avoid mutual interference between the results of multiple protocol processing, all global variable data that might affect the program's execution logic should be saved before testing. Before each test, the program's global variable data should be restored to its pre-test state based on a snapshot file, thus avoiding interference between results from multiple tests. Normally, each different game protocol corresponds to different logic within the game, while the processing logic of the same protocol is largely consistent. Therefore, snapshots can be saved according to protocol categories, and a new snapshot state should be saved each time a new protocol is received. This ensures that the snapshots are as representative as possible without creating too many snapshots to implement.

[0098] In some embodiments, after obtaining multiple snapshots, users can choose which processing logic to test. Alternatively, they can choose not to select any and test each processing logic individually, starting with the first snapshot, to check for vulnerabilities. If no selection is made and all processing logic is tested, the final vulnerability discovery results will be more comprehensive and accurate. However, if users choose to select specific processing logic, they can perform targeted testing, obtain vulnerability discovery results faster, save vulnerability discovery time, and reduce processing costs.

[0099] Taking autonomous selection as an example, it can include two types: manual participation and no manual participation. Manual participation means that testers manually select the processing logic they want to test and restore the corresponding snapshot to its running state. No manual participation means that the computer equipment determines the processing logic to be tested entirely. That is, based on the priority relationship of different protocol types, the first snapshot information is selected from multiple different snapshot information; where the priority relationship is related to the amount of basic test data belonging to the protocol type. This priority relationship can be considered as the testing order of the processing logic by the computer equipment.

[0100] Optionally, priority can be determined by determining the order of the number of basic test data belonging to each protocol type in descending order. Specifically, for game applications, there are multiple protocol types, such as health, location information, text information, and mana. For health, there are 200 input data points; for location information, there are 2000; for mana, there are 100, and so on. It can be observed that the number of basic test data points for the location information protocol type is the largest, reaching 2000. This can be considered as the processing logic corresponding to location information being continuously processed during application operation, used at least 2000 times. Because this processing logic is far more likely to be used than other processing logics, any vulnerabilities in it are more easily exploited. Therefore, this processing logic should be tested first. A snapshot of this processing logic exists; after restoring the application to the running state corresponding to this snapshot, the processing logic can be tested using mutation test data. The computer device autonomously determines the priority based on the number of basic test data points corresponding to each protocol type.

[0101] Optionally, priority can be determined based on the protocol type of the basic test data. Specifically, if a tester considers health values ​​to be important, then the protocol type for health values ​​will be pre-set to have the highest priority. Optionally, priority can also be determined based on the size of the basic test data. For example, if the size of the basic test data for a certain protocol type is 100 MB, then the data size of this basic test data is considered large, and the protocol type corresponding to this basic test data will be given a higher priority.

[0102] In some embodiments, the snapshot information includes: memory snapshot information and register snapshot information; the memory snapshot information is obtained by recording data stored in the memory of the actual hardware environment during the execution of the application. Optionally, the memory snapshot information includes all variable data in memory, including variable data in the data segment, code segment, and stack space.

[0103] Register snapshot information is obtained by recording data stored in registers of the actual hardware environment during application execution; this state data includes data stored in memory and data stored in registers. For example, suppose there are 10 input data points, but only two registers. At time t0, the values ​​stored in the two registers are the first and second input data points, respectively. At time t1, the values ​​stored in the two registers are the third and fourth input data points, respectively. At time t2, the values ​​stored in the two registers are the fifth and sixth input data points, respectively. If a snapshot of the application's running state is taken at time t0 to obtain the first running state, then the first and second input data points can be considered the register snapshot information corresponding to the first running state. Similarly, if a snapshot of the application's running state is taken at time t1 to obtain the second running state, then the third and fourth input data points can be considered the register snapshot information corresponding to the second running state. Therefore, to restore the first running state, in addition to restoring the values ​​of variables in the application based on the memory snapshot information, it is also necessary to restore the data in the registers.

[0104] In this embodiment, runtime data of the application's running state is saved, i.e., snapshot information is saved. Unlike the method of saving virtual machine snapshots in related technologies, the snapshot information in this embodiment includes memory snapshot information and register snapshot information. Relatively speaking, the snapshots in this application are easier to obtain and have fewer dependencies compared to virtual machine snapshots. Virtual machine snapshots, in addition to saving memory snapshot information, also save system state information, making them more dependent on the virtual machine and relatively complex to parse. In some embodiments, the snapshot information in this application does not include system state information; that is, this application does not consider potential system vulnerabilities but focuses on the vulnerabilities of the application itself. The reason for not focusing on system vulnerabilities is that for applications such as game applications, which are less affected by system state, the running state of the system can be disregarded. Even if the system may have a small impact on the application, this impact can be reduced through simple processing. Therefore, the technical solution provided by this embodiment can be applied to real hardware environments, taking snapshots of the application's own state data, simplifying data processing operations and the entire vulnerability discovery process.

[0105] Furthermore, the technical solution provided in this application can determine the processing logic to be tested based on the priority of the protocol type, thereby determining the snapshot information that needs to be restored. Therefore, it can closely align with the application itself and determine the testing processing logic based on the actual input data, resulting in more accurate vulnerability discovery results and better meeting actual needs.

[0106] Please refer to Figure 5This illustrates a flowchart of a vulnerability discovery method for an application provided in another embodiment of this application. The entity executing each step of this method may be... Figure 1 The terminal device 10 or server 20 in the implementation environment of the illustrated scheme. In the following method embodiments, for ease of description, only the execution subject of each step is described as a "computer device". The method may include at least one of the following steps (320-394):

[0107] Step 320: Mutate the first basic test data of the application to obtain the first mutated test data.

[0108] Step 340: Based on the first snapshot information of the application, restore the application to the first running state. The first snapshot information records the state data of the first running state that the application was in before processing the first basic test data.

[0109] Step 360: After the application is restored to the first running state, the first mutation test data is processed by the application in a real hardware environment to obtain the first running result.

[0110] Step 380: Based on the first running result, determine the vulnerability discovery results of the application.

[0111] Step 391: If the first running result is abnormal, the first basic test data is mutated according to the second mutation strategy to obtain the second mutated test data; wherein, the second mutation strategy is different from the first mutation strategy used to obtain the first mutated test data.

[0112] In this embodiment, the number of tests for vulnerability discovery in the application is not limited. Generally, if the processing result of the first mutation test data obtained from the first basic test data based on the first mutation strategy is normal operation, it indicates that the input data has little impact on the application's processing logic. Therefore, the testing of this processing logic should be relatively less, and the number of tests can be reduced accordingly. Conversely, if the processing result of the first mutation test data obtained from the first basic test data based on the first mutation strategy is abnormal operation, it indicates that the input data has a significant impact on the application's processing logic. Therefore, the testing of this processing logic should be relatively more extensive, and the number of tests should be increased.

[0113] In some embodiments, the first mutation strategy is used to determine the boundary values ​​of the first basic test data as the first mutated test data.

[0114] Optionally, the first basic test data is the health value. Generally, the health value should be in the range of 0 to 10000. Therefore, during testing, according to the first mutation strategy, the first basic test data can be mutated to the boundary value 0 or the boundary value 10000. The first mutated test data is then processed to obtain the first running result.

[0115] In some embodiments, a second mutation strategy is used to determine the non-boundary values ​​of the first basic test data as the second mutation test data.

[0116] Optionally, if the first test result is abnormal when the first mutation test data is 10000, then the number of tests needs to be increased accordingly. For example, non-boundary values ​​within the blood volume range, such as 9000, 8000, etc., can be selected to test the processing logic multiple times. This application does not limit the specific interval or size of the values, as long as they are non-boundary values.

[0117] Step 392: Based on the first snapshot information, restore the application to the first running state.

[0118] Refer to step 340 here; details will not be repeated here.

[0119] Step 393: After the application is restored to the first running state, the second mutation test data is processed by the application in a real hardware environment to obtain the second running result.

[0120] Refer to step 360 here; details will not be repeated here.

[0121] Step 394: Update the vulnerability discovery results of the application based on the second running results.

[0122] Refer to step 380 here; details will not be repeated here.

[0123] The technical solution provided in this application uses a first mutation strategy and a second mutation strategy to mutate the first basic test data. When the running result obtained using the first mutation strategy is abnormal, if the basic test data has a significant impact on the processing logic, the basic test data is mutated again using the second mutation strategy. Through multiple tests, the vulnerabilities in the application's processing logic of the basic test data can be determined, making the identification of vulnerabilities more accurate. Furthermore, using the first mutation strategy to determine the boundary values ​​of the first basic test data as the first mutated test data, directly mutating the first basic test data into boundary values, can significantly shorten the testing time. That is, when the boundary values ​​can be used by the application to run normally, the first basic test data can be considered to have little impact on the processing logic, thereby reducing the number of tests. While reducing the testing time for the processing logic, multiple tests can be performed on processing logic that may have vulnerabilities, balancing accuracy and efficiency.

[0124] Please refer to Figure 6 This diagram illustrates a block diagram of a snapshot information saving method provided in one embodiment of this application. The execution entity for each step of this method can be... Figure 1 The terminal device 10 or server 20 in the implementation environment of the illustrated scheme. In the following method embodiments, for ease of description, only the execution subject of each step is described as a "computer device". The method may include at least one of the following steps (S1 to S4):

[0125] S1. Input data received.

[0126] The computer equipment receives new input data (basic test data).

[0127] S2. Determine if it is a new protocol.

[0128] Determine whether the received input data belongs to the new protocol type. If yes, proceed to step S3; otherwise, proceed to step S4.

[0129] S3. Save a snapshot.

[0130] Save the current running state of the application.

[0131] S4. Process input data.

[0132] Process the input data.

[0133] Please refer to Figure 7 The diagram illustrates a block diagram of a vulnerability testing method provided in one embodiment of this application. The execution entity for each step of this method can be... Figure 1The terminal device 10 or server 20 is used in the implementation environment of the scheme shown. In the following method embodiments, for ease of description, only the execution subject of each step is described as a "computer device". The method may include at least one of the following steps (P1 to P10):

[0134] P1. Obtain basic test data.

[0135] Basic test data is generated by storing the normal game protocol in the packet receiving function, and all mutation test data is generated by mutation based on the normal game protocol.

[0136] P2. Variation of test data based on basic test data.

[0137] The initial mutation strategy (first mutation strategy) is derived from empirical values, such as data boundary values, like byte boundary values ​​00, 7F, 80, FF, etc. The later mutation strategy (second mutation strategy) is dynamically adjusted based on the initial test results. If the initial test results (first run results) prove that the field has little impact on the test results, then the testing of that field can be simplified, saving a significant amount of time. If the initial test results prove that the field has a significant impact on the test results, then the testing of that field can be more comprehensive, increasing the probability of discovering problems.

[0138] P3. Pause the execution of the test thread.

[0139] Before formal testing, the execution of the threads of the application under test should be paused to avoid unexpected events during the testing process.

[0140] P4. Restore memory snapshot information.

[0141] Generally, the code segment and read-only data segment do not need to be processed, as this part of the memory will not be changed during normal program operation. However, the writable data segment, stack space, and heap space are affected with each test, and this part of the memory needs to be restored. They appear in the form of writable memory. Therefore, restoring memory snapshot information means restoring this writable memory to the memory state at the time the snapshot was captured.

[0142] P5. Restore register snapshot information.

[0143] The factors affecting program execution logic include three parts: code, data, and register state. The code remains unchanged throughout the test, while the data is restored using memory snapshots. To ensure accurate test results, the register state must be completely consistent before each test.

[0144] P6. Resume test thread execution.

[0145] Once the code, data, and register states have been restored to the snapshot state, the execution of the thread under test can be resumed. A key point to note in this step is that to ensure correct thread execution, the thread resumption operation needs to be performed twice. The thread pause operation is executed twice during the entire process, therefore, thread execution needs to be resumed accordingly.

[0146] P7. Obtain the test results.

[0147] Test execution results generally fall into two categories: 1. If the test runs normally without triggering any unexpected situations, the test results are obtained by hijacking the function return address. 2. If an abnormal crash (abnormal execution) is triggered during the test, the test results are obtained by hijacking the system's exception handling function.

[0148] P8. Adjust mutation strategy.

[0149] In addition to the two scenarios of normal execution and exception triggering, the test results also include more information, such as whether the test triggered new code logic compared to previous tests. Based on the code execution (running status) of the two tests, the magnitude of the field's impact on the test results can be determined, allowing for adjustments to the protocol mutation strategy. Fields with significant impact should undergo more comprehensive testing, while fields with less noticeable impact can be tested less or not at all.

[0150] P9. Pause the execution of the test thread.

[0151] Once the test is complete, the execution of the thread under test can be paused, and execution can be resumed during the next test.

[0152] P10. Test Result Feedback.

[0153] Record meaningful test results (run results) for later verification and further utilization. For example, if the run result is abnormal, it means that the application's processing logic cannot handle the mutated data, and the mutated data can be used again to test the application.

[0154] The technical solution provided in this application significantly reduces time and labor costs. Regarding time, the time between multiple tests is reduced from several minutes to less than one second. Without the technical solution provided in this application, sending an illegal protocol during testing would interrupt the network connection between the client and server. To continue testing, the game process needs to be restarted, a complex process involving first restarting the game platform program, then the game login program, and finally the game process itself, potentially taking several minutes. Regarding labor costs, without the technical solution provided in this application, manual intervention is required during the game process restart, making automated testing impossible. With the technical solution provided in this application, no manual intervention is needed, allowing the entire vulnerability discovery process to be fully automated.

[0155] The following are embodiments of the apparatus described in this application, which can be used to execute the embodiments of the method described in this application. For details not disclosed in the apparatus embodiments of this application, please refer to the embodiments of the method described in this application.

[0156] Please refer to Figure 8 This diagram illustrates a block diagram of a vulnerability discovery apparatus for an application provided in one embodiment of this application. The apparatus has the functionality to implement the method example described above; this functionality can be implemented in hardware or by hardware executing corresponding software. The apparatus can be the computer device described above, or it can be installed within a computer device. Figure 8 As shown, the device 1400 may include: a data mutation module 1410, a state recovery module 1420, a data processing module 1430, and a result determination module 1440.

[0157] The data mutation module 1410 is used to mutate the first basic test data of the application to obtain the first mutated test data.

[0158] The state recovery module 1420 is used to restore the application to a first running state based on the first snapshot information of the application. The first snapshot information records the state data of the first running state that the application was in before processing the first basic test data.

[0159] The data processing module 1430 is used to process the first mutation test data through the application in a real hardware environment after the application is restored to the first running state, and obtain the first running result.

[0160] The result determination module 1440 is used to determine the vulnerability discovery results of the application based on the first running result.

[0161] In some embodiments, the application has multiple different snapshots, which record state data of the application's running state before processing basic test data of different protocol types.

[0162] In some embodiments, such as Figure 9 As shown, the device also includes an information selection module 1450.

[0163] The information selection module 1450 is used to select the first snapshot information from the plurality of different snapshot information according to the priority relationship of the different protocol types; wherein, the priority relationship is related to the amount of basic test data belonging to the protocol type.

[0164] In some embodiments, the snapshot information includes: memory snapshot information and register snapshot information; the memory snapshot information is obtained by recording data stored in the memory of the real hardware environment during the operation of the application; the register snapshot information is obtained by recording data stored in the registers of the real hardware environment during the operation of the application; wherein, the status data includes the data stored in the memory and the data stored in the registers.

[0165] In some embodiments, the application includes multiple processing logics, and the application uses a first processing logic among the multiple processing logics to process the first basic test data or the first variant test data.

[0166] In some embodiments, the result determination module 1440 is configured to determine, when the first running result is normal operation, that the vulnerability discovery result of the application includes the absence of vulnerabilities in the first processing logic.

[0167] The result determination module 1440 is used to determine, when the first running result is abnormal running, that the vulnerability mining result of the application includes the existence of a vulnerability in the first processing logic.

[0168] In some embodiments, the data mutation module 1410 is further configured to mutate the first basic test data according to a second mutation strategy to obtain second mutated test data when the first running result is abnormal. The second mutation strategy is different from the first mutation strategy used to obtain the first mutated test data.

[0169] The state recovery module 1420 is further configured to restore the application to the first running state based on the first snapshot information.

[0170] The data processing module 1430 is further configured to process the second mutation test data through the application in the real hardware environment after the application is restored to the first running state, and obtain the second running result.

[0171] The result determination module 1440 is further configured to update the vulnerability discovery results of the application based on the second running result.

[0172] In some embodiments, the first mutation strategy is used to determine the boundary values ​​of the first basic test data as the first mutated test data; the second mutation strategy is used to determine the non-boundary values ​​of the first basic test data as the second mutated test data.

[0173] It should be noted that the apparatus provided in the above embodiments is only illustrated by the division of the above functional modules when implementing its functions. 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. In addition, the apparatus and method embodiments provided in the above embodiments belong to the same concept, and the specific implementation process can be found in the method embodiments, which will not be repeated here.

[0174] Figure 10 A structural block diagram of a computer device provided in an exemplary embodiment of this application is shown.

[0175] Typically, computer device 1500 includes a processor 1501 and a memory 1502.

[0176] Processor 1501 may include one or more processing cores, such as a 4-core processor, a 15-core processor, etc. Processor 1501 may be implemented using at least one hardware form selected from DSP (Digital Signal Processing), FPGA (Field Programmable Gate Array), and PLA (Programmable Logic Array). Processor 1501 may also include a main processor and a coprocessor. The main processor, also known as a CPU (Central Processing Unit), is used to process data in the wake-up state; the coprocessor is a low-power processor used to process data in the standby state. In some embodiments, processor 1501 may integrate a GPU (Graphics Processing Unit), which is responsible for rendering and drawing the content required to be displayed on the screen. In some embodiments, processor 1501 may also include an AI (Artificial Intelligence) processor, which is used to handle computational operations related to machine learning.

[0177] Memory 1502 may include one or more computer-readable storage media, which may be tangible and non-transitory. Memory 1502 may also include high-speed random access memory and non-volatile memory, such as one or more disk storage devices or flash memory devices. In some embodiments, the non-transitory computer-readable storage media in memory 1502 stores a computer program that is loaded and executed by processor 1501 to implement the glue defect determination method provided in the above-described method embodiments.

[0178] Those skilled in the art will understand that Figure 10 The structure shown does not constitute a limitation on the computer device 1500, and may include more or fewer components than shown, or combine certain components, or use different component arrangements.

[0179] In an exemplary embodiment, a computer-readable storage medium is also provided, wherein a computer program is stored therein, which, when executed by a processor, implements a vulnerability discovery method for an application.

[0180] Optionally, the computer-readable storage medium may include: ROM (Read-Only Memory), RAM (Random Access Memory), SSD (Solid State Drives), or optical disc, etc. The random access memory may include ReRAM (Resistance Random Access Memory) and DRAM (Dynamic Random Access Memory).

[0181] In an exemplary embodiment, a computer program product is also provided, the computer program product including a computer program stored in a computer-readable storage medium. A processor of a computer device reads the computer program from the computer-readable storage medium, and the processor executes the computer program, causing the computer device to perform the vulnerability discovery method of the application described above.

[0182] It should be understood that "multiple" as used herein refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. Furthermore, the step numbers described herein are merely illustrative of one possible execution order. In some other embodiments, the steps may not be executed in numerical order, such as two steps with different numbers being executed simultaneously, or two steps with different numbers being executed in the reverse order of the illustration. This application does not limit this.

[0183] The above description is merely an exemplary embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A method for vulnerability discovery in an application, characterized in that, The application is an application with an anti-virtual machine protection scheme, and the method includes: The first basic test data of the application is mutated to obtain the first mutated test data. The application has multiple different snapshot information, and the different snapshot information records the state data of the running state of the application before processing the basic test data of different protocol types. Based on the priority relationship of the different protocol types, a first snapshot information is selected from the plurality of different snapshot information; wherein, the priority relationship is related to the amount of basic test data belonging to the protocol type, and the first snapshot information is obtained by running the application in a real hardware environment and recording the application's state data before the application processes the first basic test data; Based on the first snapshot information, the application is restored to the first running state; After the application is restored to the first running state, in a real hardware environment, the application processes the first variant test data as input data to obtain the first running result. The application has different processing logic for different input data. The processing logic includes at least one of the following: merging data, deleting data, addition, subtraction, multiplication and division, integration and differentiation. Based on the first running result, the vulnerability discovery results of the application are determined.

2. The method according to claim 1, characterized in that, The snapshot information includes: memory snapshot information and register snapshot information; The memory snapshot information is obtained by recording data stored in the memory of the real hardware environment during the operation of the application. The register snapshot information is obtained by recording the data stored in the registers of the real hardware environment during the operation of the application. The status data includes the data stored in the memory and the data stored in the register.

3. The method according to claim 1, characterized in that, The application includes multiple processing logics, and the application uses a first processing logic among the multiple processing logics to process the first basic test data or the first variant test data. The step of determining the vulnerability discovery results of the application based on the first running result includes: If the first running result is normal operation, it is determined that the vulnerability discovery result of the application includes that the first processing logic does not have a vulnerability; If the first running result is abnormal, it is determined that the vulnerability discovery results of the application include the existence of a vulnerability in the first processing logic.

4. The method according to claim 1, characterized in that, After determining the vulnerability discovery results of the application based on the first running result, the method further includes: If the first running result is abnormal, the first basic test data is mutated according to the second mutation strategy to obtain the second mutated test data; wherein, the second mutation strategy is different from the first mutation strategy used to obtain the first mutated test data; Based on the first snapshot information, the application is restored to the first running state; After the application is restored to the first running state, in the real hardware environment, the second mutation test data is processed by the application to obtain the second running result; Based on the second running result, update the vulnerability discovery results of the application.

5. The method according to claim 4, characterized in that, The first mutation strategy is used to determine the boundary values ​​of the first basic test data as the first mutated test data; The second mutation strategy is used to determine the non-boundary values ​​of the first basic test data as the second mutation test data.

6. A vulnerability discovery device for an application, characterized in that, The application is an application with an anti-virtual machine protection scheme, and the device includes: The data mutation module is used to mutate the first basic test data of the application to obtain the first mutated test data. The application has multiple different snapshot information, and the different snapshot information records the state data of the running state of the application before processing the basic test data of different protocol types. The information selection module is used to select a first snapshot information from a plurality of different snapshot information according to the priority relationship of the different protocol types; wherein, the priority relationship is related to the amount of basic test data belonging to the protocol type, and the first snapshot information is obtained by running the application in a real hardware environment and recording the application's state data before the application processes the first basic test data; A state recovery module is used to restore the application to a first running state based on the first snapshot information; The data processing module is used to process the first variant test data, which is the input data, through the application in a real hardware environment after the application is restored to the first running state, to obtain the first running result. The application has different processing logic for different input data, and the processing logic includes at least one of the following: merging data, deleting data, addition, subtraction, multiplication and division, integration and differentiation. The result determination module is used to determine the vulnerability discovery results of the application based on the first running result.

7. A computer device, characterized in that, The computer device includes a processor and a memory, the memory storing a computer program that is loaded and executed by the processor to implement the method as described in any one of claims 1 to 5.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, which is loaded and executed by a processor to implement the method as described in any one of claims 1 to 5.

9. A computer program product, characterized in that, The computer program product includes a computer program that is loaded and executed by a processor to implement the method as described in any one of claims 1 to 5.

Images