A mirror checking method, device, equipment and storage medium

Abstract

The application discloses a mirror image checking method and device, equipment and a storage medium, and relates to the technical field of mirror image security. The method comprises the following steps: determining a code mirror image file in a target format based on the processor architecture of a current embedded system; reconstructing the code in the code mirror image file in the target format, so as to adjust the code mirror image file into a target code mirror image file; wherein the target code mirror image file is a mirror image file in which a data code cavity is reserved; compiling the target code mirror image file, and adding vendor private definition information to a position corresponding to the data code cavity in an executable file generated after the target code mirror image file is compiled, so as to obtain a target executable file; and performing mirror image checking on the current embedded system based on the target executable file. Through the technical scheme of the application, the mirror image security is higher, and compared with the commonly used checking information adding method in the current technical field, the method is more concealed.

Description

Technical Field

[0001] This invention relates to the field of mirror security technology, and in particular to a mirror verification method, apparatus, device, and storage medium. Background Technology

[0002] In embedded systems, system version upgrades are a crucial function, essential for both early-stage project development and later feature iterations. Currently, the most common system upgrade process involves image verification, which typically relies on adding new header information to the beginning or end of the image file to create a new packaged upgrade file. This process requires adding custom information to the header or end of the compiled file after the system image has been successfully compiled. During the upgrade, the packaged file is then unpacked, and the custom information added to the fixed location is parsed; then, verification is performed based on certain fields. However, the current method of adding header verification information to the image header or end is relatively easy to detect, thus posing significant security risks.

[0003] In summary, how to provide a solution to the above-mentioned technical problems is a problem that needs to be solved by those skilled in the art. Summary of the Invention

[0004] In view of this, the purpose of this invention is to provide a method, apparatus, device, and storage medium for image verification. Compared with commonly used verification information addition methods in the current technical field, the method described in this invention is more covert and provides higher security for images. The specific solution is as follows:

[0005] Firstly, this application discloses a mirror verification method, including:

[0006] The target format of the code image file is determined based on the current processor architecture of the embedded system;

[0007] The code in the target format code image file is reconstructed to adjust the code image file into a target code image file; wherein, the target code image file is an image file with reserved data code holes;

[0008] The target code image file is compiled, and the vendor-specific definition information is added to the executable file generated after the target code image file is compiled, corresponding to the data code hole, to obtain the target executable file;

[0009] The current embedded system is image verified based on the target executable file.

[0010] Optionally, the step of refactoring the code in the target format code image file to adjust the code image file into the target code image file includes:

[0011] Determine the startup file in the code image file of the target format;

[0012] According to the preset instruction addition rules, an empty instruction is added after the first jump instruction in the startup file to adjust the code image file into the target code image file;

[0013] Accordingly, the step of compiling the target code image file and adding vendor-specific definition information to the location corresponding to the data code hole in the executable file generated after compiling the target code image file to obtain the target executable file includes:

[0014] The target code image file is compiled, and vendor-specific definition information is added to the position corresponding to the empty instruction in the executable file generated after the target code image file is compiled, so as to obtain the target executable file.

[0015] Optionally, the step of adding an empty instruction after the first jump instruction in the startup file according to a preset instruction addition rule to adjust the code image file into a target code image file includes:

[0016] Determine the current execution state of the embedded system, and determine the instruction mode corresponding to the execution state based on the instruction options preset by the compiler;

[0017] The instruction length of the current instruction is determined based on the execution state and the instruction mode, so as to obtain the length of the first byte of space occupied by the current instruction;

[0018] Obtain the data size corresponding to the vendor private definition information, and determine the length of the second byte of space occupied by the vendor private definition information based on the data size;

[0019] Based on the length of the first byte and the length of the second byte, the target number of null instructions corresponding to the addition is determined, and then the target number of null instructions are added after the first jump instruction in the startup file to adjust the code image file into the target code image file.

[0020] Optionally, the step of compiling the target code image file and adding vendor-specific definition information to the location corresponding to the data code hole in the executable file generated after compiling the target code image file to obtain the target executable file includes:

[0021] The target code image file is compiled, and through the file read / write interface, the vendor's private definition information is added to the executable file generated after the target code image file is compiled, corresponding to the position of the data code hole, so as to obtain the target executable file.

[0022] Optionally, the step of compiling the target code image file and adding vendor-specific definition information to the location corresponding to the data code hole in the executable file generated after compiling the target code image file to obtain the target executable file includes:

[0023] The target code image file is compiled, and the image verification data used for software data verification, and / or the expected data used for at least one of the operations of rehearsing, anticipating, or estimating a running mode are added to the position corresponding to the data code hole in the executable file generated after the target code image file is compiled, so as to obtain the target executable file.

[0024] Optionally, the step of performing image verification on the current embedded system based on the target executable file includes:

[0025] Determine the image verification stage type corresponding to the image verification;

[0026] Based on the image verification stage type, the current embedded system is image verified using the target executable file.

[0027] Optionally, the step of performing image verification on the current embedded system based on the target executable file according to the image verification stage type includes:

[0028] If the image verification stage type is the file download stage, then the target executable file is parsed to obtain a fixed offset position corresponding to the data code hole in order to locate the data code hole;

[0029] The image characteristics of the target executable file are verified based on the vendor-specific definition information in the data code hole, and it is determined whether the image characteristic verification of the target executable file passes.

[0030] If the image feature verification of the target executable file fails, a verification failure message is returned; if the image feature verification of the target executable file passes, the process moves from the file download stage to the image initialization stage.

[0031] The target executable file is loaded into memory, and the image loading address information of the vendor-specific definition information in the memory is determined based on the target executable file to obtain the target loading location corresponding to the vendor-specific definition information;

[0032] The system reads the vendor-specific information from the target loading location using a preset verification procedure, then verifies the vendor-specific information and determines whether the verification passes.

[0033] If the vendor-defined information verification passes, the image program corresponding to the target executable file is started; if the vendor-defined information verification fails, the initial image stage is terminated or the preset verification program is switched to the reset state.

[0034] Secondly, this application discloses a mirror verification device, comprising:

[0035] The image file format determination module is used to determine the target format of the code image file based on the processor architecture of the current embedded system.

[0036] The image file code refactoring module is used to refactor the code in the target format code image file to adjust the code image file into a target code image file; wherein, the target code image file is an image file with reserved data code holes;

[0037] The image file compilation module is used to compile the target code image file and add vendor-specific definition information to the location corresponding to the data code hole in the executable file generated after the target code image file is compiled, so as to obtain the target executable file;

[0038] The image verification module is used to perform image verification on the current embedded system based on the target executable file.

[0039] Thirdly, this application discloses an electronic device, which includes a processor and a memory; wherein the memory is used to store a computer program, which is loaded and executed by the processor to implement the mirror verification method as described above.

[0040] Fourthly, this application discloses a computer-readable storage medium for storing a computer program; wherein the computer program, when executed by a processor, implements the mirror verification method as described above.

[0041] This application provides an image verification method, comprising: determining a code image file of a target format based on the processor architecture of the current embedded system; reconstructing the code in the code image file of the target format to adjust the code image file into a target code image file; wherein the target code image file is an image file with reserved data code holes; compiling the target code image file and adding vendor-defined information to the executable file generated after the compilation of the target code image file at the position corresponding to the data code holes to obtain a target executable file; and performing image verification on the current embedded system based on the target executable file. The beneficial effects of this application are: for different processor architectures in the embedded system, a corresponding format code image file is determined; when operating on the code image file, unlike the traditional method of adding specific data to the beginning or end of the successfully compiled image file, this application directly reconstructs the code in the code image file during the compilation stage, thus reserving data code holes in the code image file. Since this process occurs before compilation, no external intervention is required; moreover, reserving data holes inside the image and then adding verification information is more difficult to identify than adding header verification information to the beginning or end of the image, thus making it more secure. Furthermore, a new method for image verification of the current embedded system using the target executable file, derived from this method of adding verification data, offers higher image security.

[0042] In addition, the mirror verification device, equipment and storage medium provided in this application correspond to the above mirror verification method and have the same effect. Attached Figure Description

[0043] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0044] Figure 1 This is a flowchart of a mirror verification method disclosed in this application;

[0045] Figure 2 This is a flowchart of a specific mirror verification method disclosed in this application;

[0046] Figure 3 This is a schematic diagram illustrating the reconstruction and compilation of an image file as disclosed in this application;

[0047] Figure 4 This is a flowchart of a specific mirror verification method disclosed in this application;

[0048] Figure 5 This is a schematic diagram of a file download stage disclosed in this application;

[0049] Figure 6 This is a schematic diagram of the structure of a mirror verification device disclosed in this application;

[0050] Figure 7 This is a structural diagram of an electronic device disclosed in this application. Detailed Implementation

[0051] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0052] Currently, in the most common system upgrade process, image verification is typically performed by adding headers. This involves appending specific data to the beginning or end of the successfully compiled image file using file I / O (input / output) operations. However, this method is relatively easy to detect, thus posing significant security risks.

[0053] Therefore, this application provides an image verification scheme that differs from commonly used verification information addition methods. The addition method is more covert and provides higher security for the image.

[0054] This invention discloses a mirror verification method, see [link to relevant documentation]. Figure 1 As shown, the method includes:

[0055] Step S11: Determine the target format code image file based on the processor architecture of the current embedded system.

[0056] Embedded systems employ various processor architectures, each offering different advantages in different tasks during actual development. This application uses the ARM processor architecture as an example for illustration. Those skilled in the art will understand that the ARM processor architecture used in current embedded systems is merely illustrative and does not limit the type of processor architecture described. The following embodiments will all use the ARM processor architecture as an example for illustration, and will not be elaborated upon further.

[0057] Generally, code image files based on the ARM processor architecture are compiled by an ARM-specific compiler, and the final packaged program is an .axf file. AXF stands for ARM Executable File, which is generated by the ARM compiler. In addition to containing the contents of binaries (binary files), it also includes additional debugging information, which is appended before the executable binary data. Therefore, in this embodiment, the code image file format determined based on the current embedded system's ARM processor architecture is an .axf format code image file containing debugging information.

[0058] Step S12: Reconstruct the code in the target format code image file to adjust the code image file into a target code image file; wherein, the target code image file is an image file with reserved data code holes.

[0059] Unlike the common method of adding headers, which involves appending specific data to the beginning or end of the compiled image file, this embodiment reconstructs the code image file during the compilation phase. This allows for reserved data code gaps in the generated target code image file. This process occurs during compilation and requires no external intervention. Because these reserved data code gaps are internal to the image, adding verification information after compilation is much more difficult to detect than adding verification information to the beginning or end of the image, thus making it more secure.

[0060] Step S13: Compile the target code image file and add the vendor's proprietary definition information to the location corresponding to the data code hole in the executable file generated after the target code image file is compiled, so as to obtain the target executable file.

[0061] In this embodiment, after reconstructing the code image file, a target code image file with reserved data code holes can be obtained. The target code image file is then compiled, and a corresponding executable file is obtained upon successful compilation. Then, vendor-defined information is added to the successfully compiled executable file to obtain the target executable file; that is, the locations of the data code holes in the executable file are replaced with vendor-defined information to obtain the target executable file.

[0062] It should be noted that vendor-defined information is added to the successfully compiled executable file via file I / O operations. Specifically, the target code image file is compiled, and the vendor-defined information is added to the corresponding location in the compiled executable file (using a file I / O interface) along with the data code gaps, thus obtaining the target executable file. It is understood that different file I / O operations correspond to different file I / O interfaces, and other corresponding operations can also be performed on the vendor-defined information using commonly used file I / O interfaces, such as modifying or querying the vendor-defined information.

[0063] In this embodiment of the application, based on the method of reserving data code holes in the code image file, the vendor-specific definition information added at the location of the data code hole is not limited to image verification data; it can also be extended to expected data that may be used during operation.

[0064] In one specific implementation, the target code image file is compiled, and image verification data for software data verification is included. For example, vendor-defined information can include the length of the bin file, CRC (Cyclic Redundancy Check) verification information, special verification magic values, product software information, hardware information, and other information used for software data verification.

[0065] In another specific implementation, anticipated data used for at least one of the operations of rehearsing, anticipating, or estimating a running mode is added to the location corresponding to the data code hole in the executable file generated after compiling the target code image file, thus obtaining the target executable file. In summary, both implementations demonstrate that after the target code image file is compiled, vendor-defined information can be filled into the image by adding custom data, serving as a way to pass certain parameters to the system.

[0066] Step S14: Perform image verification on the current embedded system based on the target executable file.

[0067] As disclosed in the preceding steps, the generated target executable file is generated by adding vendor-defined information to the successfully compiled executable file using a mechanism that reserves data gaps. Therefore, when performing image verification on a current embedded system based on this target executable file, the image verification in this embodiment is more covert and provides higher image security compared to commonly used verification information addition methods in the current technical field.

[0068] This application provides an image verification method, comprising: determining a code image file of a target format based on the processor architecture of the current embedded system; reconstructing the code in the code image file of the target format to adjust the code image file into a target code image file; wherein the target code image file is an image file with reserved data code holes; compiling the target code image file and adding vendor-defined information to the executable file generated after the compilation of the target code image file at the position corresponding to the data code holes to obtain a target executable file; and performing image verification on the current embedded system based on the target executable file. The beneficial effects of this application are: for different processor architectures in the embedded system, a corresponding format code image file is determined; when operating on the code image file, unlike the traditional method of adding specific data to the beginning or end of the successfully compiled image file, this application directly reconstructs the code in the code image file during the compilation stage, thus reserving data code holes in the code image file. Since this process occurs before compilation, no external intervention is required; moreover, reserving data holes inside the image and then adding verification information is more difficult to identify than adding header verification information to the beginning or end of the image, thus making it more secure. Furthermore, a new method for image verification of the current embedded system using the target executable file, derived from this method of adding verification data, offers higher image security.

[0069] This application discloses a specific mirror verification method. See [link to relevant documentation]. Figure 2 As shown, the method includes:

[0070] Step S21: Determine the target format code image file based on the processor architecture of the current embedded system.

[0071] For a more detailed description of the process of step S21, please refer to the relevant content disclosed in the foregoing embodiments, which will not be repeated here.

[0072] Step S22: Determine the startup file in the target format code image file; add an empty instruction after the first jump instruction in the startup file according to the preset instruction addition rules, so as to adjust the code image file into the target code image file.

[0073] In this embodiment, the mechanism based on reserved data code gaps first requires determining the startup file in the code image file. The filename may vary slightly for some ARM platforms and needs to be determined based on the actual project; it is usually the start.s or startup.s file in the code. Further, according to preset instruction addition rules, an appropriate number of no-op instructions are added after the first jump instruction. These no-op instructions create data code gaps, and under the no-op instruction, the CPU (Central Processing Unit) does nothing.

[0074] In this embodiment of the application, in order to avoid leaving unused data holes after adding vendor-defined information to the corresponding positions of data holes, it is necessary to determine the number of empty instructions to be added by using preset instruction addition rules.

[0075] Specifically, firstly, the execution state of the current embedded system is determined, and the instruction mode corresponding to the execution state is determined according to the instruction options preset by the compiler. Secondly, the instruction length of the current instruction is determined based on the execution state and the instruction mode to obtain the length of the first byte of space occupied by the current instruction. It is understandable that, generally, the AArch64 instruction set (one execution state of the ARMv8 architecture) has an instruction length of 32 bits, or 4 bytes; while the AArch32 instruction set (another execution state of the ARMv8 architecture) is generally divided into A32 (ARM instructionsets) mode and T32 (Thumb instruction sets) mode. An A32 instruction is also 32 bits long; while a T32 instruction can be 16 bits or 32 bits, which can be selected through compiler settings.

[0076] In this embodiment, machine compilation in AArch64 mode is used as an example. Unless otherwise specified, this hardware and compilation mode will be followed. In AArch64 mode, where each instruction is 32-bit, the size of the vendor-defined information to be inserted needs to be determined in advance. Therefore, the size of the vendor-defined information is obtained, and further, the length of the second byte occupied by the vendor-defined information is determined based on the data size. Finally, the target number of null instructions to be added is determined based on the first byte length and the second byte length. Then, the target number of null instructions is added after the first jump instruction in the startup file to adjust the code image file into the target code image file.

[0077] For example, assuming the size of the data to be inserted is A bytes, then the required data gap size is A / 4 bytes. Because ARM instructions occupy 32 bits, or 4 bytes, the size of the inserted data must be 4-byte aligned to ensure no unused data gaps are left in the code.

[0078] For example, if the vendor-specific definition information to be added is 16 bytes in size, the default start.s code of the project would look like this:

[0079] Start:

[0080] LDR PC,Reset_Addr

[0081] .balign 4

[0082] Reset_Addr:.word Reset_Handler

[0083] .global Reset_Handler

[0084] .type Reset_Handler,"function"

[0085] Reset_Handler:

[0086] *** / / code”

[0087] Here, `Start` is the code that initiates the project. Its first instruction, `LDR PC,Reset_Addr`, instructs the CPU to execute assembly code at the address of the function `Reset_Addr`. If a 16-byte data code gap needs to be added, four `nop` instructions need to be added after this instruction, as shown below:

[0088] Start:

[0089] LDR PC,Reset_Addr

[0090] nop

[0091] nop

[0092] nop

[0093] nop

[0094] .balign 4

[0095] Reset_Addr:.word Reset_Handler

[0096] .global Reset_Handler

[0097] .type Reset_Handler,"function"

[0098] Reset_Handler:

[0099] *** / / code”

[0100] After successful compilation, opening the compiled file and comparing it with the image file without null instructions reveals a significant amount of machine code data corresponding to these null instructions. This data is not used during image execution, nor is it accessed by any code program. Therefore, in this embodiment, the data code gaps created in the code image file using null instructions are used as locations to store vendor-defined information.

[0101] Step S23: Compile the target code image file and add the vendor-specific definition information to the position corresponding to the empty instruction in the executable file generated after the target code image file is compiled, so as to obtain the target executable file.

[0102] In this embodiment, we also use an AXF format code image containing debugging information, which is the most commonly used image file format for ARM architecture project development. After adding the NOP instruction, open the compiled .axF target executable file, and replace the machine code data containing the null instruction with custom verification data to obtain the target executable file. That is, add the vendor's proprietary information to the location corresponding to the null instruction in the executable file generated after compiling the target code image file to obtain the target executable file.

[0103] like Figure 3 The diagram illustrates the reconstruction and compilation of a code image file, all of which fall under the code compilation stage. First, the starting code of the project is modified, usually the start.s file. An empty instruction is used after the first jump instruction in the code to create a data code void. Second, vendor-defined verification information is added to the executable file of the compiled result. This is mainly done by using file operations to open the executable file and filling the machine code data corresponding to the empty instruction with vendor-defined verification data.

[0104] Step S24: Perform image verification on the current embedded system based on the target executable file.

[0105] For a more detailed explanation of step S24, please refer to the relevant content disclosed in the foregoing embodiments, which will not be repeated here.

[0106] The beneficial effects of this application are as follows: For different processor architectures in embedded systems, a corresponding code image file format is determined; when operating on the code image file, unlike the traditional method of adding specific data to the header or tail of a successfully compiled image file, this application directly reconstructs the code in the code image file during the compilation stage, leaving data gaps in the code image file. Since this process occurs before compilation, no external intervention is required; moreover, reserving data gaps within the image and then adding verification information makes it more difficult to identify than adding header verification information to the header or tail of the image, thus enhancing security. Furthermore, the new method for image verification of the current embedded system using the target executable file, derived from this method of adding verification data, offers even higher image security.

[0107] This application discloses a specific image verification method, which is a new image verification process derived from the aforementioned method of adding verification data; wherein, see Figure 4 As shown, the image verification of the current embedded system based on the target executable file includes:

[0108] Step S31: Determine the mirror verification stage type corresponding to the mirror verification.

[0109] In this embodiment of the application, the image verification stage type is divided into two types: one is in the file download stage, and the other is in the image initialization stage, i.e., the BOOT running stage.

[0110] Step S32: Perform image verification on the current embedded system based on the target executable file according to the image verification stage type.

[0111] In one specific implementation, verification is performed during the file download phase. Specifically, if the image verification phase is a file download phase, the target executable file is parsed to obtain a fixed offset position corresponding to the data code hole, thus locating the data code hole. It can be understood that by bypassing the image instruction data from the fixed offset position within the target executable file, the data hole area reserved by the null instruction can be located. Then, the image characteristics of the target executable file are verified based on the vendor-defined information in the data code hole, and it is determined whether the image characteristic verification of the target executable file passes.

[0112] like Figure 5The diagram illustrates the general process of image verification during the file download phase. First, the target executable file is opened, and then the machine code for the null instruction is offset to its location within the file code. Since the data size corresponding to the vendor's proprietary information is predetermined, the data is read according to the vendor-defined data size. Further verification of the data content is then performed. This primarily verifies the integrity, availability, and other special properties of the image. If the image characteristic verification of the target executable file fails, a verification failure message is returned; if the image characteristic verification of the target executable file passes, it proves that the image can be stored inside the chip for subsequent upgrades and updates. It should be noted that image verification during the file download phase does not rely on the limitation of the machine code loading address.

[0113] In another specific implementation, the process involves passing the file download stage and then verifying it during the image initialization stage. Specifically, the target executable file is loaded into memory, and the image load address information of the vendor-defined information in memory is determined based on the target executable file to obtain the target load location corresponding to the vendor-defined information. It should be noted that the image initialization stage relies on the image load address information, which is determined after the ARM code image file is compiled. This information determines the memory load location corresponding to the machine code of these null instructions.

[0114] Furthermore, the vendor-defined information in the target loading location is read through a preset verification program, and then the vendor-defined information is verified. In this embodiment, the vendor-defined verification information can be read from these code areas via memory access and then verified. Because this verification occurs after the program has started running, it allows for more flexible verification of board hardware information, making the verification more comprehensive.

[0115] In this embodiment, during the verification process, it is determined whether the vendor-defined information verification passes. If the vendor-defined information verification passes, the image program corresponding to the target executable file is started. If the vendor-defined information verification fails, the image initialization stage is terminated or the preset verification program is redirected to a reset state. It can be seen that during the image initialization stage or after the image starts, the memory region loaded by the image is offset to the location of the data code gap reserved during the compilation stage, and then the vendor-defined data segment is read out and filled. Verification is performed based on the content of the data segment. If the verification fails, a new image program is not started; the boot process can be terminated or the program can be redirected to a reset state and no further execution can continue.

[0116] As can be seen, the new image verification method derived from the method of adding verification data disclosed in the foregoing embodiments in this application provides more diverse verification methods. In ordinary image verification, verification information is located at the beginning or end of the image, and verification must be completed before the image is loaded. However, the verification method in this application can be used after the image starts. Furthermore, since the vendor-defined information is not limited to image verification data but can be extended to expected data that may be used during operation, it can also check the hardware platform on which the image runs or other information.

[0117] Accordingly, this application also discloses a mirror verification device, see [link to relevant documentation]. Figure 6 As shown, the device includes:

[0118] Image file format determination module 11 is used to determine the target format of the code image file based on the processor architecture of the current embedded system;

[0119] The image file code refactoring module 12 is used to refactor the code in the target format code image file to adjust the code image file into a target code image file; wherein, the target code image file is an image file with reserved data code holes;

[0120] The image file compilation module 13 is used to compile the target code image file and add the vendor's private definition information to the position corresponding to the data code hole in the executable file generated after the target code image file is compiled, so as to obtain the target executable file;

[0121] The image verification module 14 is used to perform image verification on the current embedded system based on the target executable file.

[0122] For more detailed information on the working process of each of the above modules, please refer to the relevant content disclosed in the foregoing embodiments, which will not be repeated here.

[0123] Therefore, the above-described solution in this embodiment includes: determining a target format code image file based on the processor architecture of the current embedded system; reconstructing the code in the target format code image file to adjust the code image file into a target code image file; wherein the target code image file is an image file with reserved data code holes; compiling the target code image file and adding vendor-defined information to the executable file generated after the target code image file is compiled, at the position corresponding to the data code holes to obtain a target executable file; and performing image verification on the current embedded system based on the target executable file. The beneficial effects of this application are: for different processor architectures in the embedded system, a corresponding format code image file is determined; when operating on the code image file, unlike the traditional method of adding specific data to the beginning or end of the successfully compiled image file, this application directly reconstructs the code in the code image file during the compilation stage, thus reserving data code holes in the code image file. Since this process occurs before compilation, no external intervention is required. Furthermore, reserving data gaps within the image before adding verification information makes it more difficult to detect than adding header verification information at the beginning or end of the image, thus enhancing security. Moreover, new methods for verifying embedded systems using the target executable file, derived from this method of adding verification data, offer even higher image security.

[0124] In one specific implementation, the image file code reconstruction module 12 includes:

[0125] The startup file determination module is used to determine the startup file in the target format code image file;

[0126] The empty instruction addition module is used to add an empty instruction after the first jump instruction in the startup file according to a preset instruction addition rule, so as to adjust the code image file into the target code image file;

[0127] Accordingly, the image file compilation module 13 includes:

[0128] The vendor information adding unit is used to compile the target code image file and add vendor-specific definition information to the position corresponding to the empty instruction in the executable file generated after the target code image file is compiled, so as to obtain the target executable file.

[0129] In one specific implementation, the empty instruction addition module includes:

[0130] An execution state determination unit is used to determine the current execution state of the embedded system;

[0131] The instruction mode determination unit is used to determine the instruction mode corresponding to the execution state based on the instruction options preset by the compiler.

[0132] The first byte length acquisition unit is used to determine the instruction length of the current instruction based on the execution state and the instruction mode, so as to obtain the first byte length of the space occupied by the current instruction;

[0133] The second byte length acquisition unit is used to acquire the data size corresponding to the vendor private definition information, and determine the second byte length of the space occupied by the vendor private definition information based on the data size;

[0134] The empty instruction quantity determination unit is used to determine the target quantity corresponding to adding the empty instructions based on the first byte length and the second byte length, and then add the target quantity of empty instructions after the first jump instruction of the startup file to adjust the code image file into the target code image file.

[0135] In one specific implementation, the image file compilation module 13 includes:

[0136] The file read / write operation unit is used to compile the target code image file, and through the file read / write interface, use file read / write operations to add vendor-specific definition information to the position corresponding to the data code hole in the executable file generated after the target code image file is compiled, so as to obtain the target executable file.

[0137] In one specific implementation, the image file compilation module 13 includes:

[0138] The first image file compilation unit is used to compile the target code image file and add the image verification data used for software data verification to the position corresponding to the data code hole in the executable file generated after the target code image file is compiled, so as to obtain the target executable file.

[0139] And / or, a second image file compilation unit is used to add expected data used for at least one of the operations of rehearsing, anticipating, or estimating a running mode to the position corresponding to the data code hole in the executable file generated after the target code image file is compiled, so as to obtain a target executable file.

[0140] In one specific implementation, the mirror verification module 14 includes:

[0141] The image verification stage type determination module is used to determine the image verification stage type corresponding to the image verification.

[0142] The image verification unit is used to perform image verification on the current embedded system based on the target executable file according to the image verification stage type.

[0143] In one specific implementation, the mirror verification module 14 includes:

[0144] The first-stage processing unit is configured to, if the image verification stage type is a file download stage, parse the target executable file to obtain a fixed offset position corresponding to the data code hole to locate the data code hole; verify the image characteristics of the target executable file according to the vendor-defined information in the data code hole, and determine whether the image characteristic verification of the target executable file passes; if the image characteristic verification of the target executable file fails, return a verification failure message; if the image characteristic verification of the target executable file passes, proceed from the file download stage to the image initialization stage.

[0145] The second-stage processing unit is used to load the target executable file into memory, and determine the image loading address information of the vendor private definition information in the memory according to the target executable file, so as to obtain the target loading location corresponding to the vendor private definition information; read the vendor private definition information in the target loading location through a preset verification program, then verify the vendor private definition information and determine whether the verification of the vendor private definition information passes; if the verification of the vendor private definition information passes, the image program corresponding to the target executable file is started; if the verification of the vendor private definition information fails, the image initialization stage is terminated or the preset verification program is jumped to the reset state.

[0146] Furthermore, embodiments of this application also disclose an electronic device, Figure 7 This is a structural diagram of an electronic device 20 according to an exemplary embodiment. The content of the diagram should not be construed as limiting the scope of this application.

[0147] Figure 7 This is a schematic diagram of the structure of an electronic device 20 provided in an embodiment of this application. Specifically, the electronic device 20 may include: at least one processor 21, at least one memory 22, a power supply 23, a communication interface 24, an input / output interface 25, and a communication bus 26. The memory 22 stores a computer program, which is loaded and executed by the processor 21 to implement the relevant steps in the image verification method disclosed in any of the foregoing embodiments. Alternatively, the electronic device 20 in this embodiment may specifically be a computer.

[0148] In this embodiment, the power supply 23 is used to provide operating voltage for each hardware device on the electronic device 20; the communication interface 24 can create a data transmission channel between the electronic device 20 and external devices, and the communication protocol it follows can be any communication protocol applicable to the technical solution of this application, and is not specifically limited here; the input / output interface 25 is used to acquire external input data or output data to the outside world, and its specific interface type can be selected according to specific application needs, and is not specifically limited here.

[0149] In addition, the memory 22, as a carrier for resource storage, can be a read-only memory, random access memory, disk, or optical disk, etc. The resources stored on it can include an operating system 221, computer programs 222, and data 223, etc. The data 223 can include various types of data. The storage method can be temporary storage or permanent storage.

[0150] The operating system 221 is used to manage and control the various hardware devices on the electronic device 20 and the computer program 222, which may be Windows Server, Netware, Unix, Linux, etc. In addition to including a computer program capable of performing the image verification method executed by the electronic device 20 as disclosed in any of the foregoing embodiments, the computer program 222 may further include a computer program capable of performing other specific tasks.

[0151] Furthermore, this application also discloses a computer-readable storage medium, which includes random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disks, magnetic disks, optical disks, or any other form of storage medium known in the art. The computer program, when executed by a processor, implements the aforementioned image verification method. Specific steps of this method can be found in the corresponding content disclosed in the foregoing embodiments, and will not be repeated here.

[0152] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to in the method section.

[0153] The steps of the image verification method or algorithm described in conjunction with the embodiments disclosed herein can be implemented directly by hardware, a software module executed by a processor, or a combination of both. The software module can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art.

[0154] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0155] The above provides a detailed description of the mirror verification method, apparatus, device, and storage medium provided by the present invention. Specific examples have been used to illustrate the principles and implementation methods of the present invention. The description of the above embodiments is only for the purpose of helping to understand the method and core ideas of the present invention. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of the present invention. Therefore, the content of this specification should not be construed as a limitation of the present invention.

Claims

1. A mirror verification method, characterized in that, include: The target format of the code image file is determined based on the current processor architecture of the embedded system; The code in the target format code image file is reconstructed to adjust the code image file into a target code image file; wherein, the target code image file is an image file with reserved data code holes; The target code image file is compiled, and the vendor-specific definition information is added to the executable file generated after the target code image file is compiled, corresponding to the data code hole, to obtain the target executable file; The current embedded system is image verified based on the target executable file; The refactoring of the code in the target format code image file to adjust the code image file into the target code image file includes: Determine the startup file in the code image file of the target format; According to the preset instruction addition rules, an empty instruction is added after the first jump instruction in the startup file to adjust the code image file into the target code image file.

2. The mirror verification method according to claim 1, characterized in that, The process of compiling the target code image file and adding vendor-specific definition information to the executable file generated after compilation of the target code image file at the location corresponding to the data code hole to obtain the target executable file includes: The target code image file is compiled, and vendor-specific definition information is added to the position corresponding to the empty instruction in the executable file generated after the target code image file is compiled, so as to obtain the target executable file.

3. The mirror verification method according to claim 1, characterized in that, The step of adding an empty instruction after the first jump instruction in the startup file according to a preset instruction addition rule to adjust the code image file into a target code image file includes: Determine the current execution state of the embedded system, and determine the instruction mode corresponding to the execution state based on the instruction options preset by the compiler; The instruction length of the current instruction is determined based on the execution state and the instruction mode, so as to obtain the length of the first byte of space occupied by the current instruction; Obtain the data size corresponding to the vendor private definition information, and determine the length of the second byte of space occupied by the vendor private definition information based on the data size; Based on the length of the first byte and the length of the second byte, the target number of null instructions corresponding to the addition is determined, and then the target number of null instructions are added after the first jump instruction in the startup file to adjust the code image file into the target code image file.

4. The mirror verification method according to claim 1, characterized in that, The process of compiling the target code image file and adding vendor-specific definition information to the executable file generated after compilation of the target code image file at the location corresponding to the data code hole to obtain the target executable file includes: The target code image file is compiled, and through the file read / write interface, the vendor's private definition information is added to the executable file generated after the target code image file is compiled, corresponding to the position of the data code hole, so as to obtain the target executable file.

5. The mirror verification method according to claim 1, characterized in that, The process of compiling the target code image file and adding vendor-specific definition information to the executable file generated after compilation of the target code image file at the location corresponding to the data code hole to obtain the target executable file includes: The target code image file is compiled, and the image verification data used for software data verification, and / or the expected data used for at least one of the operations of rehearsing, anticipating, or estimating a running mode are added to the position corresponding to the data code hole in the executable file generated after the target code image file is compiled, so as to obtain the target executable file.

6. The mirror verification method according to any one of claims 1 to 5, characterized in that, The image verification of the current embedded system based on the target executable file includes: Determine the image verification stage type corresponding to the image verification; Based on the image verification stage type, the current embedded system is image verified using the target executable file.

7. The mirror verification method according to claim 6, characterized in that, The step of performing image verification on the current embedded system based on the target executable file according to the image verification stage type includes: If the image verification stage type is the file download stage, then the target executable file is parsed to obtain a fixed offset position corresponding to the data code hole in order to locate the data code hole; The image characteristics of the target executable file are verified based on the vendor-specific definition information in the data code hole, and it is determined whether the image characteristic verification of the target executable file passes. If the image feature verification of the target executable file fails, a verification failure message is returned; if the image feature verification of the target executable file passes, the process moves from the file download stage to the image initialization stage. The target executable file is loaded into memory, and the image loading address information of the vendor-specific definition information in the memory is determined based on the target executable file to obtain the target loading location corresponding to the vendor-specific definition information; The system reads the vendor-specific information from the target loading location using a preset verification procedure, then verifies the vendor-specific information and determines whether the verification passes. If the vendor-defined information verification passes, the image program corresponding to the target executable file is started; if the vendor-defined information verification fails, the initial image stage is terminated or the preset verification program is switched to the reset state.

8. A mirror verification device, characterized in that, include: The image file format determination module is used to determine the target format of the code image file based on the processor architecture of the current embedded system. The image file code refactoring module is used to refactor the code in the target format code image file to adjust the code image file into a target code image file; wherein, the target code image file is an image file with reserved data code holes; The image file compilation module is used to compile the target code image file and add vendor-specific definition information to the location corresponding to the data code hole in the executable file generated after the target code image file is compiled, so as to obtain the target executable file; The image verification module is used to perform image verification on the current embedded system based on the target executable file. The image file code refactoring module includes: The startup file determination module is used to determine the startup file in the target format code image file; The empty instruction addition module is used to add an empty instruction after the first jump instruction in the startup file according to a preset instruction addition rule, so as to adjust the code image file into a target code image file.

9. An electronic device, characterized in that, The electronic device includes a processor and a memory; wherein the memory is used to store a computer program, which is loaded and executed by the processor to implement the mirror verification method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, Used to store computer programs; wherein the computer programs, when executed by a processor, implement the mirror verification method as described in any one of claims 1 to 7.

Images