A memory-based program source code testing method, device, equipment and medium

Abstract

The present application relates to the technical field of program testing, in particular to a program source code testing method and device based on memory, equipment and medium. The present application obtains dangerous memory sequence by analyzing memory operation, then inputs test case into program source code, and then starts to monitor memory consumed by program source code to complete control flow chart, function call chart and memory operation, and after program source code running ends, calculates code coverage, also monitors dangerous operation coverage. Finally, according to code coverage, memory consumption and dangerous operation coverage, the test case is updated until the program source code crashes, and the target test case is obtained. The present application not only monitors memory consumption, but also monitors code coverage and dangerous operation coverage, so that the present application can more comprehensively monitor whether the running of program source code meets the memory usage protocol, so as to more comprehensively test the memory security vulnerability types caused by running program source code.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of program testing, in particular to a memory-based program source code testing method, device, equipment and medium. BACKGROUND

[0002] Running program source code on a computer will have a certain impact on memory, which is characterized by memory security vulnerabilities. The prior art uses memory space fuzzing testing methods and memory timing fuzzing testing methods to test the types of memory security vulnerabilities caused by running program source code. Both of the above-mentioned fuzzing testing methods can only test part of the types of memory security vulnerabilities.

[0003] In summary, the types of memory security vulnerabilities tested by the program source code testing method in the prior art have limitations.

[0004] Therefore, the prior art still needs to be improved and improved. SUMMARY

[0005] To solve the above technical problems, the present application provides a memory-based program source code testing method, device, equipment and medium, which solves the problem that the types of memory security vulnerabilities tested by the program source code testing method in the prior art have limitations.

[0006] To achieve the above-mentioned purpose, the present application adopts the following technical solutions:

[0007] In a first aspect, the present application provides a memory-based program source code testing method, which comprises:

[0008] Extracting a control flow graph and a function call graph of the program source code, extracting memory operations required when running the program source code, and screening dangerous operation sequences related to memory vulnerabilities from all operation sequences involved in the memory operations;

[0009] Inputting a test case to the program source code, monitoring memory consumption, code coverage and dangerous operation coverage when the program source code after inputting the test case does not crash, wherein the memory consumption is the memory consumed by the program source code after inputting the test case when executing the control flow graph, the function call graph and the memory operations; the code coverage is used to represent the proportion of the code that has been run in the program source code, and the dangerous operation coverage is used to represent the degree to which the dangerous operation sequences are run;

[0010] According to the code coverage, the memory consumption and the dangerous operation coverage, updating the test case until the program source code crashes, obtaining a target test case, and the target test case is used to determine the type of memory security vulnerability of the program source code.

[0011] In an implementation, the filtering of dangerous operation sequences related to memory vulnerabilities from all operation sequences involved in the memory operations comprises:

[0012] determining a timing protocol rule violation in the memory vulnerabilities;

[0013] determining operation sequences constituted by the memory operations;

[0014] filtering dangerous operation sequences constituting the timing protocol rule violation from all the operation sequences.

[0015] In an implementation, the filtering of dangerous operation sequences constituting the timing protocol rule violation from all the operation sequences comprises:

[0016] determining a double free vulnerability or a use-after-free vulnerability in the timing protocol rule violation;

[0017] filtering dangerous operation sequences constituting the double free vulnerability or the use-after-free vulnerability from all the operation sequences.

[0018] In an implementation, the monitoring of memory consumption, code coverage, and dangerous operation coverage comprises:

[0019] instrumenting a monitoring program on the program source code;

[0020] monitoring the memory consumption, the code coverage, and the dangerous operation coverage by the monitoring program.

[0021] In an implementation, the monitoring of the memory consumption, the code coverage, and the dangerous operation coverage by the monitoring program comprises:

[0022] counting memory allocation operations and memory release operations corresponding to the control flow graph, the function call graph, and the memory operations;

[0023] monitoring, by the monitoring program, memory consumed by each of the memory allocation operations, denoted as allocation consumption;

[0024] monitoring, by the monitoring program, memory consumed by each of the memory release operations, denoted as release consumption;

[0025] obtaining memory consumption according to the allocation consumption and the release consumption;

[0026] obtaining, by the monitoring program, executed code from each code in the program source code;

[0027] determining a proportion of the code that has been executed, and taking the proportion as code coverage;

[0028] monitoring, by the monitoring program, positions at which the release operation and the allocation operation occur in the dangerous operation sequence, and filtering out the dangerous operation sequence that has been executed from the dangerous operation sequences according to the positions;

[0029] obtaining a dangerous operation coverage according to the number of the dangerous operation sequences and the number of the dangerous operation sequences that have been executed.

[0030] In an implementation manner, the updating the test case according to the code coverage, the memory consumption, and the dangerous operation coverage until the program source code crashes to obtain a target test case comprises:

[0031] determining a test mutation case of the test case when the code coverage changes, the memory consumption changes, or the dangerous operation coverage changes;

[0032] inputting the test mutation case into the program source code, and updating the test case until the program source code crashes to obtain a target test case when the program source code does not crash after the test mutation case is inputted.

[0033] In an implementation manner, the updating the test case according to the code coverage, the memory consumption, and the dangerous operation coverage until the program source code crashes to obtain a target test case further comprises:

[0034] when the program source code crashes after the test mutation case is inputted, taking the test mutation case as the target test case.

[0035] In a second aspect, an embodiment of the present application further provides a program source code testing device based on memory, wherein the device comprises the following components:

[0036] an information extraction module, configured to extract a control flow graph and a function call graph of a program source code, extract memory operations required when the program source code is run, and filter out dangerous operation sequences related to memory vulnerabilities from all operation sequences involved in the memory operations;

[0037] The monitoring module is used for inputting a test case into the program source code, and when the program source code after inputting the test case does not crash, monitoring memory consumption, code coverage and dangerous operation coverage, wherein the memory consumption is the memory consumed by the program source code after inputting the test case when executing the control flow graph, the function call graph and the memory operation; the code coverage is used for representing the proportion of the code that has been run in the program source code, and the dangerous operation coverage is used for representing the degree to which the dangerous operation sequence is run.

[0038] The updating module is used for updating the test case according to the code coverage, the memory consumption and the dangerous operation coverage until the program source code crashes, so as to obtain a target test case, and the target test case is used for determining the memory safety vulnerability type of the program source code.

[0039] In a third aspect, an embodiment of the present application further provides a terminal device, wherein the terminal device comprises a memory, a processor and a memory-based program source code testing program stored in the memory and executable on the processor, and the processor implements the steps of the memory-based program source code testing method when executing the memory-based program source code testing program.

[0040] In a fourth aspect, an embodiment of the present application further provides a computer readable storage medium, wherein the computer readable storage medium stores a memory-based program source code testing program, and the memory-based program source code testing program implements the steps of the memory-based program source code testing method when being executed by a processor.

[0041] Beneficial effects: The present application firstly analyzes the control flow graph, the function call graph and the memory operation contained in the program source code, and screens the dangerous operation sequence from the memory operation, then inputs the test case into the program source code, and then starts to monitor the memory consumed by the program source code for completing the control flow graph, the function call graph and the memory operation, and after the program source code is run, monitors the code that has been run in the program source code to obtain the code coverage, and also monitors the code that has been run in the dangerous operation sequence to obtain the dangerous operation coverage. Finally, the test case is updated according to the code coverage, the memory consumption and the dangerous operation coverage until the program source code crashes, so as to obtain the target test case, and the memory safety vulnerability type caused by running the program source code can be analyzed according to the target test case. From the above analysis, it can be known that the present application not only monitors the memory consumption but also monitors the code coverage and the dangerous operation coverage, so that the present application can more comprehensively monitor whether the running of the program source code satisfies the memory usage protocol, thereby more comprehensively testing the memory safety vulnerability type caused by running the program source code. BRIEF DESCRIPTION OF DRAWINGS

[0042] Figure 1 is a whole flow chart of the present application;

[0043] Figure 2 is a flow chart of static analysis and fuzz testing in an embodiment of the present application;

