CN118034850A - Simulation method of Internet of things firmware network service program based on QEMU - Google Patents

Abstract

The invention relates to a simulation method of a QEMU-based Internet of things firmware network service program, which comprises the following steps: extracting a corresponding root file system from the physical networking firmware by using a firmware extraction tool; identifying a framework in the root file system, and finding out a corresponding network service program through a starting script; finding out a simulation template of a corresponding architecture in a simulation database, constructing a simulation starting command of a corresponding network service program, and sending the simulation starting command to a QEMU simulator; starting simulation in the QEMU simulator, recording simulation data, and monitoring errors by using a serial port; the error processing mechanism is responsible for processing the error report acquired by the serial port, selecting a corresponding scheme according to the information provided by the serial port to perform automatic processing, and returning to the step four to start simulation after processing. The invention uses an automatic error processing mechanism to process common kernel and hardware errors in the firmware network service program of the Internet of things, thereby improving the simulation accuracy and success rate.

Description

Simulation method of Internet of things firmware network service program based on QEMU

Technical Field

The invention relates to the technical field of the Internet of things, in particular to a simulation method of an Internet of things firmware network service program based on QEMU.

Background

The Internet of things firmware refers to a bottom layer driver on the hardware of the Internet of things device, and the bottom layer driver comprises multiple functions such as a BIOS (basic input output system), a root file system and the like. These drivers are typically published along with the release of the internet of things device and may be updated for iteration by the vendor. Most of the internet of things devices, such as home cameras, routers, intelligent door locks, and the like, cannot basically adopt the X86 architecture commonly found in desktop computers due to low power consumption and the like. Therefore, most of the internet of things devices adopt an ARM and MIPS architecture, which also causes that firmware programs in the internet of things devices cannot normally run on a desktop computer. And firmware emulation techniques are one solution to the problem under different architectures.

Firmware emulation techniques typically accomplish instruction translation under different architectures through dynamic translation mechanisms within the corresponding emulators (e.g., QEMUs) to achieve the effect of running programs of one architecture under another architecture. While the emulator can accomplish inter-instruction translation, the normal operation of the program also requires the hardware requirements of the program and the kernel link library requirements, which is not possible with the typical emulator.

The related components of the kernel are provided when the kernel link library needs to be simulated, and different kernel link libraries have different differences, so that a unified kernel link library cannot be used for processing a program, and the corresponding kernel components need to be adopted one by one. The hardware requirements require more and this aspect is further complicated by the different standards of different hardware vendors. Most mainstream vendors today provide hardware with hardware abstraction layer (Hardware Abstract Layer, HAL) components so that a number of firmware programs can obtain corresponding hardware responses through the hardware abstraction layer's APIs. The technology is advanced, so that the program does not need to realize the hardware interaction logic of the bottom layer; but this technique does not fully cover all hardware and is not applied to simulations. At present, part of hardware still has no hardware abstraction layer, and when the program needs to respond to the hardware, the hardware virtualization technology of the QEMU can manufacture a virtual hardware to respond to the corresponding program needs, so that the problem in the aspect is solved. However, this solution is time consuming and requires manual handling to resolve.

Through the above analysis, the problems and defects existing in the prior art are as follows:

(1) The common simulator does not adopt an error processing mechanism of a kernel and hardware, so that the situation that the problem needs to be manually solved during simulation is more. Many kernel problems can be handled by automated rules because of the high degree of repetition.

(2) The API of the hardware abstraction layer is not used for solving the hardware error occurring during the simulation, so that the convenient function of the hardware abstraction layer is wasted.

(3) Hardware virtualization technology of QEMU is a convenient solution when operated manually, but this process is not automated. Meanwhile, the hardware virtualization technology of the QEMU is not combined with the hardware abstraction layer API technology, and if the hardware virtualization technology and the hardware abstraction layer API technology are combined, a wider effect can be achieved on solving the problem of simulation hardware.

Disclosure of Invention

The invention provides a simulation method of a firmware network service program of an Internet of things based on QEMU, which combines a kernel error processing scheme, hardware abstraction layer API utilization and a hardware virtualization scheme, and improves the stability and reliability of simulation.

In order to achieve the above purpose, the invention adopts the following technical scheme:

a simulation method of a QEMU-based Internet of things firmware network service program comprises the following steps:

Extracting a corresponding root file system from the physical networking firmware by using a firmware extraction tool;

Step two, identifying the architecture in the root file system, and finding out the corresponding network service program through the starting script;

Step three, finding out a simulation template of a corresponding architecture in a simulation database, constructing a simulation starting command of a corresponding network service program, and sending the simulation starting command to a QEMU simulator;

step four, starting simulation in the QEMU simulator, recording simulation data, and monitoring errors by using a serial port;

and fifthly, the error processing mechanism is responsible for processing error reporting acquired by the serial port, selecting a corresponding scheme according to information provided by the serial port to perform automatic processing, and returning to the step four to start simulation after processing.

Further, in step one, the firmware extraction tool will identify file information in the firmware through the magic number, so as to locate the relative position of the root file system and perform iterative extraction, and the proposed file system is divided into an instruction set and other files.

Further, in step two, the architecture information of the system is obtained by identifying the corresponding file of the file system instruction set, and at the same time, the scanner will scan rcS the corresponding start script, learn the absolute path of the firmware network service related program, and record the corresponding information in the simulation database.

Further, in step three, through the architecture information, the simulation database selects a simulation kernel and a complete instruction set of a corresponding architecture from the architecture information to replace and repair an original instruction set, and the simulation database uses a corresponding network service program as a simulation target and completes the construction of the QEMU simulation command by adopting a QEMU operation instruction of the corresponding architecture.

Further, in step four, after the building of the QEMU simulation command is completed, the corresponding web service program and the corresponding command will be sent to the QEMU simulator to perform simulation, and the QEMU will use the serial port provided by the command to perform error monitoring, and record the corresponding data into the simulation database.

Further, in step five, if the QEMU serial port monitors a corresponding error, the QEMU emulator will use an error handling mechanism to process the error.

Further, the error handling mechanism includes:

A start-up and kernel-error handling scheme,

The hardware abstraction layer API processing scheme,

QEMU hardware virtualization processing scheme.

Further, the starting and kernel error processing scheme includes:

The starting component processing module is used for processing the file directory or file missing problem and failing to find the corresponding initializing file problem;

The kernel component processing module is used for processing the problem of lack of a corresponding kernel module and the problem of incorrect kernel version;

The network component configuration processing module is used for processing IP configuration errors, lack of network information, multiple network interface conflicts, VLAN errors and IPTables rule errors.

Further, the hardware abstraction layer API processing scheme includes:

When the serial port of the QEMU monitors errors, the code detector analyzes source codes of the errors and records related codes, and after error reporting codes are acquired, the code detector generates a Handler for the error reporting codes in a specific format, wherein the Handler contains various information of the error reporting codes; the code detector sends the Handler into a HALAPI library for searching, and if the corresponding Handler is not found in the library, the code detector enters a QEMU hardware virtualization operation flow; if the corresponding Handler is found in the library, the corresponding type Handler is extracted and sent to the HALAPI replacement component to work.

Further, the QEMU hardware virtualization processing scheme includes:

When the Handler generated by the code detector cannot find the corresponding HAL API in the HAL API library, the error correction is completed by adopting the characteristic of QEMU hardware virtualization, and the workflow of the QEMU hardware virtualization component is as follows:

Identifying the type of the generated Handler, and judging which type of hardware the Handler belongs to; and searching a hardware template of a corresponding category in a hardware template library virtualized by the QEMU hardware, filling information in a Handler into the hardware template by the QEMU hardware virtualization component, and compiling the QEMU to obtain corresponding virtualized hardware, wherein the virtualized hardware is performed by the QEMU through simulation feedback.

The invention has the beneficial effects that:

the invention combines the kernel and hardware error processing scheme, and can simulate the error processing mechanism of the firmware of the Internet of things without damaging the logic in the program. The mechanism needs to ensure that the program can normally start the corresponding service, and meanwhile, the service is close to the actual service working situation of the program as much as possible. The mechanism comprises a kernel dependency problem when a processing program is started, and meanwhile, the hardware requirement when simulation is processed through an API of a hardware abstraction layer is needed, and the requirement of corresponding hardware of the program can be met through a hardware virtualization technology of a QEMU under the condition that the corresponding hardware abstraction layer API cannot be found.

The invention extracts the corresponding IoT firmware and obtains the root file system through the extractor, then obtains the architecture information of the root file system and the network service program to be emulated through the identifier, and obtains the corresponding data from the emulation database to generate the QEMU operation instruction. After QEMU initiates the simulation, the mechanism of the core of the present invention will be used: error handling mechanism at the time of simulation. The mechanism solves two types of errors commonly encountered in simulation through three schemes: boot and kernel errors and program demand hardware errors. The startup and kernel error handling mechanism will solve the startup and kernel error problems using the common methods of QEMU, and the hardware abstraction layer API method and QEMU hardware virtualization method will solve the program demand hardware errors. Meanwhile, in the process of solving the error, the simulation data is recorded through a simulation database so as to facilitate the subsequent simulation.

According to the QEMU-based hardware virtualization technology and the hardware abstraction layer API method, an automatic error processing mechanism is used for processing common kernel and hardware errors in the network service program of the Internet of things firmware, so that the simulation accuracy and success rate are improved, and the simulation stability and reliability of the network service program are ensured.

Drawings

Fig. 1 is a schematic diagram of a simulation method of a QEMU-based internet of things firmware web service program of the present invention.

FIG. 2 is a specific flow diagram of the boot and kernel error handling in an error handling mechanism implemented in accordance with the present invention.

FIG. 3 is a flow chart illustrating the implementation of the error handling mechanism of the present invention in program-required hardware errors.

Detailed Description

The invention provides a simulation method of a firmware network service program of an Internet of things based on QEMU, which combines a kernel error processing scheme, hardware abstraction layer API utilization and a hardware virtualization scheme, improves the stability and reliability of simulation, and comprises the following steps:

Extracting a corresponding root file system from the physical networking firmware by using a firmware extraction tool;

Step two, identifying the architecture in the root file system, and finding out the corresponding network service program through the starting script;

Step three, finding out a simulation template of a corresponding architecture in a simulation database, constructing a simulation starting command of a corresponding network service program, and sending the simulation starting command to a QEMU simulator;

step four, starting simulation in the QEMU simulator, recording simulation data, and monitoring errors by using a serial port;

and fifthly, the error processing mechanism is responsible for processing error reporting acquired by the serial port, selecting a corresponding scheme according to information provided by the serial port to perform automatic processing, and returning to the step four to start simulation after processing.

Further, in step one, the firmware extraction tool will identify file information in the firmware through the magic number, so as to locate the relative position of the root file system and perform iterative extraction, and the proposed file system is divided into an instruction set and other files.

Further, in step two, the architecture information of the system is obtained by identifying the corresponding file of the file system instruction set, and at the same time, the scanner will scan rcS the corresponding start script, learn the absolute path of the firmware network service related program, and record the corresponding information in the simulation database.

Further, in step three, through the architecture information, the simulation database selects a simulation kernel and a complete instruction set of a corresponding architecture from the architecture information to replace and repair an original instruction set, and the simulation database uses a corresponding network service program as a simulation target and completes the construction of the QEMU simulation command by adopting a QEMU operation instruction of the corresponding architecture.

Further, in step four, after the building of the QEMU simulation command is completed, the corresponding web service program and the corresponding command will be sent to the QEMU simulator to perform simulation, and the QEMU will use the serial port provided by the command to perform error monitoring, and record the corresponding data into the simulation database.

Further, in step five, if the QEMU serial port monitors a corresponding error, the QEMU emulator will use an error handling mechanism to process the error.

Further, the error handling mechanism includes:

A start-up and kernel-error handling scheme,

The hardware abstraction layer API processing scheme,

QEMU hardware virtualization processing scheme.

Further, the starting and kernel error processing scheme includes:

The starting component processing module is used for processing the file directory or file missing problem and failing to find the corresponding initializing file problem;

The kernel component processing module is used for processing the problem of lack of a corresponding kernel module and the problem of incorrect kernel version;

The network component configuration processing module is used for processing IP configuration errors, lack of network information, multiple network interface conflicts, VLAN errors and IPTables rule errors.

Further, the hardware abstraction layer API processing scheme includes:

When the serial port of the QEMU monitors errors, the code detector analyzes source codes of the errors and records related codes, and after error reporting codes are acquired, the code detector generates a Handler for the error reporting codes in a specific format, wherein the Handler contains various information of the error reporting codes; the code detector sends the Handler into a HAL API library and searches, and if no corresponding Handler is found in the library, the code detector enters a QEMU hardware virtualization operation flow; if a corresponding Handler is found in the library, the corresponding type Handler is extracted and work is performed in the HAL API replacement component.

Further, the QEMU hardware virtualization processing scheme includes:

When the Handler generated by the code detector cannot find the corresponding HAL API in the HAL API library, the error correction is completed by adopting the characteristic of QEMU hardware virtualization, and the workflow of the QEMU hardware virtualization component is as follows:

Identifying the type of the generated Handler, and judging which type of hardware the Handler belongs to; and searching a hardware template of a corresponding category in a hardware template library virtualized by the QEMU hardware, filling information in a Handler into the hardware template by the QEMU hardware virtualization component, and compiling the QEMU to obtain corresponding virtualized hardware, wherein the virtualized hardware is performed by the QEMU through simulation feedback.

It should be emphasized that referring to fig. 1-3, one embodiment of the present application, which is applied to a computer device, comprises the following steps:

s1, an extractor extracts a root file system in IoT firmware.

Further, in step S1, the extractor identifies the corresponding file through the corresponding magic number, and obtains other files contained in the file through an iterative manner, thereby extracting the entire root file system.

S2, the identifier identifies the system architecture and the corresponding network service program in the root file system, and records information into the simulation database.

Further, in step S2, the identifier locks the corresponding network service program by using the start script such as the scan rcS and inittab, and records the information into the simulation database.

And S3, the identifier finds a simulation template of a corresponding architecture in the simulation database, constructs a simulation starting command of a corresponding network service program and sends the simulation starting command to the QEMU simulator.

Further, in step S3, the emulation database may use different QEMU startup instructions according to the system architecture information acquired by the identifier, and replace the original root file system instruction set with the corresponding kernel and the corresponding instruction set.

S4, starting QEMU to simulate through QEMU instructions, and monitoring error reporting through a serial port. And if the simulation runs normally, recording simulation data into a simulation database.

S5, if the serial port captures an error, the error is processed by an error processing mechanism.

Further, in step S5, the error handling mechanism will handle from three aspects:

(1) Boot and kernel error handling scheme

When the program is started, other files are required to run or corresponding components of the kernel are required, and the program cannot continue to run after a problem occurs. This scheme may be used for processing at this time. The scheme is divided into three modules to operate:

a. And a starting component processing module:

the module mainly addresses the following two issues: the problem of file directory or file deletion does not find the corresponding initializing file problem.

The problem that the corresponding initialization file cannot be found refers to that when the simulation is started, the corresponding system needs to be acquired from the system initialization files such as rcS, but the corresponding initialization file does not exist in part of the root file system or the initialization file is not the default starting paths such as rcS and inittab. At this time the module will generate a corresponding boot file for the entire root file system, which file will include information such as the initialization program path, console type, root directory, root file system type, or memory size.

A file directory or file missing problem refers to the fact that at the start of a simulation, the program will access some files or directories to obtain relevant information. If such paths do not exist this would result in a crash of the simulation. At this point the module will extract all strings from the rest of the executable binary file in the file system. The module will then obtain them to obtain a string that is most likely to indicate the path, and prepare the file structure according to the path. The module will specifically select some of the strings at the beginning of the universal Unix path, e.g./var or/etc.

B. Kernel component processing module:

The module mainly addresses the following two issues: the lack of corresponding kernel module issues and incorrect kernel version issues.

The lack of the corresponding kernel module refers to that some kernel components are required when some programs are started, and if the corresponding kernel components are absent at this time, simulation errors are caused. However, since the kernel component is accessible through the shared library. Therefore, the module queries the shared library and sends the function with the corresponding component when the program requires the corresponding kernel component.

An incorrect kernel version problem refers to that the emulated program may require a corresponding kernel version, typically due to the kernel version being too low. The module will provide a higher kernel version for the emulated program, but will choose a lower kernel version to emulate as the case may be.

C. the network component configuration processing module:

The network service also causes a series of errors when the simulation is started, which also requires that we have a correlation scheme to solve the start-up error. The module mainly addresses the following five problems: IP configuration errors, lack of network information, multiple network interface collisions, VLAN errors, IPTables rule errors.

An IP configuration error refers to the fact that there is no corresponding IP on the network interface or an absence of IP is pointed to, at which time the program may be executed normally, but no information is monitored. The module will have the emulation system use default routing rules for IP address mapping.

Lack of network information refers to the lack of any information to find a connectable network interface (e.g., eth 0) in the root file system at the time of emulation, which would result in the program not having access to the corresponding network interface. The module will reset the network information by forcing the use of a predetermined default configuration. Further, the module is provided with an ethernet interface eth0 and a specific IP address. When the emulation is initiated, it will override the native network configuration in the root file system.

Multiple network interface conflicts refer to the presence of more network interfaces in the root file system, which may be accessed by a program when requesting network information, resulting in the acceptance of incorrect data and thus simulation errors. The module integrates the data of a plurality of network interfaces by forcedly setting one Ethernet interface, and unifies the transmission data.

VLAN errors refer to errors that occur when the network service program configures VLAN information after the simulation is started. Because the VLAN interface and the ethernet interface have different characteristics, they often need to be configured separately. The module will then provide the correct configuration rules for the VLAN and assign the VLAN ids appropriately.

IPTables rule errors refer to the fact that IPTables rules configured by the root file system intercept some data that would likely affect the proper functioning of the program. The module will then reset IPTables the values in the rules and refresh IPTables all the rules.

(2) Program demand hardware error-hardware abstraction layer API processing scheme

The hardware abstraction layer refers to an operation layer which is specially connected with the bottom layer hardware and designed by a microprocessor manufacturer for a driver program. The abstraction layer can call specific functions from the underlying hardware through some form of API without actually programming the hardware level. This reduces the workload of the developer, and also enables the developer to use the hardware without having much hardware knowledge. But this solution is not well integrated into firmware simulations. In fact, due to the nature of the hardware abstraction layer, its API can be fully viewed as a functional function of hardware when it is independent, and it can function normally even without specific hardware. Therefore, when the simulation encounters an error, the corresponding API can be used to replace the source code, thereby achieving the effect of advanced simulation. The specific flow is as follows:

When the serial port of the QEMU listens for errors, the code detector will analyze the source code of the error and record the relevant code. After the error code is obtained, the code detector generates a Handler for the error code in a specific format, wherein the Handler contains various information of the error code. The code detector will send the Handler into the HAL API library and retrieve the Handler data of all vendors that use HAL using crawlers. If no corresponding Handler is found in the library, entering a QEMU hardware virtualization working flow in the step (3); if a corresponding Handler is found in the library, the corresponding type Handler is extracted and work is performed in the HAL API replacement component.

First, the HAL API replacement component will classify the Handler of the error-prone code. Handers are classified into three categories altogether: IO component module, peripheral component module and direct MMIO request module. The IO component module corresponds to equipment codes such as a network card and a display screen, and the visual characteristic of the part of the Handler is that the part of the Handler can interact with the CPU to a certain degree and has certain data processing capability. The peripheral component module corresponds to hardware devices such as a temperature sensor, an infrared sensor and the like, and the part of the Handler is characterized in that only a small part of data is usually required to be returned, and no interaction or little interaction with the CPU is generated. The direct MMIO request module represents some MMIO requests that directly access memory across the hardware abstraction layer, which may be caused by a developer or may be errors in the program itself. Such requests are not in HAL and are also more difficult to handle by the hardware virtualization scheme of QEMU. Thus, after recognizing the code of the part of MMIO request, we can generate a specific return value for the corresponding Handler, so as to meet the requirement of the program to a certain extent.

(3) Program demand hardware error-QEMU hardware virtualization processing scheme

When the Handler generated by the code detector cannot find the corresponding HAL API in the HAL API library in (2), we will use the nature of QEMU hardware virtualization to accomplish error correction. The workflow of the QEMU hardware virtualization component is as follows:

First, the type of the generated Handler is identified, and which type of hardware the Handler belongs to is judged. Then, searching a hardware template of a corresponding category in the hardware template library of the QEMU hardware virtualization. The QEMU hardware virtualization component fills information in the Handler into the hardware template, and then compiles the QEMU to obtain corresponding virtualized hardware. Finally, the virtualized hardware is subjected to feedback execution of simulation by the QEMU.

In addition, the application also provides an application-level Internet of things firmware simulation execution system and system virtualization software, wherein the application-level Internet of things firmware simulation execution system comprises a microprocessor and a memory which are mutually linked, and the microprocessor is programmed or configured to execute the simulation method of the Internet of things firmware network service program based on QEMU hardware virtualization.

The embodiment of the application also provides a storage medium, wherein the storage medium stores a computer program, and when the computer program runs on a computer, the computer is enabled to execute the simulation method of the Internet of things firmware network service program based on QEMU hardware virtualization.

The embodiment of the application also provides computer equipment, which comprises a general memory and a processor, wherein the memory is electrically connected with the processor, the memory stores a computer program, and the processor is used for executing the simulation method of the Internet of things firmware network service program based on QEMU hardware virtualization by calling the computer program stored in the memory.

The simulation method of the Internet of things firmware network service program based on QEMU hardware virtualization realizes firmware root file system extraction, system architecture detection and network service program identification, realizes QEMU simulation instructions and simulation through a QEMU simulator and a simulation database, and uses three processing rules in an error processing mechanism to respectively and automatically process simulation errors when the simulation encounters the errors. After the processing is completed, the QEMU simulator is adopted again to start simulation, and simulation data of each time are recorded to assist the subsequent simulation flow. The system improves the success rate and the accuracy rate of the simulation of the network service program of the firmware of the Internet of things, and ensures the stability and the reliability of the simulation of the network service.

It will be appreciated by those skilled in the art that embodiments of the present application may be provided as a method, system, or computer program product. Accordingly, the present application may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present application may take the form of a computer program product embodied on one or more computer-readable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein. The present application is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the application. It will be understood that each flow and/or block of the flowchart illustrations and/or block diagrams, and combinations of flows and/or blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks. These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks. These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

The above embodiments are merely illustrative of the preferred embodiments of the present invention and are not intended to limit the scope of the present invention, and various modifications and improvements made by those skilled in the art to the technical solution of the present invention should fall within the scope of protection defined by the claims of the present invention without departing from the spirit of the design of the present invention.

Claims (10)

1. A simulation method of a QEMU-based Internet of things firmware network service program is characterized by comprising the following steps:

Extracting a corresponding root file system from the physical networking firmware by using a firmware extraction tool;

Step two, identifying the architecture in the root file system, and finding out the corresponding network service program through the starting script;

Step three, finding out a simulation template of a corresponding architecture in a simulation database, constructing a simulation starting command of a corresponding network service program, and sending the simulation starting command to a QEMU simulator;

step four, starting simulation in the QEMU simulator, recording simulation data, and monitoring errors by using a serial port;

and fifthly, the error processing mechanism is responsible for processing error reporting acquired by the serial port, selecting a corresponding scheme according to information provided by the serial port to perform automatic processing, and returning to the step four to start simulation after processing.

2. The simulation method of the QEMU-based internet of things firmware web service program according to claim 1, wherein in step one, the firmware extraction tool will identify the file information in the firmware through the big number, thereby locating the relative position of the root file system and performing iterative extraction, and the proposed file system is divided into an instruction set and other files.

3. The simulation method of the firmware network service program of the internet of things based on the QEMU according to claim 1, wherein in the second step, the architecture information of the system is obtained by identifying the corresponding file of the instruction set of the file system, and simultaneously, the scanner will scan rcS the corresponding start script, learn the absolute path of the firmware network service related program, and record the corresponding information in the simulation database.

4. The simulation method of the firmware network service program of the internet of things based on the QEMU according to claim 3, wherein in the third step, through the architecture information, the simulation database replaces and repairs the original instruction set by selecting the simulation kernel and the complete instruction set of the corresponding architecture, and the simulation database takes the corresponding network service program as a simulation target and completes the construction of the QEMU simulation command by adopting the QEMU operation instruction of the corresponding architecture.

5. The simulation method of the firmware network service program of the internet of things based on the QEMU according to claim 4, wherein in the fourth step, after the QEMU simulation command is constructed, the corresponding network service program and the corresponding command are sent to the QEMU simulator to perform simulation, the QEMU performs error monitoring by using the serial port provided by the command, and simultaneously records the corresponding data into the simulation database.

6. The simulation method of the firmware web service program of the QEMU-based internet of things according to claim 5, wherein in the fifth step, if the QEMU serial port monitors a corresponding error, the QEMU simulator uses an error handling mechanism to perform error handling.

7. The simulation method of the QEMU-based internet of things firmware web service program according to claim 6, wherein the error handling mechanism comprises:

A start-up and kernel-error handling scheme,

The hardware abstraction layer API processing scheme,

QEMU hardware virtualization processing scheme.

8. The simulation method of the QEMU-based firmware web service program of the internet of things according to claim 7, wherein the starting and kernel error handling scheme comprises:

The starting component processing module is used for processing the file directory or file missing problem and failing to find the corresponding initializing file problem;

The kernel component processing module is used for processing the problem of lack of a corresponding kernel module and the problem of incorrect kernel version;

The network component configuration processing module is used for processing IP configuration errors, lack of network information, multiple network interface conflicts, VLAN errors and IPTables rule errors.

9. The simulation method of the QEMU-based firmware web service program of the internet of things according to claim 7, wherein the hardware abstraction layer API processing scheme includes:

When the serial port of the QEMU monitors errors, the code detector analyzes source codes of the errors and records related codes, and after error reporting codes are acquired, the code detector generates a Handler for the error reporting codes in a specific format, wherein the Handler contains various information of the error reporting codes; the code detector sends the Handler into a HAL API library and searches, and if no corresponding Handler is found in the library, the code detector enters a QEMU hardware virtualization operation flow; if a corresponding Handler is found in the library, the corresponding type Handler is extracted and work is performed in the HAL API replacement component.

10. The simulation method of the QEMU-based firmware network service program of the internet of things of claim 8, wherein the QEMU hardware virtualization processing scheme comprises:

When the Handler generated by the code detector cannot find the corresponding HAL API in the HAL API library, the error correction is completed by adopting the characteristic of QEMU hardware virtualization, and the workflow of the QEMU hardware virtualization component is as follows:

Identifying the type of the generated Handler, and judging which type of hardware the Handler belongs to; and searching a hardware template of a corresponding category in a hardware template library virtualized by the QEMU hardware, filling information in a Handler into the hardware template by the QEMU hardware virtualization component, and compiling the QEMU to obtain corresponding virtualized hardware, wherein the virtualized hardware is performed by the QEMU through simulation feedback.