[HTC Wildfire S] no.human.being:
Ok, I just had a look at the Android sources and I'm pretty sure that I found out what those values mean. Unfortunately, ARM can switch endianness, but I think it's very obvious that the values are all "little endian", which means the least significant bit is stored at the lowest address in memory and the most significant bit is stored at the highest address in memory.

So let's compare the values.

0x00000000 41 4e 44 52 4f 49 44 21 18 b5 28 00 00 80 c0 12
0x00000000 41 4e 44 52 4f 49 44 21 00 b8 28 00 00 80 00 10

The first 8 bytes is a "magic number" identifying Android kernel images. It's identical for both kernels.

The next 4 bytes is the size of the kernel in bytes. This is 0x0028b518 (2.667.800 bytes) in the original image, while it is 0x0028b800 (2.668.544 bytes) in the "recomposed" one. Remember the values are little-endian so we have to read the bytes "in reverse" to get the "actual" values. As you can see we copied "too much" out of the image. The actual kernel was smaller than we thought it was while extracting it from the image, so the "size" got messed up while recomposing.

The next 4 bytes is the physical volatile memory (RAM) address to which the kernel is loaded. This is 0x12c08000 in the original image, while it is 0x10008000 on the "recomposed" one.

Now the next line.

0x00000010 20 48 02 00 00 00 c0 13 00 00 00 00 00 00 b0 13
0x00000010 00 50 02 00 00 00 00 11 00 00 00 00 00 00 f0 10

First 4 bytes is the size of the initrd. This is 0x00024820 (149.536 bytes) in the original image, while it is 0x00025000 (151.552 bytes) in the "recomposed" one. So, like with the kernel, we took data "beyond the actual size of the initrd" from the image while extracting it.

Next 4 bytes is the physical volatile memory (RAM) address to which the initrd is loaded. This is 0x13c0000000 in the original image, while it is 0x11000000 on the "recomposed" one.

Next 4 bytes is the size of the "secondary payload". This is zero (0x00000000) on both images, so it is not used.

Last 4 bytes is the physical address where the "secondary payload" is loaded to in RAM. This is 0x13b00000 on the original image while it is 0x10f00000 on the "recomposed" one, so it seems to be always 0x00100000 (1.048.576 bytes) lower than the physical address to which the initrd is loaded so "secondary payload" is probably expected to be 1 MiB at most.

Now the last line.

0x00000020 00 01 c0 12 00 08 00 00 00 00 00 00 00 00 00 00
0x00000020 00 01 00 10 00 08 00 00 00 00 00 00 00 00 00 00

First 4 bytes is the physical address for so-called "kernel tags". This is 0x12c00100 on the original image while it is 0x10000100 on the "recomposed" one. Not sure what this value does.

Next 4 bytes is the size of a memory page. This is 0x00000800 in both, the original and the "recomposed" image, so both kernels are designed to handle memory in pages of 2048 bytes. Page size is an architecture-dependant property. On an x86, pages are always 4096 bytes so this tells us that ARM's pages are half the size of x86 pages.

Last 8 bytes obviously zero in both cases.

Now the second difference.

0x00000240 d6 8a b5 a9 76 c4 d3 f3 31 af 5a d6 4f 8c 45 03
0x00000250 8b 9b 78 37 00 00 00 00 00 00 00 00 00 00 00 00

0x00000240 3a 26 00 aa dd 6c 59 61 3e aa a3 e9 39 0c 33 35
0x00000250 38 dd 69 cc 00 00 00 00 00 00 00 00 00 00 00 00

In some implementations of "mkbootimg", this is some kind of HMAC, which is the "symmetric cryptography" variant of a digital signature. Its length is obviously 20 bytes (160 bit). I don't think that anyone is verifying it though, as there are variations of the "mkbootimg" floating around that just put random numbers or timestamps here.

Let's see whether we can make use of this information to build a working kernel image.