CN110851352A - Fuzzy test system and terminal equipment - Google Patents
Fuzzy test system and terminal equipment Download PDFInfo
- Publication number
- CN110851352A CN110851352A CN201910978930.7A CN201910978930A CN110851352A CN 110851352 A CN110851352 A CN 110851352A CN 201910978930 A CN201910978930 A CN 201910978930A CN 110851352 A CN110851352 A CN 110851352A
- Authority
- CN
- China
- Prior art keywords
- fuzz testing
- test object
- engine
- ptrace
- testing system
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3668—Software testing
- G06F11/3672—Test management
- G06F11/3688—Test management for test execution, e.g. scheduling of test suites
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Computer Hardware Design (AREA)
- Quality & Reliability (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Debugging And Monitoring (AREA)
Abstract
The application belongs to the technical field of computer network safety, and particularly relates to a fuzzy test system and terminal equipment. The fuzz testing system provided by the embodiment of the application can comprise: a core fuzz testing engine, an anomaly detection engine, and an anomaly reporting engine. The core fuzzy test engine is used for generating a test vector of an input target test object; the anomaly detection engine to detect undefined and potentially unsafe behavior of the target test object; and the exception reporting engine is used for reporting all information related to the target test object when the target test object is abnormal. Compared with the existing fuzz testing which is only suitable for finding out specific weaknesses in a specific tested system, the fuzz testing system provided by the application has wider applicability.
Description
Technical Field
The application belongs to the technical field of computer network safety, and particularly relates to a fuzzy test system and terminal equipment.
Background
Fuzz testing is a "method of discovering faults (faults) in software by providing unexpected inputs to an application and monitoring for anomalies in the outputs". Fuzz testing repeatedly provides input to an application using automated or semi-automated methods. Fuzzy testers fall into two categories: one type is a mutation-based fuzz tester, which creates test cases by mutating existing data samples; the other type is a generation-based fuzzy tester, which models a protocol or a file format used by a system under test, generates an input based on the model, and creates a test case according to the input. The fuzzy test is suitable for finding specific weaknesses in a specific tested system, such as access control bugs, poor design logic, backdoor landing interfaces, memory corruption problems, multi-stage security bugs and the like, and therefore has certain limitations.
Disclosure of Invention
In view of this, embodiments of the present application provide a fuzzy test system and a terminal device, so as to solve the problem that the existing fuzzy test is only suitable for finding out a specific weakness in a specific system under test, and has a certain limitation.
A first aspect of an embodiment of the present application provides a fuzz testing system, which may include:
the core fuzzy test engine is used for generating a test vector of an input target test object;
an anomaly detection engine to detect undefined and potentially unsafe behavior of the target test object;
and the exception reporting engine is used for reporting all information related to the target test object when the target test object is abnormal.
Further, the core fuzz testing engine is further to:
a SPIKE script is obtained that describes a file format and different variants of the file format are generated using a combination of valid and invalid data.
Further, the core fuzz testing engine is further to:
acquiring a target file;
and carrying out variation on different parts of the target file by using a preset fuzzy value database to obtain a varied target file.
Further, the fuzzy value database comprises fuzzy values of binary type and fuzzy values of character string type.
Further, the anomaly detection engine is further configured to:
monitoring all signals received by the target test object;
monitoring values passed to a specified function call by the fuzz testing system in an unsecured manner using library C function hooks;
signal detection was performed using ptrace function.
Further, the signal detection using the ptrace function includes:
when the first parameter is the PTRACE function of the PTRACE _ TRACEME in the subprocess, the father process receives a signal sent to the subprocess by the fuzzy test system, judges the state of the subprocess according to the signal and sends a command to the subprocess by using different parameters in the PTRACE function.
Further, the signal detection using the ptrace function includes:
and if a signal triggering the vulnerability is detected, stopping debugging the subprocess by using a PTRACE function with a first parameter of PTRACE _ DETACH, recording the field information of the subprocess, and generating an abnormal report file.
Further, the signal detection using the ptrace function includes:
and if the detected signal is not related to the bug, using a PTRACE function with the first parameter PTRACE _ CONT to enable the subprocess to continue to execute.
Further, the operation process of the fuzz testing system comprises the following steps:
identifying a target test object;
generating fuzzy test data corresponding to the target test object;
executing the fuzz test data in the target test object;
and monitoring the target test object for abnormality.
A second aspect of embodiments of the present application provides a computer-readable storage medium storing a computer program, which when executed by a processor implements the functions of any one of the fuzz testing systems described above.
A third aspect of the embodiments of the present application provides a terminal device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, where the processor implements the computer program to implement the functions of any one of the fuzz testing systems described above.
A fourth aspect of the embodiments of the present application provides a computer program product, which, when running on a terminal device, enables the terminal device to implement the functions of any one of the above-mentioned fuzzy test systems.
Compared with the prior art, the embodiment of the application has the advantages that: the fuzz testing system provided by the embodiment of the application can comprise: a core fuzz testing engine, an anomaly detection engine, and an anomaly reporting engine. The core fuzzy test engine is used for generating a test vector of an input target test object; the anomaly detection engine to detect undefined and potentially unsafe behavior of the target test object; and the exception reporting engine is used for reporting all information related to the target test object when the target test object is abnormal. Compared with the existing fuzz testing which is only suitable for finding out specific weaknesses in a specific tested system, the fuzz testing system provided by the application has wider applicability.
Drawings
In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings needed to be used in the embodiments or the prior art descriptions will be briefly described below, and it is obvious that the drawings in the following description are only some embodiments of the present application, and it is obvious for those skilled in the art to obtain other drawings based on these drawings without inventive exercise.
FIG. 1 is a schematic diagram of a fuzzy test system in an embodiment of the present application;
fig. 2 is a schematic block diagram of a terminal device in an embodiment of the present application.
Detailed Description
In order to make the objects, features and advantages of the present invention more apparent and understandable, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present application, and it is apparent that the embodiments described below are only a part of the embodiments of the present application, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.
It will be understood that the terms "comprises" and/or "comprising," when used in this specification and the appended claims, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.
It is also to be understood that the terminology used in the description of the present application herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. As used in the specification of the present application and the appended claims, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise.
It should be further understood that the term "and/or" as used in this specification and the appended claims refers to and includes any and all possible combinations of one or more of the associated listed items.
As used in this specification and the appended claims, the term "if" may be interpreted contextually as "when", "upon" or "in response to a determination" or "in response to a detection". Similarly, the phrase "if it is determined" or "if a [ described condition or event ] is detected" may be interpreted contextually to mean "upon determining" or "in response to determining" or "upon detecting [ described condition or event ]" or "in response to detecting [ described condition or event ]".
In addition, in the description of the present application, the terms "first," "second," "third," and the like are used solely to distinguish one from another and are not to be construed as indicating or implying relative importance.
The fuzzy test technology is an automatic vulnerability mining method which is used for triggering program abnormity by generating malformed input and monitoring and recording the abnormal condition of a program so as to find potential safety hazards in an application program. The malformed input is that the necessary identification portion of the input data and most of the data are valid, but the rest of the data are invalid. Thus, the application may process the input data as valid input, which may trigger a bug in the program. File format fuzz testing is a special fuzz testing method for a specifically defined target application. These target applications are typically client applications, examples of which include media players, Office suites, and the like. However, the target application may also be a server program, such as a mail server, an anti-virus gateway filter, etc. The goal of the file fuzz test is to find defects for an application to parse a particular type of file. The application provides a system for realizing file format fuzzy test in a Linux system, which mainly researches key technologies for realizing the file format fuzzy test from the aspects of constructing abnormal elements, generating a test case, determining signals needing to be monitored, monitoring the running of a subprocess by using a debugger, capturing system signals triggering a bug, recording abnormal information and the like.
Referring to fig. 1, an embodiment of a fuzz testing system in an embodiment of the present application may include: a core fuzz test engine 11, an anomaly detection engine 12, and an anomaly reporting engine 13.
The core fuzzy test engine 11 is used to generate test vectors for the input target test objects, i.e. the engine controls what exception data is used and what objects they are used.
In SPIKE, the core fuzz testing engine needs a template, i.e., a SPIKE script that describes the file format, and is used to fetch the script and generate different variants of the file format using a combination of valid and invalid data. Among them, SPIKE is a framework written in C language, providing a series of APIs that allow fast and efficient development of network protocol fuzz testers.
In notSPIKEFile, the core fuzz testing engine is more limited and the user must provide a valid target file to it. The core fuzzy test engine is used for obtaining the target file and performing variation on different parts of the target file by using a preset fuzzy value database to obtain a varied target file. The fuzzy value database comprises binary fuzzy values and character string fuzzy values. Wherein the binary type fuzzy value can be any length and any value, and the string type fuzzy value can be different strings such as file path, URL, and any other types. To get a complete list of these types, we can look at the source code for SPIKE and notspike files. The following table provides a concise list of some valid ambiguous character exchanges and gives a short explanation:
there is no limitation on the number of fuzzy strings that may be used. It should be noted that any type of value may require special resolution or produce an exception condition that should be well represented. The reason for the ambiguity to be malformed and to find a different result of an error may be due to a simple operation such as appending html to the end of a long ambiguous string.
The anomaly detection engine 12 is configured to detect undefined and potentially unsafe behavior of the target test object.
The anomaly detection engine may detect undefined and potentially unsafe behavior of the target test object in two ways. One is to monitor all signals received by the target test object, which can only detect some bugs and will not capture actions such as meta-character injection or logic defects. The second is to use the library C function (LIBC) hook to monitor the values passed by the fuzz testing system to specified function calls in an unsecured manner, including but not limited to open, create, system, etc.
Further, the anomaly detection engine is also configured to perform signal detection using a ptrace function. Under Linux, the purpose of tracking and controlling running processes can be realized by using a system call function ptrace (), and the first parameter of the ptrace (int _ request, pid _ t _ pid, caddr _ t _ addr, int _ data) function determines the behavior of ptrace and the using method of other parameters.
When the first parameter is the PTRACE function of the PTRACE _ TRACEME in the child process, the parent process is informed to track the running of the child process, the parent process receives signals sent to the child process by the fuzzy test system, the signals indicate that the child process has certain problems, the parent process can judge the state of the child process according to the signals, and different parameters are used in the PTRACE function to send commands to the child process.
And if a signal triggering the vulnerability is detected, stopping debugging the subprocess by using a PTRACE function with a first parameter of PTRACE _ DETACH, recording the field information of the subprocess, and generating an abnormal report file.
And if the detected signal is not related to the bug, using a PTRACE function with the first parameter PTRACE _ CONT to enable the subprocess to continue to execute.
The system signals represent different types of errors, and specific types of errors can be generated when the loophole is triggered, so that the system sends corresponding signals. During the fuzzy test, firstly, the vulnerability to be searched needs to be determined, and then the system signal related to the vulnerability is determined. For example, a buffer overflow hole typically causes a memory operation error, and the following are several signals related to the memory corruption: SIGSEGV is an invalid memory reference; SIGBUS is a bus error, usually caused by a memory corruption; SIGSYS is a system call error and is also usually caused by a memory error. If the prompt signal related to the bug is captured when the monitoring application program runs, and the corresponding bug is probably triggered by the test case, the field information of the process is stored, and a program exception report is generated.
The exception reporting engine 13 is configured to report all information related to the target test object when the target test object is abnormal, where the information includes, but is not limited to, malicious instructions, CPU register state, and the like.
The fuzz testing system can report useful information of what is happening, at least the resulting signal. Ideally, more detailed information such as malicious instructions, CPU register state, and the clearing of a stack should also be included in the report. This information may be collected with the help of the system call ptrace and a library may be used to parse the instructions if it is desired to report the information to the user. The library is capable of converting a buffer of arbitrary data into a string representation of the X86 instruction. In the embodiment, the libdispasm library is preferably selected, provides a very simple interface and is regarded as the best choice of the google search engine, and the libdispasm comprises a plurality of examples, codes can be cut and pasted from the libdispasm library, and the convenience of use is greatly improved.
The operation process of the fuzz testing system can comprise the following steps: identifying a target test object; generating fuzzy test data corresponding to the target test object; executing the fuzz test data in the target test object; and monitoring the target test object for abnormality.
Most of the available software bugs are caused by that the input data is not carefully judged and processed in legality, so that the fuzzy test needs to determine the expected input of the target firstly, otherwise the fuzzy test result has great limitation. Then, test cases are required to be continuously generated according to expected input according to a certain strategy, and the process of executing the test cases generally needs to be performed in a cross manner with the process of generating the test cases so as to verify whether the generated test cases effectively increase the path coverage of the target program or trigger program bugs. In the process, an exception monitoring program is also needed to record all exception information in the fuzz test process, the exception monitoring program is usually implemented through instrumentation, and for some target programs which can start a debugging mode, the exception monitoring program can also be implemented through corresponding debugging interfaces.
In particular, when fuzz testing is performed for Adobe Acrobat, an application that cannot be directly launched, the acroread can be run first using the-DEBUG option. The use-DEBUG option enables the implementer to enter a shell that sets the correct context to invoke the real acroread implementation file. Although Acrobat's document does not contain this information, nor is it described in use, the shell script that reads acroread can query for this information. Thus, the Adobe Acrobat Reader UnixAppleOpenFilePerform buffer overflow security hole can be discovered with the help of notSPIKEFile. When the fuzzy test is carried out on the application which cannot be directly started, such as RealNetworkPlayer, the fuzzy test can be directly carried out on the execution file contained in the RealPlayer only by setting the shell environment variable HELIX _ PATH to be an installation PATH pointing to the RealPlayer.
The following describes the present application in detail by taking the example of finding a leak in the RealPlayer RealPix format character string:
a file format supported by RealPlayer, such as RealPix format, is arbitrarily selected. Some example RealPix files are selected from the vast amount of information available to google, compiled and used as the base files for notSPIKEfile fuzz testing:
the file is run through notSPIKEFile, the RealPlayer is tested for code resolving the header for defects:
user@host$export HELIX_PATH＝/opt/RealPlayer/
user@host$./notSPIKEfile-t 3 -d 1 -m 3 -r 0- -S -s SIGKILL -o FUZZY-sample1.rp sample1.rp“/opt/RealPlay/realplay.bin％FILENAME％”
[...]
user@host$
-the t option delays each call to RealPlayer by 3s, -d tells the fuzz testing system to wait 1s between terminating an idle process and starting a new process, -m specifies starting 3 concurrent RealPlayer instances, and-r tells the tool to start the test from the 0 th byte of the whole file. -S designates a string fuzz test mode, -S designates the termination of the idle process by the SIGKILL signal. And finally, telling the tool the format of the fuzzy test file name, namely the sample file name sample1.rp, so that the tool can analyze the file. After execution, several crashes are reported.
The FUZZY-sample1.rp-0x28ab156b-dump. txt file created by the fuzz testing system is opened and the detailed report can be seen. The file causing the crash is saved at 1228-fyzy-sample 1.rp, the contents of the file causing the crash are reviewed, and information is found from the contents of the file that reveals the problem:
if the% n character appears in the file, it is suspected that the format string is missing a hole and the resulting crash occurs. The guess was confirmed when the RealPlayer execution file was run using the GDB.
user@host～/notSPIKEfile$gdb-q/opt/RealPlayer/realplay.bin
Using host libthread_db library“/lib/tls/lib/thread_db.so.1”.
(gdb)r 12288-FUZZY-sample1.rp
Starting program:/opt/RealPlayer/realplayer.bin 12288-FUZZY-sample1.rp
Program received signal SIGSEGV.Segmentation fault.
0xb7e53e67 in vfprintf()from/lib/tls/libc.so.6
(gdb)x/i$pc
0xb7e53e67<vfprintf+13719>:mov％ecx,(％eax)
The above is that a format string hole of RealPlayer is found, and the hole is located in the code for processing timeformat.
In summary, the fuzz testing system provided by the embodiment of the present application may include: a core fuzz testing engine, an anomaly detection engine, and an anomaly reporting engine. The core fuzzy test engine is used for generating a test vector of an input target test object; the anomaly detection engine to detect undefined and potentially unsafe behavior of the target test object; and the exception reporting engine is used for reporting all information related to the target test object when the target test object is abnormal. Compared with the existing fuzz testing which is only suitable for finding out specific weaknesses in a specific tested system, the fuzz testing system provided by the application has wider applicability.
Fig. 2 shows a schematic block diagram of a terminal device provided in an embodiment of the present application, and for convenience of description, only a part related to the embodiment of the present application is shown.
As shown in fig. 2, the terminal device 2 of this embodiment includes: a processor 20, a memory 21 and a computer program 22 stored in said memory 21 and executable on said processor 20. The processor 20, when executing the computer program 22, implements the functionality described above in the various fuzz testing system embodiments.
Illustratively, the computer program 22 may be partitioned into one or more modules/units that are stored in the memory 21 and executed by the processor 20 to accomplish the present application. The one or more modules/units may be a series of computer program instruction segments capable of performing specific functions, which are used to describe the execution process of the computer program 22 in the terminal device 2.
The terminal device 2 may be a desktop computer, a notebook, a palm computer, a cloud server, or other computing devices. It will be understood by those skilled in the art that fig. 2 is only an example of the terminal device 2, and does not constitute a limitation to the terminal device 2, and may include more or less components than those shown, or combine some components, or different components, for example, the terminal device 2 may further include an input-output device, a network access device, a bus, etc.
The Processor 20 may be a Central Processing Unit (CPU), other general purpose Processor, a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA) or other Programmable logic device, discrete Gate or transistor logic device, discrete hardware component, etc. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like.
The memory 21 may be an internal storage unit of the terminal device 2, such as a hard disk or a memory of the terminal device 2. The memory 21 may also be an external storage device of the terminal device 2, such as a plug-in hard disk, a Smart Media Card (SMC), a Secure Digital (SD) Card, a Flash memory Card (Flash Card), and the like, which are provided on the terminal device 2. Further, the memory 21 may also include both an internal storage unit and an external storage device of the terminal device 2. The memory 21 is used for storing the computer program and other programs and data required by the terminal device 2. The memory 21 may also be used to temporarily store data that has been output or is to be output.
It will be apparent to those skilled in the art that, for convenience and brevity of description, only the above-mentioned division of the functional units and modules is illustrated, and in practical applications, the above-mentioned function distribution may be performed by different functional units and modules according to needs, that is, the internal structure of the apparatus is divided into different functional units or modules to perform all or part of the above-mentioned functions. Each functional unit and module in the embodiments may be integrated in one processing unit, or each unit may exist alone physically, or two or more units are integrated in one unit, and the integrated unit may be implemented in a form of hardware, or in a form of software functional unit. In addition, specific names of the functional units and modules are only for convenience of distinguishing from each other, and are not used for limiting the protection scope of the present application. The specific working processes of the units and modules in the system may refer to the corresponding processes in the foregoing method embodiments, and are not described herein again.
In the above embodiments, the descriptions of the respective embodiments have respective emphasis, and reference may be made to the related descriptions of other embodiments for parts that are not described or illustrated in a certain embodiment.
Those of ordinary skill in the art will appreciate that the various illustrative elements and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware or combinations of computer software and electronic hardware. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the implementation. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.
In the embodiments provided in the present application, it should be understood that the disclosed apparatus/terminal device and method may be implemented in other ways. For example, the above-described embodiments of the apparatus/terminal device are merely illustrative, and for example, the division of the modules or units is only one logical division, and there may be other divisions when actually implemented, for example, a plurality of units or components may be combined or integrated into another system, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection through some interfaces, devices or units, and may be in an electrical, mechanical or other form.
The units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of the embodiment.
In addition, functional units in the embodiments of the present application may be integrated into one processing unit, or each unit may exist alone physically, or two or more units are integrated into one unit. The integrated unit can be realized in a form of hardware, and can also be realized in a form of a software functional unit.
The integrated modules/units, if implemented in the form of software functional units and sold or used as separate products, may be stored in a computer readable storage medium. Based on such understanding, all or part of the flow in the method of the embodiments described above can be realized by a computer program, which can be stored in a computer-readable storage medium and can realize the steps of the embodiments of the methods described above when the computer program is executed by a processor. Wherein the computer program comprises computer program code, which may be in the form of source code, object code, an executable file or some intermediate form, etc. The computer-readable medium may include: any entity or device capable of carrying the computer program code, recording medium, usb disk, removable hard disk, magnetic disk, optical disk, computer Memory, Read-Only Memory (ROM), Random Access Memory (RAM), electrical carrier wave signals, telecommunications signals, software distribution medium, and the like. It should be noted that the computer readable medium may contain content that is subject to appropriate increase or decrease as required by legislation and patent practice in jurisdictions, for example, in some jurisdictions, computer readable media does not include electrical carrier signals and telecommunications signals as is required by legislation and patent practice.
The above-mentioned embodiments are only used for illustrating the technical solutions of the present application, and not for limiting the same; although the present application has been described in detail with reference to the foregoing embodiments, it should be understood by those of ordinary skill in the art that: the technical solutions described in the foregoing embodiments may still be modified, or some technical features may be equivalently replaced; such modifications and substitutions do not substantially depart from the spirit and scope of the embodiments of the present application and are intended to be included within the scope of the present application.
Claims (10)
1. A fuzz testing system, comprising:
the core fuzzy test engine is used for generating a test vector of an input target test object;
an anomaly detection engine to detect undefined and potentially unsafe behavior of the target test object;
and the exception reporting engine is used for reporting all information related to the target test object when the target test object is abnormal.
2. The fuzz testing system of claim 1, wherein the core fuzz testing engine is further configured to:
a SPIKE script is obtained that describes a file format and different variants of the file format are generated using a combination of valid and invalid data.
3. The fuzz testing system of claim 1, wherein the core fuzz testing engine is further configured to:
acquiring a target file;
and carrying out variation on different parts of the target file by using a preset fuzzy value database to obtain a varied target file.
4. The fuzzing system according to claim 3, wherein the fuzzing value database includes binary type fuzzing values and string type fuzzing values.
5. The fuzz testing system of claim 1, wherein the anomaly detection engine is further configured to:
monitoring all signals received by the target test object;
monitoring values passed to a specified function call by the fuzz testing system in an unsecured manner using library C function hooks;
signal detection was performed using ptrace function.
6. The fuzz testing system of claim 5, wherein the signal detection using a ptrace function comprises:
when the first parameter is the PTRACE function of the PTRACE _ TRACEME in the subprocess, the father process receives a signal sent to the subprocess by the fuzzy test system, judges the state of the subprocess according to the signal and sends a command to the subprocess by using different parameters in the PTRACE function.
7. The fuzz testing system of claim 5, wherein the signal detection using a ptrace function comprises:
and if a signal triggering the vulnerability is detected, stopping debugging the subprocess by using a PTRACE function with a first parameter of PTRACE _ DETACH, recording the field information of the subprocess, and generating an abnormal report file.
8. The fuzz testing system of claim 5, wherein the signal detection using a ptrace function comprises:
and if the detected signal is not related to the bug, using a PTRACE function with the first parameter PTRACE _ CONT to enable the subprocess to continue to execute.
9. The fuzz testing system according to any of claims 1 to 8, wherein the operation of the fuzz testing system comprises:
identifying a target test object;
generating fuzzy test data corresponding to the target test object;
executing the fuzz test data in the target test object;
and monitoring the target test object for abnormality.
10. A terminal device comprising a memory, a processor and a computer program stored in the memory and executable on the processor, characterized in that the processor implements the functionality of the fuzz testing system according to any of the claims 1 to 9 when executing the computer program.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910978930.7A CN110851352A (en) | 2019-10-15 | 2019-10-15 | Fuzzy test system and terminal equipment |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910978930.7A CN110851352A (en) | 2019-10-15 | 2019-10-15 | Fuzzy test system and terminal equipment |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN110851352A true CN110851352A (en) | 2020-02-28 |
Family
ID=69597595
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201910978930.7A Pending CN110851352A (en) | 2019-10-15 | 2019-10-15 | Fuzzy test system and terminal equipment |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN110851352A (en) |
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112269597A (en) * | 2020-10-23 | 2021-01-26 | 中国人民解放军战略支援部队信息工程大学 | Method and system for detecting abnormal behavior of processor instruction |
| CN112347484A (en) * | 2020-10-27 | 2021-02-09 | 杭州安恒信息技术股份有限公司 | Software vulnerability detection method, device, equipment and computer readable storage medium |
| CN113194497A (en) * | 2021-03-12 | 2021-07-30 | 深圳开源互联网安全技术有限公司 | Wifi packet sending method and device in fuzzy test and storage medium |
| CN113992433A (en) * | 2021-12-24 | 2022-01-28 | 杭州海康威视数字技术股份有限公司 | Network equipment concurrency fuzzy test method and device based on variation strategy |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN104573523A (en) * | 2013-10-24 | 2015-04-29 | 深圳市腾讯计算机系统有限公司 | File vulnerability mining realization method and device |
| CN106487813A (en) * | 2016-12-13 | 2017-03-08 | 北京匡恩网络科技有限责任公司 | Industry control network safety detecting system and detection method |
| CN108182359A (en) * | 2017-12-29 | 2018-06-19 | 中国信息通信研究院 | The method, apparatus and storage medium of API safeties under a kind of test trusted context |
-
2019
- 2019-10-15 CN CN201910978930.7A patent/CN110851352A/en active Pending
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN104573523A (en) * | 2013-10-24 | 2015-04-29 | 深圳市腾讯计算机系统有限公司 | File vulnerability mining realization method and device |
| CN106487813A (en) * | 2016-12-13 | 2017-03-08 | 北京匡恩网络科技有限责任公司 | Industry control network safety detecting system and detection method |
| CN108182359A (en) * | 2017-12-29 | 2018-06-19 | 中国信息通信研究院 | The method, apparatus and storage medium of API safeties under a kind of test trusted context |
Non-Patent Citations (2)
| Title |
|---|
| MICHAEL SUTTON 等: "《模糊测试-强制性安全漏洞发掘》", 31 January 2009, 机械工业出版社 * |
| 刘天鹏 等: "基于文件格式信息的改进模糊测试方法", 《计算机系统应用》 * |
Cited By (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112269597A (en) * | 2020-10-23 | 2021-01-26 | 中国人民解放军战略支援部队信息工程大学 | Method and system for detecting abnormal behavior of processor instruction |
| CN112269597B (en) * | 2020-10-23 | 2023-03-24 | 中国人民解放军战略支援部队信息工程大学 | Method and system for detecting abnormal behavior of processor instruction |
| CN112347484A (en) * | 2020-10-27 | 2021-02-09 | 杭州安恒信息技术股份有限公司 | Software vulnerability detection method, device, equipment and computer readable storage medium |
| CN113194497A (en) * | 2021-03-12 | 2021-07-30 | 深圳开源互联网安全技术有限公司 | Wifi packet sending method and device in fuzzy test and storage medium |
| CN113992433A (en) * | 2021-12-24 | 2022-01-28 | 杭州海康威视数字技术股份有限公司 | Network equipment concurrency fuzzy test method and device based on variation strategy |
| CN113992433B (en) * | 2021-12-24 | 2022-03-25 | 杭州海康威视数字技术股份有限公司 | Network equipment concurrency fuzzy test method and device based on variation strategy |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US8839203B2 (en) | Code coverage-based taint perimeter detection | |
| Carmony et al. | Extract Me If You Can: Abusing PDF Parsers in Malware Detectors. | |
| CN110851352A (en) | Fuzzy test system and terminal equipment | |
| JP7517585B2 (en) | Analytical function providing device, analytical function providing program, and analytical function providing method | |
| CN109101815B (en) | Malicious software detection method and related equipment | |
| US8453115B2 (en) | Automatic data manipulation to influence code paths | |
| US20210357309A1 (en) | Systems and methods for debugging and application development | |
| CN109255240B (en) | Vulnerability processing method and device | |
| Chen et al. | A large-scale empirical study on control flow identification of smart contracts | |
| CN113114680B (en) | Detection method and detection device for file uploading vulnerability | |
| US9495542B2 (en) | Software inspection system | |
| CN111782526A (en) | Interface testing method and device, electronic equipment and storage medium | |
| CN111475411A (en) | Server problem detection method, system, terminal and storage medium | |
| CN111884876A (en) | Method, device, equipment and medium for detecting protocol type of network protocol | |
| CN113158197A (en) | SQL injection vulnerability detection method and system based on active IAST | |
| CN112685745B (en) | Firmware detection method, device, equipment and storage medium | |
| US20070079288A1 (en) | System and method for capturing filtered execution history of executable program code | |
| Wi et al. | Diffcsp: Finding browser bugs in content security policy enforcement through differential testing | |
| CN110287700B (en) | iOS application security analysis method and device | |
| Antunes et al. | Evaluating and improving penetration testing in web services | |
| Chang et al. | Validating system properties exhibited in execution traces | |
| US20170142145A1 (en) | Computation apparatus and method for identifying attacks on a technical system on the basis of events of an event sequence | |
| Laranjeiro et al. | Experimental robustness evaluation of JMS middleware | |
| Basso et al. | An investigation of java faults operators derived from a field data study on java software faults | |
| CN116992453A (en) | Method and system for automatically positioning vulnerability root cause based on Hash stack |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| RJ01 | Rejection of invention patent application after publication |
Application publication date: 20200228 |
|
| RJ01 | Rejection of invention patent application after publication |