Method, device, electronic device, and medium for analyzing firmware

Abstract

The embodiments of the present disclosure disclose a method, apparatus, electronic device, and medium for analyzing firmware. A specific implementation of the method includes: obtaining the firmware to be analyzed; receiving parameters of external hardware input associated with the firmware to be analyzed; parsing the firmware to be analyzed based on information about the single-chip microcomputer on which the firmware to be analyzed runs, so as to support the firmware to be analyzed running on a virtual machine; using the parameters as input, running the firmware to be analyzed, and generating an operation result, wherein the operation result includes status information of the target hardware in the single-chip microcomputer simulated by the virtual machine. This implementation realizes the adaptive virtualization of single-chip microcomputers connected to different external hardware, and improves the versatility of single-chip microcomputer virtual machines.

Description

Technical Field

[0001] Embodiments of the present disclosure relate to the field of computer technology, and more particularly, to a method, apparatus, electronic device, and medium for analyzing firmware. Background Art

[0002] Firmware analysis typically refers to a technical cracking method that penetrates the underlying hardware (e.g., at the chip level). It is frequently used in practical applications such as system attack and defense, hardware cracking, and reverse engineering. Compared to reverse engineering of common embedded devices, reverse engineering of microcontroller units (MCUs) is typically more tedious and complex because it requires analyzing and debugging every chip-defined I / O interface, supporting circuits, and connected external hardware.

[0003] In the existing technology, reverse analysts can often only forcibly modify the simulation software (Simulator) used for development based on a general open source virtual machine or product provider to adapt to the external hardware connected to the microcontroller to be analyzed, resulting in poor versatility. Summary of the Invention

[0004] Embodiments of the present disclosure provide a method, apparatus, electronic device, and medium for analyzing firmware.

[0005] In a first aspect, an embodiment of the present disclosure provides a method for analyzing firmware, the method comprising: obtaining firmware to be analyzed; receiving parameters of external hardware input associated with the firmware to be analyzed; parsing the firmware to be analyzed based on information of a single-chip microcomputer on which the firmware to be analyzed runs, so as to support the firmware to be analyzed running on a virtual machine; using the parameters as input, running the firmware to be analyzed, and generating an operation result, wherein the operation result includes status information of the target hardware in the single-chip microcomputer simulated by the virtual machine.

[0006] In some embodiments, the above-mentioned parsing of the firmware to be analyzed based on the information of the single-chip microcomputer on which the firmware to be analyzed runs to support the firmware to be analyzed to run on a virtual machine includes: determining the type of the single-chip microcomputer according to the information of the single-chip microcomputer on which the firmware to be analyzed runs; parsing the firmware to be analyzed into a machine language that matches the type; and setting a firmware running environment that matches the type.

[0007] In some embodiments, the above parameters include unconventional parameters for safety testing.

[0008] In some embodiments, the parameters of the external hardware input associated with the firmware to be analyzed include a character string input by a keyboard; and the above-mentioned method of using the parameters as input to run the firmware to be analyzed to generate an operation result includes: comparing the character string with a value in a first memory address located on the virtual machine to generate a first comparison result; in response to determining that the first comparison result is used to indicate inconsistency, comparing the character string with a value in a second memory address located on the virtual machine to generate a second comparison result; and generating an operation result based on the first memory address, the second memory address and the second result.

[0009] In some embodiments, in response to determining that the first comparison result is used to indicate inconsistency, the string is compared with the value in the second memory address located on the virtual machine to generate a second comparison result, the method also includes: sending a command for instructing to update the value in the second memory address; and receiving prompt information for indicating that the value in the second memory address cannot be changed.

[0010] In some embodiments, the above-mentioned taking parameters as input, running the firmware to be analyzed, and generating an operation result includes: receiving instrumentation information associated with the firmware to be analyzed; taking parameters as input, running the firmware to be analyzed according to the instructions of the instrumentation information, and generating an operation result, wherein the operation result includes operation feature data for the code location indicated by the instrumentation information.

[0011] In a second aspect, an embodiment of the present disclosure provides a device for analyzing firmware, comprising: an acquisition unit configured to acquire firmware to be analyzed; a receiving unit configured to receive parameters of external hardware input associated with the firmware to be analyzed; a parsing unit configured to parse the firmware to be analyzed based on information of a single-chip microcomputer on which the firmware to be analyzed runs, so as to support the firmware to be analyzed running on a virtual machine; and a generation unit configured to take the parameters as input, run the firmware to be analyzed, and generate an operation result, wherein the operation result includes status information of the target hardware in the single-chip microcomputer simulated by the virtual machine.

