Attend XDA's Second Annual Developer Conference, XDA:DevCon 2014!
5,809,576 Members 37,830 Now Online
XDA Developers Android and Mobile Development Forum

[script] repack-zImage.sh: Unpack and repack a zImage without kernel source, V. 5

Tip us?
 
mizch
Old
(Last edited by mizch; 3rd May 2011 at 07:23 PM.)
#1  
Senior Member - OP
Thanks Meter 71
Posts: 158
Join Date: Nov 2010
Default [script] repack-zImage.sh: Unpack and repack a zImage without kernel source, V. 5

repack-zImage.sh is a bash script for Linux which allows you to unpack a kernel image (zImage) for modification and repack it afterwards into a new working kernel image.

You don't need a kernel tree for this program nor a compiler. It should work with any zImage that contains an initramfs, for whatever phone, operating system or CPU architecture you like.

My main purpose when I wrote it was to modify the initramfs of leaked Samsung i5800 firmware for which no kernel source is available.

Usage:
=====

Put the unzipped script into some directory along your $PATH (e.g., /usr/local/bin). Put the unpacked files from initramfs_utils.zip into /usr/local/bin.

Then simply run 'repack-zImage.sh -u' with your zImage in the current directory and it will create a directory named 'zImage_unpacked' which contains the unpacked blocks of your zImage. Refer to the comments near the start of the program to identify which file corresponds to which fragment of the original zImage. (The file name of the zImage should be "zImage". If it isn't, pass it as the only non-option argument. The subdirectory's name will change accordingly.)

Most notably, there will be a directory 'initramfs' in there, which contains all files from the original initramfs in their original tree. You can modify the contents as you like, but keep in mind that your initramfs cannot grow larger than the space reserved for it in the original zImage. So you're restricted to relatively small changes which should, however, satisfy many needs. You always can call a script or executable on some other partition (including the SD card if already mounted) if you need more room for your modifications.

After your modifications are done, cd back to the directory which contains zImage and zImage_unpacked and run 'repack-zImage.sh -p' to start the packing process.

This will create a directory called 'zImage_packing' which contains your new zImage (and a zImage.tar for loaders like ODIN). It will emit (between others) one or two messages about a padding being done and about how many bytes were padded. This number (or the lower number of the two) is an indication about how many compressed bytes are left for further additions to the initrd.

If your initramfs (or some other modified part) grows too large, the script will abort with an appropriate error message.

In initramfs-utils.zip, three programs are provided. They should be copied to /usr/local/bin:
* cpio_set0. This is a slightly modified cpio (compiled for 32 bit Linux). repack-zImage.sh will run without it, but there may be slightly more room in your initramfs if you use the modified one. It sets all file times in the archive to 0 (epoch), thus yielding better and consistent compression results. Else, the size of the compressed initramfs will differ from invocation to invocation due to differing atimes. Put it somewhere along your $PATH (e.g., /usr/local/bin).
* gen_init_cpio and
* gen_initramfs_list.sh. These are utilities copied from a kernel tree and used to support creation of an initramfs (in certain modes).

'repack-zImage.sh --help' will output usage information.


Happy hacking,

mizch


Current Version: 6
2011-05-03
('repack-zImage.sh --version' will output version information.)

- added support for lzma compressed ramdisks (both directions)

Version 4
2011-02-17

- Workaround for ambiguous gunzip result, see post #20
- Some code cleanup + CLI cleanup
- better error detection

Version 3
2011-01-06

- now also works with unzipped initramfs withing gzipped zImage part (i.e., all kinds of zImages)

Version 1
2011-01-05

- initial version. Works only for gzipped initramfs within gzipped zImage (e.g., G3 Eclair kernels)

-----------------------
repack-zImage.zip contains version 4 of the script.
For the newest version, download repack-zImage.v6.zip and initramfs-utils.zip.
Attached Files
File Type: zip initramfs-utils.zip - [Click for QR Code] (176.2 KB, 5478 views)
File Type: zip repack-zImage.zip - [Click for QR Code] (7.4 KB, 2900 views)
File Type: zip repack-zImage.v6.zip - [Click for QR Code] (7.9 KB, 6032 views)
The Following 28 Users Say Thank You to mizch For This Useful Post: [ Click to Expand ]
 
Gsam101
Old
(Last edited by Gsam101; 5th January 2011 at 04:40 PM.)
#2  
Senior Member
Thanks Meter 98
Posts: 266
Join Date: Oct 2010
Location: Paris
It didn't work on zImage from Froyo firmware i tried. Great work however .

Works however for Eclair firmwares i've tested.
 
precurse
Old
#3  
Senior Member
Thanks Meter 22
Posts: 179
Join Date: Aug 2010
Good work.

Is this based off the i9000 script?

Also, I've noticed with the i5800 Eclair firmwares that the initramfs is gzipped AND cpio'd. So... Kernel + initramfs.cpio.gz are gzipped together.

Basically you need to extract [kernel+initramfs.cpio.gz].gz, extract initramfs.cpio.gz again, then extract initramfs with cpio.

On Froyo, the kernel + initramfs.cpio is gzipped together, but nothing more. So after you extract the kernel and initramfs, you just need to extract with cpio after that.

Hope that kind of helps..
The Following 3 Users Say Thank You to precurse For This Useful Post: [ Click to Expand ]
 
mizch
Old
(Last edited by mizch; 5th January 2011 at 05:46 PM.)
#4  
Senior Member - OP
Thanks Meter 71
Posts: 158
Join Date: Nov 2010
In didn't go into Froyo for the i5800 until now. I used Eclair. It eases testing if you can compare things to a working kernel tree.

I see that Froyo doesn't use a compressed initramfs within the compressed kernel (which I doubt to make much sense anyway since compressing an already compressed part again is likely to produce a larger result). In theory, thus Froyo is easier to cope with than what I have now, but I have to write the code to handle it. This will need some time, maybe tomorrow, maybe the weekend.

And, no, this is not based on code from the i9000. It was written up from scratch. But I took some ideas from there and thank dkcldark for his good work.
The Following User Says Thank You to mizch For This Useful Post: [ Click to Expand ]
 
precurse
Old
#5  
Senior Member
Thanks Meter 22
Posts: 179
Join Date: Aug 2010
Quote:
Originally Posted by mizch View Post
In didn't go into Froyo for the i5800 until now. I used Eclair. It eases testing if you can compare things to a working kernel tree.

I see that Froyo doesn't use a compressed initramfs within the compressed kernel (which I doubt to make much sense anyway since compressing an already compressed part again is likely to produce a larger result). In theory, thus Froyo is easier to cope with than what I have now, but I have to write the code to handle it. This will need some time, maybe tomorrow, maybe the weekend.

And, no, this is not based on code from the i9000. It was written up from scratch. But I took some ideas from there and thank dkcldark for his good work.
If we can get this modified for Froyo, it will allow for native ext2 mounting within the initramfs. Then we can add things to it like the way CWM works - busybox, adb, etc... So that we have a recovery adb setup before /system mounts.
 
Gsam101
Old
#6  
Senior Member
Thanks Meter 98
Posts: 266
Join Date: Oct 2010
Location: Paris
Quote:
Originally Posted by precurse View Post
If we can get this modified for Froyo, it will allow for native ext2 mounting within the initramfs. Then we can add things to it like the way CWM works - busybox, adb, etc... So that we have a recovery adb setup before /system mounts.
Exactly, that could be very useful, since we could get ext2 (ext4 maybe if we compile it as a module ?) in /data natively
 
precurse
Old
#7  
Senior Member
Thanks Meter 22
Posts: 179
Join Date: Aug 2010
Quote:
Originally Posted by Gsam101 View Post
Exactly, that could be very useful, since we could get ext2 (ext4 maybe if we compile it as a module ?) in /data natively
I already tried building ext4 and other modules off the i9000 sources... Didn't seem to work too well. Kept complaining about memmap or some random errors when I tried loading them.

Perhaps we can try them against JPF or something.
 
precurse
Old
#8  
Senior Member
Thanks Meter 22
Posts: 179
Join Date: Aug 2010
Heck.. or even allow a user to use a file off their SD card to loopback mount /system partitions... Or /data partitions - like how the i9000 has a (built-in) 16gb SD card.
 
Gsam101
Old
#9  
Senior Member
Thanks Meter 98
Posts: 266
Join Date: Oct 2010
Location: Paris
Quote:
Originally Posted by precurse View Post
I already tried building ext4 and other modules off the i9000 sources... Didn't seem to work too well. Kept complaining about memmap or some random errors when I tried loading them.

Perhaps we can try them against JPF or something.
I think so. Maybe we should just try to build an ext4 module with standard linux sources with armv6 as target ? Since i9000 has an armv7 processor..
 
precurse
Old
#10  
Senior Member
Thanks Meter 22
Posts: 179
Join Date: Aug 2010
Quote:
Originally Posted by Gsam101 View Post
I think so. Maybe we should just try to build an ext4 module with standard linux sources with armv6 as target ? Since i9000 has an armv7 processor..
I setup my .conf to use the same CPU as what the G3 uses. I can't compile a kernel, but the modules compile.

It's a much different error I got from these modules than when I tried loading i9000 modules.

Tags
kernel, zimag
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes