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

Search This thread

vbenkovskyy

Senior Member
Feb 12, 2011
213
65
Could someone help to extract. Script tells that file is not found but it's in the directory with the script and utils.
 

Attachments

  • zImage.zip
    4.1 MB · Views: 167

DoR2

Senior Member
Mar 9, 2012
311
105
Snezhinsk
Could someone help to extract. Script tells that file is not found but it's in the directory with the script and utils.

I have tried to unpack your zImage but I got an error
Code:
Separating gzipped part from trailer in 'piggy.gz+piggy_trailer'
Trying size: 2131356  3197034  3729873  3996293  4129503  4196108  4229411  4246063  4254389  4258552  4260634  4261675  4262196  4262457  4262588  4262654./repack-zImage.sh: line 284: [: : integer expression expected

padding check (may take some time): 14

Found uncompressed ramdisk.
Detecting padding (may take some time): 4188
Unpacking initramfs
cpio: Malformed number rrect 
cpio: Malformed number cpio m
cpio: Malformed number ethod 
cpio: Malformed number used: 
cpio: Malformed number use -H
cpio: Malformed number  newc 
cpio: Malformed number option
cpio: Malformed number o cpio magi
cpio: premature end of file

repack-zImage.sh: cpio -t failed.
Terminated

Also I can recommend running this command in order to get full access to all files in this directory.
Code:
chmod 777 *

BTW, you can try to use ArchiKitchen in order to unpack zImage and work on your ROM. Good Luck!
 

gekkehenkie11

Inactive Recognized Developer
Dec 9, 2010
2,766
5,584
This tool seems outdated, doesn't work on modern kernels including DT it seems ...
 

yhaddad

Senior Member
Oct 15, 2008
71
2
It should work on a kernel of galaxy gear s watch?

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.
 

gekkehenkie11

Inactive Recognized Developer
Dec 9, 2010
2,766
5,584
Still no new kernel unpacker tool ? :(

---------- Post added at 11:53 PM ---------- Previous post was at 11:03 PM ----------

Actually I just found out how to decompress a modern kernel :) Just search the boot.img for 894C5A4F (that's 0x89 followed by "LZO"). In my case I needed the second hit (after some ascii text 'System halted' etc). So cut everything off before that, save it with a .LZO extention and you can simply unpack it with an LZO unpacker :)
 

sagarsorathiya433

Senior Member
Sep 21, 2015
114
64
Gandhinagar
repack-zImage.sh: Can't find a gzip header in file 'zImage' :(
please help me to solve this error i have tried 10.10 n 16.04
 

Attachments

  • 1.png
    1.png
    27.4 KB · Views: 280
Last edited:

Top Liked Posts

  • There are no posts matching your filters.
  • 36
    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.
    3
    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..
    3
    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.

    Thank you for this utility. I've taken the liberty of making a couple of bugfixes - one to initialise compress_list in the -3 option case, and the other to initialise at_min to 0 rather than blank in gunzipWithTrailer. The first stops the -3 option hanging, and the second is cosmetic and prevents sh complaining.

    I can confirm it works with zImage 4.0.4 XWLPT for the Samsung Galaxy S II (i9100).

    Peter
    3
    I'm assuming this tool is dead, as I get same errors as last posters and seems no one can post the cause
    try following the same steps i've given in my kernel development tutorials and you shouldnt get any errors...
    2
    Got the zImage, thanks. I could reproduce the problem. What happens:

    Using gzip's magic number, I can tell the start of a gzipped section. To determine its end, I need the help of gunzip. It reports "trailing garbage" if its file is too long, "truncated file" if too small, "OK" otherwise.

    With your zImage, gunzip reports "truncated" when fed with 5749017 bytes, "trailing garbage" at 5749018. Obviously, only one of the two (not both!) can be correct. But this is what gunzip reports in your case. I found that 5749016 is the correct size. Erm.

    As a workaround, I now detect when the gunzip result is oscillating this way and if it does, I search nearby towards lower size values for an exact match. This is not an ideal solution but I have to deal with what gunzip returns and this fits it best.

    I'll do some cleanup and some final tests now and if they succeed, I will post the new version in about an hour or so in the first posting of this thread.

    EDIT: New version posted.