[0012] In some embodiments, the above-mentioned parsing unit includes: a determination module, configured to determine the type of the microcontroller based on information about the microcontroller on which the firmware to be analyzed runs; a parsing module, configured to parse the firmware to be analyzed into a machine language that matches the type; and a setting module, configured to set a firmware running environment that matches the type.

[0013] In some embodiments, the above parameters include unconventional parameters for safety testing.

[0014] In some embodiments, the parameters of the external hardware input associated with the firmware to be analyzed include a character string input by a keyboard; and the generation unit is further configured to: compare the character string with a value in a first memory address located on the virtual machine to generate a first comparison result; in response to determining that the first comparison result is used to indicate inconsistency, compare the character string with a value in a second memory address located on the virtual machine to generate a second comparison result; and generate an operation result based on the first memory address, the second memory address and the second result.

[0015] In some embodiments, the device is further configured to: send a command for instructing to update the value in the second memory address; and receive prompt information for indicating that the value in the second memory address cannot be changed.

[0016] In some embodiments, the generation unit is further configured to: receive instrumentation information associated with the firmware to be analyzed; take parameters as input, run the firmware to be analyzed according to the instructions of the instrumentation information, and generate an operation result, wherein the operation result includes operation feature data for the code location indicated by the instrumentation information.

[0017] In a third aspect, an embodiment of the present disclosure provides an electronic device comprising: one or more processors; a storage device on which one or more programs are stored; when the one or more programs are executed by one or more processors, the one or more processors implement the method described in any implementation method in the first aspect.

[0018] In a fourth aspect, an embodiment of the present disclosure provides a computer-readable medium having a computer program stored thereon, which, when executed by a processor, implements the method described in any implementation manner in the first aspect.

[0019] The embodiments of the present disclosure provide a method, apparatus, electronic device, and medium for analyzing firmware. The firmware to be analyzed is parsed based on information about the single-chip microcomputer on which the firmware to be analyzed runs, and the parameters of the external hardware input associated with the firmware to be analyzed are used as input to run the firmware to be analyzed, so as to generate an operating result for indicating the status information of the target hardware in the single-chip microcomputer virtual machine, thereby realizing adaptive virtualization of single-chip microcomputers connected to different external hardware, improving the versatility of the single-chip microcomputer virtual machine, and realizing analysis and testing of the single-chip microcomputer firmware by passing different parameters, thereby improving the flexibility and efficiency of firmware analysis. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] Other features, objects and advantages of the present disclosure will become more apparent from a reading of the detailed description of non-limiting embodiments made with reference to the following drawings:

[0021] Figure 1is an exemplary system architecture diagram in which an embodiment of the present disclosure may be applied;

[0022] Figure 2 is a flowchart of one embodiment of a method for analyzing firmware according to the present disclosure;

[0023] Figure 3 is a schematic diagram of an application scenario of a method for analyzing firmware according to an embodiment of the present disclosure;

[0024] Figure 4 is a flowchart of another embodiment of a method for analyzing firmware according to the present disclosure;

[0025] Figure 5 is a structural diagram of an embodiment of an apparatus for analyzing firmware according to the present disclosure;

[0026] Figure 6 It is a schematic structural diagram of an electronic device suitable for implementing the embodiments of the present disclosure. DETAILED DESCRIPTION

[0027] The present disclosure will be further described in detail below with reference to the accompanying drawings and examples. It should be understood that the specific embodiments described herein are intended only to illustrate the relevant invention and are not intended to limit the invention. It should also be noted that, for ease of description, only portions relevant to the relevant invention are shown in the accompanying drawings.

[0028] It should be noted that, in the absence of conflict, the embodiments and features of the embodiments in the present disclosure may be combined with each other. The present disclosure will be described in detail below with reference to the accompanying drawings and in combination with the embodiments.

[0029] Figure 1 An exemplary architecture 100 is shown to which the method for analyzing firmware or the apparatus for analyzing firmware of the present disclosure can be applied.

[0030] like Figure 1 As shown, system architecture 100 may include terminal devices 101, 102, 103, a network 104, and a server 105. Network 104 is a medium for providing communication links between terminal devices 101, 102, 103 and server 105. Network 104 may include various connection types, such as wired or wireless communication links or fiber optic cables.

[0031] The terminal devices 101, 102, and 103 interact with the server 105 via the network 104 to receive or send messages, etc. Various communication client applications can be installed on the terminal devices 101, 102, and 103, such as web browser applications, shopping applications, search applications, instant messaging tools, email clients, single-chip virtual machine applications, etc.

[0032] The terminal devices 101, 102, and 103 can be hardware or software. When the terminal devices 101, 102, and 103 are hardware, they can be various electronic devices with display screens and supporting human-computer interaction, including but not limited to smartphones, tablet computers, laptop computers, and desktop computers. When the terminal devices 101, 102, and 103 are software, they can be installed in the electronic devices listed above. They can be implemented as multiple software or software modules (for example, software or software modules for providing distributed services), or they can be implemented as a single software or software module. No specific limitation is made here.

[0033] The server 105 may be a server that provides various services, such as a background server that provides support for single-chip virtual machine applications on the terminal devices 101, 102, and 103. The background server may provide various conditions for the operation of the firmware to be analyzed received by the terminal devices 101, 102, and 103, such as providing different parsing tools.

[0034] It should be noted that the server can be either hardware or software. When the server is hardware, it can be implemented as a distributed server cluster consisting of multiple servers, or as a single server. When the server is software, it can be implemented as multiple software or software modules (e.g., software or software modules for providing distributed services), or as a single software or software module. No specific limitations are given here.

[0035] It should be noted that the method for analyzing firmware provided in the embodiments of the present disclosure can be executed by the terminal devices 101, 102, 103, or by the server 105. Accordingly, the apparatus for analyzing firmware can be provided in the terminal devices 101, 102, 103, or in the server 105.

[0036] It should be understood that Figure 1 The number of terminal devices, networks and servers in the embodiment is merely illustrative. Any number of terminal devices, networks and servers may be provided as required.

[0037] Continue to refer Figure 2 , shows a process 200 of an embodiment of a method for analyzing firmware according to the present disclosure. The method for analyzing firmware includes the following steps:

[0038] Step 201: Obtain the firmware to be analyzed.