[0044] Figure 3 is a memory usage protocol chart in an embodiment of the present application;

[0045] Figure 4 is a structure chart of a memory-based program source code testing device provided by the present application;

[0046] Figure 5 is an internal structure principle block diagram of a terminal device provided by an embodiment of the present application. DETAILED DESCRIPTION

[0047] The technical solutions in the present application are described clearly and completely below in combination with embodiments and the accompanying drawings. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative labor fall within the scope of protection of the present application.

[0048] It is found through research that running program source code on a computer has certain influence on memory, which is characterized by memory security vulnerabilities. The prior art adopts memory space fuzz testing methods and memory timing fuzz testing methods to test memory security vulnerability types caused by running program source code. The above two kinds of fuzz testing methods can only test part of the memory security vulnerability types.

[0049] To solve the above technical problems, the memory security vulnerability types tested by the program source code testing method in the prior art have limitations. In specific implementation, firstly, a control flow chart and a function call chart of the program source code are extracted, and memory operations required when running the program source code are extracted, and dangerous operation sequences related to memory vulnerabilities are screened out from the memory operations; then test cases are input to the program source code, and when the program source code after inputting the test cases does not crash, memory consumption, code coverage, and dangerous operation coverage are monitored, wherein the memory consumption is the memory consumed by the program source code after inputting the test cases when executing the control flow chart, the function call chart, and the memory operations; the code coverage is used to represent the proportion of the code that has been run in the program source code, and the dangerous operation coverage is used to represent the degree to which the dangerous operation sequences are run; finally, the test cases are updated according to the code coverage, the memory consumption, and the dangerous operation coverage, until the program source code crashes, and a target test case is obtained, which is used to determine the memory security vulnerability type of the program source code.

[0050] For example, a control flow graph and a function call graph of the program source code are extracted, and memory operations required when the program source code is run are extracted. The control flow graph is used to represent steps and the order of the steps required to implement the function of the program source code, that is, the control flow graph is used to collect branch coverage. The function call graph is used to represent functions required when the program source code is run, that is, the function call graph is used to record function call entries and returns. The memory operations are memory operations required when the program source code is run on a computer. For example, the memory operations include memory operation a, memory operation b, memory operation c, memory operation d, memory operation e, and memory operation f. Different execution orders of the six memory operations will produce different operation sequences. The operation sequence b, d, and c will cause a memory vulnerability, that is, sequentially executing the memory operation b, the memory operation d, and the memory operation c will cause a memory vulnerability. Therefore, the operation sequence b, d, and c is a dangerous operation sequence. Similarly, if the operation sequence c, e, and b also causes a memory vulnerability, the operation sequence c, e, and b is also a dangerous operation sequence.

[0051] The test case A is input into the program source code. If the program source code does not crash at this time, the memory consumed by the control flow graph, the function call graph, and the memory operations during the running of the program source code is monitored, that is, the memory consumption is monitored. The code required to be executed by the program source code to output a result corresponding to the test case is also monitored. The proportion of the code to all codes in the program source code is the code coverage. It is monitored which of the first dangerous operation sequence b, d, and c and the second dangerous operation sequence c, e, and b are executed to obtain the dangerous operation coverage.

[0052] According to the code coverage, the memory consumption, and the dangerous operation coverage, the test case A is updated until the program source code crashes. The test case at the time of the crash is the target test case. The test case A can be a test mutation case (which is prior art) used to generate the test case A, or another test case B can be used to replace the test case A.

[0053] The test case A is input into the program source code. If the program source code has crashed at this time, the test case A is taken as the target test case. According to the target test case, the type of the memory security vulnerability caused by the program source code is determined. The type of the memory security vulnerability is determined by prior art.

[0054] The program source code testing method of the embodiment can be applied to a terminal device. The terminal device can be a terminal product with a data processing function, such as a computer. In the embodiment, as shown in Figure 1 the program source code testing method specifically includes the following steps:

[0055] S100, extract the control flow diagram and function call diagram of the program source code, extract the memory operations required when running the program source code, and filter out dangerous operation sequences related to memory vulnerabilities from all operation sequences involved in the memory operations;

[0056] S200, input test cases into the program source code. When the program source code does not crash after inputting the test cases, monitor memory consumption, code coverage, and dangerous operation coverage. Memory consumption refers to the memory consumed by the program source code after inputting the test cases when executing the control flow graph, the function call graph, and the memory operations. Code coverage represents the proportion of executed code in the program source code, and dangerous operation coverage represents the degree to which the dangerous operation sequence is executed.

[0057] S300, based on the code coverage, memory consumption, and dangerous operation coverage, update the test cases until the program source code crashes, to obtain target test cases, which are used to determine the type of memory security vulnerability in the program source code.

[0058] Extract the control flow graph, function call graph, and memory operations from the program source code, and filter out memory sequences (i.e., dangerous operation sequences) from the memory operations. Insert a monitoring program into the extracted source code to monitor the control flow graph, function call graph, memory operations, and dangerous operation sequences. Figure 2 As shown, the static analysis output includes the control flow diagram, function call graph, memory operations, and dangerous operation sequences. Test cases are input into the program source code, and a monitoring program is used to monitor code coverage, memory consumption, and dangerous operation coverage (dangerous operation coverage is...). Figure 2 The test case is used to determine whether the program source code crashes (based on memory operation coverage and memory sequence coverage). If the values ​​of code coverage, memory consumption, and dangerous operation coverage all reach a level that causes the program source code to crash, then that test case is used as the target test case. If the program source code does not crash, but the values ​​of code coverage, memory consumption, and dangerous operation coverage change, then that test case is added to the seed pool to update the seed pool (the seed pool is used to provide test cases for testing other program source code). Several test variants of the test case are generated (the number of test variants is denoted as the energy value). These test variants are then input into the program source code one by one. By monitoring the code coverage, memory consumption, and dangerous operation coverage at this point, it is determined whether the program source code has crashed. If it has crashed, the test variant corresponding to the crash is used as the target test case.

[0059] The program source code test method of the present application further comprises testing the use-after-free (UAF) vulnerability and the double-free (DF) vulnerability after memory release, and the specific test process is as follows:

[0060] When the memory operation is memory allocation (the size of the memory is denoted as m), as shown in Figure 3 , first check whether the current memory consumption M plus m exceeds the preset memory threshold (i.e., the system memory size), that is, whether M+m is greater than the preset memory threshold. If it exceeds the threshold, it means that the memory operation will cause a memory overflow vulnerability or a memory allocation failure vulnerability. Otherwise, update the current memory consumption to M+m, that is, M=M+m, allocate a memory block for the memory operation, and set the allocation state of the memory block (i.e., the memory block has been allocated to the memory operation).

[0061] The memory block is in the allocated state, that is, the memory block remains active until the memory block is released or the program source code exits, and then it can be analyzed that the program source code has a memory leak vulnerability.

[0062] When the memory block is released, it enters the recycling state, and the current memory consumption is updated to M-m, that is, M=M-m. If any use or release operation is performed on the memory block after release, the state of the memory block is the trap state, which means that the program source code has the use-after-free and double-free vulnerabilities.

[0063] Performing any use or release operation on an uninitialized memory address (in the init state) indicates that a null pointer dereference vulnerability or an invalid free vulnerability is detected.

[0064] A global variable D can also be used to represent the current stack depth. When a function is called, variable D+1; when the function returns, D-1. It is worth noting that recursive functions can be overcalled, gradually consuming the stack until it overflows.

[0065] The depth of the stack represents the degree of memory space vulnerability, which refers to dangerous memory operations, that is, once the memory operation is executed, it will cause the system to be occupied with resources exceeding the threshold, such as entering a function, the stack exceeds the system stack depth, or the memory allocation exceeds the allocatable space size.

