Vulnerability mining method and system based on Windows CE operating system embedded device simulation

Abstract

The invention provides a vulnerability mining method and system based on Windows CE operating system embedded device simulation. The method comprises the steps that embedded device processor information is acquired; firmware of the embedded device is unpacked to extract a file; obtaining an operating system of the embedded device based on processor information of the embedded device and the extracted file, and packaging the operating system and applications of the embedded device to form a complete simulation mirror image which is used for realizing system state simulation of the embedded device using the Windows CE operating system; and running fuzzy testing in the simulation environment to carry out vulnerability mining on the corresponding function module of the firmware.

Description

Technical Field

[0001] The present invention belongs to the technical field of embedded device vulnerability mining, and in particular relates to a vulnerability mining method and system based on Windows CE operating system embedded device simulation. Background Art

[0002] The statements in this section merely provide background information related to the present invention and do not necessarily constitute prior art.

[0003] With the in-depth development of Internet of Things technology, a large number of embedded devices are connected to the Internet. Based on commercial cost control, embedded devices are designed to save costs as much as possible while being sufficient to complete specific functions. This makes the hardware resources of embedded devices very limited, resulting in a lack of security protection measures for these devices. If a security vulnerability occurs, it will bring serious security risks to the use of the embedded device.

[0004] Since industrial control systems are directly related to production processes and equipment safety, direct testing of their embedded devices may lead to production interruptions, equipment damage, and even safety accidents. Industrial control systems usually operate in complex industrial environments, and direct testing may be limited by environmental factors, affecting the accuracy of test results. At the same time, direct testing requires a lot of manpower, material resources, and time, and production activities may need to be suspended during the testing process, resulting in increased costs.

[0005] In the prior art, when analyzing the security of embedded device firmware, static analysis technology is mainly relied on. However, facing a large number of embedded devices, the problems of high labor costs and high false alarm rates are gradually becoming prominent.

[0006] In contrast, dynamic analysis technology has significantly improved the efficiency of vulnerability mining with its high accuracy and high degree of automation. However, the hardware dependency of embedded device firmware security analysis is a huge challenge. Firmware simulation that separates embedded firmware from the underlying hardware has become a research focus in academia.

[0007] Fuzz testing is a vulnerability mining method that discovers target vulnerabilities by providing unexpected inputs to the program under test and monitoring abnormal results. However, it has some limitations.

[0008] Generation-based fuzz testing requires writing different test codes for different types of programs to describe the format and grammatical rules of the input file, which has low reusability. Mutation-based fuzz testing lacks the ability to constrain test cases, and a large number of test cases will be discarded because they cannot meet the protocol format standards, resulting in reduced fuzz testing efficiency.

[0009] To sum up, there are currently defects and shortcomings when directly testing industrial control systems related to production processes and equipment, such as easy damage to equipment, high testing costs, and low vulnerability discovery efficiency. Summary of the invention

[0010] In order to overcome the deficiencies of the above-mentioned prior art, the present invention provides a vulnerability mining method based on Windows CE operating system embedded device simulation, which can realize firmware simulation of embedded devices and vulnerability mining during the simulation process, improve system security, prevent potential threats, and ensure the smooth progress of industrial production.

[0011] To achieve the above objectives, one or more embodiments of the present invention provide the following technical solutions:

[0012] In the first aspect, a vulnerability mining method based on Windows CE operating system embedded device simulation is disclosed, including:

[0013] Get embedded device processor information;

[0014] Firmware unpacking of embedded device firmware to extract files;

[0015] Based on the embedded device processor information and the extracted files, the operating system of the embedded device is obtained, and the operating system and the application of the embedded device are packaged to form a complete simulation image, which is used to realize the system state simulation of the embedded device using the Windows CE operating system;

[0016] Run fuzz testing in a simulation environment to discover vulnerabilities in the corresponding functional modules of the firmware.

[0017] As a further technical solution, the method of obtaining the embedded device processor information is:

[0018] For actual physical devices, obtain the processor model based on the information in the Windows CE system's control panel; or

[0019] Use dedicated software or a network cable to connect to the actual physical device to obtain the processor's hardware information, including the processor model.

[0020] As a further technical solution, the firmware of the embedded device is unpacked to extract files, specifically including:

[0021] Get the embedded device firmware kernel NK.bin by accessing the website or reading the SD card. The NK.bin file contains Windows system files and some additional customized components.

