I'd like to modify some of the init scripts in an initramfs that is embedded in a kernel bzImage. I know I can modify them by not changing the size of any files (e.g. by commenting out lines, and deleting letters or adding comments if necessary to even things out.)
Ideally, I'd like to DD out the xz file from the zImage. Decompress it. Modify the cpio, then recompress it, and DD back to the zImage. My hope is that by not changing the size of any files, this is going to work. Although I appreciate it may not be that easy. So any help with that would be much appreciated.
In addition, I've run binwalk on the kernel image, and it looks like this:
DECIMAL HEXADECIMAL DESCRIPTION -------------------------------------------------------------------------------- 0 0x0 Microsoft executable, portable (PE) 16817 0x41B1 xz compressed data 7297600 0x6F5A40 xz compressed data 7299230 0x6F609E Unix path: /x86/boot/compressed/kaslr_64.c!? 7483729 0x723151 Certificate in DER format (x509 v3), header length: 4, sequence length: 762
Now. I've also run Binwalk -e on the file, and it is able to successfully extract the xz archives, and decompress at least one of them (0x41B1) into a .cpio file, which I've verified contains the initramfs. But a couple issues I've run into don't make sense to me:
The "xz" file extracted by binwalk is 7468247 in size. Yet, if you subtract the offsets above between the two xz files you get 7280783. Why is there a difference?
When I try to run xz -d on the .xz file extracted by binwalk I get a message "Compressed data is corrupt." And if I do a hexdump of the XZ file extracted by binwalk it doesn't appear to have the magic bytes associated with an XZ file up top. So what is binwalk doing differently to properly extract the XZ file? And what exactly is binwalk extracting since it doesn't appear to be a valid XZ file (at least according to the XZ utility)?
When I run the xz_wrap script (included in the linux kernel) (or any other options of XZ that I have tried) on the extracted CPIO file by Binwalk--no matter what I do--I can't get an xz file to generate that is exactly the same as the original .xz file that binwalk extracted from the zImage. Can anyone explain this or what I can do to generate the exact same XZ archive?
I know with certainty the Kernel is using "CONFIG_HAVE_KERNEL_XZ=y" since I've been able to extract that much. Although I'll note that after I enabled some debugging in Binwalk, I can see it is using its lzma decompressor to decompress the XZ file extracted from the kernel image.
Any suggestions here? I'm certainly not trying to reinvent the wheel. So if someone else has come up with a way to repack an initramfs into a x86 Kernel, I'd be interested in looking at that. I'm also open to any other suggestions here.