[0066] In one embodiment, the method first filters out operation sequences with length greater than 1 from the operation sequences corresponding to the memory operations, because operation sequences with length greater than 1 are likely to put the memory block into a trap state (i.e., violate the protocol timing rules), and operation sequences that can put the memory block into a defect state are dangerous operation sequences. The method of filtering dangerous operation sequences includes the following specific steps: determining the timing protocol violation in the memory vulnerability; determining the operation sequences composed of the memory operations; determining the double-free vulnerability or the use-after-free vulnerability in the timing protocol violation; and filtering out dangerous operation sequences that constitute the double-free vulnerability or the use-after-free vulnerability from all the operation sequences.

[0067] The method of filtering dangerous operation sequences is based on the following principle: first, collect all memory allocation operations and their corresponding allocated memory object pointers, and store the results in S M (2nd row), for each memory operation s m and its corresponding object m, use pointer analysis to identify their potential alias pointers (4th row). Subsequently, MemSpate identifies all memory release operations that release the memory object m through the alias pointers, and generates a set S F (5th row).

[0068] Find all memory use operations related to any alias pointer m, and generate a set S U (6th row).

[0069] With the help of reachability analysis, if s m can reach S F , S F , then add the path of the operation sequence [s m , s f , s u ] to S; if s m can reach S F , S F can reach s' f , then add the path of the operation sequence [s m , s f , s' f ] to S, where s u is a use operation from SU, s f and s' f are two different release operations from S F , that is, [s m , s f , s u ] is a use-after-free vulnerability, and [s m , s f , s' f ] is a double-free vulnerability.

[0070] The algorithm required to screen the dangerous operation sequence of double release vulnerability and post-release use vulnerability is shown as follows in this embodiment:

[0071]

[0072] In Embodiment Two, based on Embodiment One, the monitoring of memory consumption, code coverage, and dangerous operation coverage in Step S200 in this embodiment includes the following specific steps S201 to S209:

[0073] S201, instrumenting a monitoring program on the program source code.

[0074] S202, counting the memory allocation operations and memory release operations corresponding to the control flow graph, the function call graph, and the memory operations.

[0075] S203, monitoring the memory consumed by each memory allocation operation by the monitoring program, denoted as allocation consumption.

[0076] For the allocation operation, the size of each allocated memory needs to be calculated, and the memory size is accumulated to obtain the memory size consumed due to the allocation operation. That is, the allocation consumption is counted through lines 9 to 11 of the algorithm.

[0077] S204, monitoring the memory consumed by each memory release operation by the monitoring program, denoted as release consumption.

[0078] For each release operation, the size of the released memory needs to be found, and the memory size is accumulated to obtain the memory size consumed due to the release operation. That is, the release consumption is counted through lines 13 to 15 of the algorithm.

[0079] S205, obtaining memory consumption according to the allocation consumption and the release consumption.

[0080] In this embodiment, the allocation consumption and the release consumption are taken as the memory size consumed due to the allocation operation and the release operation.

[0081] This embodiment also records the entry (line 3) and return instruction (line 7) of each function, and respectively increases (line 4) and decreases (line 9) the stack depth by 1. At the same time, MemSpate tracks the maximum stack depth (line 5), which is beneficial for seed selection during the fuzzy loop. And tracks the maximum memory consumption (line 12), which is also beneficial for seed selection during the fuzzy loop.

[0082] S206, monitoring each code in the program source code by the monitoring program to obtain the executed code.

[0083] code_cov is used to detect each basic block in the program source code to determine whether the code within each basic block is executed, that is, the code that has been executed is detected by line 26 of the algorithm.

[0084] S207, determining the proportion of the code that has been executed, and taking the proportion as the code coverage;

[0085] S208, monitoring the positions of the release operation and the allocation operation in the dangerous operation sequence by the monitoring program, and filtering out the dangerous operation sequence that has been executed from the dangerous operation sequence according to the positions.

[0086] S209, obtaining the dangerous operation coverage according to the number of the dangerous operation sequences and the number of the dangerous operation sequences that have been executed.

[0087] Steps S208 and S209 are to detect which operation sequences in the dangerous operation sequence have been executed, that is, if the instruction of the program source code contains a release operation (line 16 of the algorithm), all sequences related to the release are retrieved (line 17). For each sequence seq, if the release appears at the last position in seq (that is, the sequence is a DF sequence), it means that the sequence is covered (lines 18-19), that is, it has been executed; otherwise (that is, a UAF or DF sequence subsequence), MemSpate locates the position of the release in seq and marks the position as covered (lines 21-22). The use operation follows a similar procedure for the allocation operation, that is, whether the sequence is executed is detected by lines 23-25 of the algorithm to detect whether the last position of the sequence appears the allocation operation.

[0088] This embodiment detects whether the sequence has been executed, that is, whether it is covered, by the following algorithm:

[0089]

[0090] Embodiment three, the example includes the following specific steps:

[0091] When the code coverage changes or the memory consumption changes or the dangerous operation coverage changes, determine the test variation case of the test case;

[0092] Input the test variation case into the program source code, and when the program source code after inputting the test variation case does not crash, update the test case until the program source code crashes to obtain a target test case.

[0093] When the program source code after inputting the test variation case crashes, take the test variation case as the target test case.

[0094] First, the seeds (which are also test cases) in the seed pool are initialized (corresponding to line 3 of the algorithm), then a seed is selected from the seed pool Queue (corresponding to line 5 of the algorithm) and an energy value testcase_num is set for the seed (corresponding to line 6 of the algorithm, setting the energy value is also to set the number of test mutation cases for the test case, where the test mutation cases are generated from the test case, which is the prior art). After that, for each mutated test case (i.e. test mutation case), the execution of the monitoring program P' (i.e. program source code) is monitored, and information about code coverage, memory operation sequence coverage, maximum stack depth and maximum memory consumption is collected (corresponding to line 9 of the algorithm). If the program crashes, the tasecase will be added to the crash set S (corresponding to lines 10-11 of the algorithm). In addition, if this crash is categorized by ASAN as a memory-related vulnerability, the seed will be added to S mem (corresponding to lines 12-13 of the algorithm). Otherwise, check if the test case increases new code branch coverage (corresponding to line 14 of the algorithm), introduces new memory operation sequence coverage (corresponding to line 16 of the algorithm), or leads to greater stack / heap memory consumption (corresponding to line 18 of the algorithm), then the test case will be added to the seed pool for further testing (lines 15, 17, 19).

[0095]

[0096]

[0097] In summary, the test method of the present application uses a more comprehensive memory usage protocol, identifies memory operation sequences that may violate the protocol, and estimates whether running memory consumption exceeds an acceptable threshold. Then monitor the coverage of these operation sequences and track the maximum memory consumption. The test method of the present application takes into full consideration the detection of memory space vulnerabilities and memory timing vulnerabilities, and can test for stack overflow, heap overflow, allocation failure, double-free, heap-use-after-free, invalid-free and null-pointer-dereference.

[0098] The embodiment also provides a memory-based program source code testing device, as shown in Figure 4 The device comprises the following components:

[0099] The information extraction module 01 is configured to extract a control flow graph and a function call graph of a program source code, extract memory operations required when the program source code is executed, and screen dangerous operation sequences related to memory vulnerabilities from all operation sequences involved in the memory operations.

[0100] The monitoring module 02 is configured to input a test case into the program source code, and monitor memory consumption, code coverage, and dangerous operation coverage when the program source code does not crash after the test case is input, wherein the memory consumption is the memory consumed by the program source code when the control flow graph, the function call graph, and the memory operations are executed after the test case is input; the code coverage is used to represent the proportion of the code that has been executed in the program source code; and the dangerous operation coverage is used to represent the degree to which the dangerous operation sequences are executed.

[0101] The updating module 03 is configured to update the test case according to the code coverage, the memory consumption, and the dangerous operation coverage until the program source code crashes, so as to obtain a target test case, wherein the target test case is used to determine the type of the memory security vulnerability of the program source code.

[0102] Based on the above-mentioned embodiments, the application further provides a terminal device, a principle block diagram of which can be shown in Figure 5 The terminal device comprises a processor, a memory, a network interface, and a display screen which are connected through a system bus. The processor of the terminal device is configured to provide computing and control capabilities. The memory of the terminal device comprises a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operating system and the computer program in the non-volatile storage medium to run. The network interface of the terminal device is configured to communicate with external terminals through network connection. The computer program is executed by the processor to implement a memory-based program source code testing method. The display screen of the terminal device can be a liquid crystal display screen or an electronic ink display screen.

[0103] Those skilled in the art can understand that, Figure 5 The principle block diagram shown in the above-mentioned embodiments is only a block diagram of part of the structure related to the application scheme, and does not constitute a limitation on the terminal device to which the application scheme is applied. Specifically, the terminal device can comprise more or fewer components than those shown in the diagram, or combine certain components, or have a different component arrangement.

[0104] In one embodiment, a terminal device is provided, which comprises a memory, a processor, and a memory-based program source code testing program stored in the memory and executable on the processor. When the processor executes the memory-based program source code testing program, the following operation instructions are implemented.

[0105] extracting a control flow graph and a function call graph of the program source code, extracting memory operations required when the program source code is executed, and screening dangerous operation sequences related to memory vulnerabilities from all operation sequences involved in the memory operations;

[0106] inputting a test case to the program source code, and monitoring memory consumption, code coverage, and dangerous operation coverage when the program source code after the test case is input does not crash, wherein the memory consumption is memory consumed by the program source code after the test case is input when the control flow graph, the function call graph, and the memory operations are executed; the code coverage is used to represent a proportion of code that has been executed in the program source code; and the dangerous operation coverage is used to represent a degree to which the dangerous operation sequences are executed;

[0107] updating the test case according to the code coverage, the memory consumption, and the dangerous operation coverage until the program source code crashes, to obtain a target test case, wherein the target test case is used to determine a memory security vulnerability type of the program source code.

[0108] Those skilled in the art can understand that all or part of the processes in the above-mentioned embodiments can be completed by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer readable storage medium. When the computer program is executed, the processes of the above-mentioned embodiments can be included. Any reference to memory, storage, database, or other medium used in the embodiments provided by the present application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. As an illustration but not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), synchronous link (Synchlink) DRAM (SLDRAM), memory bus (Rambus) direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).

[0109] It should be pointed out finally that the above embodiments are only used to illustrate the technical solutions of the present application, but not to limit the same; and although the present application has been described in detail with reference to the foregoing embodiments, it should be appreciated by those skilled in the art that the technical solutions recorded in the foregoing embodiments can be modified, or some technical features thereof can be replaced equivalently; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present application.

Claims

1. A memory-based program source code testing method characterized by, The method comprises the following steps: extracting a control flow graph and a function call graph of program source code, extracting memory operations required when the program source code is executed, and screening dangerous operation sequences related to memory vulnerabilities from all operation sequences involved in the memory operations; inputting a test case into the program source code, and monitoring memory consumption, code coverage, and dangerous operation coverage when the program source code after the test case is inputted does not crash, wherein the memory consumption is the memory consumed by the program source code after the test case is inputted when the control flow graph, the function call graph, and the memory operations are executed; the code coverage is used to represent the proportion of the code that has been executed in the program source code; and the dangerous operation coverage is used to represent the degree to which the dangerous operation sequences are executed; updating the test case according to the code coverage, the memory consumption, and the dangerous operation coverage until the program source code crashes, so as to obtain a target test case, which is used to determine the type of memory security vulnerability of the program source code; the step of screening the dangerous operation sequences related to the memory vulnerabilities from all the operation sequences involved in the memory operations comprises the following steps: determining a violation of a time sequence protocol rule in the memory vulnerabilities; determining an operation sequence formed by the memory operations; determining a double-free vulnerability or a use-after-free vulnerability in the violation of the time sequence protocol rule; screening dangerous operation sequences constituting the double-free vulnerability or the use-after-free vulnerability from all the operation sequences; the step of updating the test case according to the code coverage, the memory consumption, and the dangerous operation coverage until the program source code crashes, so as to obtain a target test case comprises the following steps: when the code coverage changes or the memory consumption changes or the dangerous operation coverage changes, determining a test variation case of the test case; inputting the test variation case into the program source code, and updating the test case until the program source code crashes when the program source code after the test variation case is inputted does not crash, so as to obtain a target test case.