[0022] For NK.bin, use the decompression tool to extract the files in it.

[0023] As a further technical solution, the unpacking tool includes cvrtbin, viewbin and dumprom in the Windows CE development toolkit, and the files in NK.bin are extracted based on the above tools.

[0024] As a further technical solution, when the embedded device is a programmable logic controller, the firmware of the embedded device is unpacked to extract the file, specifically including:

[0025] Based on the PLC's official website, navigate to the firmware download page:

[0026] On the official website, navigate further to the firmware download area based on the firmware download page;

[0027] Select the corresponding model in the firmware download area to download and obtain the device firmware kernel NK.bin;

[0028] Use the unpacking tool to extract the files in the device firmware kernel NK.bin.

[0029] As a further technical solution, the operating system of the embedded device is obtained based on the embedded device processor information and the extracted files, including:

[0030] Extract QEMU emulator development board configuration information;

[0031] Generate BSP configuration files and compile custom kernels;

[0032] Based on the extracted configuration information, a BSP configuration file is generated and a customized kernel is compiled to obtain the operating system of the embedded device.

[0033] As a further technical solution, extract the QEMU emulator development board configuration information, including:

[0034] Clone the QEMU Git repository and switch to the branch that contains the QEMU emulator development board support.

[0035] In the QEMU source code, find the machine definition associated with the specific architecture;

[0036] Get the development board configuration information.

[0037] As a further technical solution, a BSP configuration file is generated, including:

[0038] In the BSP development environment, install the corresponding development tools;

[0039] Create a new PB project, start the project wizard, and initialize the BSP framework;

[0040] Depending on the target operating system and hardware platform, choose to clone a BSP template or create a new BSP framework from scratch;

[0041] Set up the BSP directory structure, write peripheral drivers based on hardware configuration information, and write or modify hardware abstraction layer code to provide abstraction and encapsulation of hardware so that the operating system or RTOS can access hardware resources more conveniently;

[0042] Finally, use the development tool chain to compile the BSP source code to generate an executable binary file or image.

[0043] As a further technical solution, compile a custom kernel. The specific process includes:

[0044] Based on the created BSP, add corresponding modules according to requirements;

[0045] Select the basic configuration structure;

[0046] Select the basic configuration and project name of the operating system image;

[0047] Choose a method to customize your device: Select operating system features;

[0048] Select the basic class library;

[0049] Select Operating System Core Services.

[0050] As a further technical solution, the operating system and the application of the embedded device are packaged to form a complete simulation image, including:

[0051] Mounting method: Package the application files extracted from the embedded device firmware into a disk image file in fat16 format, and then convert it to qcow2 format supported by QEMU; or

[0052] Packaging method: Modify the project.bib file of the Windows CE.NET target project to integrate the application files extracted from the embedded device firmware into the created Windows CE BSP.

[0053] As a further technical solution, fuzz testing is performed in a simulation environment to mine vulnerabilities in the corresponding functional modules of the firmware, specifically including:

[0054] Using generation strategies, we can generate test cases that conform to the protocol specifications based on the precise syntax information of the network communication protocol, and generate high-quality seed files.

[0055] Introduce mutation strategies to perform refined mutation operations on the generated test cases, and combine the returned coverage information to continuously optimize the test case mutation strategy, conduct more in-depth and comprehensive testing of the tested program, obtain input space and potential abnormal scenarios, and predict possible vulnerabilities and defects in the tested program;

[0056] During the test execution phase, the execution status and abnormal behavior of the program under test are closely monitored, and the vulnerabilities and defects in the program under test are identified by comparing and analyzing these results.

[0057] Second, a vulnerability mining system based on Windows CE operating system embedded device simulation is disclosed, including:

[0058] The preprocessing module is configured to: obtain embedded device processor information;

[0059] Firmware unpacking of embedded device firmware to extract files;

[0060] The embedded device simulation module is configured to: obtain the operating system of the embedded device based on the embedded device processor information and the extracted files, package the operating system and the application of the embedded device to form a complete simulation image, which is used to realize the system state simulation of the embedded device using the Windows CE operating system;

[0061] The vulnerability mining fuzz testing module is configured to: run fuzz testing in a simulation environment to mine vulnerabilities in the corresponding functional modules of the firmware.

[0062] One or more of the above technical solutions have the following beneficial effects:

[0063] The technical solution of the present invention discloses a vulnerability mining solution based on Windows CE operating system embedded device simulation, which takes into account the advantages of not being disturbed when the device is running, protecting the device and reducing the testing cost, and at the same time solves the defect of low efficiency of previous fuzzy testing, that is, the method has the characteristics of low testing risk, low testing cost, high testing efficiency and discovery of potential vulnerabilities, and has significant advantages in improving the performance of industrial control systems, enhancing security, reducing testing risks and costs, etc.

[0064] Advantages of additional aspects of the present invention will be given in part in the following description, and in part will become obvious from the following description, or will be learned through practice of the present invention. BRIEF DESCRIPTION OF THE DRAWINGS

[0065] The accompanying drawings in the specification, which constitute a part of the present invention, are used to provide a further understanding of the present invention. The exemplary embodiments of the present invention and their descriptions are used to explain the present invention and do not constitute improper limitations on the present invention.

[0066] Figure 1 The overall flow chart of the vulnerability mining technical solution based on Windows CE operating system embedded device simulation according to the embodiment of the present invention;

[0067] Figure 2 This is a flowchart of firmware simulation of an embedded device of Windows CE operating system according to an embodiment of the present invention;

[0068] Figure 3 This is a flowchart of fuzz testing for Windows CE embedded device vulnerability mining according to an embodiment of the present invention. DETAILED DESCRIPTION

[0069] It should be noted that the following detailed descriptions are exemplary and are intended to provide further explanation of the present invention. Unless otherwise specified, all technical and scientific terms used herein have the same meanings as those commonly understood by those skilled in the art to which the present invention belongs.

[0070] It should be noted that the terms used herein are for describing specific embodiments only and are not intended to be limiting of exemplary embodiments according to the present invention.

[0071] In the absence of conflict, the embodiments of the present invention and the features of the embodiments may be combined with each other.

[0072] Glossary:

[0073] Windows CE: Windows Embedded Compact, a special term for operating systems;

[0074] BSP: Board Support Package;

[0075] PLC: Programmable Logic Controller;

[0076] QEMU: An open source emulator.

[0077] Embodiment 1

[0078] See attached Figure 1 As shown, this embodiment discloses a vulnerability mining method based on Windows CE operating system embedded device simulation, including:

[0079] Step 1: Preprocessing stage: including obtaining embedded device processor information, embedded device firmware unpacking and file extraction;

[0080] Step 2: Firmware simulation stage: including QEMU emulator development board configuration information extraction, Windows CE BSP (board support package) and system custom compilation, simulation image packaging integration (including custom compiled system and related applications extracted from firmware) and simulation verification;

[0081] Step 3: Run fuzz testing in a simulation environment to discover vulnerabilities.

[0082] The overall technical solution of this embodiment customizes an operating system based on the hardware configuration information of the embedded device, and packages it with the necessary applications of the embedded device to form a complete simulation image, thereby realizing system-state simulation of the embedded device using the Windows CE operating system, and finally applying fuzz testing technology to discover vulnerabilities in the corresponding functional modules of the firmware.

[0083] The above step 1 specifically includes:

[0084] Step 1-1: Get embedded device processor information:

[0085] In one implementation, when there is an actual physical device, the processor model can be viewed in the control panel of the Windows CE system; when there is no physical device, the processor model information can be obtained by consulting the technical manual, user guide and other related documents of the device.

[0086] In another embodiment, when there is an actual physical device, the hardware information of the Beckhoff PLC, including the processor model, can be viewed using dedicated software provided by the manufacturer, such as TwinCAT of the Beckhoff series, or by connecting the actual device via an Ethernet cable. When there is no physical device, the manufacturer's official website will provide a device manual or user guide. The corresponding model of the Beckhoff CX8190 device manual can be selected based on the simulation device, which will include the technical specifications and hardware information of the PLC and clearly list the processor model.

[0087] In this step, the embedded device processor information is obtained, including basic information of the simulated device, including the operating system, architecture, etc., in preparation for the subsequent simulation of the operating system or application.

[0088] Step 1-2: Unpacking and extracting files of embedded device firmware: Obtain the embedded device firmware kernel NK.bin through the supplier's support website, SD card reading and other methods. The NK.bin file contains Windows system files and some additional customized components. NK.bin cannot be viewed directly, and an unpacking tool is needed to extract the files inside. The extraction tool needs to use cvrtbin, viewbin, and dumprom in the Windows CE Development Kit. These tools are combined to extract the files in NK.bin.

[0089] The above-mentioned extracted files include applications of the wince operating system, registry information and other files. The subsequent packaging or mounting methods in the simulation stage need to use the extracted files to implement.

[0090] For programmable logic controllers, visit their official website and navigate to the firmware download page: On the official website, you usually need to find a page labeled "Support", "Download", "Software" or similar, then navigate further to the firmware download area, then select the corresponding model and click Download. After obtaining the device firmware kernel NK.bin through the official website, NK.bin cannot be viewed directly, and you need to use an unpacking tool to extract the files inside. The extraction tool requires cvrtbin, viewbin, and dumprom in the Windows CE Development Kit. The detailed steps are as follows:

[0091] #View NK.bin information to get the starting address and length information

[0092] viewbin.exe NK.bin

[0093] Image Start=0x80000000,length=0x06A361BC

[0094] Start address = 0x80001468

[0095] Checking record#51for potential TOC(ROMOFFSET=0xFA9BC1F8)

[0096] Checking record#567for potential TOC(ROMOFFSET=0x00000000)

[0097] NOTICE! Record 567 looked like a TOC except DLL first=0x4001EE2B,andDLL last=0x451BF000

[0098] Done.

[0099] #Convert NK.bin to NK.nb0

[0100] cvrtbin.exe-ra 0x80000000-w 32-l 0x06A9E010 NK.bin

[0101] ViewBin...NK.bin

[0102] Image Start=0x80000000,length=0x06A9E010

[0103] Start address = 0x80001468

[0104] Checking record#51for potential TOC(ROMOFFSET=0xFA9543F8)

[0105] Checking record#570for potential TOC(ROMOFFSET=0x00000000)

[0106] NOTICE! Record 570looked like a TOC except DLL first=0x4001EE2B,andDLL last=0x451BF000

[0107] start 80000000 length 00000004

[0108] start 80000040length 00000008

[0109] start 80000048length 00000004

[0110] start 80001000length 000053d8 ..........

[0112] start 86a9abc0 length 00003450

[0113] Progress...

[0114] 0% Done.

[0115] #Dump all the files in NK.nb0. nk_dump is the extracted folder.

[0116] dumprom.exe-dnk_dump-v-5NK.nb0

[0117] Use these tools together to extract the NK.bin file through the above steps.

[0118] See attached Figure 2 As shown, the above step 2 specifically includes:

[0119] Step 2-1: Extract QEMU emulator development board configuration information: Use the command to clone the QEMU Git repository and switch to the branch containing QEMU emulator development board support git clone https: / / gitlab.com / qemu-project / qemu.git. In the QEMU source code, enter the hw / arm / directory and find the machine definition related to the specific architecture. The development board configuration information is located in the hw / arm / vexpress.c file, which contains configuration information such as structure type, machine type initialization code, processor ID, hardware configuration initialization, etc.

[0120] In this step, use the command to clone the QEMU Git repository and switch to the branch that contains the QEMU emulator development board support. Finally, find the QEMU.Git Git repository to obtain the QEMU source code.

[0121] Find the machine definition related to a specific architecture. Specifically, QEMU contains multiple simulation architectures. It is necessary to find the definition of the architecture that meets the simulation target, and then obtain the development board information such as the arm architecture, and customize the subsequent BSP file based on this information.

[0122] Step 2-2: Windows CE BSP (board support package) and system customized compilation: The construction of a customized kernel consists of two stages, namely generating a BSP configuration file and customizing the compilation system. The customizing compilation system stage is particularly important. It is necessary to set environment variables, and then these variables act as filters in the header file to build the required BSP. It is customized according to the actual operating system and architecture, so that the simulation accuracy is high and the restoration degree is strong.

[0123] BSP (Board Support Package) is the interface layer between the operating system and the hardware. It consists of the following items: boot loader, OAL (OEM abstraction layer), KITL for debugging the OS during the development phase, and configuration files for the specified board (for example: config.bib).

[0124] To implement the emulation function of an embedded device under the Windows CE operating system, you need to customize the BSP according to the embedded device architecture, including the following steps:

[0125] Step 2-2-1: Generate BSP configuration file: First, prepare the BSP development environment, install the corresponding development tools Visual Studio 2008 and Platform Builder, create a new PB project, start the project wizard, initialize the BSP framework, select a suitable BSP template to clone or create a new BSP framework from scratch according to the target operating system and hardware platform, set the directory structure of BSP, including source code, header files, link scripts, configuration files, etc., add necessary devices to BSP according to hardware configuration information (such as: serial port, display device, keyboard and mouse input devices, SD card and other storage devices, network devices, etc.), modify config.big, platflam.bib and other configuration files and add corresponding device driver source code, write or modify the hardware abstraction layer (HAL) code to provide hardware abstraction and encapsulation, so that the operating system or RTOS can access hardware resources more conveniently. Finally, use the development tool chain to compile the BSP source code to generate an executable binary file or image, that is, finally generate the BSP file, and put the executable file into Visual Studio to generate the simulation kernel with the platform build plug-in.

[0126] Step 2-2-2: Compile a custom kernel:

[0127] Based on the specific BSP that has been created, add corresponding modules according to the requirements;

[0128] Select the basic configuration structure (Platform Configuration);

[0129] Select the basic configuration and project name of the operating system image;

[0130] Select the method for customizing the device (Custom Device): Select the operating system characteristics;

[0131] Select the basic class library (Application and Services Development): commonly used class libraries, interface functions, etc.;

[0132] Select the core OS services: mainly select some common hardware, tools, features, etc.

[0133] (1): PB can generate two types of images: Release files are placed in:

[0134] C:\Windows CE700\OSDesigns\qemu\RelDir\qemu_ARMV7_Release directory;

[0135] Debug version: used for debugging; files are placed in

[0136] In the C:\Windows CE700\OSDesigns\qemu\RelDir\qemu_ARMV7_Debug directory.

[0137] (2) After completing the configuration, click build→build platform to compile and generate the system image file. In the generated directory, there is a NK.BIN file, which is the operating system image file, that is, the Windows CE.net kernel to be used in the end.

[0138] NK.BIN is the last step in the platform creation process and the ultimate goal of configuring Windows CE. According to the specific BSP that has been created, add the corresponding modules according to the requirements, and finally build to generate a customized new kernel. Makeimg.exe uses all configuration files to merge the target modules and files into a unique Windows CE image file NK.BIN.

[0139] This kernel NK.BIN, convert it to NK.NB0 format and then use qemu emulation command, qemu-system-arm-global virtio-mmio.force-legacy=false-machine type=vexpress-a15-m 512-device

[0140] loader,addr=0x80000000,file=NK.bin.load-0x800010c0.raw-device

[0141] loader,addr=0x800010c0,cpu-num=0-device virtio-tablet-device-blockdev driver=file,filename=image.qcow2,node-name=d0-devicevirtio-blk-device,drive=d0Finally, the simulation is implemented.

[0142] Based on BSP, through the customized BSP file, use the programming tool Visual Studio, and then add the corresponding functional components, compile and run, and then generate a new kernel. Use the generated kernel and load this kernel image with the qemu simulation command to realize the simulation of the embedded device operating system, and a graphical interface and some application interfaces will appear.

[0143] Step 2-3: Simulate the image packaging integration (including the custom compiled system and related applications extracted from the firmware) and simulate and verify.

[0144] Packaging and Integration:

[0145] Method 1: Mounting method: Package the application files extracted from the embedded device firmware into a disk image file in fat16 format, and then convert it to qcow2 format supported by QEMU.

[0146] Command: qemu-img convert-f vpc-O qcow2 002.vhd image3.qcow2

[0147] The generated .qcow2 image needs to be modified before it can be used: copy the content of the address (0x50000 - the end of the file) and store it as a separate file, for example: image003.qcow2, and then mount image003.qcow2 in qemu

[0148] Method 2: Packaging method: Modify the project.bib file of the Windows CE.NET target project to integrate the application files extracted from the embedded device firmware into the created Windows CE BSP.

[0149] 1) Assume that the project.bib file directory of the WindowsCE target project is C:\Windows CE700\OSDesigns\qemu\RelDir\qemu_ARMV7_Debug, and the project has been built successfully, and the Windows CE application is Startup.exe;

[0150] 2) Copy the application Startup.exe to the project directory