[0039] In this embodiment, the execution subject of the method for analyzing firmware (such as Figure 1The server 105 shown can obtain the firmware to be analyzed via a wired connection or a wireless connection. The firmware to be analyzed can be obtained through various firmware extraction methods. As an example, the execution entity can typically obtain the firmware file to be analyzed from a communication-connected electronic device, such as a file in the ELF format.

[0040] Step 202: Receive parameters of external hardware input associated with the firmware to be analyzed.

[0041] In this embodiment, the execution subject may receive parameters input by external hardware associated with the firmware to be analyzed obtained in step 201 in a wired or wireless manner. The external hardware associated with the firmware to be analyzed generally refers to external hardware electrically connected to the single-chip microcomputer corresponding to the firmware to be analyzed. The specific form of the external hardware may be determined according to the actual application scenario of the single-chip microcomputer. As an example, the external hardware may include various sensors, such as a voltmeter, a barometer, and the like. Thus, the parameters input by the external hardware may include voltage values and air pressure values. As another example, the external hardware may include a keyboard. Thus, the parameters input by the external hardware may include an input character string.

[0042] In some optional implementations of this embodiment, the above parameters may include unconventional parameters for security testing.

[0043] In these implementations, the above-mentioned unconventional parameters can be used to indicate unconventional parameters for security testing that are different from conventional development environments. As an example, the above-mentioned safety test may include but is not limited to at least one of the following: virtual voltage pressure test, wireless junk data transmission and reception test, signal leakage analysis test, interface (I / O) data test. As another example, the above-mentioned safety test may also include an overload test. For example, when the above-mentioned external hardware is a barometer, the above-mentioned unconventional parameters may include parameters for indicating that high pressure (e.g., 1000kPa) and low pressure (e.g., 10kPa) alternate 50 times within 1 second.

[0044] Based on the above optional implementation methods, this solution can provide users with security testing using unconventional parameters based on the MCU virtual machine. Compared with the MCU virtual machines provided by existing product providers for development only, it can support finding vulnerabilities in extreme environments, thereby providing a comprehensive tool based on the MCU virtual machine that integrates testing, analysis and reverse engineering functions.

[0045] In some optional implementations of this embodiment, the parameters input by the external hardware associated with the firmware to be analyzed may include a character string input by a keyboard.

[0046] Step 203: parsing the firmware to be analyzed based on the information of the single chip microcomputer on which the firmware to be analyzed runs, so as to support the firmware to be analyzed to run on the virtual machine.

[0047] In this embodiment, based on the information about the microcontroller on which the firmware to be analyzed runs, the execution entity may parse the firmware to be analyzed obtained in step 201 in various ways to enable the firmware to be analyzed to run on the virtual machine. For example, the information about the microcontroller on which the firmware to be analyzed runs may include the file formats supported by the microcontroller.

[0048] It should be noted that the above execution subject supports the firmware to be analyzed to run on a non-real physical single-chip microcomputer, which is equivalent to providing a single-chip microcomputer virtual machine.

[0049] In some optional implementations of this embodiment, the execution subject may parse the firmware to be analyzed based on the information of the microcontroller on which the firmware to be analyzed runs according to the following steps:

[0050] The first step is to determine the type of MCU based on the information of the MCU on which the firmware to be analyzed runs.

[0051] In these implementations, the execution subject may determine the type of the MCU based on the information of the MCU on which the firmware to be analyzed runs obtained in step 201. The type may include, for example, the file formats supported by the MCU.

[0052] The second step is to parse the firmware to be analyzed into machine language that matches the type.

[0053] In these implementations, the execution entity may parse the firmware to be analyzed obtained in step 201 into a machine language that matches the type determined in step 1 in various ways.

[0054] The third step is to set the firmware operating environment that matches the type.

[0055] In these implementations, the execution subject can be set in various ways to a firmware execution environment that matches the type determined in the first step, wherein the firmware execution environment can include but is not limited to at least one of the following: registers, memory, registry, and stack.

[0056] Based on the above optional implementation methods, this solution can adapt to different MCUs through language parsing and firmware operating environment settings, thereby improving the versatility of the MCU virtual machine.

[0057] In these implementations, the execution entity may optionally select a protocol that matches the interface type of the external hardware in step 202 to set a firmware operating environment that matches the interface type. The execution entity may select an API (Application Programming Interface) that matches the interface type of the external hardware based on a preset API set to enable communication between the microcontroller virtual machine and the virtualized external hardware.

[0058] Step 204 : Using the parameters as input, the firmware to be analyzed is run to generate a run result.

[0059] In this embodiment, the execution entity can use various methods to take parameters as input, execute the firmware to be analyzed, and generate execution results. The execution results may include status information of the target hardware in the microcontroller simulated by the virtual machine. The target hardware may include, but is not limited to, at least one of the following: registers, memory, and I / O interfaces. For example, the status information may include values stored in registers or memory, or the on / off status of an I / O interface.

[0060] In this embodiment, the execution subject may run the firmware to be analyzed based on parsing the firmware to be analyzed in step 203 , and use the parameters received in step 202 as input when parameters need to be input, thereby generating an execution result.

[0061] In some optional implementations of this embodiment, the parameters inputted based on the sensor associated with the firmware to be analyzed may include a character string inputted via a keyboard. The execution subject may execute the firmware to be analyzed using the parameters as input to generate an execution result by following the steps below:

[0062] In the first step, the character string is compared with a value in a first memory address on the virtual machine to generate a first comparison result.

[0063] In these implementations, the execution entity may compare the string with a value at a first memory address on the virtual machine to generate a first comparison result.

[0064] As an example, the firmware to be analyzed may be firmware running on a safe that is unlocked using a password. The execution entity may execute the instructions indicated by the firmware to be analyzed obtained in step 201. For example, the instructions may instruct to compare the string received in step 202 with the value at a first memory address on the virtual machine to generate a first comparison result. The value at the first memory address may be, for example, changeable via parameter settings. The value at the first memory address may be, for example, a password set by a user.

[0065] In a second step, in response to determining that the first comparison result indicates inconsistency, the character string is compared with a value at a second memory address on the virtual machine to generate a second comparison result.

[0066] In these implementations, the execution entity may continue to execute the instructions indicated by the firmware to be analyzed obtained in step 201. For example, the instructions may instruct, in response to determining that the first comparison result generated in the first step indicates inconsistency, to compare the string with a value at a second memory address on the virtual machine to generate a second comparison result.

[0067] The third step is to generate an operation result based on the first memory address, the second memory address and the second result.

[0068] In these implementations, based on the first memory address in the first step, the second memory address in the second step, and the second result, the execution subject may generate an execution result in various ways. For example, when the target hardware is memory corresponding to the first and second memory addresses, the execution result may include the first and second memory addresses to enable a technician to determine whether the memory addresses are identical.

[0069] As another example, the above-mentioned operation result may also include information indicating whether the input character string is consistent with a preset character string (eg, the value in the first memory address or the second memory address), such as whether the input password is correct.

[0070] Based on the above optional implementation methods, this solution can generate status information of the target hardware of interest by running the firmware to be analyzed in the firmware running environment, thereby providing a data basis for firmware analysis.

[0071] In some optional implementations of this embodiment, the above execution entity may further perform the following steps:

[0072] S1. Send a command for instructing to update the value in the second memory address.

[0073] In these implementations, the execution entity may send a command instructing to update the value in the second memory address in various ways.

[0074] S2. Receive prompt information indicating that the value in the second memory address cannot be changed.

[0075] In these implementations, the execution entity may receive prompt information indicating that the value in the second memory address cannot be changed.

[0076] Based on the above optional implementation, this solution can analyze the firmware to be analyzed by attempting to modify the value in the memory address. Thus, as an example, by comparing the input password twice with the firmware to be analyzed, and the value in the second memory address cannot be modified, this provides a technical basis for determining the "backdoor password."

[0077] Continue to see Figure 3 , Figure 3 FIG. 1 is a schematic diagram of an application scenario of a method for analyzing firmware according to an embodiment of the present disclosure. Figure 3 In the application scenario, the user 301 inputs the firmware file extracted from the physical single-chip microcomputer (not shown in the figure) into the terminal device 302. The user 301 can also input the reading of the barometer (not shown in the figure) connected to the physical single-chip microcomputer into the terminal device 302. The terminal device 302 can parse the above-mentioned firmware file based on the file type supported by the physical single-chip microcomputer on which the above-mentioned firmware file is running, so as to support the above-mentioned firmware file to run on the single-chip microcomputer virtual machine 303 provided by the terminal device. The terminal device 302 can input the reading input by the user as a parameter of the virtual barometer 304 into the single-chip microcomputer virtual machine 303, and run the parsed firmware file. Optionally, the user 301 can view the state changes of the value in the memory of the specified address in the single-chip microcomputer virtual machine 303 during the operation of the above-mentioned firmware by entering a command.

[0078] At present, one of the existing technologies is usually to forcibly modify the simulation software used for development based on a general open source virtual machine or provided by a product provider to adapt to the external hardware connected to the single-chip microcomputer to be analyzed, resulting in poor versatility and low efficiency of firmware analysis. The method provided by the above-mentioned embodiment of the present disclosure parses the firmware to be analyzed based on the information of the single-chip microcomputer on which the firmware to be analyzed runs, and uses the parameters of the external hardware input associated with the firmware to be analyzed as input to run the firmware to be analyzed to generate an operating result for indicating the status information of the target hardware in the single-chip microcomputer virtual machine, thereby realizing adaptive virtualization of single-chip microcomputers connected to different external hardware, improving the versatility of the single-chip microcomputer virtual machine, and realizing analysis and testing of the single-chip microcomputer firmware by passing different parameters, thereby improving the flexibility and efficiency of firmware analysis.

[0079] Further references Figure 4 , which shows a process 400 of another embodiment of a method for analyzing firmware. The process 400 of the method for analyzing firmware includes the following steps:

[0080] Step 401: Receive the firmware to be analyzed.

[0081] Step 402: Receive parameters of external hardware input associated with the firmware to be analyzed.

[0082] Step 403: parsing the firmware to be analyzed based on the information of the single chip microcomputer on which the firmware to be analyzed runs, so as to support the firmware to be analyzed to run on the virtual machine.

[0083] The above steps 401 to 403 are respectively consistent with steps 201 to 203 and their optional implementations in the aforementioned embodiment. The above description of steps 201 to 203 and their optional implementations also applies to steps 401 to 403 and will not be repeated here.

[0084] Step 404: Receive instrumentation information associated with the firmware to be analyzed.

[0085] In this embodiment, the execution entity of the method for analyzing firmware can receive the instrumentation information associated with the firmware to be analyzed obtained in step 401 through various means. The instrumentation information can be used to indicate the code location of interest. As an example, the execution entity can obtain the instrumentation information associated with the firmware to be analyzed through a parameter indicating the code location passed by an instrumentation API.

[0086] Step 405 : Taking the parameters as input, the firmware to be analyzed is run according to the instruction of the instrumentation information to generate a running result.

[0087] In this embodiment, the execution subject may use the parameters of the external hardware input associated with the firmware to be analyzed received in step 402 as input, run the firmware to be analyzed obtained in step 401 according to the indication of the instrumentation information, and generate an operation result in various ways. The operation result may include operation characteristic data for the code location indicated by the instrumentation information. The operation characteristic data may include, for example, changes in values stored in memory, registers, etc. The execution subject may use a method similar to step 204 and its optional implementation in the aforementioned embodiment to run the firmware to be analyzed.

[0088] As an example, if the firmware to be analyzed includes a code for indicating that a one-minute interval is required between two consecutive password inputs, the above-mentioned plug-in information can be used to indicate that the condition of requiring a one-minute interval between two consecutive password inputs is masked, so that the above-mentioned execution entity can continuously enter the password when running the firmware to be analyzed obtained in the above step 401.

[0089] from Figure 4As can be seen, process 400 of the firmware analysis method in this embodiment includes the steps of receiving instrumentation information associated with the firmware to be analyzed, taking parameters as input, running the firmware to be analyzed according to the instrumentation information, and generating an execution result. Thus, the solution described in this embodiment can utilize instrumentation information to achieve flexible analysis of the firmware to be analyzed, thereby providing a technical foundation for improving the cracking efficiency of reverse engineers.

[0090] Further references Figure 5 As an implementation of the methods shown in the above figures, the present disclosure provides an embodiment of a device for analyzing firmware. Figure 2 or Figure 4 Corresponding to the method embodiment shown, the device can be specifically applied to various electronic devices.

[0091] like Figure 5 As shown, the apparatus 500 for analyzing firmware provided by this embodiment includes an acquisition unit 501, a receiving unit 502, a parsing unit 503, and a generating unit 504. The acquisition unit 501 is configured to acquire firmware to be analyzed; the receiving unit 502 is configured to receive parameters input by external hardware associated with the firmware to be analyzed; the parsing unit 503 is configured to parse the firmware to be analyzed based on information about the microcontroller on which the firmware to be analyzed runs, so as to support the firmware to be analyzed running on a virtual machine; and the generating unit 504 is configured to take the parameters as input, run the firmware to be analyzed, and generate an execution result, wherein the execution result includes status information of the target hardware in the microcontroller simulated by the virtual machine.

[0092] In the present embodiment, in the apparatus 500 for analyzing firmware, the specific processing of the acquisition unit 501, the receiving unit 502, the parsing unit 503 and the generating unit 504 and the technical effects thereof can be referred to in the respective Figure 2 The relevant descriptions of step 201, step 202, step 203 and step 204 in the corresponding embodiment are not repeated here.

[0093] In some optional implementations of this embodiment, the above-mentioned parsing unit 503 may include: a determination module (not shown in the figure), configured to determine the type of the microcontroller based on information about the microcontroller on which the firmware to be analyzed runs; a parsing module (not shown in the figure), configured to parse the firmware to be analyzed into a machine language that matches the type; and a setting module (not shown in the figure), configured to set a firmware running environment that matches the type.

[0094] It should be noted that, optionally, the above-mentioned parsing unit 503 can be used as a pluggable module and integrated into the Qiling framework (Qiling) which is a dynamic binary file analysis framework.

[0095] In some optional implementations of this embodiment, the above parameters may include unconventional parameters for security testing.

[0096] In some optional implementations of this embodiment, the parameters of the external hardware input associated with the firmware to be analyzed may include a character string input via a keyboard. The generation unit 504 may be further configured to: compare the character string with a value at a first memory address on the virtual machine to generate a first comparison result; in response to determining that the first comparison result indicates an inconsistency, compare the character string with a value at a second memory address on the virtual machine to generate a second comparison result; and generate an execution result based on the first memory address, the second memory address, and the second result.

[0097] In some optional implementations of this embodiment, the above-mentioned device 500 for analyzing firmware can be further configured to: send a command for instructing to update the value in the second memory address; and receive prompt information indicating that the value in the second memory address cannot be changed.

[0098] In some optional implementations of this embodiment, the above-mentioned generation unit 504 can be further configured to: receive instrumentation information associated with the firmware to be analyzed; take parameters as input, run the firmware to be analyzed according to the instructions of the instrumentation information, and generate an operation result, wherein the operation result includes operation feature data for the code location indicated by the instrumentation information.

[0099] The device provided by the above-mentioned embodiment of the present disclosure parses the firmware to be analyzed based on the information of the single-chip microcomputer on which the firmware to be analyzed is running, obtained by the obtaining unit 501, by the parsing unit 503, and the generating unit 504 uses the parameters of the external hardware input associated with the firmware to be analyzed received by the receiving unit 502 as input to run the firmware to be analyzed, so as to generate an operating result for indicating the status information of the target hardware in the single-chip microcomputer virtual machine, thereby realizing adaptive virtualization of single-chip microcomputers connected to different external hardware, improving the versatility of the single-chip microcomputer virtual machine, and realizing analysis and testing of the single-chip microcomputer firmware by passing different parameters, thereby improving the flexibility and efficiency of firmware analysis.

[0100] Reference below Figure 6 , which shows an electronic device (eg Figure 1 A schematic diagram of the structure of the server in (600). Figure 6 The server shown is merely an example and should not limit the functions and scope of use of the embodiments of the present application.

[0101] like Figure 6As shown, the electronic device 600 may include a processing device (e.g., a central processing unit, a graphics processing unit, etc.) 601, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 602 or a program loaded from a storage device 608 into a random access memory (RAM) 603. Various programs and data required for the operation of the electronic device 600 are also stored in the RAM 603. The processing device 601, the ROM 602, and the RAM 603 are connected to each other via a bus 604. An input / output (I / O) interface 605 is also connected to the bus 604.

[0102] Typically, the following devices may be connected to the I / O interface 605: an input device 606 including, for example, a touch screen, a touchpad, a keyboard, a mouse, a camera, a microphone, an accelerometer, a gyroscope, etc.; an output device 607 including, for example, a liquid crystal display (LCD), a speaker, a vibrator, etc.; a storage device 608 including, for example, a magnetic tape, a hard disk, etc.; and a communication device 609. The communication device 609 may allow the electronic device 600 to communicate with other devices wirelessly or by wire to exchange data. Although Figure 6 The electronic device 600 is shown with various devices, but it should be understood that it is not required to implement or possess all of the devices shown. More or fewer devices may be implemented or possessed instead. Figure 6 Each block shown in the figure may represent one device, or may represent multiple devices as needed.

[0103] In particular, according to an embodiment of the present application, the process described above with reference to the flowchart can be implemented as a computer software program. For example, an embodiment of the present application includes a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program includes program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from the network via the communication device 609, or installed from the storage device 608, or installed from the ROM 602. When the computer program is executed by the processing device 601, the above-mentioned functions defined in the method of the embodiment of the present application are performed.

[0104] It should be noted that the computer-readable medium described in the embodiments of the present disclosure may be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two. The computer-readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device, or device, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the embodiments of the present disclosure, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, device, or device. In the embodiments of the present disclosure, the computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, which carries computer-readable program code. Such a propagated data signal may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. A computer-readable signal medium may also be any computer-readable medium other than a computer-readable storage medium that can transmit, propagate, or convey a program for use by or in conjunction with an instruction execution system, apparatus, or device. The program code embodied on the computer-readable medium may be conveyed using any suitable medium, including but not limited to wires, optical cables, RF (Radio Frequency), or any suitable combination thereof.

[0105] The computer-readable medium may be included in the electronic device, or may exist independently and not be incorporated into the electronic device. The computer-readable medium carries one or more programs. When executed by the electronic device, the electronic device: obtains firmware to be analyzed; receives parameters input from external hardware associated with the firmware to be analyzed; parses the firmware to be analyzed based on information about the microcontroller on which the firmware to be analyzed runs, to support the firmware to be analyzed running on a virtual machine; and runs the firmware to be analyzed using the parameters as input, generating a run result, wherein the run result includes status information of the target hardware in the microcontroller simulated by the virtual machine.

[0106] Computer program code for performing the operations of embodiments of the present disclosure may be written in one or more programming languages, or a combination thereof, including object-oriented programming languages such as Java, Smalltalk, C++, and conventional procedural programming languages such as "C", Python, or similar programming languages. The program code may be executed entirely on the user's computer, partially on the user's computer, as a stand-alone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving a remote computer, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0107] The flowcharts and block diagrams in the accompanying drawings illustrate the possible implementation architecture, functions and operations of the systems, methods and computer program products according to the various embodiments of the present disclosure. In this regard, each box in the flowchart or block diagram can represent a module, program segment, or a part of code, and the module, program segment, or a part of code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a different order than that marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram and / or flowchart, and the combination of the boxes in the block diagram and / or flowchart, can be implemented with a dedicated hardware-based system that performs the specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0108] The units involved in the embodiments described in the present disclosure may be implemented by software or hardware. The units described may also be provided in a processor. For example, they may be described as: a processor comprising an acquisition unit, a receiving unit, a parsing unit, and a generation unit. The names of these units do not, in some cases, constitute limitations on the units themselves. For example, the acquisition unit may also be described as a "unit for acquiring firmware to be analyzed."

[0109] The above description is merely a preferred embodiment of the present disclosure and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of the invention involved in the embodiments of the present disclosure is not limited to the technical solutions formed by a specific combination of the above-mentioned technical features, but should also encompass other technical solutions formed by any combination of the above-mentioned technical features or their equivalents without departing from the above-mentioned inventive concept. For example, a technical solution formed by mutually replacing the above-mentioned features with (but not limited to) technical features with similar functions disclosed in the embodiments of the present disclosure.

Claims

1. A method for analyzing firmware, comprising: Get the firmware to be analyzed; receiving parameters inputted by external hardware associated with the firmware to be analyzed; Based on information about the single-chip microcomputer on which the firmware to be analyzed runs, the firmware to be analyzed is parsed to support the firmware to be analyzed running on a virtual machine; wherein the firmware running environment that matches the interface type of the external hardware is set based on a protocol that matches the interface type of the external hardware; The firmware to be analyzed is run using the parameters as input to generate a run result, wherein the run result includes status information of target hardware in the single-chip microcomputer simulated by the virtual machine.

2. The method according to claim 1, wherein The parsing of the firmware to be analyzed based on the information of the single-chip microcomputer on which the firmware to be analyzed runs, so as to support the firmware to be analyzed to run on the virtual machine, includes: Determining the type of the single-chip microcomputer according to information of the single-chip microcomputer on which the firmware to be analyzed runs; Parsing the firmware to be analyzed into a machine language matching the type; Set the firmware operating environment that matches the type described.

3. The method according to claim 2, wherein: The parameters include unconventional parameters used for safety testing.

4. The method according to claim 2, wherein: The parameters input by the external hardware associated with the firmware to be analyzed include a character string input by a keyboard; as well as The step of taking the parameters as input, running the firmware to be analyzed, and generating a running result includes: Comparing the string with a value at a first memory address on the virtual machine to generate a first comparison result; In response to determining that the first comparison result indicates an inconsistency, comparing the string with a value at a second memory address on the virtual machine to generate a second comparison result; An operation result is generated based on the first memory address, the second memory address and the second comparison result.

5. The method according to claim 4, wherein: After, in response to determining that the first comparison result indicates inconsistency, comparing the string with a value at a second memory address on the virtual machine to generate a second comparison result, the method further includes: Sending a command for instructing to update the value in the second memory address; Receive prompt information indicating that the value in the second memory address cannot be changed.

6. The method according to any one of claims 1 to 5, wherein: The step of taking the parameters as input, running the firmware to be analyzed, and generating a running result includes: Receiving instrumentation information associated with the firmware to be analyzed; The parameters are used as input, and the firmware to be analyzed is run according to the indication of the instrumentation information to generate an operation result, wherein the operation result includes operation feature data for the code position indicated by the instrumentation information.

7. A device for analyzing firmware, comprising: an acquisition unit, configured to acquire firmware to be analyzed; a receiving unit configured to receive parameters input by external hardware associated with the firmware to be analyzed; A parsing unit configured to parse the firmware to be analyzed based on information of the single-chip microcomputer on which the firmware to be analyzed runs, so as to support the firmware to be analyzed running on the virtual machine; wherein the firmware running environment matching the interface type of the external hardware is set based on a protocol matching the interface type of the external hardware; The generating unit is configured to take the parameters as input, run the firmware to be analyzed, and generate a running result, wherein the running result includes status information of the target hardware in the single-chip microcomputer simulated by the virtual machine.

8. The device according to claim 7, wherein The parsing unit includes: a determination module configured to determine the type of the single-chip microcomputer according to information of the single-chip microcomputer on which the firmware to be analyzed runs; a parsing module configured to parse the firmware to be analyzed into a machine language matching the type; The setting module is configured to set a firmware running environment matching the type.

9. An electronic device comprising: one or more processors; a storage device having one or more programs stored thereon; When the one or more programs are executed by the one or more processors, the one or more processors implement the method according to any one of claims 1 to 6.

10. A computer-readable medium having a computer program stored thereon, wherein: When the program is executed by a processor, the method according to any one of claims 1 to 6 is implemented.

Images