Research on the image file format of Windows ce6.0 Operating System

 

I sorted out some of the binfiles I studied earlier, wrote an article, and threw it out. It will be published at the end of the year. I haven't done anything recently. I 've been idle for a long time. Sometimes I have a look at C #, and there is nothing better. It indicates that I have sorted out the materials I used to write articles and some materials I used to write articles, I wrote the article and published it. I hope to learn from my classmates. Do not copy it!

The image files of the Windows CE operating system and bootloader compiled and compiled by the Windows CE development tool platform build are mainly in two formats. bin is a record-type image file with the filename suffix and. A raw image file with the suffix nb0. The former organizes image data in units of records, and the latter is a binary snapshot of the image running in an embedded system.

The first step for downloaderimage function execution is to call the getimagetype function to obtain the format type of the image file. Getimagetype is also a blcommon library function, which is implemented in the same source file as the downloadimage function. The principle of the getimagetype function to query the image file format type is very simple: Each Windows CE image file has a 7-byte signature (magic number) at the start position of the file data ), it corresponds to the image file format as follows:

"N000ff \ x0a" -- bl_image_type_manifest

"X000ff \ x0a" -- bl_image_type_multixip

"B000ff \ x0a" -- bl_image_type_bin

"S000ff \ x0a" -- bl_image_type_signed_bin

"R000ff \ x0a" -- bl_image_type_signed_nb0

No signature -- bl_image_type_unknown

 

Typedef Enum _ bl_image_type

{

Bl_image_type_manifest = 0,

Bl_image_type_bin,

Bl_image_type_nb0,

Bl_image_type_signed_bin,

Bl_image_type_signed_nb0,

Bl_image_type_multixip,

Bl_image_type_unknown,

Bl_image_type_not_found,

} Bl_image_type;

The first four types of images are record-type images. Only bl_image_type_signed_nb0 indicates the original image file format. In addition, the downloaderimage function treats the bl_image_type_unknown type with no signature as the original image. Bl_image_type_multixip is used in Windows CE 5.0 and earlier versions to represent multi-segment image files. In Windows CE 6.0, bl_image_type_manifest is used to process multi-segment operating system images, the bl_image_type_multixip type is no longer supported. The definition of this type is reserved only for backward compatibility in source code.

The data in the bl_image_type_manifest image file is the region information of the record-type image file with multiple segments. Multi-segment images are, in short, binary data of the operating system or bootloader is scattered in discontinuous physical storage intervals. Manifest literally means a "cargo bill". This type of image file is not real Windows ce OS or Binary Runtime data of bootloader, only the header information used to download multi-region images. Due to the special nature of the image data, "n000ff \ x0a" -- bl_image_type_manifest type image files -- also known as manifest data -- are stored in different locations from general image file data, it uses the special global variable g_downloadmanifest for storing dowloadmanifest.

The dowloadmanifest struct type is defined in header file % _ winceroot % \ public \ common \ oak \ Inc \ blcommon. h as follows:

// Download manifest.

Typedef struct _ multibininfo _

{

DWORD dwnumregions; // number of files to be downloaded, number of binfiles to be downloaded

Regioninfo region [bl_max_bin_regions];

} Multibininfo, * pmultibininfo;

Typedef multibininfo downloadmanifest;

Typedef multibininfo * pdownloadmanifest;

Multi-segment means that data is stored in multiple image files in the binary operating hours of an operating system or bootloader, the data of these image files corresponds to multiple physical storage areas that can be continuous or discontinuous. Dwnumregion, a member of the dowloadmanifest struct, is the number of segments of a multi-region image, that is, the number of files of multiple subsequent image files. The region array member is responsible for storing the information of each region segment. The bl_max_bin_regions header file % _ winceroot % \ public \ common \ oak \ Inc \ blcommon. H is defined as 25, which means that the number of multi-region image segments cannot exceed 25. The element type regioninfo of the region array member is a struct defined in the header file blcommon. h:

// Download file info (start address, length, filename, etc.). Download file information

Typedef struct _ regioninfo _

{

DWORD dwregionstart;

DWORD dwregionlength;

Char szfilename [max_path];

} Regioninfo, * pregioninfo;

The three members of the regioninfo struct, dwregionstart, dwregionlength, and szfilename, respectively indicate the starting address of an image segment in physical storage, the length of the segment in bytes, and correspond to the Image segment. image File Name.

For image files of the bl_image_type_manifest type, the file data follows the 7-byte format pattern, and the download port reads the 4-byte verification data, followed by the number of 4-byte segments. The number of segments is stored in the dwnumregions Member of the g_downloadermanifest global variable, the attribute data of the g_downloadermanifest.dwnumregions segments of the image is read in sequence, including the starting address, segment length, and the image file name of the segment data, which are stored in the element of the g_downloadermanifest.dwnumregions array. The downloaderimage function calls the checkimagemanifest function to read the 4-byte verification data and all subsequent manifest data. Then, the checkimagemanifest function calls the verifychecksum function to verify the manifest data, however, the verification scope is limited to the data that stores the field header information in the g_downloadermanifest.regions array, excluding the 4-byte g_downloadermanifest.dwnumregions data.

Bl_image_type_manifest is an alternative among all image file formats. It is only used for downloading other types of image files but with leading information, it does not contain valid Binary Runtime data of the Windows CE operating system or bootloader. If the operating system image has only one segment, or you use a record-type image file that contains the storage location and other header information, you can also use the manifest leading data. After the image file of the bl_image_type_manifest type is downloaded, The downloaderimage function does not immediately execute and return the result, download the image file containing the real operating system binary data based on the information provided by the manifest data in the global variable g_downloadermanifest.

The bl_image_type_bin type is the most common and common record-type image file format. bin is the file name suffix. The downloaderimage function calls the downloadbin function to process this type of image files. downloaderimage is also a blcommon library function. In an image file of the bl_image_type_bin type, the initial 7-byte signature is followed by the starting address and length of the image file in bytes of the destination physical storage in the embedded system, each occupies 4 bytes. The two data types correspond to the dwregionstart and dwregionlength members of the regioninfo struct respectively. The next step is to store multiple records with the same structure as binary data in the operating system ), each record consists of 4-byte memory start address dwrecaddr, 4-byte record length dwreclen, 4-byte Verification Code dwrecchk, and dwreclen-byte record data. The downloaderimage function reads each record from the download port in sequence and performs verification on them. The verification is also based on records, after the verification is complete, the record data with the removal header is stored in the physical storage location of the address specified by dwrecaddr. If the destination storage location of the record is the fllash storage device, it is usually cached in the RAM memory before writing the entire image file to the fllash.

Similar to bl_image_type_bin, the most common raw image files are suffixed with. nb0 as the file name. They are processed using the downloadernb0 function. Because the data in the original image file is only the most direct snapshot of the data in the binary running hours of the Windows CE operating system or bootloader in physical storage, it is completely unformatted, there is not even a 7-byte signature. In the getimagetype function, this image file format type is defined as bl_image_type_unknown. Generally, the downloaderimage function treats the unsigned bl_image_type_unknown type as the original image file, but with high security (the macro secure_bootloader is defined) image files without signatures should not be accepted by bootloader. The method for processing original image files is the easiest. bootloader only needs to read all the image data from the download port and store the data to the corresponding storage location, and does not require verification. The starting address and length of the original image file data in physical storage depend on the manifest data. the image file of the nb0 type cannot be downloaded separately. bootloader must first download the image file of the bl_image_type_manifest type as its leading attribute information.

. A binfile is an image file that describes the nature of the file. It consists of the file header (head), the starting address of the image data (imagestart), the image data length (imagelength), and multiple relatively independent records (record). The header consists of seven bytes. The content is: 42 30 30 30 46 46 0a, that is, "b000ff \ x0a". This is the basis for determining whether the image file is of the. Bin type. The starting address (imagestart) of the image data is composed of four bytes. It defines the starting address of the image file to be parsed and loaded in the memory. The Image Data Length (imagelength) is also composed of four bytes, which indicates the total storage space occupied by the. Bin image file after parsing in the memory. Each record consists of a 4-byte start storage address (recordstart), a 4-byte data length (recordlength), and a 4-byte checksum) and recordlength record data (recorddata.

According to the preceding. BIN file format, the. binfile is not a simple copy of the memory program space. Therefore, it cannot be directly written into the memory or flash space by serial port. It must be downloaded through Pb and parsed by eboot according to the. binfile format and loaded again before running.

The. nb0 file is different. It is a hard copy of the memory running program image, and its data content is the same as the data in the memory when the program is running. In view of this,. nb0 can be downloaded to the specified position through the serial port for direct operation. Obviously,. nb0 is a non-existing image file.