[0151] C:\Windows CE700\OSDesigns\qemu\RelDir\qemu_ARMV7_Debug

[0152] 3) Modify the project.bib file of the project and add the following content in the FILES Section:

[0153] Startup.exeC:\WindowsCE700\OSDesigns\qemu\RelDir\qemu_ARMV7_Debug\CXConfig.exe NK S

[0154] 4) Regenerate the kernel image: Platform Builder IDE: [Build]->[Make Image]. After success, the resulting NK.bin contains the application Startup.exe

[0155] Simulation verification:

[0156] Use the customized Windows CE system image and the disk image to be mounted, configure the QEMU command related parameters, and start the simulation.

[0157] In order to verify the accuracy and effectiveness of the simulation environment, the test cases or actual applications of the embedded device are run to check whether the simulation environment can correctly simulate the behavior and response of the application.

[0158] See attached Figure 3 As shown in the figure, embedded device vulnerability mining in step 3:

[0159] After the successful simulation of the designed embedded device based on Windows CE operating system, dynamic binary instrumentation technology and abnormal behavior detection are used in vulnerability detection, allowing the behavior of the program to be monitored at runtime and further refining the tracking of branch coverage. By tracking the conditional judgments in the program and trying to generate more inputs to explore new branches, the efficiency of discovering potential problems is improved.

[0160] In fuzz testing, the mutation-based fuzz testing and generation-based fuzz testing strategies are innovatively integrated:

[0161] First, the generation strategy is used to generate test cases that comply with the protocol specifications based on the precise syntax information of the network communication protocol (this information is captured and analyzed by professional tools such as Wireshark), and to generate high-quality seed files. This file is used to improve the test coverage and reduce the number of invalid test cases generated. High-quality seed files are usually more in line with the input format and semantic requirements of the target program, thereby improving the efficiency of vulnerability mining.

[0162] Subsequently, a mutation strategy was introduced to perform refined mutation operations on the generated test cases, and combined with the returned coverage information, the test case mutation strategy was continuously optimized, thereby achieving a more in-depth and comprehensive test of the program under test, exploring a wider input space and potential abnormal scenarios, and revealing possible vulnerabilities and defects in the program under test.

[0163] The mutation strategy is to use known data samples as the basis (seed), perform mutation operations (such as bit flipping, mathematical addition and subtraction, insertion and deletion, splicing, etc.) on them, generate a large amount of new test data, and then input them into the target program to monitor the abnormal output of the program, so as to find errors or loopholes in the program.

[0164] The above coverage information refers to the coverage of the target program code during the execution of the test case. It can reflect whether the test case effectively explores various execution paths and logical branches of the program. Methods for obtaining coverage information include instrumentation, which is a method of inserting additional instructions or code segments into the program code to collect program execution information.

[0165] The above mutation process is not only carried out randomly, but also designed specifically according to the specific characteristics of the program under test and the test objectives to ensure the effectiveness and pertinence of the mutation.

[0166] The result is more comprehensive and effective test cases.

[0167] In order to improve the test efficiency, the generated test cases need to be strictly optimized. By removing duplicate or invalid test cases and retaining test cases that can cover critical paths and abnormal scenarios, the accuracy and effectiveness of the test are ensured.

[0168] During the test execution phase, the execution status and abnormal behavior of the program under test are closely monitored, and the test results are recorded in detail. By comparing and analyzing these results, the vulnerabilities and defects in the program under test can be accurately identified, thus providing strong support for subsequent repair work.

[0169] When the simulation successfully detects vulnerabilities, a high-accuracy fuzz test case generation method is designed by combining generation-based fuzz testing and mutation-based fuzz testing. A fine-grained mutation method that can be accurate to the protocol field level is designed, and the test case mutation strategy is optimized through the coverage information returned by the protocol field-level mutation, solving the problem that the existing network protocol fuzz test mutation method can only be accurate to the test case level.

[0170] In view of the problem that there is a lack of simulation test methods for devices based on the Windows CE operating system, the sub-technical solution of this embodiment builds a Windows CE system image of a development board supported by QEMU, so that a Windows CE system compatible with the target device instruction set can be simulated in QEMU. At the same time, the key applications in the target device are integrated into the simulation system by mounting or packaging methods for runtime testing.

[0171] In response to the current lack of efficient and accurate vulnerability mining methods for Windows CE operating system devices: the sub-technical solution of this embodiment performs vulnerability mining by running fuzz testing in a simulation environment, efficiently generates and inputs variant data, and accurately identifies vulnerabilities in embedded devices.

[0172] The main processes involved in the overall technical solution of this embodiment include: embedded device collection and information extraction, analysis of detailed information of the target hardware, development or customization of the corresponding BSP (board support package) of the processor that can simulate a specific architecture, compilation of a customized kernel, integration of information of specific devices such as PLC (programmable logic controller) by packaging or loading methods, forming a complete simulation image, and after successful operation in the QEMU simulation environment, finally applying fuzz testing technology to the corresponding functional modules of the firmware to mine vulnerabilities and identify potential security vulnerabilities. By using this method, the constraints of embedded device hardware are broken, the limitations of limited hardware resources of physical devices are alleviated, and the concerns about damaging the system are eliminated, making dynamic analysis technologies such as vulnerability mining that are difficult to implement on the original physical system feasible, achieving the purpose of low-cost dynamic analysis and security research on a large scale.

[0173] Embodiment 2

[0174] The purpose of this embodiment is to provide a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the steps of the above method are implemented when the processor executes the program.

[0175] Embodiment 3

[0176] The purpose of this embodiment is to provide a computer-readable storage medium.

[0177] A computer-readable storage medium stores a computer program, which executes the steps of the above method when executed by a processor.

[0178] Embodiment 4

[0179] The purpose of this embodiment is to provide a vulnerability mining system based on Windows CE operating system embedded device simulation, including:

[0180] The preprocessing module is configured to: obtain embedded device processor information;

[0181] Firmware unpacking of embedded device firmware to extract files;

[0182] The embedded device simulation module is configured to: obtain the operating system of the embedded device based on the embedded device processor information and the extracted files, package the operating system and the application of the embedded device to form a complete simulation image, which is used to realize the system state simulation of the embedded device using the Windows CE operating system;

[0183] The vulnerability mining fuzz testing module is configured to: run fuzz testing in a simulation environment to mine vulnerabilities in the corresponding functional modules of the firmware.

[0184] Embodiment 5

[0185] The purpose of this embodiment is to provide a computer program product containing instructions, which, when running on a computer, enables the computer to execute the methods and functions involved in any of the above embodiments.

[0186] The steps involved in the apparatus of the above embodiment correspond to the method embodiment 1, and the specific implementation method can refer to the relevant description part of embodiment 1. The term "computer-readable storage medium" should be understood as a single medium or multiple media including one or more instruction sets; it should also be understood to include any medium that can store, encode or carry an instruction set for execution by a processor and enable the processor to execute any method in the present invention.

[0187] Those skilled in the art should understand that the modules or steps of the present invention described above can be implemented by a general-purpose computer device, or alternatively, they can be implemented by a program code executable by a computing device, so that they can be stored in a storage device and executed by the computing device, or they can be made into individual integrated circuit modules, or multiple modules or steps therein can be made into a single integrated circuit module for implementation. The present invention is not limited to any specific combination of hardware and software.

[0188] Although the above describes the specific implementation mode of the present invention in conjunction with the accompanying drawings, it is not intended to limit the scope of protection of the present invention. Those skilled in the art should understand that various modifications or variations that can be made by those skilled in the art on the basis of the technical solution of the present invention without creative work are still within the scope of protection of the present invention.

Claims

1. A vulnerability mining method based on Windows CE operating system embedded device simulation, characterized in that: include: Get embedded device processor information; Firmware unpacking of embedded device firmware to extract files; Based on the embedded device processor information and the extracted files, the operating system of the embedded device is obtained, and the operating system and the application of the embedded device are packaged to form a complete simulation image, which is used to realize the system state simulation of the embedded device using the Windows CE operating system; Run fuzz testing in a simulation environment to discover vulnerabilities in the corresponding functional modules of the firmware.

2. The vulnerability mining method based on Windows CE operating system embedded device simulation as claimed in claim 1 is characterized in that: The way to obtain embedded device processor information is: For actual physical devices, obtain the processor model based on the information in the Windows CE system's control panel; or Connect to the actual physical device through dedicated software or network cable to obtain the hardware information of the processor, including the processor model; Preferably, unpacking the firmware of the embedded device to extract files specifically includes: Get the embedded device firmware kernel NK.bin by accessing the website or reading the SD card. The NK.bin file contains Windows system files and some additional customized components. For NK.bin, use the decompression tool to extract the files in it.

3. The vulnerability mining method based on Windows CE operating system embedded device simulation as claimed in claim 1 is characterized in that: When the embedded device is a programmable logic controller, the firmware of the embedded device is unpacked to extract files, specifically including: Based on the PLC's official website, navigate to the firmware download page: On the official website, navigate further to the firmware download area based on the firmware download page; Select the corresponding model in the firmware download area to download and obtain the device firmware kernel NK.bin; Use the unpacking tool to extract the files in the device firmware kernel NK.bin; Preferably, obtaining the operating system of the embedded device based on the embedded device processor information and the extracted file includes: Extract QEMU emulator development board configuration information; Generate BSP configuration files and compile custom kernels; Based on the extracted configuration information, a BSP configuration file is generated and a customized kernel is compiled to obtain the operating system of the embedded device.

4. The vulnerability mining method based on Windows CE operating system embedded device simulation as claimed in claim 1 is characterized in that: Extract the QEMU emulator development board configuration information, including: Clone the QEMU Git repository and switch to the branch that contains the QEMU emulator development board support. In the QEMU source code, find the machine definition associated with the specific architecture; Get the development board configuration information; Preferably, generating a BSP configuration file includes: In the BSP development environment, install the corresponding development tools; Create a new PB project, start the project wizard, and initialize the BSP framework; Depending on the target operating system and hardware platform, choose to clone a BSP template or create a new BSP framework from scratch; Set up the BSP directory structure, write peripheral drivers based on hardware configuration information, and write or modify hardware abstraction layer code to provide abstraction and encapsulation of hardware so that the operating system or RTOS can access hardware resources more conveniently; Finally, use the development tool chain to compile the BSP source code to generate an executable binary file or image.

5. The vulnerability mining method based on Windows CE operating system embedded device simulation as claimed in claim 1 is characterized in that: Compile a custom kernel. The specific process includes: Based on the created BSP, add corresponding modules according to requirements; Select the basic configuration structure; Select the basic configuration and project name of the operating system image; Choose a method to customize your device: Select operating system features; Select the basic class library; Select operating system core services; Preferably, the operating system and the application of the embedded device are packaged to form a complete simulation image, including: Mounting method: Package the application files extracted from the embedded device firmware into a disk image file in fat16 format, and then convert it to qcow2 format supported by QEMU; or Packaging method: Modify the project.bib file of the Windows CE.NET target project to integrate the application files extracted from the embedded device firmware into the created Windows CE BSP.

6. The vulnerability mining method based on Windows CE operating system embedded device simulation as claimed in claim 1 is characterized in that: Run fuzz testing in a simulation environment to discover vulnerabilities in the corresponding functional modules of the firmware, including: Using generation strategies, we can generate test cases that conform to the protocol specifications based on the precise syntax information of the network communication protocol, and generate high-quality seed files. Introduce mutation strategies to perform refined mutation operations on the generated test cases, and combine the returned coverage information to continuously optimize the test case mutation strategy, conduct more in-depth and comprehensive testing of the tested program, obtain the input space and potential abnormal scenarios, and predict possible vulnerabilities and defects in the tested program; During the test execution phase, the execution status and abnormal behavior of the program under test are closely monitored, and the vulnerabilities and defects in the program under test are identified by comparing and analyzing these results.

7. A vulnerability mining system based on Windows CE operating system embedded device simulation, characterized by: include: The preprocessing module is configured to: obtain embedded device processor information; Firmware unpacking of embedded device firmware to extract files; The embedded device simulation module is configured to: obtain the operating system of the embedded device based on the embedded device processor information and the extracted files, package the operating system and the application of the embedded device to form a complete simulation image, which is used to realize the system state simulation of the embedded device using the Windows CE operating system; The vulnerability mining fuzz testing module is configured to: run fuzz testing in a simulation environment to mine vulnerabilities in the corresponding functional modules of the firmware.

8. A computer program product, comprising a computer program, characterized in that When the computer program is executed by a processor, the method according to any one of claims 1 to 6 is implemented.

9. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the program, the steps of the method described in any one of claims 1 to 6 are implemented.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the program is executed by a processor, the steps of the method described in any one of claims 1 to 6 are performed.

Images