Related
I following the instructions found from here:
Building Kernels
and download the kernel from here:
INDEX of ROMS/RECOVERY/ROOT/GUIDES/FIRMWARE/KERNEL/VIDEOS/etc..
I am using TF300TG, so I just followed the link to my tablet kernel source from the thread. I have successfully built the kernel by using the config.gz found in the tablet /proc/config.gz (is great that Asus is providing such info). I also enable a kernel module for my old USB ethernet dongle and able to use it to get online. :victory:
After poking around the kernel configuration, and reading the thread TF300T kernel source repository, I am curious about enabling OC and possible other features. I had downloaded the update.zip from the thread, and trying to understand the whole process of how to flash kernel to the tablet. My idea is to modify the update.zip to make use of it to update my tablet. But before I start doing something serious, I have questions...
I found the following kernel file: kernel.blob in update.zip. Is this the same file as 'zImage' in arch/arm/boot/ after built successful?
The next question is on how to backup my existing kernel? I notice from the update-script, the kernel is flash using the following command:
run_program("/sbin/busybox", "dd", "if=/tmp/kernel.blob", "of=/dev/block/mmcblk0p4");
Click to expand...
Click to collapse
Does this mean, I can run the same command in reverse to keep a copy of my current kernel?
I had done kernel compiling before, but those were in PC/x86 platform. ARM platform seems to be different from what I used to.
I found the following kernel file: kernel.blob in update.zip. Is this the same file as 'zImage' in arch/arm/boot/ after built successful?
Click to expand...
Click to collapse
Not exactly...
A blob file is a sort of archive that can contain several files.
For example, the kernel.blob you mention above contains the actual kernel (zImage) but also a ram disk.
As far as I understand a blob file is the only type of file that can be flashed to different partitions of your TF300T(G) using fastboot method.
To flash using CWM or TWRP you will need to pack blob file(s) into a special kind of zip package.
Below I have shared my script that I use to create a TWRP flashable zip package including a custom built kernel.
Hopefully it may shed some light in the steps required to go from zImage to blob file and TWRP flashable zip package.
The script takes the root path to your kernel source directory as first (and only) argument.
In same directory as script I have unpacked update.zip (from untermensch's kernel repository thread) as parts of this zip file are re-used.
---
#!/bin/sh
KERNEL_HOME=$1
KERNEL_NAME=my_kernel_$$
# Repack new kernel and old ram disk into blob file
cp ${KERNEL_HOME}/arch/arm/boot/zImage boot.blob.lnx-kernel.gz
repack-bootimg.pl boot.blob.lnx-kernel.gz boot.blob.lnx-ramdisk out.blob.lnx
blobpack out.blob LNX out.blob.lnx
# Prepend magic header
cat signblob_magic out.blob > kernel.blob
# Add kernel modules to ensure kernel and modules always match.
# If mismatch e.g WiFi might not work.
find ${KERNEL_HOME} -name "*.ko" -exec cp {} system/lib/modules \;
# Save kernel config in case it needs to be rebuilt some day.
cp ${KERNEL_HOME}/.config kernel_config
# Zip everything
zip -9 -r ${KERNEL_NAME}.zip kernel_config kernel.blob system/ META-INF/
# Sign zip using SignApk
java -Xmx1024m -jar signapk.jar -w testkey.x509.pem testkey.pk8 ${KERNEL_NAME}.zip ${KERNEL_NAME}-signed.zip
---
The next question is on how to backup my existing kernel? I notice from the update-script, the kernel is flash using the following command:
Does this mean, I can run the same command in reverse to keep a copy of my current kernel?
Click to expand...
Click to collapse
In theory this should work but if not mistaken mmcblk0p4 is just a sort of staging partition.
During bootup whatever is in mmcblk0p4 is copied to another partition (mmcblk0p0?).
(I guess this is the blue bar you can observe when flashing custom roms/kernels)
Someone more familiar with the details please correct me.
Instead of trying to backup your current kernel I would suggest to try to get the original
kernel by unpacking the official update packages from ASUS support web page.
I had done kernel compiling before, but those were in PC/x86 platform. ARM platform seems to be different from what I used to.
Click to expand...
Click to collapse
Not that much different really, just need to search the google.com and XDA forums and you shall find answers...
gaze57 said:
Not exactly...
A blob file is a sort of archive that can contain several files.
For example, the kernel.blob you mention above contains the actual kernel (zImage) but also a ram disk.
As far as I understand a blob file is the only type of file that can be flashed to different partitions of your TF300T(G) using fastboot method.
To flash using CWM or TWRP you will need to pack blob file(s) into a special kind of zip package.
Below I have shared my script that I use to create a TWRP flashable zip package including a custom built kernel.
Hopefully it may shed some light in the steps required to go from zImage to blob file and TWRP flashable zip package.
The script takes the root path to your kernel source directory as first (and only) argument.
In same directory as script I have unpacked update.zip (from untermensch's kernel repository thread) as parts of this zip file are re-used.
---
#!/bin/sh
KERNEL_HOME=$1
KERNEL_NAME=my_kernel_$$
# Repack new kernel and old ram disk into blob file
cp ${KERNEL_HOME}/arch/arm/boot/zImage boot.blob.lnx-kernel.gz
repack-bootimg.pl boot.blob.lnx-kernel.gz boot.blob.lnx-ramdisk out.blob.lnx
blobpack out.blob LNX out.blob.lnx
# Prepend magic header
cat signblob_magic out.blob > kernel.blob
# Add kernel modules to ensure kernel and modules always match.
# If mismatch e.g WiFi might not work.
find ${KERNEL_HOME} -name "*.ko" -exec cp {} system/lib/modules \;
# Save kernel config in case it needs to be rebuilt some day.
cp ${KERNEL_HOME}/.config kernel_config
# Zip everything
zip -9 -r ${KERNEL_NAME}.zip kernel_config kernel.blob system/ META-INF/
# Sign zip using SignApk
java -Xmx1024m -jar signapk.jar -w testkey.x509.pem testkey.pk8 ${KERNEL_NAME}.zip ${KERNEL_NAME}-signed.zip
---
In theory this should work but if not mistaken mmcblk0p4 is just a sort of staging partition.
During bootup whatever is in mmcblk0p4 is copied to another partition (mmcblk0p0?).
(I guess this is the blue bar you can observe when flashing custom roms/kernels)
Someone more familiar with the details please correct me.
Instead of trying to backup your current kernel I would suggest to try to get the original
kernel by unpacking the official update packages from ASUS support web page.
Not that much different really, just need to search the google.com and XDA forums and you shall find answers...
Click to expand...
Click to collapse
Whoa... Thanks for the info. I go read up more on this.
I have not seen this posted anywhere, so I thought I would post it here. This is NOT purely my work, and I do not take credit for it as such.
Included in the attached ZIP are the following files:
boot_info - prints information about the boot.img passed to it, including the base address and ramdisk address. This tool prints out everything needed to repack the boot.img correctly.
split_boot - More commonly known as split_bootimg.pl, this rips apart the boot.img to extract the ramdisk and zImage. It has been modified by me to split the boot.img into a separate folder (specified by the file name of the boot.img passed to it) and to extract the ramdisk into a sub-folder as well (extracts the cpio from the gz and then extracts the actual files from the cpio archive)
unpack_ramdisk - unpacks the given ramdisk file.
Code:
Usage: unpack_ramdisk <ramdiskFile>
repack_ramdisk - repacks the ramdisk from the given directory (found online and modified slightly to take a directory)
Code:
Usage: repack_ramdisk <ramdiskDirectory> [outputFile]
mkbootimg - mkbootimg binary that creates a boot.img file from the given ramdisk and zImage. Updated to a version compiled by me to support the --ramdiskaddr option (ramdisk address) so that even nonstandard boot.img's can be repacked correctly (Use with boot_info for best results).
umkbootimg - included for convenience. Not made by me. Original thread here.
unpack - wrapper script made by me for the umkbootimg binary^ to unpack the boot.img into a separate directory and then unpack the ramdisk into a sub-directory.
Note: These tools were made for Linux. They may also work on Cygwin, but I have not personally tested them.
ANYONE is free to use / modify / kang these files as they see fit. No need to ever ask or do anything more than download.
Enjoy.
UPDATE: If you downloaded, please redownload. There was an error with my repack_ramdisk script, but it's fixed now.
Updated tools with a new boot_info script, also added my own mkbootimg binary compiled with the ramdisk address option.
Boot_info now displays the following information:
Commandline
Pagesize
Base address
Ramdisk address.
Which is everything you need to make a functional boot.img, even when the original boot.img is packed with a non-standard mkbootimg (ie, the ramdisk offset is different than the normal offset).
How exactly do we use these files to unpack and repack?
I've tried running the scripts with chmod at 755 but it doesn't work.
I am i missing something?
All the scripts must be in a folder in your path (~/bin for example)
Then it should work, because they call on each other. I keep all of them in my ~/bin folder, but they can be anywhere in your PATH
Sent from my buttered S3
if Android Magic Word not found at offset 0, it fail.
twins.7 said:
if Android Magic Word not found at offset 0, it fail.
Click to expand...
Click to collapse
No, if you use unmkbootimg instead split_boot, it also finds embedded images.
CNexus said:
No, if you use unmkbootimg instead split_boot, it also finds embedded images.
Click to expand...
Click to collapse
OK, it work. But .... sorry to much complain
My boot.img has magic word in offset 2048. so it mean, there is additional header in first 2048 byte.
umkbootimg succesfully extract embedded boot.img, but in repacking, I lost the first 2048 byte, because magic header placed in offset 0.
Actually, what is the additional header for? really asking...
I fail to fastboot flash if the image have no additional header.
And it will fail to verify, if the additional header is wrong. or is it called signed boot.img?
If I change the content of boot.img, I can't flash it to device. It always said verify fail. I though, the additional header has CRC or hash or anything.
If you have spare time and want to help me, I'll post my image
Thanks for this tools
Send from my AMOI N828 using Xda Premium
twins.7 said:
OK, it work. But .... sorry to much complain
My boot.img has magic word in offset 2048. so it mean, there is additional header in first 2048 byte.
umkbootimg succesfully extract embedded boot.img, but in repacking, I lost the first 2048 byte, because magic header placed in offset 0.
Actually, what is the additional header for? really asking...
I fail to fastboot flash if the image have no additional header.
And it will fail to verify, if the additional header is wrong. or is it called signed boot.img?
If I change the content of boot.img, I can't flash it to device. It always said verify fail. I though, the additional header has CRC or hash or anything.
If you have spare time and want to help me, I'll post my image
Click to expand...
Click to collapse
I'm not sure. No tool will work for all devices, and since I've never had a device that has this special packing, it would be best if you asked one of your kernel devs for help unpacking/repacking
CNexus said:
I'm not sure. No tool will work for all devices, and since I've never had a device that has this special packing, it would be best if you asked one of your kernel devs for help unpacking/repacking
Click to expand...
Click to collapse
ok thank's
CNexus said:
I have not seen this posted anywhere, so I thought I would post it here. This is NOT purely my work, and I do not take credit for it as such.
Included in the attached ZIP are the following files:
boot_info - prints information about the boot.img passed to it, including the base address and ramdisk address. This tool prints out everything needed to repack the boot.img correctly.
split_boot - More commonly known as split_bootimg.pl, this rips apart the boot.img to extract the ramdisk and zImage. It has been modified by me to split the boot.img into a separate folder (specified by the file name of the boot.img passed to it) and to extract the ramdisk into a sub-folder as well (extracts the cpio from the gz and then extracts the actual files from the cpio archive)
unpack_ramdisk - unpacks the given ramdisk file.
Code:
Usage: unpack_ramdisk <ramdiskFile>
repack_ramdisk - repacks the ramdisk from the given directory (found online and modified slightly to take a directory)
Code:
Usage: repack_ramdisk <ramdiskDirectory> [outputFile]
mkbootimg - mkbootimg binary that creates a boot.img file from the given ramdisk and zImage. Updated to a version compiled by me to support the --ramdiskaddr option (ramdisk address) so that even nonstandard boot.img's can be repacked correctly (Use with boot_info for best results).
umkbootimg - included for convenience. Not made by me. Original thread here.
unpack - wrapper script made by me for the umkbootimg binary^ to unpack the boot.img into a separate directory and then unpack the ramdisk into a sub-directory.
Note: These tools were made for Linux. They may also work on Cygwin, but I have not personally tested them.
ANYONE is free to use / modify / kang these files as they see fit. No need to ever ask or do anything more than download.
Enjoy.
Click to expand...
Click to collapse
is it possible to make these run on the device?
i have tried
adb root
adb remount
adb push * /sdcard/tmp/
adb push * /system/xbin/
adb push * /system/bin/
adb shell
cd /sdcard/tmp/
for f in $(ls)
do
chmod 755 /system/bin/$f
chmod 775 /system/xbin/$f
done
cd /
rm -r /sdcard/tmp
cd /sdcard/working
split_bootimg.pl boot.img
returns "Permission denied"
hmmmmm???????? what could be the problem????????
ricky310711 said:
is it possible to make these run on the device?
i have tried
adb root
adb remount
adb push * /sdcard/tmp/
adb push * /system/xbin/
adb push * /system/bin/
adb shell
cd /sdcard/tmp/
for f in $(ls)
do
chmod 755 /system/bin/$f
chmod 775 /system/xbin/$f
done
cd /
rm -r /sdcard/tmp
cd /sdcard/working
split_bootimg.pl boot.img
returns "Permission denied"
hmmmmm???????? what could be the problem????????
Click to expand...
Click to collapse
The Perl script should work if you have Perl (compiled for ARM x86) on your device.
The binaries will not work as they are not compiled for ARM. The scripts (at least some of them) should work if you change all instances of "#!/bin/bash" and "#!/usr/bin/env bash" to "#!/system/bin/sh".
CNexus said:
The Perl script should work if you have Perl (compiled for ARM x86) on your device.
The binaries will not work as they are not compiled for ARM. The scripts (at least some of them) should work if you change all instances of "#!/bin/bash" and "#!/usr/bin/env bash" to "#!/system/bin/sh".
Click to expand...
Click to collapse
will see if i can get it working tonight! this could be pretty good if i can get it to unpack on device!
ricky310711 said:
will see if i can get it working tonight! this could be pretty good if i can get it to unpack on device!
Click to expand...
Click to collapse
No need...download this zip and extract http://www12.zippyshare.com/v/37266634/file.html
It already contains an unmkbootimg binary compiled for ARM. Then you would just need to unpack the ramdisk to finish it off.
CNexus said:
No need...download this zip and extract http://www12.zippyshare.com/v/37266634/file.html
It already contains an unmkbootimg binary compiled for ARM. Then you would just need to unpack the ramdisk to finish it off.
Click to expand...
Click to collapse
no way, ive been looking for something like this for ages, who is the author?
ricky310711 said:
no way, ive been looking for something like this for ages, who is the author?
Click to expand...
Click to collapse
I don't know who originally compiled that unmkbootimg binary for ARM.
CNexus said:
I don't know who originally compiled that unmkbootimg binary for ARM.
Click to expand...
Click to collapse
hmm, gotta findout! i wanna use it in my tool!
Is this boot.img tool compatible with Microsoft windows as well?
Sent from my SPH-L710 using XDA Premium 4 mobile app
shakim24 said:
Is this boot.img tool compatible with Microsoft windows as well?
Sent from my SPH-L710 using XDA Premium 4 mobile app
Click to expand...
Click to collapse
Read the OP.
Hi/Hello/good evening!
I have a broken MTK phone waiting for spareparts and one backup file from its SDCard made with CWM
name userdata_20130615_140224.backup where I need to extract contact data from.
How to do it?
I have been searching a whole while now but could not find one single post about opening this archive.
Pls help!
Thank you,
Erwin
If u have any spare phone with Titanium Backup installed then u can transfer ur backup to tat mobile's sd card and use TB to extract data from Nanoid Backup..
Sent from my WT19i using xda premium
expanding file
hi,
unyaffs doesnt work on that .backup file and I dont have a spare phone lying around. I got the file on windows
and please after reading 20.000 tuts on "backups" can there be one that explains how to extract the file
with windows?
thank you,
Erwin
NOW!!!
ewoewo said:
hi,
unyaffs doesnt work on that .backup file and i dont have a spare phone lying around. I got the file on windows
and please after reading 20.000 tuts on "backups" can there be one that explains how to extract the file
with windows?
Thank you,
erwin
Click to expand...
Click to collapse
tell me the tec solution internet!
ewoewo said:
Hi/Hello/good evening!
I have a userdata#######.backup and I cant enter into recovery mode. once i try toenter recovery mode in boots and shuts down without entering into recovery mode. I want to restore this backup file. Help me out
Thank you!!
Click to expand...
Click to collapse
It's a 512 byte header in front of a "tar.gz"
hexdump -C userdata_xxxxxxxx_yyyyyy.backup | lessshowed the magical zip header "1f8b0800 00000000" at offset 0x200
So, skipping 512 bytes, the rest can be gunzip | tar
dd if=userdata_xxxxxxxx_yyyyyy.backup bs=512 skip=1 | gunzip -c | tar xv
Code:
dd if=/home/user/_backups/E380-android-phone/userdata_20160126_223433.backup bs=512 skip=1 > /home/user/_backups/E380-android-phone/userdata_20160126_223433.backup.dd-out.tar.gz
Worked for me. Then just used KDE's archive opener (Ark) to view the files, looks to have everything in there except keys and whatnot.
if you prefer a linux solution use this script it converts android backup to nandroid backup
http://forum.xda-developers.com/showthread.php?p=65374561
Hello! Super-Developers, mega-programmers and smart hackers!
Nobody does not know how to open *. backup file?
No one can't help in this problem suffering millions of android/windows users?
You suggest them to install Unix/Linux system, - everybody to become hackers and programmers?!
maybe in the World exists GUI- programme to open *. backup file?
Someone can solve this problem of the century?
Philoandr said:
Hello! Super-Developers, mega-programmers and smart hackers!
Nobody does not know how to open *. backup file?
No one can't help in this problem suffering millions of android/windows users?
You suggest them to install Unix/Linux system, - everybody to become hackers and programmers?!
maybe in the World exists GUI- programme to open *. backup file?
Someone can solve this problem of the century?
Click to expand...
Click to collapse
What do you expect. You are trying to edit a Linux based file. Not to mention a closed sourced compressed file.
There are free programs like OSFMount or DiskInternals Linux Reader for mounting (android) linux file system images on Windows. Also 7-Zip for Windows can extract files from linux file system images.
However, there is metadata like user identifier and group ownership, file permissions, SELinux context (user role type range) stored for each file, which gets lost once you have saved linux files to windows disk. Without this metadata you can not restore files to phone.
Regardless you can extract files in windows if you just care about pictures, music files etc. Maybe one day there is a developer who may write such a program no matter its useless for restoring complete user data to phone.
Regarding the userdata*.backup files (no cwm) this is a chinese feature not provided by google android open source project. Without source code its nearly impossible to analyze the checksum algorithm. You can not re-create a userdata*.backup file.
What you can do is unpacking it. make a guess. cut off the first 512 byte header of each file which is probably the checksum. then merge the files together. Now you have a file for further analysis. Its probably either a ext4 disk image or a (gz compressed) tarball archive. a disk image can be mounted as a new drive, metadata keeps preserved in this case. a tarball archive must extracted with gnu tar to linux file system. when extracting with 7-Zip you will lose metadata.
There is a risk of tarball archive is unheadered Tar, in this case 7-zip will not extract it. If your phone is encrypted, the disk image is probably encrypted disk image (thats where the hacker stuff starts).
If you want to remove the checksum in windows, there is a small problem. There is no such command. You can use a third party command line utility Trunc to try it. (truncate deletes only from tail)
Another way for Windows, you can use some linux utils with cygwin. I don't know exactly how to do it, but @Doc_cheilvenerdi.org released a Windows script Odinatrix which converts unheadered Tar to Ustar Tar. From this you can use some linux utils (i don't know if it works for converting backups, too)
1. unpack the Odinatrix-WINDOWS.zip file. copy the folder named "files" containing cygwin linux utils. rename the folder to bash (or any meaningful name)
2. create a new folder on Windows Desktop
3. move the backup files to <some folder>
4. open the Windows Command Prompt
goto Windows Start - Run...
type: %SystemRoot%\system32\cmd.exe - press OK
now type the following commands in Windows terminal console:
5. add bash folder to windows environment variable %PATH%
(example: PATH=%PATH%;C:\Program Files\bash)
Code:
PATH=%PATH%;<path to bash folder>
6. change directory and list backup files
Code:
cd %UserProfile%\Desktop\<some folder>
dir /a userdata*.backup*
7. cut off 512 byte header from each file using (cygwin) gnu "dd" linux util like @ektoric suggest in post #6.
do this for each file, skipping 512 bytes only (without unpacking). replace the wildcard * with <date>_<time>
Code:
dd if=userdata*.backup of=userdata*.part0 bs=512 skip=1
dd if=userdata*.backup1 of=userdata*.part1 bs=512 skip=1
dd if=userdata*.backup2 of=userdata*.part2 bs=512 skip=1
dd if=userdata*.backup3 of=userdata*.part3 bs=512 skip=1
8. merge the files with windows
Code:
copy /v /y userdata*.part0 /b + userdata*.part1 /b + userdata*.part2 /b + userdata*.part3 /b userdata*.img /b
9. try to mount the userdata*.img with OSFMount. if not working, try extracting with 7-zip.
Besides this linux is no hacker-os and just as easily operated as windows. You can boot a live distribution from usb-stick without installing.
for further questions, please visit the main thread
[Q] How to Extract data from .Backup file ? - Created with android system recovery
zelendel said:
What do you expect. You are trying to edit a Linux based file. Not to mention a closed sourced compressed file.
Click to expand...
Click to collapse
Thank you for the answer!
Please comment next:
1) Video how to extract files from
"Linux based, Not to mention, a closed sourced compressed" backup file with metadata:
Распаковка и извлечение файлов из резервной копии - YouTube
m.youtube.com/watch?v=HNXed7RGR2g
2) quote from Android Backup Extractor's README-TXT-instruction:
"Usage:-- Windows: very easy"?
Android Backup Extractor - -- sourceforge.net/projects/adbextractor/files
-sourceforge.net/projects/adbextractor/reviews?source=navbar
I tried to use Android Backup Extractor In WinXp SP3
but windows version of this app shows cygwin&some other files missing.
Do you know why it doesn't work?
I don't need to recover backup on its own place.
My target is to extract and open few files: photos, videos, documents...
Strangely 7zip also doesn't work. Thank you in advance!
adbextractor is for adb backups *.ab only (btw open source).
cygwin is a implementation of linux utils running in windows.
the above solution uses cygwin, did you try?
aIecxs said:
adbextractor is for adb backups *.ab only (btw open source).
cygwin is a implementation of linux utils running in windows.
the above solution uses cygwin, did you try?
Click to expand...
Click to collapse
Thank you for first very detailed answer!
It seems that you have a remarkable grasp of this subject,
that's why I ask you to comment my previous post about video and Android Backup Extractor.
Your second post is not clear for me: adbextractor is only for *.ab files??
I have few files cygwin, is it a separate program??
I attempted to run file start.exe - windows version of Android Backup Extractor with those few cygwin files
but unsuccessful.
I read and test a lot, but The problem is still unsettled.
i came up two years ago with same question, how to unpack, and ended up with learning linux. i have uploaded a bash script, but i don't know if it works. i am not a developer and still learning, and nobody give feedback.
what is exactly file name of your backup? suffix *.ab or *.backup? these are completely different, don't mix up tools.
if you mean userdata_20180313_161000.backup files, please try mini tut above beginning 1.
aIecxs said:
i came up two years ago with same question, how to unpack, and ended up with learning linux. ... i am not a developer and still learning
Click to expand...
Click to collapse
It is classic aphorismic sentence!! I like it.
What's the bash script? for what goal? it is for Windows? If yes, I'll try it. give me the link.
my files are userdata_20100102_045926.backup, -=-=.backup1, 2, 3......
I'm not Englishman, "mini tut" is mini tutorial?
You have 100 posts and 25 thanks - super rate for notdeveloper.
the tool in video (adbextractor) can not unpack your backup. your backup is a splitted ext4 partition image. OSFMount can open ext4 partition images from Windows
bckp2cwm.sh script is basically doing the same steps like mini tutorial above. unfortunately it is for linux. main goal is convert userdata*.backup to cwm backup, but its paused in the middle (after unpacking, before repacking)
as windows user, all you need is a usb-stick. there is a tool unetbootin running in windows. it is a one-click-solution for downloading and copying any linux distribution to usb-stick. you can boot into linux from this usb-stick, for example ubuntu
aIecxs said:
OSFMount can open ext4 partition images from Windows
Click to expand...
Click to collapse
OSFMount can extract few files from my backup?
Thank you very much for efficient advices!!!:highfive:
I'll try them in sequence.
although Linux is not my :angel:dream.
Solution for Windows
1. Download and install free hhd hex editor neo.
2. Open each of your .backup files, in select menu select range at 0 offset size 512 decimal, delete and save.
3. Use Windows copy command to join files as described in post#11 (Thanks to the author for free education).
4. Use any program that reads Linux disk image files. I used diskinternals (mount image from the drive menu first). Openext worked too.
This won't work on tar archives if I understand correctly. This took me days to figure out and only minutes to execute. No thanks to confusing android prompts while upgrading to a new OS.
yoyohelp said:
1. Download and install free hhd hex editor neo.
2. Open each of your .backup files, in select menu select range at 0 offset size 512 decimal, delete and save.
3. Use Windows copy command to join files as described in post#11 (Thanks to the author for free education).
4. Use any program that reads Linux disk image files. I used diskinternals (mount image from the drive menu first). Openext worked too.
This won't work on tar archives if I understand correctly. This took me days to figure out and only minutes to execute. No thanks to confusing android prompts while upgrading to a new OS.
Click to expand...
Click to collapse
Hi i have a problem i have 5 files from the backup each with 2gb when i do the command from post 11 it works nice but when goes to backup part 3 it gives an error, what could it be? Im i doing something wrong?
This is a tutorial I've decided to put together as I'm learning to compile kernels. It will cover unpacking and repacking a boot.img and/or recovery.img, and also touch on unpacking the ramdisk after we have unpacked the boot.img This tutorial will only focus on executing this on a android device using the terminal emulator app but of course you could use these tools on a PC in a adb shell.
This would not be possible without the hard work of xda member @Modding.MyMind. I am not responsible for anything you do to your device by using these tools.
What you will need
1. Android device
2. Have root
3. Have busybox installed (1.23.1 is recommended)
4. Terminal Emulator app
5. Root Explorer app
6. Your devices boot.img and/or recovery.img
7. mkbootimg_tools-master.zip (download below)
https://www.dropbox.com/s/fiat0zrf2f533uq/mkbootimg_tools-master.zip?dl=0
DIRECTIONS
1. Let's pull the boot.img we are going to work with using dd. Open your terminal and type su > press enter. Type dd if=/dev/block/platform/msm_sdcc.1/by-name/boot of=/sdcard/boot.img > press enter and now you should see a file on your sdcard called boot.img
2. Place the zip file on the root of your internal sdcard and extract it. You will see a folder called mkbootimg_tools-master and inside that folder you will see 2 folders. One called ARM and one called README.md Now we are going to copy the ARM folder to data/local/tmp and paste it inside of the tmp folder.
3. Now we need to go the ARM folder that you just copied inside tmp and set the permissions to 0777 (rwxrwxrwx) and also set the same permissions for each file inside the ARM folder.
4. Now go inside the ARM folder and copy the bash file to system/xbin and set the permission to chmod 0755 (rwxr-xr-x)
5. Ok now copy the boot.img file that we pulled onto your sdcard inside the ARM folder and leave the permissions for that file 0666 (rw-rw-rw-)
6. Open up your terminal emulator app and type su > press enter
7. Now we are going to change directories to the ARM folder which we want to be in by typing cd data/local/tmp/ARM > press enter
########################################
Now to unpack your boot.img
1. Type ./mkboot boot.img bootfolder > press enter and you will see the magic happen. It will automatically create a folder called bootfolder which is your project folder and you can name it whatever you like but I like to call it bootfolder and if I was unpacking a recovery.img I would call it recoveryfolder
2. So now you have your unpacked boot.img.
3. Now go to your terminal and type cd bootfolder > and press enter. We are going into your bootfolder now because that is where your ramdisk.gz is located and we are now going to decompress your ramdisk by typing gunzip -dc ramdisk.gz | cpio -i > and press enter and it will decompress your ramdisk for you.
4. So now you have unpacked a boot.img and also learned how to decompress your ramdisk.
########################################
How to decompress a ramdisk in lzma format
1. ./mkboot recovery.img workfolder
2. cd workfolder/ramdisk
3. Now type lzma -dc ../ramdisk.lzma | cpio -i; strings *.ko
4. Now you will have your lzma compressed ramdisk inside your workfolder
#######################################
Now we are going to repack your boot.img
1. In your terminal type cd .. > and press enter so you will move back 1 directory into your ARM folder.
2. Now to repack you are going to type ./mkboot bootfolder boot.img > and press enter and that will repack your boot.img for you
*wherever you saw me type a > don't ever type that as I was just showing that you are done the command or syntax and your are ready to press enter
Source code https://github.com/ModdingMyMind/mkbootimg_tools/commit/6c44267b4a8a43504c870678c68df6a31b8e2f18
Screenshot - https://www.dropbox.com/s/se171tzgnf6wp0q/Screenshot_2015-03-12-02-49-50.png?dl=0
Screenshot - https://www.dropbox.com/s/5bzt8p6l2ltosl6/Screenshot_2015-03-12-02-50-04.png?dl=0
Thanks to @leonardoafa for being a great help & friend
How different is it for a recovery image file please?
Is the same, just put your recovery.img in the ARM folder and you might want to call your project folder something different than bootfolder (ex; recoveryfolder) so you don't get confused or forget
Oh yes, however ramdisk folder is empty when you use only a recovery image. Less content of course.
image45 said:
Oh yes, however ramdisk folder is empty when you use only a recovery image. Less content of course.
Click to expand...
Click to collapse
When i use twrp everything is working perfect. Your ramdisk is probably in a lzma format I'm guessing
As you can see im inside of my ramdisk folder, which is inside my recoveryfolder
https://www.dropbox.com/sc/ffyy2ndrkl57hn4/AACV__FpJuScCvIvErx2WFffa
@image45 i added how to decompress a ramdisk in lzma format to the op
Nice guide :good:
Yes very detailed, thank you.
@skulldreamz
Hi my friend, do you still want to learn about scripts.
Please go to telegram app.
Thanks
@image45 can you sendme your image that uses a lzma compressed ramdisk. The project supports lzma so there should be no need to decompress it manually however, if the project is not doing what it should already be doing then I need to debug the script, find the culprit, make my fix, and push the changes to my github. Would be greatly appreciated. Thanks.
app
Hy,
I use this app for long time to open boot.img and extract ramdisk.
The app asked then if you want open the ramdisk also.
Only click on your boot.img and in 4 sec its open.
Second function is to pack a boot.img.
Very simple to use, also for beginners.
konsolen said:
Hy,
I use this app for long time to open boot.img and extract ramdisk.
The app asked then if you want open the ramdisk also.
Only click on your boot.img and in 4 sec its open.
Second function is to pack a boot.img.
Very simple to use, also for beginners.
Click to expand...
Click to collapse
It only decompresses gzip ramdisks. Doesn't support other types unless you modify the ramdisk.sh script used inside the apk. It also doesn't support images with dt binaries which is more common nowadays. I use to use this a long time ago but to say it simple, it is outdated and lacks support.
However, if it works then I say use it. Especially if the person isn't comfortable with command lines.
Very helpful thx
Thanks
Sent from my SAMSUNG-SGH-I747 using Tapatalk
I see this is an older thread but tried it on my Nexus 6p. When I repacked boot it was significantly smaller in size. It also has the warning of non standard address. Anything I should do or be aware of?
Fe Mike said:
I see this is an older thread but tried it on my Nexus 6p. When I repacked boot it was significantly smaller in size. It also has the warning of non standard address. Anything I should do or be aware of?
Click to expand...
Click to collapse
Try using mkboot....
https://github.com/xiaolu/mkbootimg_tools
The Sickness said:
Try using mkboot....
https://github.com/xiaolu/mkbootimg_tools
Click to expand...
Click to collapse
Thank you, bare with me as Im fairly new to this. Just to be clear, when i go to link there is the ARM folder that has all the same stuff in it or the single mkboot file thats 9.46mb in size? Not sure how to download just the mkboot file. When i click it, it just opens up the code. Do i copy and paste the code?
Fe Mike said:
Thank you, bare with me as Im fairly new to this. Just to be clear, when i go to link there is the ARM folder that has all the same stuff in it or the single mkboot file thats 9.46mb in size? Not sure how to download just the mkboot file. When i click it, it just opens up the code. Do i copy and paste the code?
Click to expand...
Click to collapse
You have to clone the source using "git clone" in your terminal. Which means you need to be on Linux
The Sickness said:
You have to clone the source using "git clone" in your terminal. Which means you need to be on Linux
Click to expand...
Click to collapse
Ok, I was able to clone using cygwin. But i was reading in the forums that the size of extracted boot from phone will not be the same as it being repacked. So I used original files from this post and and just extracted, unpacked, and repacked. Then just flashed img thru twrp and everthing went well. Thank you for your response.
SHM said:
It only decompresses gzip ramdisks. Doesn't support other types unless you modify the ramdisk.sh script used inside the apk. It also doesn't support images with dt binaries which is more common nowadays. I use to use this a long time ago but to say it simple, it is outdated and lacks support.
However, if it works then I say use it. Especially if the person isn't comfortable with command lines.
Click to expand...
Click to collapse
Why haven't you made something like this, he's just using someone else's tools, please MMM, you're the man
I am a Windows user, and I was having quite the trouble unpacking and repacking system.new.dat files. I tried all sorts of Windows Chinese tools for the job, but no matter what I did, when I put the system.new.dat file and system.transfer.list file back into the flashable zip (even if I made no changes to the system.new.dat file... just unpacked and repacked), I would get an error flashing the file.
I finally got around this by installing Ubuntu 16.04 Xenial Xerus on VirtualBox. You can find a lot of tutorials online about how to do that. I am basing my instructions off of xpirt's tutorial on unpacking and repacking with the tools he provides. But it took me about 2 days to figure it out because I kept running into problems since some of the instructions made assumptions that the user knows how to use Linux. I am very new to Linux. I am not completely sure how to do *everything* from the command line, so if someone wants to add to my instructions to make it easier, please do so. But these are the things I did to figure it out.
So here are the noob-friendly Linux Ubuntu instructions on how to unpack and repack:
Section 1: Getting everything Ready
1. Download your flashable .zip rom. In my case, I downloaded cm-12.1-20150619-UNOFFICIAL-afyonltetmo.zip to my Ubuntu Desktop. You can download it to your Home Directory as well. Doesn't matter.
2. Download sdat2img. I downloaded mine to my Home Directory.
3. Download img2sdat. I also downloaded this to my Home Directory.
4. Extract all 3 zips, by right clicking on them and choosing 'Extract Here.' It will extract them into their own directories. The main directories that you need to pay attention to are /sdat2img-master/ and /img2sdat-master/
5. Download ext4fs either right into the sdat2img-master folder, or anywhere you want and then drag and drop it into the sdat2img-master folder.
6. Open Terminal, and install Python 2.7, if it's not already installed. Put
Code:
sudo apt-get install python-2.7 python-pip
Section 2: Beginning the Unpacking Process
*Note, you can copy and paste the codes; however, you can't use keyboard shortcuts in terminal. You have to right click and choose your option.
*Another note: Where you see "user" in the terminal commands, substitute it with your Linux username.
1. In your extracted folder from your flashable zip, right click on system.new.dat and system.transfer.list and choose 'cut.' Then paste them in the sdat2img-master folder.
2. Back in Terminal put
Code:
cd sdat2img-master
. That will get you into the right directory.
3. Now put
Code:
./sdat2img.py system.transfer.list system.new.dat system.img
. That will create your raw ext4 .img file.
4. You want to create an output directory for all the files that are in system.img. Put
Code:
mkdir output
5. Now you can mount system.img, and it will mount it into that output folder. Put
Code:
sudo mount -t ext4 -o loop system.img output/
6. You might have the problem that you don't have ownership of all the files (they have little "locks" on them). To gain ownership, put
Code:
sudo chown -R user:user /home/user/sdat2img-master/output
. If you still can't get read and write access, just try rebooting your Ubuntu virtual computer. That was the only thing that finally worked for me. You can start modifying stuff as you wish.
Section 3: Compress files back to a raw ext4 image
1. You are now going to need your file_contexts file from your original extract rom zip. COPY (not cut) and paste it into the sdat2img-master folder.
2. You are also going to need your 'make_ext4fs' file. Make sure it is in the sdat2img-master folder. You might have trouble with permissions, so just in case, put
Code:
chmod 777 /home/user/sdat2img-master/make_ext4fs
into terminal.
3. In Files (Ubuntu's "File Manager"), in the sdat2img-master folder, right click on your system.img file and go to 'Properties'. Notice the information in "Size." Ignore the GB, but look at the bytes. Mine is 2,411,724,800. Copy that number, but remove the commas. So mine is 2411724800.
4. Next is the actual compressing part. Put
Code:
./make_ext4fs -T 0 -S file_contexts -l 2411724800 -a system system_new.img output/
into terminal, but substitute '2411724800' with whatever size you got from the Properties in system.img. You will now how a new file called system_new.img.
Section 4: Converting ext4 (raw image) to img (sparse image)
1. Now you will need to install img2simg. In Terminal, put
Code:
sudo apt-get install android-tools-fsutils
2. Now you can put
Code:
img2simg system_new.img system_new_sparse.img
You will now have a file called system_new_sparse.img that is ready to be packed in a new dat file.
Section 5: Converting img (sparse image) to dat (sparse data)
1. Cut and paste your system_new_sparse.img into img2sdat-master folder that you made earlier.
2. Now you need to navigate to that folder in terminal. Put
Code:
cd /home/user/img2sdat-master
3. Now you can put
Code:
./img2sdat.py system_new_sparse.img
to create your new dat file. It will first ask you which Android version it's for. Enter the number corresponding and hit enter.
4. You're now pretty much done. As you'll see, it created 3 files: system.new.dat, system.patch.dat, and system.transfer.list. Just paste these files into your folder where your flashable zip files are, replacing any original ones in there. Make sure you also have your file_contexts file in there as well. Highlight all the files in there, right click, and zip them up. Then name your flashable zip whatever you want and try flashing!