As described in the android source, the format of the boot images (boot.img and recovery.img) is simple.
The first 2048 bytes are the header, which contains information about the image.
Then comes the kernel, then the ramdisk, then optionally the second stage.
Since the image is divided into pages, between each of those code segments is a padding(of 0x00).
OF COURSE the images by motorola in the XT300 do NOT follow this standard.
The *_size and *_addr are different. did not manage to understand those. The kernel is compressed in gzip apparently(search for the gzip magic 1f 8b 08 00) with a a binary that handles the decompressing as prefix for the code block.
The binary header code is probably the bootloader. As explained in another post, when erasing the boot partition, fastboot disappears and the device ends unrecoverable from our point of view. Seems to be the same method used in the droid with the mbmloader, etc.
The biggest problem is that at the end of the image is the CERTIFICATE. YAY! The certificate is a encrypted section which stores a kind of checksum of the image. The bootloader decrypts this checksum and then verifies it against the present image.
So, without being able to modify this checksum since it is encrypted by motorola, a custom boot image can’t be run. This sucks. Thanks Motorola…
Sorry, I do not know which format they are in and hence how to show them as text with
openssl. If someone finds out, please leave a comment.