CN113438273A - User-level simulation method and device for application program in Internet of things equipment - Google Patents
User-level simulation method and device for application program in Internet of things equipment Download PDFInfo
- Publication number
- CN113438273A CN113438273A CN202110555943.0A CN202110555943A CN113438273A CN 113438273 A CN113438273 A CN 113438273A CN 202110555943 A CN202110555943 A CN 202110555943A CN 113438273 A CN113438273 A CN 113438273A
- Authority
- CN
- China
- Prior art keywords
- application program
- program
- tested
- environment
- file
- 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.)
- Granted
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
-
- 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/3684—Test management for test design, e.g. generating new test cases
-
- 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
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/14—Network analysis or design
- H04L41/145—Network analysis or design involving simulating, designing, planning or modelling of a network
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- Quality & Reliability (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computer Hardware Design (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Health & Medical Sciences (AREA)
- Computing Systems (AREA)
- General Health & Medical Sciences (AREA)
- Medical Informatics (AREA)
- Debugging And Monitoring (AREA)
Abstract
The invention discloses a user-level simulation method and a user-level simulation device for application programs in Internet of things equipment, wherein the user-level simulation method comprises the following steps: unpacking the firmware of the Internet of things equipment, and identifying the application program to be detected according to the obtained file system; acquiring the environment dependence required by the application program to be tested; according to the environment dependence, constructing and initializing an operation environment; and after limiting the execution resources of the operating environment, executing the simulation of the application program to be tested. The method abstracts the running environment limit on which the program depends as a model, can test the program at lower cost, can customize fine granularity according to different requirements of test equipment and target service, and has the characteristics of strong expansibility, high efficiency, good universality and low coupling.
Description
Technical Field
The invention relates to the technical field of user-level simulation, in particular to a user-level simulation method and device for an application program in equipment of the Internet of things, mainly aiming at solving the bottleneck of operating the application program in the equipment of the Internet of things through simulation aiming at the difficulty of simulating the application program in the equipment of the Internet of things, and providing a system call virtualization scheme to improve the success rate of the simulation.
Background
Whether the function of the program is verified or the safety test is carried out, the code is required to be run for verification, but the test carried out by using the entity equipment has certain defects, on one hand, the resource of the entity equipment is limited, and the cost is higher; on the other hand, the entity equipment is unstable in operation, and is difficult to acquire the run-time information and perform efficient testing.
Emulation is a technique for executing operating systems or application programs of other architectures, and by means of translating instructions and software to emulate hardware, programs of different architectures can be executed. By executing the heterogeneous architecture program in the simulation environment, information of the program may be obtained for software security analysis. Compared with the use of entity equipment for testing, the simulation technology has the advantages of rich feedback information, controllable test cost and the like, so the simulation technology is widely applied to the fields of program analysis, fuzzy test and the like and is the basis for carrying out the vulnerability analysis of the heterogeneous-architecture program.
Compared with the mature desktop application development, most of the internet of things equipment manufacturers mainly aim at completing the realization of corresponding functions in the process of designing and developing the internet of things equipment software application, and the safety of the equipment is less considered. Meanwhile, due to the fact that the operating environment and the equipment characteristics of the internet of things equipment are different, a set of unified technical framework can hardly be used, a large number of manufacturers use self-developed technical frameworks, and the self-developed technical frameworks which are not strictly audited are inevitably used to bring corresponding safety problems. In order to test and analyze the safety problem of the internet of things equipment, an automatic test environment needs to be constructed through a simulation technology.
In the field of simulation of the internet of things equipment, the simulation technology can be divided into full simulation and partial simulation according to the means of the simulation technology. Full emulation is the emulation of the entire firmware system on the premise that the firmware is acquired. After the simulation mode is put forward for the first time, the range and the efficiency of the fuzzy test of the equipment of the Internet of things are greatly improved.
The simulation problem of the equipment of the internet of things is solved to a certain extent due to the appearance of full simulation, but because the full simulation technology tries to simulate the whole system and introduces complex dependence conditions, a plurality of scenes can not be solved in the operation process of the simulation. Some researchers subsequently propose a partial simulation technology, which only simulates a part of devices of the firmware to realize the effect of overall simulation, thereby reducing the difficulty of simulation.
Partial simulation, also known as hybrid simulation, works on the idea of using a specific simulation tool to simulate a peripheral, redirecting hardware interactions to the actual device. The success rate of simulation test in this way is higher than that of full simulation technology, but the used methods are all used for simulating specific types of equipment, so that the limitation is large.
The simulation is the basis for carrying out automatic testing on programs in the firmware of the equipment of the internet of things, but because the types of the equipment of the internet of things are various and the ecology is relatively closed, the ecological closure of the system and the limited execution environment of the equipment of the internet of things need to be considered when designing a simulation scheme. In general, the following problems need to be solved for simulating the internet of things equipment:
(1) the system is ecologically closed and complex. The existing full-simulation scheme is relatively universal, but the full-system simulation scheme has more dependence and has limitation on the support range. Partial simulation schemes have a higher success rate but sacrifice versatility. To realize a scheme which gives consideration to universality and success rate, the simulation of the Internet of things equipment with a complex ecosystem can be realized.
(2) It is difficult to construct an execution environment required for the program. The user-level scheme is different from the kernel implementation and does not execute the entire system, so the execution environment required by the program needs to be constructed. The missing operating environments can be divided into file systems, devices and the like, and the environments in the file systems are mainly executable files and configuration files; device environments are largely devoid of specific devices, such as storage devices and network devices.
Disclosure of Invention
In order to overcome the existing difficulties, the invention provides an automatic simulation method and device for an application program in equipment of the internet of things.
A user-level simulation method for an application program in equipment of the Internet of things comprises the following steps:
1) unpacking the firmware of the Internet of things equipment, and identifying the application program to be detected according to the obtained file system;
2) acquiring the environment dependence required by the application program to be tested;
3) according to the environment dependence, constructing and initializing an operation environment;
4) and after limiting the execution resources of the operating environment, executing the simulation of the application program to be tested.
Further, the file system includes: executable files, dynamic link library files, and configuration files for the operating system.
Further, the application under test is identified by the following policy:
1) acquiring an executable file of the application program to be detected according to the file system, acquiring the program name and version information of the application program to be detected from the executable file, and identifying the application program to be detected;
2) and acquiring fingerprint characteristics of the plurality of application programs, comparing the fingerprint characteristics with the fingerprint characteristics of the application program to be detected obtained based on the file system, and identifying the application program to be detected.
Further, environmental dependencies include: executable files, configuration files, network devices, and storage devices.
Further, the operating environment is initialized by:
1) acquiring a calling parameter, collecting required information when the application program to be tested runs and shielding unnecessary error reporting information when the application program to be tested runs by utilizing a system calling correction technology;
2) reconstructing a file system necessary for running the application program to be tested based on the file system, the host machine file system, the preset system configuration and the dynamically generated program configuration file;
3) simulating hardware in an operating system kernel layer, and realizing definition of a drive in an operating system software layer;
4) establishing external equipment on which an application program to be tested depends by defining functions in the file _ operations structure, and registering module _ init and module _ exit to realize driving of the external equipment;
5) loading a virtual network card to set a network environment required by the running of an application program to be tested;
6) based on a Linux registration mechanism, corresponding execution logic is registered in an operating system kernel through the collected characteristics of executable files with different architectures.
Further, the function includes: open, release, read, write, mmap, and ioctl.
Further, the method for limiting the execution resources of the operating environment comprises the following steps: : the method comprises the steps of limiting restarting capacity based on a Linux Capability mechanism, limiting the use of system resources by a program based on Control group and setting an isolated environment based on namespace. .
Further, when the simulation of the application program to be tested is executed, if the application program to be tested is a network service program, a request is initiated to the corresponding network service port to check the service running state; and if the application program to be tested is a command line program, checking the running state of the program by checking a return value of the running of the program.
A storage medium having a computer program stored therein, wherein the computer program is arranged to perform the above-mentioned method when executed.
An electronic device comprising a memory having a computer program stored therein and a processor arranged to run the computer to perform the method as described above.
The method of the invention has the following advantages:
(1) the method has strong expansibility. The method abstracts the running environment limit on which the program depends into a model, and when new firmware is encountered, the new model is supplemented according to the standard agreed in the text.
(2) The method has high efficiency and universal applicability. Both full simulation and partial simulation systems need to simulate the whole system, which causes a great deal of performance consumption. The method of the invention simulates at the user level and can test the program with less cost.
(3) The method has low coupling. The method can finely adjust different test targets, and the specific implementation process can customize fine granularity according to different requirements of test equipment and target service, so that the method has expandability and higher flexibility.
Drawings
FIG. 1 is a block diagram of a user-level simulation.
FIG. 2 is a schematic diagram of a user-level emulation based on guest system call virtualization.
Fig. 3 is a flow chart of system call modification.
Detailed Description
The technical solution in the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present invention. 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 invention.
The simulation of the Internet of things equipment can test the Internet of things equipment under the condition that corresponding entity equipment does not exist, and the efficiency of testing the application program in the Internet of things equipment can be effectively improved. How to realize user-level simulation in a plurality of devices without uniform implementation standards and provide support for software vulnerability analysis by using simulation work is a problem worthy of research.
The test object of the method is an application program in the equipment of the Internet of things, and the method is mainly used for simulating the application program in the firmware of the equipment of the Internet of things. For a given piece of internet of things device corresponding firmware and application program therein, the text first identifies the information to be tested. Its execution environment is built by a variety of methods.
The following key problems need to be solved:
key problem 1: how to automatically run simulation flow on application program in equipment of Internet of things
The security analysis of software can be simply divided into two modes, namely dynamic analysis and static analysis, based on whether the software is executed or not.
The static analysis has limited use scenes due to high consumption of computing resources, low accuracy and the like, and the dynamic analysis has become an important part of most software development processes due to the advantages of high testing efficiency, low resource consumption and the like. If the internet of things equipment needs to be subjected to efficient software security testing, dynamic analysis is indispensable content, and network application in the internet of things equipment needs to be simulated, a corresponding equipment running environment needs to be constructed. As mentioned above, the architecture and common operating environment of the internet of things devices are different, custom modified operating systems are usually used, and some custom devices also exist. Therefore, only the execution environments required by the running of the programs are correspondingly constructed, the application program to be tested can be normally run and tested.
Key problem 2: how to support more diverse device emulation
The implementation discloses an automatic simulation method and device for Internet of things equipment. The specific module composition of the device is shown in fig. 1, and comprises a firmware database, a preprocessing module and a user-level simulation module.
The method has the advantages that the file dependence is divided into four layers from bottom to top to complement the missing file, the first layer is used for mounting a firmware file system, and the first layer is an execution basis; the second layer dynamically creates a missing file according to the runtime information, and the layer creates part of the required files on the basis of the executable files; the third layer covers a specific system configuration file, and the third layer is used for normalizing the configuration and facilitating subsequent testing; and the fourth layer is to create a configuration file corresponding to the application according to the analysis of the fingerprint and the configuration file, and the fourth layer is to correct the details on the basis of the previous layer so as to ensure that the program to be tested can normally run.
The invention mainly uses the customized kernel module to realize virtual equipment in a software mode. In the Linux operating system, hardware devices are also treated as files, and have corresponding file standard operations, and similarly, considering that in the design of Linux, the standard of drive definition is only slightly modified several times, and all the drive operations can be enumerated easily. And designing a kernel module according to the drive definition standard, simulating standard operation for realizing a file in a kernel drive mode for each device, and finishing software virtualization realization of hardware by customizing the kernel module.
The method is embodied in several steps as shown in fig. 2, which are described in detail as follows:
step 1: and acquiring a basic application program by unpacking, wherein the known file system format is traversed mainly based on the firmware characteristics, and the unpacking is carried out by using an unpacking method corresponding to the firmware format.
The firmware unpacking realizes the identification and unpacking of the mainstream packing mode, mainly comprises the firmware unpacking of different file system formats such as Ar, YAFFS2, JFFS2, SquashFS, CramFS, ROMFS and the like, and can extract the core file system through the unpacking. For encrypted firmware, the system is internally provided with a part of characteristics of a known encryption algorithm and a corresponding decryption algorithm for decrypting and then unpacking the firmware.
Step 2: and identifying the application program for the unpacked file system through a preset identification algorithm. The identification algorithm is based on program feature identification, and the method presets a plurality of groups of features according to the program name of the program and information such as specific character strings, data segments and the like in the program, determines whether the program to be detected exists or not in a feature comparison mode, and selects the program.
The system realizes a set of identification modes to acquire the program to be detected, and the identification modes mainly comprise two modes of fingerprint matching and file name searching. After the system filters out the executable files based on the file types, the system identifies the list to be tested to select the files to be tested. The fingerprint identification is based on a manually preset fingerprint, and based on a character string of a specific pattern contained in an executable file, for example, common HTTP programs such as the GoAhead and the lighttpd all contain program name and version information in the executable file in the specific pattern, so that the program to be tested can be obtained in this way. Similarly, for the convenience of identification and testing by developers, common applications usually do not use meaningless strings, but use specific names, such as httpd, telnetd, etc., so that a preset list of filenames can be used to identify the program under test.
And analyzing the running dependence of the corresponding program by means of program analysis. Mainly executable files, configuration files, network devices, storage devices and the like on which the program runs.
The dependency analysis mainly analyzes the dependency of the file and the network, and the module obtains information such as file dependency, network dependency, equipment dependency and the like required by the starting of the program to be tested through the analysis of the system starting script, the drive file and the analysis of the program to be tested. And after the dependency is analyzed, the method is used for establishing a corresponding file runtime environment, a corresponding network environment and a corresponding virtual equipment environment for use. The file operation environment mainly comprises various device files and configuration files, the network environment mainly comprises a network card for system test, and the virtual device environment corresponds to peripheral equipment required by a program.
And step 3: as shown in fig. 3, the system call virtualization technology sequentially performs several operations, such as file system reconstruction, hardware simulation based on a customized kernel module, and transparent process start, based on the system call operation correction technology, to complete virtualization of the system call.
The system call correction technology is mainly used for controlling and analyzing system call based on ptrace, on one hand, parameters of the system call are obtained, on the other hand, the result of the system call is controlled, information required by program operation is collected, and meanwhile, unnecessary error reporting information is shielded.
On the basis of a system call correction technology, a file system necessary for program operation is rebuilt based on a file system unpacked by firmware, a file system of a host machine, preset system configuration and a dynamically generated program configuration file.
The basic configuration files of the system comprise important user-related configurations such as password and shadow, network-related configurations such as a DNS (domain name system) server and time-related configurations such as TZ (time zone) and localme. The files have relatively fixed formats, and corresponding configuration files are preset in the system for unifying the test environments.
The dynamically generated configuration file is generated by two modes, firstly, the dynamically generated configuration file corresponds to a program with a fingerprint in the system, the system identifies the program according to the fingerprint, creates a corresponding configuration file, and executes the program by using the configuration file. If the execution is not successful, other alternative configuration files under the same fingerprint are used for testing. When all the configuration files can not be executed successfully, analyzing the system script in the firmware, mainly initializing the files, finding out the generation mode of the configuration files and the execution parameters of the program from the system script, and executing the configuration files correspondingly to create the configuration files.
The hardware is simulated in an operating system kernel layer based on software implementation, the definition of driving is realized in a software layer by establishing a model of the equipment, and the equipment requirement required by program operation is met through the driving.
Regarding an external device on which a program depends, the external device is regarded as an IO model, and is established through a file _ operations structure, and the implementation of functions such as open, release, read, write, mmap, ioctl and the like of the structure needs to be defined. In addition, the driver needs to register module _ init and module _ exit for simulating operations at device initialization and logoff.
Besides the storage device, the network device such as a network card is also an important dependence for the system to run, and the system sets the network environment required by the program to run by loading a corresponding virtual network card.
The process transparent starting technology is based on a Linux registration mechanism, corresponding execution logic is registered in an operating system kernel based on the characteristics of collected executable files with different architectures, and the execution logic is transferred to a running environment customized in the text when the running of the different architecture program is triggered, so that the different architecture program can be normally executed.
And 4, step 4: since the system call of the program to be tested is realized after the host is converted, the simulation environment needs to be isolated to a certain extent to prevent the converted system call from affecting the host environment. Before the simulation starts, the Capability of the whole environment which is possibly influenced by restarting and the like is limited based on a Linux Capability mechanism, the use amount of computing resources, memory resources and the like of the environment is limited, a file system is protected, and the influence of the simulation system on a host system is prevented. Also, part of the program checks whether it owns the root right. This document further limits the ability to invoke resources, affect the host environment, and the like. In addition, in order to prevent the tested network environment from influencing the host machine environment, an isolated network environment is set based on the virtual network card.
And 5: if the target is a network service program, the written test program is used for sending a request message of a corresponding protocol, and if a corresponding port returns a correct response corresponding to the protocol, the simulation is considered to be successful, otherwise, the simulation is considered to be failed. If the target is a command line program, when the correct result is output and no error is reported, the simulation is considered to be successful.
Experimental data
The system obtains 7989 firmware from 46 manufacturers as a test set in a crawler crawling mode, and the firmware is used for verifying the generation efficiency of the test mode and actual test experiments. Most of the firmware data sets are the firmware of the routing equipment, and the firmware of some cameras and NAS is also included. The firmware comprises i386, ARM, MIPS and PowerPC, and has a plurality of corresponding architectures such as 32 bits, 64 bits, a size end and the like.
The simulation capability is measured by taking the application program as a dimension, and the standard for judging whether the application program is simulated successfully by the system is as follows: and sending a request message of the corresponding protocol by using the written test program, and if the corresponding port returns a correct response corresponding to the protocol, considering that the simulation is successful, otherwise, considering that the simulation is failed.
In this standard, 7020 firmware successfully simulates all the programs to be tested selected based on the fingerprint library, 951 firmware has a part of the programs to be tested which are not simulated successfully, 1 firmware has all the programs to be tested which are not simulated successfully, and 17 firmware does not find the programs to be tested.
Compared with the current representative working Firmadyne, only 1971 firmware in 8617 firmware can successfully access the network, the proportion is only 22.9%, and the system data is greatly improved.
The above examples are provided only for the purpose of describing the present invention, and are not intended to limit the scope of the present invention. The scope of the invention is defined by the appended claims. Various equivalent substitutions and modifications can be made without departing from the spirit and principles of the invention, and are intended to be within the scope of the invention.
Claims (10)
1. A user-level simulation method for an application program in equipment of the Internet of things comprises the following steps:
1) unpacking the firmware of the Internet of things equipment, and identifying the application program to be detected according to the obtained file system;
2) acquiring the environment dependence required by the application program to be tested;
3) according to the environment dependence, constructing and initializing an operation environment;
4) and after limiting the execution resources of the operating environment, executing the simulation of the application program to be tested.
2. The method of claim 1, wherein the file system comprises: executable files, dynamic link library files, and configuration files for the operating system.
3. The method of claim 1, wherein the application under test is identified by the following policy:
1) acquiring an executable file of the application program to be detected according to the file system, acquiring the program name and version information of the application program to be detected from the executable file, and identifying the application program to be detected;
2) and acquiring fingerprint characteristics of the plurality of application programs, comparing the fingerprint characteristics with the fingerprint characteristics of the application program to be detected obtained based on the file system, and identifying the application program to be detected.
4. The method of claim 1, wherein the context dependencies comprise: executable files, configuration files, network devices, and storage devices.
5. The method of claim 1, wherein the operating environment is initialized by:
1) acquiring a calling parameter, collecting required information when the application program to be tested runs and shielding unnecessary error reporting information when the application program to be tested runs by utilizing a system calling correction technology;
2) reconstructing a file system necessary for running the application program to be tested based on the file system, the host machine file system, the preset system configuration and the dynamically generated program configuration file;
3) simulating hardware in an operating system kernel layer, and realizing definition of a drive in an operating system software layer;
4) establishing external equipment on which an application program to be tested depends by defining functions in the file _ operations structure, and registering module _ init and module _ exit to realize driving of the external equipment;
5) loading a virtual network card to set a network environment required by the running of an application program to be tested;
6) based on a Linux registration mechanism, corresponding execution logic is registered in an operating system kernel through the collected characteristics of executable files with different architectures.
6. The method of claim 5, wherein the function comprises: open, release, read, write, mmap, and ioctl.
7. The method of claim 1, wherein the method of limiting execution resources of the runtime environment comprises: the method comprises the steps of limiting restarting capacity based on a Linux Capability mechanism, limiting the use of system resources by a program based on Control group and setting an isolated environment based on namespace.
8. The method of claim 1, wherein when the simulation of the application program to be tested is performed, if the application program to be tested is a web service program, the service operation state is checked by making a request to a corresponding web service port; and if the application program to be tested is a command line program, checking the running state of the program by checking a return value of the running of the program.
9. A storage medium having a computer program stored thereon, wherein the computer program is arranged to, when run, perform the method of any of claims 1-8.
10. An electronic device comprising a memory having a computer program stored therein and a processor arranged to run the computer program to perform the method according to any of claims 1-8.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110555943.0A CN113438273B (en) | 2021-05-21 | 2021-05-21 | User-level simulation method and device for application program in Internet of things equipment |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110555943.0A CN113438273B (en) | 2021-05-21 | 2021-05-21 | User-level simulation method and device for application program in Internet of things equipment |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN113438273A true CN113438273A (en) | 2021-09-24 |
| CN113438273B CN113438273B (en) | 2022-08-16 |
Family
ID=77802573
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202110555943.0A Active CN113438273B (en) | 2021-05-21 | 2021-05-21 | User-level simulation method and device for application program in Internet of things equipment |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN113438273B (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114185615A (en) * | 2021-12-08 | 2022-03-15 | 北京天融信网络安全技术有限公司 | Audit system-based function extension method and device |
Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102567198A (en) * | 2010-12-30 | 2012-07-11 | 中国移动通信集团公司 | System and method for testing application program in physical system environment |
| CN102930210A (en) * | 2012-10-14 | 2013-02-13 | 江苏金陵科技集团公司 | System and method for automatically analyzing, detecting and classifying malicious program behavior |
| US20180165451A1 (en) * | 2015-06-16 | 2018-06-14 | Nec Corporation | Analysis system, analysis method, analysis device, and storage medium |
| CN111597109A (en) * | 2020-04-24 | 2020-08-28 | 清华大学 | Defect detection method and system for cross-architecture firmware stack memory |
| CN112241311A (en) * | 2020-10-22 | 2021-01-19 | 杭州安恒信息技术股份有限公司 | Firmware simulation method and device, electronic equipment and readable storage medium |
| CN112287342A (en) * | 2020-09-23 | 2021-01-29 | 北京沃东天骏信息技术有限公司 | Internet of things firmware dynamic detection method and device, electronic equipment and storage medium |
| CN112417461A (en) * | 2020-12-07 | 2021-02-26 | 北京梆梆安全科技有限公司 | Fuzzy test method and system for equipment firmware |
-
2021
- 2021-05-21 CN CN202110555943.0A patent/CN113438273B/en active Active
Patent Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102567198A (en) * | 2010-12-30 | 2012-07-11 | 中国移动通信集团公司 | System and method for testing application program in physical system environment |
| CN102930210A (en) * | 2012-10-14 | 2013-02-13 | 江苏金陵科技集团公司 | System and method for automatically analyzing, detecting and classifying malicious program behavior |
| US20180165451A1 (en) * | 2015-06-16 | 2018-06-14 | Nec Corporation | Analysis system, analysis method, analysis device, and storage medium |
| CN111597109A (en) * | 2020-04-24 | 2020-08-28 | 清华大学 | Defect detection method and system for cross-architecture firmware stack memory |
| CN112287342A (en) * | 2020-09-23 | 2021-01-29 | 北京沃东天骏信息技术有限公司 | Internet of things firmware dynamic detection method and device, electronic equipment and storage medium |
| CN112241311A (en) * | 2020-10-22 | 2021-01-19 | 杭州安恒信息技术股份有限公司 | Firmware simulation method and device, electronic equipment and readable storage medium |
| CN112417461A (en) * | 2020-12-07 | 2021-02-26 | 北京梆梆安全科技有限公司 | Fuzzy test method and system for equipment firmware |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114185615A (en) * | 2021-12-08 | 2022-03-15 | 北京天融信网络安全技术有限公司 | Audit system-based function extension method and device |
Also Published As
| Publication number | Publication date |
|---|---|
| CN113438273B (en) | 2022-08-16 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11216256B2 (en) | Determining based on static compiler analysis that execution of compiler code would result in unacceptable program behavior | |
| Cheng et al. | DTaint: detecting the taint-style vulnerability in embedded device firmware | |
| US12008386B2 (en) | Conservative class preloading for real time java execution | |
| US8356285B2 (en) | Facilitated introspection of virtualized environments | |
| US20050108562A1 (en) | Technique for detecting executable malicious code using a combination of static and dynamic analyses | |
| CN115062309B (en) | Vulnerability mining method based on equipment firmware simulation in novel power system and storage medium | |
| Cotroneo et al. | Evolutionary fuzzing of android OS vendor system services | |
| CN107368739B (en) | Kernel drive monitoring method and device | |
| CN114969760A (en) | Vulnerability detection method and device, computer readable medium and electronic equipment | |
| CN113438273B (en) | User-level simulation method and device for application program in Internet of things equipment | |
| Peng et al. | {GLeeFuzz}: Fuzzing {WebGL} Through Error Message Guided Mutation | |
| EP4160455A1 (en) | Behavior analysis based on finite-state machine for malware detection | |
| CN115544518A (en) | Vulnerability scanning engine implementation method and device, vulnerability scanning method and electronic equipment | |
| Zhu et al. | Dytaint: The implementation of a novel lightweight 3-state dynamic taint analysis framework for x86 binary programs | |
| Bhardwaj et al. | Fuzz testing in stack-based buffer overflow | |
| Yao et al. | Research on IoT device vulnerability mining technology based on static preprocessing and coloring analysis | |
| Liu et al. | Automated vulnerability detection in embedded devices | |
| EP4312401A1 (en) | Methods and systems for analyzing environment-sensitive malware with coverage-guided fuzzing | |
| Xu et al. | Framework for State‐Aware Virtual Hardware Fuzzing | |
| Greco et al. | Firmware Dynamic Analysis Through Rewriting | |
| CN112528273B (en) | Medical data detection method, device, medium and electronic equipment | |
| US11989291B2 (en) | System, method, and apparatus for software verification | |
| Fortino et al. | Enabling Faster Security Assessment of Re-hosted Firmware | |
| Liu et al. | A lightweight IoT firmware vulnerability detection scheme based on homology detection | |
| Zhang et al. | Memory corruption vulnerabilities detection for android binary software |
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 | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |