CN112241311A - Firmware simulation method and device, electronic equipment and readable storage medium - Google Patents
Firmware simulation method and device, electronic equipment and readable storage medium Download PDFInfo
- Publication number
- CN112241311A CN112241311A CN202011141413.3A CN202011141413A CN112241311A CN 112241311 A CN112241311 A CN 112241311A CN 202011141413 A CN202011141413 A CN 202011141413A CN 112241311 A CN112241311 A CN 112241311A
- Authority
- CN
- China
- Prior art keywords
- firmware
- file
- simulation
- network card
- service
- 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.)
- Withdrawn
Links
- 238000004088 simulation Methods 0.000 title claims abstract description 104
- 238000000034 method Methods 0.000 title claims abstract description 58
- 238000012545 processing Methods 0.000 claims abstract description 51
- 238000004891 communication Methods 0.000 claims description 20
- 238000004590 computer program Methods 0.000 claims description 10
- 230000006870 function Effects 0.000 abstract description 19
- 230000008569 process Effects 0.000 description 10
- 238000010586 diagram Methods 0.000 description 9
- 238000005516 engineering process Methods 0.000 description 5
- 238000004458 analytical method Methods 0.000 description 4
- 230000005236 sound signal Effects 0.000 description 4
- 230000003068 static effect Effects 0.000 description 4
- 230000009471 action Effects 0.000 description 3
- 239000000243 solution Substances 0.000 description 3
- 238000004422 calculation algorithm Methods 0.000 description 2
- 239000000284 extract Substances 0.000 description 2
- 238000002347 injection Methods 0.000 description 2
- 239000007924 injection Substances 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 238000003491 array Methods 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 230000036316 preload Effects 0.000 description 1
- 230000000750 progressive effect Effects 0.000 description 1
- 238000012360 testing method Methods 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
- G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
- G06F21/577—Assessing vulnerabilities and evaluating computer system security
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
- G06F2009/45591—Monitoring or debugging support
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
- G06F2009/45595—Network integration; Enabling network access in virtual machine instances
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- General Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Computer Hardware Design (AREA)
- Computer Security & Cryptography (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Computing Systems (AREA)
- Stored Programmes (AREA)
Abstract
The application discloses a firmware simulation method, a firmware simulation device, electronic equipment and a computer readable storage medium, wherein the method comprises the following steps: acquiring a firmware file and extracting a file system from the firmware file; identifying a service class corresponding to firmware in a file system; obtaining a patch file corresponding to the service type, and performing patch processing by using the patch file to obtain a firmware virtual machine; carrying out simulation processing on the firmware virtual machine to obtain a simulation result; because different firmware is usually based on different hardware environments when providing different services, and some operation functions related to the hardware environments exist in the firmware, in order to improve the simulation success rate, the method utilizes different patch files to carry out targeted patch processing according to different service types, so that the firmware virtual machine is closer to the real condition, and the success rate of simulation processing can be improved.
Description
Technical Field
The present disclosure relates to the field of internet of things, and in particular, to a firmware simulation method, a firmware simulation apparatus, an electronic device, and a computer-readable storage medium.
Background
In the process of vulnerability discovery of the equipment firmware of the internet of things, in order to perform dynamic reverse analysis and program logic analysis on the equipment firmware, simulation of the equipment firmware is often required. In the firmware simulation process, a firmadyne tool (an open source firmware simulation tool) is used in many cases, and the firmadyne is a linux embedded firmware simulation platform based on a qemu system simulator. Due to the lack of hardware environment during simulation, in order to improve the simulation success rate and accuracy, the related art patches the firmware virtual machine by using a general patch, but the simulation success rate of the related art is still low.
Therefore, the problem of low simulation success rate in the related art is a technical problem to be solved by those skilled in the art.
Disclosure of Invention
In view of the above, an object of the present application is to provide a firmware simulation method, a firmware simulation apparatus, an electronic device and a computer-readable storage medium, which improve the success rate of simulation processing.
In order to solve the above technical problem, the present application provides a firmware simulation method, including:
acquiring a firmware file and extracting a file system from the firmware file;
identifying a service class corresponding to firmware in the file system;
obtaining a patch file corresponding to the service type, and performing patch processing by using the patch file to obtain a firmware virtual machine;
and carrying out simulation processing on the firmware virtual machine to obtain a simulation result.
Optionally, the performing emulation processing on the firmware virtual machine includes:
acquiring configuration information of a virtual network card, and locally configuring a first virtual network card by using the configuration information of the virtual network card;
configuring a second virtual network card with a second IP address for the firmware virtual machine, and establishing point-to-point connection between the first virtual network card and the second virtual network card; the second IP address is an IP address of the same subnet network segment as the first IP address corresponding to the first virtual network card;
and performing simulation processing on the firmware virtual machine based on the point-to-point connection.
Optionally, configuring a second virtual network card with a second IP address for the firmware virtual machine, and establishing a point-to-point connection between the first virtual network card and the second virtual network card, includes:
setting a target parameter corresponding to the second virtual network card as a first parameter so as to establish pipeline communication between the first virtual network card and the second virtual network card;
and acquiring the second IP address from the starting parameters, and configuring the second virtual network card by using the second IP address.
Optionally, the method further comprises:
setting a target service backdoor corresponding to the firmware virtual machine; the target service backdoor comprises a telnet service backdoor and a ssh service backdoor.
Optionally, the method further comprises:
and if the simulation fault is detected, controlling the firmware virtual machine by using the target service backdoor.
Optionally, the identifying a service class corresponding to the firmware in the file system includes:
acquiring characteristic information corresponding to the firmware; the characteristic information comprises a characteristic character string and/or a characteristic file name;
and determining the service class by using the characteristic information.
Optionally, the obtaining the patch file corresponding to the service category includes:
determining a category identification corresponding to the service category;
and obtaining the patch file by utilizing the category identification.
The present application further provides a firmware simulation apparatus, including:
the file system acquisition module is used for acquiring the firmware file and extracting a file system from the firmware file;
the service class identification module is used for identifying the service class corresponding to the firmware in the file system;
the patch processing module is used for acquiring a patch file corresponding to the service type and performing patch processing by using the patch file to obtain a firmware virtual machine;
and the simulation module is used for carrying out simulation processing on the firmware virtual machine to obtain a simulation result.
The present application further provides an electronic device comprising a memory and a processor, wherein:
the memory is used for storing a computer program;
the processor is used for executing the computer program to realize the firmware simulation method.
The present application also provides a computer-readable storage medium for storing a computer program, wherein the computer program, when executed by a processor, implements the firmware simulation method described above.
The firmware simulation method provided by the application acquires a firmware file and extracts a file system from the firmware file; identifying a service class corresponding to firmware in a file system; obtaining a patch file corresponding to the service type, and performing patch processing by using the patch file to obtain a firmware virtual machine; and carrying out simulation processing on the firmware virtual machine to obtain a simulation result.
Therefore, after the file system corresponding to the firmware file is extracted, the method detects which services are respectively provided by the firmware, namely, identifies the service type corresponding to the firmware. Since different firmware is usually based on different hardware environments when providing different services, and there are usually some operating functions related to the hardware environments in the firmware. Therefore, in order to improve the success rate of simulation, the patch file corresponding to the service class can be used for patch processing, so that the hardware environment corresponding to the service class is simulated by software, and the operation function related to the hardware environment is specifically processed, so that the operation function can be simulated, and the success rate of simulation is further improved. According to the method, different patch files are utilized to carry out targeted patch processing according to different service types, so that the firmware virtual machine is closer to the real situation, the success rate of simulation processing can be improved, and the problem of low simulation success rate in the related technology is solved.
In addition, the application also provides a firmware simulation device, electronic equipment and a computer readable storage medium, and the beneficial effects are also achieved.
Drawings
In order to more clearly illustrate the technical solutions in the embodiments or related technologies of the present application, the drawings needed to be used in the description of the embodiments or related technologies are briefly introduced below, it is obvious that the drawings in the following description are only embodiments of the present application, and for those skilled in the art, other drawings can be obtained according to the provided drawings without creative efforts.
Fig. 1 is a flowchart of a firmware simulation method according to an embodiment of the present application;
fig. 2 is a schematic diagram of a patch processing flow provided in an embodiment of the present application;
fig. 3 is a schematic diagram of peer-to-peer communication according to an embodiment of the present application;
fig. 4 is a schematic diagram illustrating a target service backdoor injection flow according to an embodiment of the present disclosure;
fig. 5 is a schematic structural diagram of a firmware emulation apparatus according to an embodiment of the present disclosure;
fig. 6 is a schematic structural diagram of an electronic device according to an embodiment of the present application.
Detailed Description
In order to make the objects, technical solutions and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are only a part of the embodiments of the present application, and not all 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.
Referring to fig. 1, fig. 1 is a flowchart of a firmware simulation method according to an embodiment of the present disclosure. The method comprises the following steps:
s101: and acquiring the firmware file and extracting the file system from the firmware file.
It should be noted that, in this embodiment, part or all of the steps of the firmware simulation method may be executed by an executed electronic device, and the specified electronic device is a device for simulating firmware and may be referred to as a host. The electronic device may specifically be a computer, or may be a server, specifically an electronic device with a qemu (virtual operating system simulator) simulator environment and a firmadyne tool. The firmadyne is a linux embedded firmware simulation platform based on a qemu system simulator.
The firmware file may specifically be a bin file, which may correspond to any one or more internet of things devices, such as a router, a camera, and the like. The firmware file is analyzed, and a file system can be extracted from the firmware file, wherein the file system comprises a plurality of firmware corresponding to the firmware file. It should be noted that the firmware mentioned here is not hardware, but an executable file that can run on hardware. In order to solve the problem that the executable file is separated from the hardware and the hardware environment is lost, the problem that the firmware is lost and the hardware environment is not successfully simulated can be solved by using the patch, so that the simulation can be successfully carried out.
It should be noted that the present embodiment does not limit how to extract the file system from the firmware file. In one possible implementation, the firmware file may be formatted and parsed to obtain a file system. In another possible implementation, an image may be generated before format parsing is performed, and the image is then used to obtain the file system.
S102: a class of service corresponding to firmware in the file system is identified.
The same internet of things device may run different services, while different internet of things devices may run the same services, the services being related to the hardware environment of the internet of things device, and the service classes corresponding to the firmware. Therefore, in order to improve the success rate of simulation, the service class corresponding to the firmware can be identified so as to determine the hardware environment corresponding to the firmware, and then targeted patching operation is performed on the hardware environment. The embodiment does not limit the specific way of determining the service class corresponding to the firmware, for example, in a possible implementation, the firmware has a corresponding service class identifier, and the corresponding service class is identified by identifying the service class identifier.
Further, in another possible implementation, the step S102 may include:
step 11: acquiring characteristic information corresponding to the firmware; the characteristic information includes a characteristic character string and/or a characteristic file name.
Step 12: the service class is determined using the characteristic information.
The firmware is an executable file, wherein the content is specifically executed on hardware by the internet of things device, and the firmware has a feature capable of reflecting the service class of the internet of things device, and the feature is feature information. The characteristic information may be a characteristic string, such as a function string unique to a certain service class. The feature information may also be a feature file name, where the file name is a file name of an executable file, and file names of executable files in different internet of things devices may be different. The characteristic information can also take other forms, and the information specifically included in the characteristic information can be in one or more forms, for example, the characteristic information can include both a characteristic character string and a characteristic file name. By the method, the service class corresponding to the firmware can be accurately determined.
S103: and obtaining a patch file corresponding to the service type, and performing patch processing by using the patch file to obtain the firmware virtual machine.
After the service class is determined, a patch file corresponding to the service class may be acquired. It can be understood that, because the hardware environments required by different service classes are different, only the hardware environment required by part of the firmware can be compensated by using the universal patch file for patching, and the hardware environments required by all the components cannot be supplemented, thereby resulting in a low success rate of simulation. In order to solve the problem, when the patch file is acquired, the patch file corresponding to the service type needs to be acquired, the patch file can make up for the hardware environment required by the firmware, and when a plurality of firmware have different service types, different patch files can be adopted for targeted patch processing, so that simulation can be successfully performed on all the firmware.
The patch processing comprises patch operation, and the patch operation is operation for patching a corresponding running environment on the firmware so as to make up for the hardware environment. In a specific embodiment, the patch processing is hook patch processing, and the patch operation is hook operation. In particular, hook operation is used for performing device firmware simulation, some operation functions related to a hardware environment, such as library function nvram _ get, generally exist in a firmware program (i.e. firmware in the present application), and it is generally difficult to directly simulate hardware operation. Therefore, such functions can be hijacked and hook operations can be carried out during simulation, and specific code operations or return values of the functions can be changed. And compiling the dynamic link library program of the same-name function. The LD _ PRELOAD environment variable is changed into a dynamic link library program, and a library function which needs to be loaded when the firmware program runs can be hijacked, so that the firmware program can execute a specified function of hook when the hijacked function is executed, the reliability of hardware environment compensation is improved, and the success rate of simulation is improved.
For example, for a router device of a common Goahead-based web service, when it is detected that the target firmware runs the Goahead service, the patch of the corresponding service is applied to the target firmware. In one embodiment, some hardware operation functions common in the Goahead are hook-hijacked with LD _ PRELAOD environment variables, and the return value of the function is changed. In another embodiment, a patch modification may be made to the binary code of a firmware program using the radius 2 tool.
The specific content of the patch file is not limited, and may be used to specify which functions are subjected to hook patching, or may specify how hook patching is performed, or may be what modification is performed on binary code, for example. The firmware virtual machine may be generated after the patch processing, the firmware virtual machine is located on the host machine and used for performing firmware simulation, and a specific generation manner thereof may refer to related technologies and is not described herein again.
It can be understood that, since there are a plurality of service categories, there are a plurality of corresponding patch files, and the step of obtaining the patch file may include:
step 21: and determining the category identification corresponding to the service category.
Step 22: and obtaining the patch file by utilizing the category identification.
Each service category has a category identifier, and the category identifier corresponds to the patch file, so that the one-to-one correspondence between the service categories and the patch files can be realized. The category identification may specifically be a name of the service category, or may be a number of the service category. The corresponding patch file can be accurately acquired by using the category identification.
Referring to fig. 2, fig. 2 is a schematic diagram illustrating a patch processing flow according to an embodiment of the present disclosure. After identifying the specific application service of the firmware operation, according to the difference of service types, such as the goahead service, the httpd service, etc., a targeted hook patch processing is performed to obtain the processed firmware, and further obtain the firmware virtual machine.
S104: and carrying out simulation processing on the firmware virtual machine to obtain a simulation result.
And after the firmware virtual machine is obtained, performing simulation processing on the firmware virtual machine to further obtain a simulation result. The firmware virtual machine is subjected to targeted patching processing, so that the successful simulation can be ensured, the success rate of the simulation is improved, the obtained simulation result is more reliable, and the specific process of the simulation processing is not limited. Further, in order to prevent the network connection with the host from being disconnected when the firmware virtual machine performs the emulation processing, the embodiment connects the firmware virtual machine and the host in a point-to-point connection manner. Specifically, the step S104 may include:
step 31: and acquiring the configuration information of the virtual network card, and locally configuring the first virtual network card by using the configuration information of the virtual network card.
Step 32: and configuring a second virtual network card with a second IP address for the firmware virtual machine, and establishing point-to-point connection between the first virtual network card and the second virtual network card.
Step 33: and performing simulation processing on the firmware virtual machine based on the point-to-point connection.
It should be noted that the second IP address is an IP address in the same subnet section as the first IP address corresponding to the first virtual network card. In this embodiment, the first virtual network card is a virtual network card used by a host, and specifically may be a tap virtual network card, in which case, the first virtual network card may be a tap0 network card. The virtual network card configuration information may record an IP address, i.e., a first IP address, corresponding to the tap0 network card. The virtual network card configuration information may further specify a subnet section corresponding to the first IP address, so as to configure a second virtual network card in the subsequent process. After the first virtual network card is configured, a second virtual network card having a fixed second IP address may be configured for the firmware virtual machine. After the second virtual network card is configured, a point-to-point connection between the first virtual network card and the second virtual network card can be established, and the firmware virtual machine is subjected to simulation processing based on the point-to-point connection.
Specifically, the step of configuring a second virtual network card with a second IP address for the firmware virtual machine, and establishing a point-to-point connection between the first virtual network card and the second virtual network card may include:
step 41: and setting the target parameter corresponding to the second virtual network card as the first parameter so as to establish pipeline communication between the first virtual network card and the second virtual network card.
Step 42: and acquiring a second IP address from the starting parameters, and configuring the second virtual network card by using the second IP address.
Specifically, the target parameter corresponding to the second virtual network card is a-net parameter, the first parameter is a type parameter corresponding to the first virtual network card, and the pipeline communication can be established between the first virtual network card and the second virtual network card by setting the target parameter as the first parameter. Referring to fig. 3, fig. 3 is a schematic diagram of peer-to-peer communication according to an embodiment of the present disclosure. The second virtual network card is an eth0 network card, and when the first virtual network card is a tap0 virtual network card, the-net parameter can be set to tap, that is, the eth0 network card in the virtual machine and the tap0 virtual network card in the host machine can establish pipeline communication. The startup parameters are used for starting the firmware virtual machine so as to perform simulation processing on the firmware virtual machine. The start parameter may be used to configure the eth0 network card and allocate a static IP to the eth0 network card, and may include a command to configure the eth0 network card and allocate a static IP, for example. The IP address of the eth0 network card is set to be any IP address of the tap0 virtual network card in the same subnet segment, and the first virtual network card and the second virtual network card can establish the network communication from the beginning to the point, namely the point-to-point connection, based on the environment of the qemu simulator. The command for allocating the static IP may be a command for directly specifying the IP, or may be a command for selecting the IP in the subnet section corresponding to the first IP address specified by the virtual network card configuration information. The point-to-point connection is established after the IP address is determined, so that the network connection between the firmware virtual machine and the host machine can be ensured, and the reliability is better compared with the network connection adopting a DHCP (dynamic host configuration protocol).
Further, in order to prevent the uncontrollable condition of the simulation process caused by uncontrollable input or a great number of error reports in the simulation process, before the simulation process, the method may further include:
step 51: setting a target service backdoor corresponding to the firmware virtual machine; the target service backdoor comprises a telnet service backdoor and a ssh service backdoor.
Correspondingly, the method can further comprise the following steps:
step 52: and if the simulation fault is detected, controlling the firmware virtual machine by using the target service backdoor.
The embodiment does not limit the specific way of setting the target service backdoor, for example, the backdoor of the target service may be injected in the target file, and the target service is a communication protocol service. Referring to fig. 4, fig. 4 is a schematic view illustrating a target service backdoor injection flow according to an embodiment of the present disclosure. Specifically, a backdoor of telnet service and ssh service commands can be added to a start script (such as rcS and inittab) in a file system corresponding to the firmware virtual machine, so that even when a simulation fault occurs during firmware simulation, for example, an uncontrollable command line window of the firmware virtual machine is input and a large number of errors occur, normal network communication can be performed between the host and the firmware virtual machine by using the target service backdoor, that is, the firmware virtual machine is controlled and debugged by using other communication protocols. It should be noted that, in this embodiment, the execution sequence of the three steps of setting the target service backdoor, performing the peer-to-peer connection network configuration, and generating the firmware virtual machine is not limited, and for example, the three steps may be executed in parallel, that is, executed simultaneously, or executed serially, that is, executed sequentially.
In summary, this embodiment will describe a specific firmware simulation process. Taking a D-Link DIR-878 router as an example, firstly, a firmware file is obtained, analysis based on a firmware format is carried out on a firmware simulation platform, after a file system obtained after analysis is finished, a shell command related to network configuration of a virtual machine eth0 network card is added into a start script such as rcS, inittab and the like, and meanwhile, a backdoor of service commands such as telnet, ssh and the like is injected into the script. And after searching and analyzing the service operated in the file system, patching is carried out, whether the service needs to be started through hook is judged, and if the hook is determined to be needed, corresponding codes are operated in a hook script according to the corresponding service. After the hook service is completed, simulating the corresponding service of the starting equipment by using a qemu simulator, and testing the simulated service.
By applying the firmware simulation method provided by the embodiment of the application, after the file system corresponding to the firmware file is extracted, services provided by the firmware file are respectively detected, namely, the service type corresponding to the firmware is identified. Since different firmware is usually based on different hardware environments when providing different services, and there are usually some operating functions related to the hardware environments in the firmware. Therefore, in order to improve the success rate of simulation, the patch file corresponding to the service class can be used for patch processing, so that the hardware environment corresponding to the service class is simulated by software, and the operation function related to the hardware environment is specifically processed, so that the operation function can be simulated, and the success rate of simulation is further improved. According to the method, different patch files are utilized to carry out targeted patch processing according to different service types, so that the firmware virtual machine is closer to the real situation, the success rate of simulation processing can be improved, and the problem of low simulation success rate in the related technology is solved.
In the following, the firmware simulation apparatus provided in the embodiments of the present application is introduced, and the firmware simulation apparatus described below and the firmware simulation method described above may be referred to correspondingly.
Referring to fig. 5, fig. 5 is a schematic structural diagram of a firmware emulation device according to an embodiment of the present application, including:
a file system obtaining module 110, configured to obtain a firmware file and extract a file system from the firmware file;
a service class identification module 120, configured to identify a service class corresponding to firmware in the file system;
a patch processing module 130, configured to obtain a patch file corresponding to the service type, and perform patch processing using the patch file to obtain a firmware virtual machine;
and the simulation module 140 is configured to perform simulation processing on the firmware virtual machine to obtain a simulation result.
Optionally, the simulation module 140 includes:
the first configuration unit is used for acquiring the configuration information of the virtual network card and locally configuring the first virtual network card by using the configuration information of the virtual network card;
the second configuration unit is used for configuring a second virtual network card with a second IP address for the firmware virtual machine and establishing point-to-point connection between the first virtual network card and the second virtual network card; the second IP address is an IP address of the same subnet network segment as the first IP address corresponding to the first virtual network card;
and the simulation unit is used for carrying out simulation processing on the firmware virtual machine based on the point-to-point connection.
Optionally, the second configuration unit comprises:
the pipeline communication establishing subunit is used for setting a target parameter corresponding to the second virtual network card as a first parameter so as to establish pipeline communication between the first virtual network card and the second virtual network card;
and the address configuration subunit is used for acquiring the second IP address from the starting parameters and configuring the second virtual network card by using the second IP address.
Optionally, the method further comprises:
the back door setting module is used for setting a target service back door corresponding to the firmware virtual machine; the target service backdoor comprises a telnet service backdoor and a ssh service backdoor.
Optionally, the method further comprises:
and the control module is used for controlling the firmware virtual machine by using the target service backdoor if the simulation fault is detected.
Optionally, the service class identification module 120 includes:
the device comprises a characteristic information acquisition unit, a firmware acquisition unit and a firmware processing unit, wherein the characteristic information acquisition unit is used for acquiring characteristic information corresponding to firmware; the characteristic information comprises a characteristic character string and/or a characteristic file name;
and the class determining unit is used for determining the service class by utilizing the characteristic information.
Optionally, the patch processing module 130 includes:
the identification determining unit is used for determining the category identification corresponding to the service category;
and the patch file acquisition unit is used for acquiring the patch file by utilizing the category identification.
In the following, the electronic device provided by the embodiment of the present application is introduced, and the electronic device described below and the firmware simulation method described above may be referred to correspondingly.
Referring to fig. 6, fig. 6 is a schematic structural diagram of an electronic device according to an embodiment of the present disclosure. Wherein the electronic device 100 may include a processor 101 and a memory 102, and may further include one or more of a multimedia component 103, an information input/information output (I/O) interface 104, and a communication component 105.
The processor 101 is configured to control the overall operation of the electronic device 100 to complete all or part of the steps in the firmware simulation method; the memory 102 is used to store various types of data to support operation at the electronic device 100, such data may include, for example, instructions for any application or method operating on the electronic device 100, as well as application-related data. The Memory 102 may be implemented by any type or combination of volatile and non-volatile Memory devices, such as one or more of Static Random Access Memory (SRAM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Erasable Programmable Read-Only Memory (EPROM), Programmable Read-Only Memory (PROM), Read-Only Memory (ROM), magnetic Memory, flash Memory, magnetic or optical disk.
The multimedia component 103 may include a screen and an audio component. Wherein the screen may be, for example, a touch screen and the audio component is used for outputting and/or inputting audio signals. For example, the audio component may include a microphone for receiving external audio signals. The received audio signal may further be stored in the memory 102 or transmitted through the communication component 105. The audio assembly also includes at least one speaker for outputting audio signals. The I/O interface 104 provides an interface between the processor 101 and other interface modules, such as a keyboard, mouse, buttons, etc. These buttons may be virtual buttons or physical buttons. The communication component 105 is used for wired or wireless communication between the electronic device 100 and other devices. Wireless Communication, such as Wi-Fi, bluetooth, Near Field Communication (NFC), 2G, 3G, or 4G, or a combination of one or more of them, so that the corresponding Communication component 105 may include: Wi-Fi part, Bluetooth part, NFC part.
The electronic Device 100 may be implemented by one or more Application Specific Integrated Circuits (ASICs), Digital Signal Processors (DSPs), Digital Signal Processing Devices (DSPDs), Programmable Logic Devices (PLDs), Field Programmable Gate Arrays (FPGAs), controllers, microcontrollers, microprocessors or other electronic components, and is configured to perform the firmware simulation method according to the above embodiments.
The following describes a computer-readable storage medium provided in an embodiment of the present application, and the computer-readable storage medium described below and the firmware simulation method described above may be referred to correspondingly.
The present application further provides a computer-readable storage medium, on which a computer program is stored, and the computer program, when executed by a processor, implements the steps of the firmware simulation method described above.
The computer-readable storage medium may include: various media capable of storing program codes, such as a usb disk, a removable hard disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), a magnetic disk, or an optical disk.
The embodiments are described in a progressive manner, each embodiment focuses on differences from other embodiments, and the same or similar parts among the embodiments are referred to each other. The device disclosed by the embodiment corresponds to the method disclosed by the embodiment, so that the description is simple, and the relevant points can be referred to the method part for description.
Those of skill would further appreciate that the various illustrative components and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, computer software, or combinations of both, and that the various illustrative components and steps have been described above generally in terms of their functionality in order to clearly illustrate this interchangeability of hardware and software. 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.
The steps of a method or algorithm described in connection with the embodiments disclosed herein may be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two. A software module may reside in Random Access Memory (RAM), memory, Read Only Memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art.
Finally, it should also be noted that, herein, relationships such as first and second, etc., are intended only to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. Also, the terms include, or any other variation is intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that includes a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus.
The principle and the implementation of the present application are explained herein by applying specific examples, and the above description of the embodiments is only used to help understand the method and the core idea of the present application; meanwhile, for a person skilled in the art, according to the idea of the present application, there may be variations in the specific embodiments and the application scope, and in summary, the content of the present specification should not be construed as a limitation to the present application.
Claims (10)
1. A method for simulating firmware, comprising:
acquiring a firmware file and extracting a file system from the firmware file;
identifying a service class corresponding to firmware in the file system;
obtaining a patch file corresponding to the service type, and performing patch processing by using the patch file to obtain a firmware virtual machine;
and carrying out simulation processing on the firmware virtual machine to obtain a simulation result.
2. The firmware emulation method according to claim 1, wherein the performing emulation processing on the firmware virtual machine includes:
acquiring configuration information of a virtual network card, and locally configuring a first virtual network card by using the configuration information of the virtual network card;
configuring a second virtual network card with a second IP address for the firmware virtual machine, and establishing point-to-point connection between the first virtual network card and the second virtual network card; the second IP address is an IP address of the same subnet network segment as the first IP address corresponding to the first virtual network card;
and performing simulation processing on the firmware virtual machine based on the point-to-point connection.
3. The firmware emulation simulation method of claim 2, wherein the configuring a second virtual network card having a second IP address for the firmware virtual machine and establishing a point-to-point connection between the first virtual network card and the second virtual network card comprises:
setting a target parameter corresponding to the second virtual network card as a first parameter so as to establish pipeline communication between the first virtual network card and the second virtual network card;
and acquiring the second IP address from the starting parameters, and configuring the second virtual network card by using the second IP address.
4. The firmware emulation simulation method of claim 1, further comprising:
setting a target service backdoor corresponding to the firmware virtual machine; the target service backdoor comprises a telnet service backdoor and a ssh service backdoor.
5. The firmware emulation simulation method of claim 4, further comprising:
and if the simulation fault is detected, controlling the firmware virtual machine by using the target service backdoor.
6. The method of claim 1, wherein the identifying the class of service corresponding to the firmware in the file system comprises:
acquiring characteristic information corresponding to the firmware; the characteristic information comprises a characteristic character string and/or a characteristic file name;
and determining the service class by using the characteristic information.
7. The firmware emulation simulation method according to claim 1, wherein the obtaining a patch file corresponding to the service class includes:
determining a category identification corresponding to the service category;
and obtaining the patch file by utilizing the category identification.
8. A firmware emulation apparatus, comprising:
the file system acquisition module is used for acquiring the firmware file and extracting a file system from the firmware file;
the service class identification module is used for identifying the service class corresponding to the firmware in the file system;
the patch processing module is used for acquiring a patch file corresponding to the service type and performing patch processing by using the patch file to obtain a firmware virtual machine;
and the simulation module is used for carrying out simulation processing on the firmware virtual machine to obtain a simulation result.
9. An electronic device comprising a memory and a processor, wherein:
the memory is used for storing a computer program;
the processor for executing the computer program to implement the firmware emulation simulation method of any one of claims 1 to 7.
10. A computer-readable storage medium for storing a computer program, wherein the computer program, when executed by a processor, implements the firmware simulation method of any one of claims 1 to 7.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011141413.3A CN112241311A (en) | 2020-10-22 | 2020-10-22 | Firmware simulation method and device, electronic equipment and readable storage medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011141413.3A CN112241311A (en) | 2020-10-22 | 2020-10-22 | Firmware simulation method and device, electronic equipment and readable storage medium |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN112241311A true CN112241311A (en) | 2021-01-19 |
Family
ID=74169956
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202011141413.3A Withdrawn CN112241311A (en) | 2020-10-22 | 2020-10-22 | Firmware simulation method and device, electronic equipment and readable storage medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN112241311A (en) |
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113438273A (en) * | 2021-05-21 | 2021-09-24 | 中国科学院信息工程研究所 | User-level simulation method and device for application program in Internet of things equipment |
| CN113468010A (en) * | 2021-09-02 | 2021-10-01 | 湖北芯擎科技有限公司 | File processing method and device, electronic equipment and computer readable storage medium |
| CN113703920A (en) * | 2021-08-27 | 2021-11-26 | 烽火通信科技股份有限公司 | Hardware simulation method and platform |
| CN113904945A (en) * | 2021-10-15 | 2022-01-07 | 杭州安恒信息技术股份有限公司 | Internet of things equipment simulation debugging method and device, electronic device and storage medium |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN109375945A (en) * | 2018-08-28 | 2019-02-22 | 中国人民解放军国防科技大学 | Firmware version detection method and vulnerability repair rate evaluation method for Internet of things equipment |
| CN110941832A (en) * | 2019-11-28 | 2020-03-31 | 杭州安恒信息技术股份有限公司 | Embedded Internet of things equipment firmware vulnerability discovery method, device and equipment |
| CN111400719A (en) * | 2020-03-12 | 2020-07-10 | 中国科学院信息工程研究所 | Firmware vulnerability distinguishing method and system based on open source component version identification |
-
2020
- 2020-10-22 CN CN202011141413.3A patent/CN112241311A/en not_active Withdrawn
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN109375945A (en) * | 2018-08-28 | 2019-02-22 | 中国人民解放军国防科技大学 | Firmware version detection method and vulnerability repair rate evaluation method for Internet of things equipment |
| CN110941832A (en) * | 2019-11-28 | 2020-03-31 | 杭州安恒信息技术股份有限公司 | Embedded Internet of things equipment firmware vulnerability discovery method, device and equipment |
| CN111400719A (en) * | 2020-03-12 | 2020-07-10 | 中国科学院信息工程研究所 | Firmware vulnerability distinguishing method and system based on open source component version identification |
Non-Patent Citations (1)
| Title |
|---|
| 朱怀东 等: ""基于内存模糊测试的嵌入式固件漏洞检测"", 《计算机工程与设计》, 16 September 2018 (2018-09-16), pages 0 - 4 * |
Cited By (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113438273A (en) * | 2021-05-21 | 2021-09-24 | 中国科学院信息工程研究所 | User-level simulation method and device for application program in Internet of things equipment |
| CN113438273B (en) * | 2021-05-21 | 2022-08-16 | 中国科学院信息工程研究所 | User-level simulation method and device for application program in Internet of things equipment |
| CN113703920A (en) * | 2021-08-27 | 2021-11-26 | 烽火通信科技股份有限公司 | Hardware simulation method and platform |
| CN113703920B (en) * | 2021-08-27 | 2023-08-08 | 烽火通信科技股份有限公司 | Hardware simulation method and platform |
| CN113468010A (en) * | 2021-09-02 | 2021-10-01 | 湖北芯擎科技有限公司 | File processing method and device, electronic equipment and computer readable storage medium |
| CN113904945A (en) * | 2021-10-15 | 2022-01-07 | 杭州安恒信息技术股份有限公司 | Internet of things equipment simulation debugging method and device, electronic device and storage medium |
| CN113904945B (en) * | 2021-10-15 | 2024-04-09 | 杭州安恒信息技术股份有限公司 | Internet of things equipment simulation debugging method and device, electronic device and storage medium |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN112241311A (en) | Firmware simulation method and device, electronic equipment and readable storage medium | |
| CN108959068B (en) | Software interface testing method, device and storage medium | |
| KR102341154B1 (en) | High-speed application for installation on mobile devices for permitting remote configuration of such mobile devices | |
| CN108845930B (en) | Interface operation test method and device, storage medium and electronic device | |
| CN111026645B (en) | User interface automatic test method and device, storage medium and electronic equipment | |
| CN111367534B (en) | Service arrangement method and system based on application environment | |
| CN107678949B (en) | Automatic testing method for realizing different communication modes of embedded equipment | |
| CN109614325B (en) | Method and device for determining control attribute, electronic equipment and storage medium | |
| CN112732587B (en) | Automatic test log acquisition method and device, electronic equipment and storage medium | |
| WO2017020459A1 (en) | Method and apparatus for configuring plugin package for host | |
| CN106648762B (en) | Method and device for building development environment | |
| CN109683997B (en) | Method for accessing application program interface through sandbox, sandbox and sandbox equipment | |
| CN107113199B (en) | Analysis device for analyzing and processing communication sequences | |
| CN112540924A (en) | Interface automation test method, device, equipment and storage medium | |
| CN111770174A (en) | Cloud platform deployment method, device, equipment and readable storage medium | |
| CN116166525A (en) | Method and device for generating test script | |
| CN113986270B (en) | Distributed application deployment method and device, storage medium and electronic equipment | |
| CN111651352A (en) | Warehouse code merging method and device | |
| CN111522749B (en) | Page testing method and device, readable storage medium and electronic equipment | |
| CN109976773B (en) | Deployment method and device of game testing environment | |
| CN111930625A (en) | Log obtaining method, device and system based on cloud service platform | |
| CN113360379B (en) | Program test environment creation method and program test environment creation apparatus | |
| CN115904978A (en) | Redfish interface testing method, computing device and storage medium | |
| CN113986263A (en) | Code automation test method, device, electronic equipment and storage medium | |
| CN113515452A (en) | Automatic test method and system for application, electronic equipment and storage medium |
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 | ||
| WW01 | Invention patent application withdrawn after publication | ||
| WW01 | Invention patent application withdrawn after publication |
Application publication date: 20210119 |