boot.img structure & creating custom boot.img - Galaxy Ace S5830i Q&A, Help & Troubleshooting

Hello Folks
I'm in the process of trying to create a custom boot.img. I've read a few threads and used the tools from this thread http://forum.xda-developers.com/showthread.php?t=2319018
I'm able to split the boot.img with the umkbootimg tool and create the file structure, make my alterations, re-pack the ramdisk and use mkbootimage to create a new boot.img file. But no matter what I do I cannot get this new boot.img to work. So, eventually I tried simply splitting the boot.img and just re-combining it again without making any changes. The boot.img still didn;t work, so I decided to have a closer look at the original and the new boot.img. I could only see 1 difference. At address 0x240 of the original appears to be a binary hash 20 bytes long, this hash also appears in the new boot.img byte for byte but what DOESN'T appear is what follows it at 0x260, in the original this seems to be another hash but this one is plain text, and that hash is NOT in the new boot.img. With this being the only difference I'm assuming this is some kind of verification/signature hash? As this is missing from the new boot.img I can only conclude this is why it isn't working, indeed, if I manually enter the hash into the new boot.img it does indeed work, but I'd expect it to, it is then after all a byte for byte duplicate of the original boot.img. So my question is, what is this hash? I've tried making md5s of the kernel, the ramdisk, the kernel+ramdisk and none seem to match.
EDIT: OK hold the press. Sorry, dunno how I missed it the first time I tested it, but the plain text hash appears to be simply an MD5 of the kernel image. Not sure what the binary hash is yet, but since the mkbootimage tool seems to calculate this correctly, it's not vital I figure that out. I could always look at the source code i guess heh.
Thanks for any help.
Dino

---

DobermanG said:
Hello Folks
I'm in the process of trying to create a custom boot.img. I've read a few threads and used the tools from this thread http://forum.xda-developers.com/showthread.php?t=2319018
I'm able to split the boot.img with the umkbootimg tool and create the file structure, make my alterations, re-pack the ramdisk and use mkbootimage to create a new boot.img file. But no matter what I do I cannot get this new boot.img to work. So, eventually I tried simply splitting the boot.img and just re-combining it again without making any changes. The boot.img still didn;t work, so I decided to have a closer look at the original and the new boot.img. I could only see 1 difference. At address 0x240 of the original appears to be a binary hash 20 bytes long, this hash also appears in the new boot.img byte for byte but what DOESN'T appear is what follows it at 0x260, in the original this seems to be another hash but this one is plain text, and that hash is NOT in the new boot.img. With this being the only difference I'm assuming this is some kind of verification/signature hash? As this is missing from the new boot.img I can only conclude this is why it isn't working, indeed, if I manually enter the hash into the new boot.img it does indeed work, but I'd expect it to, it is then after all a byte for byte duplicate of the original boot.img. So my question is, what is this hash? I've tried making md5s of the kernel, the ramdisk, the kernel+ramdisk and none seem to match.
EDIT: OK hold the press. Sorry, dunno how I missed it the first time I tested it, but the plain text hash appears to be simply an MD5 of the kernel image. Not sure what the binary hash is yet, but since the mkbootimage tool seems to calculate this correctly, it's not vital I figure that out. I could always look at the source code i guess heh.
Thanks for any help.
Dino
Click to expand...
Click to collapse
I am having the same problem

---

Raakib zargar said:
I am having the same problem
Click to expand...
Click to collapse
I've made some progress. Using ubuntu linux I've managed to unpack a boot.img, alter the files, repack and boot from it. Get the tools from the post I linked to above (remember to thank the poster) , you need:
mkbootimg
umkbootimg
I just dropped the binaries into the folder I was working from on my linux box. I then made a folder called ram (mkdir ram)
Copied the boot.img I wanted to unpack into my working folder and executed:
./umkbootimg boot.img
This split the image into the kernel (zImage) and ramdisk (initramfs.cpio.gz) take note of what umkbootimg says about repacking it as it contains important offsets and addresses. On mine it said
Code:
To recompile this image, use:
mkbootimg --kernel zImage --ramdisk initramfs.cpio.gz --base 0x81600000 --pagesize 4096 -o new_boot.img
Now cd into the ram folder (cd ram) and execute (assuming you have gzip and cpio installed on your linux box)
gunzip -c ../initramfs.cpio.gz | cpio -i
This will unpack all the files. Then make whatever changes you want. When completed, from within the ram folder execute
find . | cpio -o -H newc | gzip > ../new-initrd
then go back one folder (cd ..) and execute
./mkbootimg --kernel zImage --ramdisk new-initrd --base 0x81600000 --pagesize 4096 -o new_boot.img
(obviously use whatever parameters were quoted to you by umkbootimg earlier, mine is only an exmaple)
This then creates a valid boot.img that *should* work.
To flash it for testing I use Odin. Copy the new_boot.img to another folder and rename it to boot.img, then execute the following
tar -H ustar -c boot.img > boot.tar
md5sum -t boot.tar >> boot.tar
mv boot.tar boot.tar.md5
Then you can use Odin to flash the new image boot.tar.md5 (PDA).
The problem I'm having is that at the stage init.rc runs, it appears the sdcard is not available, neither /dev/block/mmcblk0 or /dev/block/vold/ paths are available. I'm basically trying to shift my /data folder from internal memory to external sdcard. If possible moving /system to the sdcard as well to make it easy to fiddle around with firmwares.

---

YESSSSSSSSSSSSSSSSSSSSSSSSSSSS!!!!
Hah, well it seems the solution was to make the event running in init.rc wait until the stream device for the sdcard was available. Then all it took was a small modification of init.rc where /data is usually mounted
Original code
Code:
mount rfs /dev/stl11 /data2 nosuid crypt nodev check=no
chown system system /data
chmod 0771 /data
Altered code
Code:
mkdir /data2 0771 system system
mount rfs /dev/stl11 /data2 nosuid nodev check=no
wait /dev/block/mmcblk0p2 300
mount ext3 /dev/block/mmcblk0p2 /data
chown system system /data
chmod 0771 /data
I've only tried it out on an old slow 8gb for testing, but I'll be cracking out the class 10 card now.
I know this is probably old news to you experience devs, but I'm still happy with myself for managing to do it
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}