Flashing Custom Content

I did the following and it looks like I got all the code, haven't tried compiling yet:
Is that what you tried?

I was looking into this last night.  I found out there is a script in the linux kernel source tree /scripts/extract-ikconfig which is supposed to be able to extract some config info from a zImage.  It doesn't really work for finding that config on our zImage, but I was able to look at the script source to see how it decompresses the data from zImage.  Basically it searches for the offset of the first occurence of hex values "1f 8b 08 00" which is the magic number used to identify .gz files.  In our stock zImage, this occurs at 0x33F0 (13296 in decimal).

If you take the file from that offset forward, then you can decompress it with standard tools.

As for putting it back into a zImage, I'm assuming that everything before the gz chunk is part of the decompression stub, and should not ever require modification.  So hopefully prepending that to a re-archived image would work.

However there is one other snag that I haven't quite figured.  If you notice when you zcat the .gz, it displays a message about "ignoring trailing garbage".  So there is apparently some data at the end of this zImage file, which is not part of the gz archive, and I'm still not sure what that represents.  When I tried re-compressing the unmodified image on my ubuntu box...
I got a nearly identical file, except for bytes 5 through 8 (representing modified time), and of course the missing trailing garbage that was ignored during extracting the archive.

I don't know if we can just append that trailing data onto the end of our re-compressed file, or if maybe it's some super secret checksum data or something like that which depends on the contents of the rest of the image.


Edit:
I spoke with someone smarter than me on irc, regarding the trailing data (name removed for privacy):

Has anyone successfully compiled the Samsung kernel source?  As I understand it doesn't include the needed filesystem drivers, but is it possible to compile at all?  I'd be interested to see what the output image looks like.  I will probably give it a try later.  Maybe we can find a way to build from the source we have, and then patch in that binary driver from the recovery image kernel somehow.

Oh snap I just realized it built an Image file which is twice the size of the zImage.

For toolchain just export the path to its bin dir via /etc/environment and then edit the cross compiler option in the kernel sources makefile.
Also I had to move the kernel source directory to /root/android_kernel or something.  Then there's an sh script int the kernel scripts dir to create that initrd file I was talking about.

I'm posting all this from my phone so excuse the formatting please.

As far as the image is concerned, could the zImage file from CJ05 actually just be the Image file renamed as zImage?

Edit:  Okay so no it's not a renamed Image file.  I wonder what all Samsung left out to make up for the missing 1.8 meg.

In my bootloader info thread I discovered that the bootloader in /dev/bml2 is some kind of bootloader/firmware that appears to do the flashing/partitioning/etc and also does checksumming (god bless `strings`!!). It should be possible to dissect this with a hex editor... like the good old days of hacking PS2 games... force it to continue anyway on a checksum fail! after that we should be home free to flash whatever image we want on there!

Ok, I've been hard at work trying to recreate the initramfs in our custom compiled kernel.

The initramfs is stored as a cpio file embedded in the gunzipped Image file.  Here is what you can do to extract the files, assuming you have already gunzip'ed Image out of zImage from following my above post:
So we now know all the files that are included in it, and we have their data.

When the zImage gets built, it uses scripts/gen_initramfs_list.sh to create the initramfs.img file.  Apparently the Samsung kernel was originally built using a initrd.arm.initramfs_list file which is text listing out all the files to include in the initramfs including permissions,etc.  However, if you run You will see that you have the option of just passing in an already created .cpio file instead of a list file. This is the route I took to try to test my build for now.  Edited .config in the top kernel source directory so that CONFIG_INITRAMFS_SOURCE is set to the path of my Image.cpio

A better solution would be to completely recreate the initrd.arm.initramfs_list file which I think we can do with a little work.  This would allow us to easily modify the individual files in this cpio archive.
There are a couple good references which should help understand what we need to do:


As the last line in that snippet says, rung usr/gen_init_cpio for more info about the format of the list file which we need to create:


There's no tool that I've found that can regenerate this list file from a cpio archive.  The closest thing to it would be getting cpio to list out the files:
I've attached the output of this command, and as you can see it's not in the proper format: file modes are in the wrong format, link information is absent, device node IDs are not included, etc.

So we either need to manually convert this file into the proper format, or write a program to extract this data directly from the cpio file and automatically generate the full list file.  I'm going to start working on the latter.