2. The memory-based program source code testing method of claim 1, wherein, the step of monitoring the memory consumption, the code coverage, and the dangerous operation coverage comprises the following steps: inserting a monitoring program into the program source code; monitoring the memory consumption, the code coverage, and the dangerous operation coverage by the monitoring program.

3. The memory-based program source code testing method of claim 2, wherein, the step of monitoring the memory consumption, the code coverage, and the dangerous operation coverage by the monitoring program comprises the following steps: counting memory allocation operations and memory release operations corresponding to the control flow graph, the function call graph, and the memory operations; monitoring the memory consumed by each memory allocation operation by the monitoring program, which is recorded as allocation consumption; monitoring the memory consumed by each memory release operation by the monitoring program, which is recorded as release consumption; obtaining memory consumption according to the allocation consumption and the release consumption; monitoring each code in the program source code by the monitoring program to obtain executed code; determining the proportion of the executed code, and taking the proportion as code coverage. monitoring the positions of the release operation and the allocation operation in the dangerous operation sequence by the monitoring procedure, and screening the dangerous operation sequence that has been executed from the dangerous operation sequence according to the positions; obtaining a dangerous operation coverage rate according to the number of the dangerous operation sequences and the number of the dangerous operation sequences that have been executed.

4. The memory-based program source code testing method of claim 1, wherein, The updating the test case according to the code coverage rate, the memory consumption and the dangerous operation coverage rate until the program source code crashes to obtain a target test case further comprises: When the program source code crashes after the test mutation case is input, the test mutation case is taken as the target test case.

5. A memory-based program source code testing apparatus characterized by comprising: The device comprises the following components: an information extraction module, configured to extract a control flow graph and a function call graph of a program source code, extract a memory operation required when the program source code is run, and screen a dangerous operation sequence related to a memory vulnerability from all operation sequences involved in the memory operation; a monitoring module, configured to input a test case to the program source code, and monitor a memory consumption, a code coverage rate and a dangerous operation coverage rate when the program source code does not crash after the test case is input, wherein the memory consumption is the memory consumed by the program source code when the control flow graph, the function call graph and the memory operation are executed after the test case is input; the code coverage rate is used to represent the proportion of the code that has been run in the program source code; and the dangerous operation coverage rate is used to represent the degree to which the dangerous operation sequence is run; an updating module, configured to update the test case according to the code coverage rate, the memory consumption and the dangerous operation coverage rate until the program source code crashes to obtain a target test case, wherein the target test case is used to determine a memory security vulnerability type of the program source code. The screening of the dangerous operation sequence related to the memory vulnerability from all the operation sequences involved in the memory operation comprises: determining a violation of a timing protocol rule in the memory vulnerability; determining an operation sequence formed by the memory operation; determining a double free vulnerability or a use-after-free vulnerability in the violation of the timing protocol rule; screening a dangerous operation sequence constituting the double free vulnerability or the use-after-free vulnerability from all the operation sequences; The updating the test case according to the code coverage rate, the memory consumption and the dangerous operation coverage rate until the program source code crashes to obtain a target test case comprises: determining a test mutation case of the test case when the code coverage rate changes or the memory consumption changes or the dangerous operation coverage rate changes; inputting the test mutation case to the program source code, and updating the test case until the program source code crashes to obtain a target test case when the program source code does not crash after the test mutation case is input.

6. A terminal device, characterized by comprising: The terminal device comprises a memory, a processor, and a memory-based program source code testing program stored in the memory and executable on the processor, and the processor implements the steps of the memory-based program source code testing method according to any one of claims 1-4 when executing the memory-based program source code testing program.

7. A computer readable storage medium characterized in that, The computer readable storage medium stores a memory-based program source code testing program, and the memory-based program source code testing program implements the steps of the memory-based program source code testing method according to any one of claims 1-4 when executed by a processor.

Images