I *think* I got this to work, but someone with less n00b should verify.
Code:
'find your header
grep -a -b --only-matching $'\x1f\x8b\x08\x00' < zImage
'use your header value
dd bs=1 if=zImage skip={your number} | gzip -d -c > initramfs.cpio
'extract
sudo cpio -i --no-absolute-filenames < ../initramfs.cpio
I did compile this into a new zImage, but it made no difference, still looping samsungs..
This method (not mine) also works, but generates a file list. You should be able cpio out the files with minor adjustments.. credit to skeeterslint for this.
Code:
grep -a -b --only-matching `perl -e'print "\x1F\x8B\x08"'` zImage
dd if=zImage bs=1 skip=#fromsteponehere | gunzip > Image
grep -a -b --only-matching `perl -e'print "\x1F\x8B\x08"'` Image
dd if=Image bs=1 skip=#fromstep3goeshere | gzip -d -c | cpio -t
Related
Anyone know how to do that and bundle it back up into a zImage we can flash on the Vibrant/Galaxy S? HTC's boot.img was reasonably simple to mod, but I haven't found any good data on re-assembling the zImage Samsung uses. I have been able to extract the initrd, but nothing on putting it back together.
I'd prefer not to completely build the kernel, as I'd like to keep using JACs and he hasn't posted the source. And I'd have to build the cross-compiler as well, time consuming.
Irritating, the Samsung kernel source build works but doesn't do this bit either. No initrd... grrrr...
No doubt there is a way to reverse-engineer the way the kernel and ramdisk is put together, but it's way beyond my capability at the moment. With that said, if we can take it apart, we can probably put it back together.
i too am looking for instructions how to repack and/or split this
Jr33 said:
i too am looking for instructions how to repack and/or split this
Click to expand...
Click to collapse
Here's how you pull the initrd out from a Vibrant image, well, JAC OCv4 anyway.. Based on a thread and script in the international Galaxy S forum. I still don't know how to re-assemble it, but Wes put some stuff in git that might help, I'm still building after a repo sync. After you run the script with the zImage as the only parameter, you should get an initrd directory with the extracted contents of the ramdisk.
Code:
#!/bin/sh
zImage=$1
#=======================================================
# find start of gziped kernel object in the zImage file:
#=======================================================
pos=`grep -a -b --only-matching $'\x1F\x8B\x08' $zImage | cut -f 1 -d :`
echo "-I- Extracting kernel image from $zImage (start = $pos)"
# dd if=$zImage bs=1 skip=$pos | gunzip > kernel.img
#===========================================================================
# find start and end of the "cpio" initramfs image inside the kernel object:
# ASCII cpio header starts with '070701'
# The end of the cpio archive is marked with an empty file named TRAILER!!!
#===========================================================================
search=`perl -e'print "\x1F\x8B\x08"'`
start=`grep -a -b --only-matching $search kernel.img | head -1 | cut -f 1 -d :`
echo "-I- Extracting initramfs image from kernel.img (start = $start, end = $end)"
dd if=kernel.img bs=1 skip=$start | gzip -d -c > initramfs.img
mkdir initrd
cd initrd
cpio -i --no-absolute-filenames < ../initramfs.img
I've read several tutorials both here and elsewhere. I've got a few different methods down using mkbootimg, unpackbootimg, abootimg, the perl scripts, and I have gzip/gunzip/cpio commands down. Splitting and repacking go without errors.
However, I cannot, to save my life, whether I modify something or not, get a boot image that I split and repacked to boot on my device.
I have a G4 H811 the T-Mobile variant. I have been playing with boot images and kernels included with ROMs and a custom kernel, even dd'd the working boot partition from my device. I simply cannot repack something that boots.
Here's an example approach, here I'm using binaries from a custom kernel zip mkbootimg, unpackbootimg, and the busybox included in the zip. I'm doing exactly what the kernel maintainer does to split the image, replace zImage and repack, only manually in a terminal and modifying the ramdisk leaving everything else alone.
mkdir boot
cd boot/
cat /dev/block/bootdevice/by-name/boot >boot.img
chmod 755 busybox
chmod 755 mkbootimg
chmod 755 unpackbootimg
./unpackbootimg -i boot.img
mkdir initrd
cd initrd
cat ../boot.img-ramdisk.gz | ../busybox gunzip | ../busybox cpio -vid
vi init.rc(made changes)
../busybox find . | ../busybox cpio -o -H newc | ../busybox gzip >../myinitrd.img
cd ..
./mkbootimg --kernel boot.img-zImage --ramdisk myinitrd.img --cmdline "$(cat boot.img-cmdline)" --base 0x$(cat boot.img-base) --pagesize 4096 --ramdisk_offset $(cat boot.img-ramdiskoffset) --tags_offset $(cat boot.img-tagsoffset) --output myboot.img
./busybox dd if=myboot.img of=/dev/block/bootdevice/by-name/boot
I end up with with a 26.8MB myboot.img and a bootloop
Here's a really good example, I changed absolutely nothing. After unpacking and repacking I end up with two different size boot images. What am I missing here?
I'm looking for a way to transfer files with the correct permissions over adb. I can create a tarball and push it to my phone on the fly but for some reason I can't extract it without creating a temporary file. What I mean is that
Code:
tar -c file | adb exec-in 'cat > /file.tar' && adb shell 'tar -xf /file.tar -C dir'
works but
Code:
tar -c file | adb exec-in 'tar -xf - -C dir'
doesn't. Actually, it does but not all files are transferred over. Am I missing out on something?
@Ciren__
adb exec-out and/or adb exec-in
writes/reads to/from only files
I've used this:
Bash:
tar czplf - --acls --selinux --xattrs --numeric-owner -C /mnt/tmp/ data/com.android.messaging | adb exec-in tar -f - -x -p -z -v -C /data
... to restore an app from a whole partition image backup (mounted with `kpartx` and `mount -t ext4 -o ro,noload`).
I'm not sure if all those flags are actually needed, but that was my first guess at something which I thought would work.
The command line options for Linux/WSL/WSL2/Mac are a result of all the requests for a way to build img files outside of the kitchen. Now there is a way to do exactly this and more.
This post will be updated as features/commands are added or changed. The example commands below will work with the latest version of the kitchen.
If you have problems, make sure you are fully updated.
If something works in the kitchen but does not work in the CLI, please post about it in this thread.
If something does not work in the kitchen and does not work in the CLI, please post in the main kitchen thread.
Command Line Examples:
Unpack img file
Code:
$ /path/to/kitchen/superr -f unpack_img system.img -p superr_project-name
Pack img file
Code:
$ /path/to/kitchen/superr -f pack_img system.img raw -p superr_project-name
$ /path/to/kitchen/superr -f pack_img system.img sparse -p superr_project-name
$ /path/to/kitchen/superr -f pack_img system.img dat -p superr_project-name
$ /path/to/kitchen/superr -f pack_img system.img lz4 -p superr_project-name
Unpack super.img
Code:
$ /path/to/kitchen/superr -f unpack_super super.img -p superr_project-name
Pack super.img
Code:
$ /path/to/kitchen/superr -f pack_super system_new.img vendor_new.img product_new.img raw -p superr_project-name
$ /path/to/kitchen/superr -f pack_super system_new.img vendor_new.img product_new.img sparse -p superr_project-name
$ /path/to/kitchen/superr -f pack_super system_new.img vendor_new.img product_new.img dat -p superr_project-name
$ /path/to/kitchen/superr -f pack_super system_new.img vendor_new.img product_new.img lz4 -p superr_project-name
Deodex
Code:
$ /path/to/kitchen/superr -f deodex -p superr_project-name
Remove dm-verity
Code:
$ /path/to/kitchen/superr -f dmverity -p superr_project-name
Remove forceencrypt
Code:
$ /path/to/kitchen/superr -f forcee -p superr_project-name
Reserved
amazing, thank you!
Want to thank you for this. Awesome !!!
Thank you
PLZ HELP
I am trying to unpack stock rom for moto g play 2021 (C:\Users\Code3p0\Downloads\XT2093-3_GUAMNA_BOOST_11_RZA31.Q2-146-14-6_subsidy-DEFAULT_regulatory-DEFAULT_CFC.xml.zip)
super.img_sparsechunk.0
cannot upload rom to Kitchen
cannot unpack due to errno 2 (file not found no such file system.img)
hi, good move.
adding plugins options via cli will be appeciated
I can't script worth a sh|t, hence my desire to share with other Pixel 4a5g owners, haha. Provided there is already a folder named '/partbackups' on the microsd card, the script should make a dd image backup of ALL 73 partitions on the phone, including userdata (pics, etc.) in compressed .gz format to save space (and time, since the script pipes the output to gzip).
I want to make it so it creates a folder with unique $Date$Time appended if not already existing (mkdir -p) for each backup run. So if run again it makes a new folder under /partbackups,One of these days I'll finish it, unless someone else wants to. This is just a rough draft. Requires dd utility in recovery, tested with TWRP. Need fastboot to boot TWRP
Put the script where you will remember it. I put it on the root of the phone's user storage which is /sdcard (or /emulated/0) or something. Doesnt matter where you put it (Downloads,Documents, etc.)
From Bootloader screen and phone connected to USB: fastboot boot twrp.img (unplug usb cable from phone after OK from terminal/cmd window).
TWRP should load. Goto Mount screen. Insert USB2GO usb adapter/microsd reader with properly formatted filesystem (I used ext4, but I think exfat works too?). You should see your storage there and go ahead and mount it. Then back out to main menu, goto advanced, then terminal. FYI, when mounted, the path to the mount point/microsd reader (USB2GO) is '/auto0-1/' .
Make sure to mark the script as executable: chmod +x partbackupgz.sh
run the script: ./partbackupgz.sh
There will only be output after each partition compresses over to storage. userdata (sda19) takes the longest. Let it run. It's not frozen. Does seem to use battery.
When it's done it will dump and compress each partition over on the fly with gzip.
When it's done, unmount the storage, remove and reboot. Again. I don't code/script. This is a work in progress. I'm not responsible if you open up a portal.
Please improve this script. I'll write a recovery script when I need one..Lol. Or maybe you will.
Bash:
#!/system/bin/sh
dd if=/dev/block/sda1 bs=1M | gzip -c > /auto0-1/partbackups/ssd.img.gz
dd if=/dev/block/sda2 bs=1M | gzip -c > /auto0-1/partbackups/persist.img.gz
dd if=/dev/block/sda3 bs=1M | gzip -c > /auto0-1/partbackups/misc.img.gz
dd if=/dev/block/sda4 bs=1M | gzip -c > /auto0-1/partbackups/keystore.img.gz
dd if=/dev/block/sda5 bs=1M | gzip -c > /auto0-1/partbackups/frp.img.gz
dd if=/dev/block/sda6 bs=1M | gzip -c > /auto0-1/partbackups/boot_a.img.gz
dd if=/dev/block/sda7 bs=1M | gzip -c > /auto0-1/partbackups/boot_b.img.gz
dd if=/dev/block/sda8 bs=1M | gzip -c > /auto0-1/partbackups/vendor_boot_a.img.gz
dd if=/dev/block/sda9 bs=1M | gzip -c > /auto0-1/partbackups/vendor_boot_b.img.gz
dd if=/dev/block/sda10 bs=1M | gzip -c > /auto0-1/partbackups/dtbo_a.img.gz
dd if=/dev/block/sda11 bs=1M | gzip -c > /auto0-1/partbackups/dtbo_b.img.gz
dd if=/dev/block/sda12 bs=1M | gzip -c > /auto0-1/partbackups/modem_a.img.gz
dd if=/dev/block/sda13 bs=1M | gzip -c > /auto0-1/partbackups/modem_b.img.gz
dd if=/dev/block/sda14 bs=1M | gzip -c > /auto0-1/partbackups/klog.img.gz
dd if=/dev/block/sda15 bs=1M | gzip -c > /auto0-1/partbackups/metadata.img.gz
dd if=/dev/block/sda16 bs=1M | gzip -c > /auto0-1/partbackups/vbmeta_system_a.img.gz
dd if=/dev/block/sda17 bs=1M | gzip -c > /auto0-1/partbackups/vbmeta_system_b.img.gz
dd if=/dev/block/sda18 bs=1M | gzip -c > /auto0-1/partbackups/super.img.gz
dd if=/dev/block/sda19 bs=1M | gzip -c > /auto0-1/partbackups/userdata.img.gz
dd if=/dev/block/sdb1 bs=1M | gzip -c > /auto0-1/partbackups/xbl_a.img.gz
dd if=/dev/block/sdb2 bs=1M | gzip -c > /auto0-1/partbackups/xbl_config_a.img.gz
dd if=/dev/block/sdc1 bs=1M | gzip -c > /auto0-1/partbackups/xbl_b.img.gz
dd if=/dev/block/sdc2 bs=1M | gzip -c > /auto0-1/partbackups/xbl_config_b.img.gz
dd if=/dev/block/sdd1 bs=1M | gzip -c > /auto0-1/partbackups/ALIGN_TO_128K_1.img.gz
dd if=/dev/block/sdd2 bs=1M | gzip -c > /auto0-1/partbackups/cdt.img.gz
dd if=/dev/block/sdd3 bs=1M | gzip -c > /auto0-1/partbackups/ddr.img.gz
dd if=/dev/block/sde1 bs=1M | gzip -c > /auto0-1/partbackups/aop_a.img.gz
dd if=/dev/block/sde2 bs=1M | gzip -c > /auto0-1/partbackups/tz_a.img.gz
dd if=/dev/block/sde3 bs=1M | gzip -c > /auto0-1/partbackups/hyp_a.img.gz
dd if=/dev/block/sde4 bs=1M | gzip -c > /auto0-1/partbackups/abl_a.img.gz
dd if=/dev/block/sde5 bs=1M | gzip -c > /auto0-1/partbackups/keymaster_a.img.gz
dd if=/dev/block/sde6 bs=1M | gzip -c > /auto0-1/partbackups/cmnlib_a.img.gz
dd if=/dev/block/sde7 bs=1M | gzip -c > /auto0-1/partbackups/cmnlib64_a.img.gz
dd if=/dev/block/sde8 bs=1M | gzip -c > /auto0-1/partbackups/devcfg_a.img.gz
dd if=/dev/block/sde9 bs=1M | gzip -c > /auto0-1/partbackups/qupfw_a.img.gz
dd if=/dev/block/sde10 bs=1M | gzip -c > /auto0-1/partbackups/vbmeta_a.img.gz
dd if=/dev/block/sde11 bs=1M | gzip -c > /auto0-1/partbackups/reserve_1.img.gz
dd if=/dev/block/sde12 bs=1M | gzip -c > /auto0-1/partbackups/uefisecapp_a.img.gz
dd if=/dev/block/sde13 bs=1M | gzip -c > /auto0-1/partbackups/imagefv_a.img.gz
dd if=/dev/block/sde14 bs=1M | gzip -c > /auto0-1/partbackups/apdp_a.img.gz
dd if=/dev/block/sde15 bs=1M | gzip -c > /auto0-1/partbackups/multiimgoem_a.img.gz
dd if=/dev/block/sde16 bs=1M | gzip -c > /auto0-1/partbackups/featenabler_a.img.gz
dd if=/dev/block/sde17 bs=1M | gzip -c > /auto0-1/partbackups/aop_b.img.gz
dd if=/dev/block/sde18 bs=1M | gzip -c > /auto0-1/partbackups/tz_b.img.gz
dd if=/dev/block/sde19 bs=1M | gzip -c > /auto0-1/partbackups/hyp_b.img.gz
dd if=/dev/block/sde20 bs=1M | gzip -c > /auto0-1/partbackups/abl_b.img.gz
dd if=/dev/block/sde21 bs=1M | gzip -c > /auto0-1/partbackups/keymaster_b.img.gz
dd if=/dev/block/sde22 bs=1M | gzip -c > /auto0-1/partbackups/cmnlib_b.img.gz
dd if=/dev/block/sde23 bs=1M | gzip -c > /auto0-1/partbackups/cmnlib64_b.img.gz
dd if=/dev/block/sde24 bs=1M | gzip -c > /auto0-1/partbackups/devcfg_b.img.gz
dd if=/dev/block/sde25 bs=1M | gzip -c > /auto0-1/partbackups/qupfw_b.img.gz
dd if=/dev/block/sde26 bs=1M | gzip -c > /auto0-1/partbackups/vbmeta_b.img.gz
dd if=/dev/block/sde27 bs=1M | gzip -c > /auto0-1/partbackups/reserve_2.img.gz
dd if=/dev/block/sde28 bs=1M | gzip -c > /auto0-1/partbackups/uefisecapp_b.img.gz
dd if=/dev/block/sde29 bs=1M | gzip -c > /auto0-1/partbackups/imagefv_b.img.gz
dd if=/dev/block/sde30 bs=1M | gzip -c > /auto0-1/partbackups/apdp_b.img.gz
dd if=/dev/block/sde31 bs=1M | gzip -c > /auto0-1/partbackups/multiimgoem_b.img.gz
dd if=/dev/block/sde32 bs=1M | gzip -c > /auto0-1/partbackups/featenabler_b.img.gz
dd if=/dev/block/sde33 bs=1M | gzip -c > /auto0-1/partbackups/devinfo.img.gz
dd if=/dev/block/sde34 bs=1M | gzip -c > /auto0-1/partbackups/spunvm.img.gz
dd if=/dev/block/sde35 bs=1M | gzip -c > /auto0-1/partbackups/splash.img.gz
dd if=/dev/block/sde36 bs=1M | gzip -c > /auto0-1/partbackups/limits.img.gz
dd if=/dev/block/sde37 bs=1M | gzip -c > /auto0-1/partbackups/limits-cdsp.img.gz
dd if=/dev/block/sde38 bs=1M | gzip -c > /auto0-1/partbackups/toolsfv.img.gz
dd if=/dev/block/sde39 bs=1M | gzip -c > /auto0-1/partbackups/logfs.img.gz
dd if=/dev/block/sde40 bs=1M | gzip -c > /auto0-1/partbackups/storsec.img.gz
dd if=/dev/block/sde41 bs=1M | gzip -c > /auto0-1/partbackups/uefivarstore.img.gz
dd if=/dev/block/sde42 bs=1M | gzip -c > /auto0-1/partbackups/secdata.img.gz
dd if=/dev/block/sdf1 bs=1M | gzip -c > /auto0-1/partbackups/ALIGN_TO_128K_2.img.gz
dd if=/dev/block/sdf2 bs=1M | gzip -c > /auto0-1/partbackups/modemst1.img.gz
dd if=/dev/block/sdf3 bs=1M | gzip -c > /auto0-1/partbackups/modemst2.img.gz
dd if=/dev/block/sdf4 bs=1M | gzip -c > /auto0-1/partbackups/fsg.img.gz
dd if=/dev/block/sdf5 bs=1M | gzip -c > /auto0-1/partbackups/fsc.img.gz
what's the point of backup partitions? most can be downloaded from google, some are auto generated, some are just cache and userdata is encrypted therefore useless. not to mention will fail on fat32 storage.
mine aren't encrypted. i think when I put a custom rom on, one of the requirements was to wipe the device which removed the encryption (LineageOS). I can open the .gz files with any archive utility. Or flash them. Similar but different than an ADB pull since dd copies ALL bits including those shown as not in use which for recovery purposes might be good (deleted file).
Some of the partitions not included are EFS partitions that include things like IMEI and serial number. There is supposed to be a backup/auto restoration if one gets wiped and/or golden copy but it has been known on "some" roms (I'd never use MIUI) where EFS gets totally nuked and unless you have a backup of it, or QPST backup of NV, you're screwed.
I think, this will copy EVERYTHING. For encrypted phones, this could still work, abeit more work involved because one would have to extract their key beforehand and then they coud use it to access their encrypted archives. I guess? I dunno.
And this script would be run from the phone in recovery (TWRP), I thought TWRP (or LineageRecovery) works with no encryption only? So it would only benefit those people anyway.
wouldn't it be easier to add important partitions to twrp fstab with flag backup=1?
FBE + metadata encryption used to be supported in TWRP up to Android 12, seems maintainers still working on it.
Oh, if that's the case, great (encryption support). I guess there were issues with A11-A12 and twrp at least
on 4a5g.
Does modiying twrp /fstab give more access to partitions to backup? If so, that would be sweet because I would have it do ALL of them, or at least of course the option. The persist is not enough, in some.....weird...cases and not nessessary this model phone, people have hosed their EFS--how, who knows. But yea I love TWRP. If twrp could be tweaked to backup all partitions if listed in /fstab, that would be super spiffy.
seriously I have no clue how things work on this TWRP, but on older devices one could just add lines in twrp.fstab ourself.
please ask in TWRP support thread maintainer might add important partitions.
thx for info.