Related
If you are looking for a way to easily unpack / repack boot.img, recovery.img or logo.bin from your MediaTek device (all except Android One devices), don't look any further. Here you can find my own Perl scripts.
Scripts were first based on the ones available on Android-DLS WiKi, but are now highly modified in order to work with specific MTK boot and recovery images. The scripts fully work with every image from all known MediaTek SoC:
MT6516
MT65x3 (MT6513 and MT6573)
MT65x5 (MT6515 and MT6575)
MT6577
MT65x2 (MT6572, MT6582 and MT6592)
MT6589
MT83xx (MT8377 and MT8389)
MT6595
The most up to date version of the scripts is always available at my public github repository: bgcngm/mtk-tools. Scripts require Perl v5.14+ to be installed and were fully tested under Ubuntu 12.04 as well as Windows 7 x64 (using Cygwin).
Please don't just leech the files and go away. You can easily say thanks just by pressing "Thanks" button.
Unpack script usage:
Code:
Usage: unpack-MTK.pl <infile> [COMMAND ...]
Unpacks MediaTek boot, recovery or logo images
Optional COMMANDs for boot or recovery images are:
-info_only
Display file information only
(useful to check image information without unpacking)
-kernel_only [--debug]
Extract kernel only
-ramdisk_only [--debug]
Extract ramdisk only
(optional argument '--debug' can additionally be used to provide useful
information for debugging purposes, even while unpacking both kernel
and ramdisk)
Optional COMMANDs for logo images are:
-force_logo_res <width> <height>
Forces file to be unpacked by specifying image resolution (in pixels)
(only useful when no zlib compressed images are found)
-invert_logo_res
Invert image resolution (width <-> height)
(may be useful when extracted images appear to be broken)
Repack script usage:
Code:
Usage: repack-MTK.pl <COMMAND ...> <outfile>
Repacks MediaTek boot, recovery or logo images
COMMANDs for boot or recovery images are:
-boot [--debug] <kernel> <ramdisk-directory>
Repacks boot image
-recovery [--debug] <kernel> <ramdisk-directory>
Repacks recovery image
(optional argument '--debug' can additionally be used to provide useful
information for debugging purposes, while repacking)
COMMANDs for logo images are:
-logo [--no_compression] <logo-directory>
Repacks logo image
(optional argument '--no_compression' can be used to repack logo images
without compression)
Version history:
modified to work with MT6516 boot and recovery images (17-03-2011)
included support for MT65x3 and eliminated the need of header files (16-10-2011)
added cygwin mkbootimg binary and propper fix (17-05-2012)
included support for MT65xx logo images (31-07-2012)
fixed problem unpacking logo images containing more than nine packed rgb565 raw files (29-11-2012)
re-written logo images file verification (29-12-2012)
image resolution is now calculated and shown when unpacking logo images (02-01-2013)
added colored screen output (04-01-2013)
included support for logo images containing uncompressed raw files (06-01-2013)
more verbose output when unpacking boot and recovery images (13-01-2013)
kernel or ramdisk extraction only is now supported (13-01-2013)
re-written check of needed binaries (13-01-2013)
ramdisk.cpio.gz deleted after successful extraction (15-01-2013)
added rgb565 <=> png images conversion (27-01-2013)
code cleanup and revised verbose output (16-10-2014)
boot or recovery is now extracted to the working directory (16-10-2014)
unpack result is stored on the working directory, despite of the input file path (17-10-2014)
added support for new platforms - MT6595 (thanks @carliv) (29-12-2014)
minor code cleanup and revised information output for boot and recovery images (29-12-2014)
make scripts more future-proof by supporting even more args (30-12-2014)
continue repacking even if there's no extra args file (01-01-2015)
more verbose output when repacking boot and recovery images (02-01-2015)
added new cmdline option for debugging purposes when unpacking / repacking boot and recovery images (06-01-2015)
Credits:
Android-DLS for the initial scripts
starix (from forum.china-iphone.ru) for the decryption of logo.bin files structure
carliv (from forum.xda-developers.com) for new platform support and new binaries
XDA:DevDB Information
MTK-Tools, Tool/Utility for the Android General
Contributors
bgcngm
Version Information
Status: Stable
Created 2014-10-15
Last Updated 2014-10-17
Editing .rgb565 raw files
There may be other ways for doing this, but here's a short info that will help you to edit .rgb656 raw files found inside MTK logo images.
Download and install Paint.NET
Download the attached plugin and copy the RGB565.dll file to the folder: "C:\Program Files\Paint.Net\FileTypes"
Open the .rgb565 file and enter image height and width
Information:
The plugin will allow read and write support to the RGB565 or RAW565 format. This format is used by the Android platform for the initial boot screen of the device. It will also allow you to open a BMP, PNG, JPG or other image and save it as a RGB565 file.
RGB565 is simply the raw pixel data of a bitmap file. It does not contain any header information and does not contain the dimensions of the image. The only thing that is known is the total number of pixels. When opening a .rgb565 file, the user must specify the height and width of the image, which is the resolution of your device's screen.
Just as an example, for a device with a 540 x 960 screen, the .rgb565 file for that device will have 518400 pixels. The size of the file in bytes will be twice the number of pixels, i.e. 1036800 bytes.
hello,
i tried ur script and works with MT6573 but i need some help.
How to repack?
The syntax u posted looks little jumbled and i need a example on unpack and repacking from u
Burned from my laser torch using pencil cells
Simple... let's say you unpack a boot.img:
Code:
unpack-MT65xx.pl boot.img
This extracts the kernel (it will be named boot.img-kernel.img) and the ramdisk folder (it will be named boot.img-ramdisk).
In order to repack, you should run:
Code:
repack-MT65xx.pl boot.img-kernel.img boot.img-ramdisk new-boot.img
If you are repacking a recovery.img, then it should be:
Code:
repack-MT65xx.pl -recovery recovery.img-kernel.img recovery.img-ramdisk new-recovery.img
I m getting "can't exec "mkbootimg" : No such file or directory at ./repack-Mt65xx.pl line 66" error
Now?
Edit: Solved the error
Burned from my laser torch using pencil cells
How did u solve?
Sent from my Android using Tapatalk 2
Probably it was just a matter of setting the proper permissions.
Hello, sorry for my bad english
help me please
i'm getting this error:
C:\Perl\MT65xx_scripts>unpack-MT65xx.pl recovery.img
Subroutine Cwd::fastcwd redefined at C:/Perl/lib/Cwd.pm line 819.
Subroutine Cwd::getcwd redefined at C:/Perl/lib/Cwd.pm line 819.
Subroutine Cwd::abs_path redefined at C:/Perl/lib/Cwd.pm line 819.
kernel written to boot/recovery.img-kernel.img
the boot image does not appear to contain a valid gzip file at C:\Perl\MT65xx_sc
ripts\unpack-MT65xx.pl line 48.
My telephone have a MT6573 processor
I have only used the scripts under Ubuntu, so never tested it on a Windows environment.
Are you sure that you have Perl correctly installed?
tried with ubuntu works.
Thanks!!!
Works in windows with cygwin too with some minor tweaking...
change the repack script line 66, mkbootimg to ./mkbootimg.exe & replace mkbootimg with this windows version... i think it should work with any mkbootimg.exe windows version too...
ignore the unpack scripts error though, it works fine actually in cygwin...
bgcngm said:
If you are looking for a way to easily unpack / repack boot.img (or recovery.img) from your MediaTek device, don't look any further. Here you can find my own Perl scripts.
These scripts are based on the ones available on Android-DLS WiKi, but highly modified in order to work with specific MTK boot and recovery images. Currently, these scripts fully work with any MT6516, MT6513 or MT6573 boot image. I believe it will still work for the new MT6575 images.
Unpack script usage:
Code:
unpack-MT65xx.pl <image>
Repack script usage:
Code:
repack-MT65xx.pl [-recovery] <kernel> <ramdisk-directory> <outfile>
Click to expand...
Click to collapse
when i type
unpack-MT65xx.pl boot.img
in terminal it says
unpack-MT65xx.pl cammand not found
im on ubuntu 11
Solution to the error!!
Edit: Solved the error - can't exec "mkbootimg"
If someone gets the error:
can't exec "mkbootimg" : No such file or directory at ./repack-Mt65xx.pl line 66
Follow this:
In Ubuntu:
copy the 'mkbootimg' file and paste it in your /bin folder.
A command like this in the terminal will do the work:
Code:
sudo cp /path/to/unpack-repack-scripts/mkbootimg /bin
(enter your password, when it asks)
In windows(using cygwin):
Edit:
Use the OP to download latest script.
bindassdost said:
when i type
unpack-MT65xx.pl boot.img
in terminal it says
unpack-MT65xx.pl cammand not found
im on ubuntu 11
Click to expand...
Click to collapse
type like this bro:
Code:
./unpack-MT65xx.pl boot.img
hope it helps !
marsavo said:
Hello, sorry for my bad english
help me please
i'm getting this error:
C:\Perl\MT65xx_scripts>unpack-MT65xx.pl recovery.img
Subroutine Cwd::fastcwd redefined at C:/Perl/lib/Cwd.pm line 819.
Subroutine Cwd::getcwd redefined at C:/Perl/lib/Cwd.pm line 819.
Subroutine Cwd::abs_path redefined at C:/Perl/lib/Cwd.pm line 819.
kernel written to boot/recovery.img-kernel.img
the boot image does not appear to contain a valid gzip file at C:\Perl\MT65xx_sc
ripts\unpack-MT65xx.pl line 48.
Click to expand...
Click to collapse
I am getting the same error. I am running this script on windows 7. My phone is based on MT6516.
ajparag said:
I am getting the same error. I am running this script on windows 7. My phone is based on MT6516.
Click to expand...
Click to collapse
Dude Check whether you have installed perl packages for cygwin properly
bgcngm said:
Simple... let's say you unpack a boot.img:
Code:
unpack-MT65xx.pl boot.img
This extracts the kernel (it will be named boot.img-kernel.img) and the ramdisk folder (it will be named boot.img-ramdisk).
In order to repack, you should run:
Code:
repack-MT65xx.pl boot.img-kernel.img boot.img-ramdisk new-boot.img
If you are repacking a recovery.img, then it should be:
Code:
repack-MT65xx.pl -recovery recovery.img-kernel.img recovery.img-ramdisk new-recovery.img
Click to expand...
Click to collapse
Thanks for sharing. Very useful.
varun.chitre15 said:
I m getting "can't exec "mkbootimg" : No such file or directory at ./repack-Mt65xx.pl line 66" error
Now?
Edit: Solved the error
Burned from my laser torch using pencil cells
Click to expand...
Click to collapse
give the binary execute permission, and move it to somewhere in the path:
sudo chmod a+x mkbootimg
sudo mv mkbootimg /bin
@OP
Real Gr8 job
For those people facing problems regarding the mkbootimg ,
Just that you need that binary compiled for your system
Here is for OS X (tested on 10.7.4) attached !
I just compiled form the Source
got from Internet ( lazy to boot that thing in Parallels )
for compiling !!
Source for Windows :
http://www.freeyourandroid.com/guide/extract-edit-repack-boot-img-windows
mkbootimg for OS X, Linux and Windows
Does any one need for Linux ?
ninadpchaudhari said:
Does any one need for Linux ?
Click to expand...
Click to collapse
The binary for Linux is already included in the 7zip file, along with the scripts.
MKBOOTIMG-TOOLS
MY GITHUB SOURCE:
https://github.com/ModdingMyMind/mkbootimg_tools
Original Author: xiaolu (GITHUB SOURCE: https://github.com/xiaolu/mkbootimg_tools)
Heavily Modified By: Modding.MyMind
This project is originally based from xiaolu. To make this compatible for ARM I modified the script, compiled some binaries such as file, bash, grep, gzip, lzma, xz, mkbootimg, etc.
-- This project uses busybox but due to how stripped and limited busybox is it ultimately led to me having to compile a few binaries from source. These binaries must be part of the project in order for the project to be successful. For example, busybox grep will not always give accurate offsets for the android header. One of MANY bugs found with busybox.
This project supports device tree binaries found inside the Boot.img and Recovery.img.
This project supports multiple Ramdisk compressions.
-- This project will check the ramdisk compression and if it determines that the tool does not support that particular compression then it will display a hazard warning letting the user know that the compression is not supported and that the ramdisk currently cannot be decompressed or compressed until support has been officially added.
-- If the compression is supported it will display what type of compression the Ramdisk is and how many blocks it has when unpacked.
This project will determine your kernel size, ramdisk size, and TRUE OFFSETS (not just the standard mkbootimg.c offsets).
-- With respect to the offsets; You will learn that many available tools found available specifically handle images where the ANDROID! header is located at 0x0. Not all images are built like this from stock. This project will find the header, base, kernel offset, ramdisk offset, second offset, and tags offset. It will rebuild the image using DD to insure the android header is located at 0x0. The found offsets inside the image will be cross referenced to see if the OEM of that image built it using the standard mkbootimg.c. If it detects any offsets which are built using NON-standard offsets then it will display a warning as well as show you what the image TRUE offsets actually are. Those same offsets are then applied to properly rebuild your image to insure that it boots like it was intended to do.
-- The warning will let you know that you may modify mkbootimg.c with the NON-standard values if you wish to have a binary specific to your device. The offsets displayed are not the address. Because the offsets are determined and not the address this makes it possible for this project to not have to rebuild mkbootimg.c. When the project is used to rebuild your image using the mkbootimg args such as --ramdisk_offset, --kernel_offsets, etc, etc, this then tells mkbootimg.c to ignore the hardcoded offsets and only use the ones it has been instructed to use. This is even more successful by insuring the BASE is accurate and applying the base as one of the mkbootimg args (--base 0 <-- this is lazy and stupid).
The mkboot script requires two args whether unpacking the image or repacking the image.
-- mkboot boot.img bootfolder (This will unpack the image)
1. mkboot is the script.
2. boot.img is the actual image.
3. bootfolder will be created and become the project folder.
-- mkboot bootfolder newboot.img (This will repack the image)
1. mkboot is the script.
2. bootfolder is the project folder which has the needed files and information to repack.
3. This will be the name of the finished build.
UNPACK STANDARD IMAGE
This image uses standard mkbootimg.c:
[email protected]:/data/local/tmp/mkbootimg_tools-master # ./mkboot boot.img work
Unpack & decompress boot.img to work
kernel : zImage
ramdisk : ramdisk
page size : 2048
kernel size : 2529072
ramdisk size : 230255
base : 0x12200000
kernel offset : 0x00008000
ramdisk offset : 0x01000000
second_offset : 0x00f00000
tags offset : 0x00000100
cmd line : mem=471M console=ttyMSM2,115200n8 androidboot.hardware=thunderc lge.rev=10
Ramdisk is lzma format.
1436 blocks
Unpack completed.
[email protected]:/data/local/tmp/mkbootimg_tools-master #
Click to expand...
Click to collapse
REPACK STANDARD IMAGE
Image repacked with standard mkbootimg.c:
[email protected]:/data/local/tmp/mkbootimg_tools-master # ./mkboot work boot.img
mkbootimg from work/img_info.
kernel : zImage
ramdisk : new_ramdisk.lzma
page size : 2048
kernel size : 2529072
ramdisk size : 230029
base : 0x12200000
kernel offset : 0x00008000
ramdisk offset : 0x01000000
tags offset : 0x00000100
cmd line : mem=471M console=ttyMSM2,115200n8 androidboot.hardware=thunderc lge.rev=10
Kernel size: 2529072, new ramdisk size: 230029, boot.img: 2762752.
boot.img has been created.
[email protected]:/data/local/tmp/mkbootimg_tools-master #
Click to expand...
Click to collapse
UNPACK NON-STANDARD IMAGE
This image uses non-standard mkbootimg.c:
[email protected]:/data/local/tmp/mkbootimg_tools-master # ./mkboot recovery.img work
Unpack & decompress recovery.img to work
****** WARNING ******* WARNING ******* WARNING ******
This image is built using NON-standard mkbootimg!
RAMDISK_OFFSET is 0x01608000
You can modify mkbootimg.c with the above value(s)
****** WARNING ******* WARNING ******* WARNING ******
kernel : zImage
ramdisk : ramdisk
page size : 2048
kernel size : 5834192
ramdisk size : 4351685
base : 0x80600000
kernel offset : 0x00008000
ramdisk offset : 0x01608000
second_offset : 0x00f00000
tags offset : 0x00000100
cmd line : console=ttyHSL0,115200,n8 user_debug=31
Ramdisk is gzip format.
14837 blocks
Unpack completed.
[email protected]:/data/local/tmp/mkbootimg_tools-master #
Click to expand...
Click to collapse
REPACK NON-STANDARD IMAGE
Image repacked with non-standard mkbootimg.c:
[email protected]:/data/local/tmp/mkbootimg_tools-master # ./mkboot work recovery.img
mkbootimg from work/img_info.
kernel : zImage
ramdisk : new_ramdisk.gzip
page size : 2048
kernel size : 5834192
ramdisk size : 4358038
base : 0x80600000
kernel offset : 0x00008000
ramdisk offset : 0x01608000
tags offset : 0x00000100
cmd line : console=ttyHSL0,115200,n8 user_debug=31
Kernel size: 5834192, new ramdisk size: 4358038, recovery.img: 10194944.
recovery.img has been created.
[email protected]:/data/local/tmp/mkbootimg_tools-master #
Click to expand...
Click to collapse
UNPACK IMAGE WITH INCOMPATIBLE RAMDISK
[email protected]:/data/local/tmp/mkbootimg_tools-master # ./mkboot boot-1.img work
Unpack & decompress boot-1.img to work
kernel : zImage
ramdisk : ramdisk
page size : 2048
kernel size : 3580032
ramdisk size : 594701
base : 0x10000000
kernel offset : 0x00008000
ramdisk offset : 0x01000000
second_offset : 0x00f00000
tags offset : 0x00000100
cmd line :
****** HAZARD ******* HAZARD ******* HAZARD ******
Ramdisk is data format. Can't unpack ramdisk.
This tool currently does not support data.
****** HAZARD ******* HAZARD ******* HAZARD ******
[email protected]:/data/local/tmp/mkbootimg_tools-master #
Click to expand...
Click to collapse
REPACK IMAGE WITH INCOMPATIBLE RAMDISK
[email protected]d:/data/local/tmp/mkbootimg_tools-master # ./mkboot work boot-1.img
mkbootimg from work/img_info.
****** HAZARD ******* HAZARD ******* HAZARD ******
Ramdisk is data format. Can't repack ramdisk.
This tool currently does not support data.
****** HAZARD ******* HAZARD ******* HAZARD ******
[email protected]:/data/local/tmp/mkbootimg_tools-master #
Click to expand...
Click to collapse
*Reserved*
If your boot.img and/or recovery.img is found to not be supported using this tool then please send me your boot.img and recovery.img so I may review it and determine if official support can be added. Thanks.
Add support for MediaTek Images:
-- Unpack and repack boot/recovery images.
-- Append proper headers to ramdisk when repacking.
-- Compiled mkimage to assist with the headers.
-- This support currently does not include the logo images at this time.
-- MT6516
-- MT65x3 (MT6513 and MT6573)
-- MT65x5 (MT6515 and MT6575)
-- MT6577
-- MT65x2 (MT6572 and MT6582)
-- MT6589
-- MT83xx (MT8377 and MT8389)
Modding.MyMind said:
If your boot.img and/or recovery.img is found to not be supported using this tool then please send me your boot.img and recovery.img so I may review it and determine if official support can be added. Thanks.
Click to expand...
Click to collapse
getting error
Code:
[email protected]:/ $ su
/mkbootimg_tool/ARM <
/mkboot boot.img h3ll <
<Unpack and repack boot.img tool>
----------------------------------------------------------------------
Not enough parameters or parameter error!
unpack boot.img & decompress ramdisk
mkboot [img] [output dir]
mkboot boot.img boot20130905
^[[?1;2cUse the unpacked directory repack boot.img(img_info)
mkboot [unpacked dir] [newbootfile]
mkboot boot20130905 newboot.img
^[[?1;[email protected]:/data/local/tmp/mkbootimg_tool/A;2c1;2c <
sh: 1: not found
sh: 2c1: not found
sh: 2c: not found
127|[email protected]:/data/local/tmp/mkbootimg_tool/ARM #
H3LL said:
getting error
Code:
[email protected]:/ $ su
/mkbootimg_tool/ARM <
/mkboot boot.img h3ll <
----------------------------------------------------------------------
Not enough parameters or parameter error!
unpack boot.img & decompress ramdisk
mkboot [img] [output dir]
mkboot boot.img boot20130905
^[[?1;2cUse the unpacked directory repack boot.img(img_info)
mkboot [unpacked dir] [newbootfile]
mkboot boot20130905 newboot.img
^[[?1;[email protected]:/data/local/tmp/mkbootimg_tool/A;2c1;2c <
sh: 1: not found
sh: 2c1: not found
sh: 2c: not found
127|[email protected]:/data/local/tmp/mkbootimg_tool/ARM #
Click to expand...
Click to collapse
Check the permissions, check that bash is placed at /system/xbin, and insure the image you are trying to unpack is in the same directory where the mkboot script is located or else, insure you specify the image path properly.
If it still errors out insure your device is ARM and compatible for the project. If yes, then at the top of the script will be; #set -x. Uncomment it and run the script again, then copy and paste it's output here.
Also, send me your image to download and verify on my end. Thanks.
Modding.MyMind said:
Check the permissions, check that bash is placed at /system/xbin, and insure the image you are trying to unpack is in the same directory where the mkboot script is located or else, insure you specify the image path properly.
If it still errors out insure your device is ARM and compatible for the project. If yes, then at the top of the script will be; #set -x. Uncomment it and run the script again, then copy and paste it's output here.
Also, send me your image to download and verify on my end. Thanks.
Click to expand...
Click to collapse
tried same output as above here's boot.IMG
H3LL said:
tried same output as above here's boot.IMG
Click to expand...
Click to collapse
Your image doesn't have an android header. It's elf. This tool currently doesn't support it but now that I have your boot.img I can see about adding support. Can you send me your recovery image as well so I may verify that the process is the same for both when unpacking and repacking. Some images such as MediaTek have different headers for the ramdisk depending on whether it's the boot or recovery and so I would like to confirm the same with yours as well. Thanks.
Edit: Also, this tool won't work on your device unless the binaries are compiled from source for your machine. It's currently for ARM, but your device won't play nice with it.
Modding.MyMind said:
Your image doesn't have an android header. It's elf. This tool currently doesn't support it but now that I have your boot.img I can see about adding support. Can you send me your recovery image as well so I may verify that the process is the same for both when unpacking and repacking. Some images such as MediaTek have different headers for the ramdisk depending on whether it's the boot or recovery and so I would like to confirm the same with yours as well. Thanks.
Edit: Also, this tool won't work on your device unless the binaries are compiled from source for your machine. It's currently for ARM, but your device won't play nice with it.
Click to expand...
Click to collapse
there is no recovery. img for this device (its not mediatek) its in ramdisk of the boot.img....yeah my device is ARM
H3LL said:
there is no recovery. img for this device (its not mediatek) its in ramdisk of the boot.img....yeah my device is ARM
Click to expand...
Click to collapse
Reviewed the binaries and somehow overlooked a few after compiling them. Some aren't even true static when I originally thought I did compile them as such. There are also some which are true static but focus on either hard floats or soft floats. So, I need to go back and recompile the ones which stood out and push them to my repo. This may very well be why it isn't playing fair on your Sony device.
With that said, adding support for your image is gonna be a bit complicated to write out in bash since it is very involved lol. However, I am gonna make an attempt by taking on the challenge and seeing if I can get it done .
The github account doesn't exist anymore and there's no download link?
[null]
how to compile this for windows
I can't use one over the other because I need gamepass cuz Iwant to save money on hardware not buy games on steam but also i need linux because bash is miles better than some IDE which takes up 30 gb at minimum
I assume you are a ROM builder. When your device vendor continue violate the GPL, refuse to open the device kernel source, let's we reverse engineering our device stock kernel.
Dedicated to ex Google Hugo Barra. Ends up as a GPL violator a pretty miserable.
Tools:
Python tool csplitb https://github.com/mypalmike/csplitb
dtc binary from out/target/product/<device>/obj/KERNEL_OBJ/scripts/dtc
unpackbootimg from out/host/linux-x86/bin
extract-ikconfig from kernel/<vendor>/<device>/scripts
Copy all needed tools to your PATH, $HOME/bin/
Steps:
Unpack stock boot.img using unpackbootimg:
Code:
$ mkdir boot
$ cd boot
$ unpackbootimg -i ../boot.img -o .
Split DT image to DTB files, for MSM8916 in this example:
Code:
$ mkdir dtb
$ cd dtb
$ csplitb.py --prefix msm8916- --suffix .dtb --number 4 D00DFEED ../boot.img-dt
Find proper DTB file for your device, device model "Qualcomm Technologies, Inc. MSM 8916 QRD SKUM" string from my device dmesg output in this example:
Code:
$ grep -r "QRD SKUM"
Binary file msm8916-0011.dtb matches
Convert DTB to DTS files:
Code:
$ dtc -I dtb -O dts -o ../msm8916-0011.dts msm8916-0011.dtb
$ cd ../
Extract kernel config
Code:
extract-ikconfig boot.img-zImage > msm8916_defconfig
This how to success story: http://forum.xda-developers.com/android/development/rom-cyanogenmod-unofficial-builds-t3200883
RESERVED.
what is use of convert DTB TO DTS
ela1103 said:
what is use of convert DTB TO DTS
Click to expand...
Click to collapse
Reconstruct a closed source kernel or vendor kernel update not in sync to their open source version or vendor DTS completely not available, prepared outside the kernel source.
Amazing! Hope Hugo Barra stumbles upon this post!
Nice Ketut! I love the way you live OpenSource!
guys, someone can send me dtc binary for me please? I extrcting the boot img of mtk device and I dont have the dtc binary
Thanks and sorry fir my bad english
Thanks for sharing this. :highfive:
Do you know any way to circumvent lz4 zImage compression? Trying to do it for Xiaomi Mi 5.
@ketut.kumajaya What if my boot.img does not have any dt files. My boot.img-dt is 0 bytes and the error prints this:
Traceback (most recent call last):
File "/home/nick/bin/csplitb.py", line 64, in <module>
main()
File "/home/nick/bin/csplitb.py", line 61, in main
return csplitb.run()
File "/home/nick/bin/csplitb.py", line 26, in run
self.mm = mmap.mmap(f.fileno(), 0)
ValueError: cannot mmap an empty file
Halp
For anyone that may need, another way to split appended dtbs is by using this tool.
i have only stock boot and recovery how to unpack in decompile plz upload video your tutroial
@ketut.kumajaya on step 2 you using this value D00DFEED, and what is that value mean? Is that value for dtb header or what? Can u explain sir, thanks
Guizão BR said:
guys, someone can send me dtc binary for me please? I extrcting the boot img of mtk device and I dont have the dtc binary
Thanks and sorry fir my bad english
Click to expand...
Click to collapse
Sometimes device tree binaries live in a separate partition. That's sort of the idea behind a device tree - it's just that the bindings on ARM are so in flux that keeping a static device tree embedded in "firmware" becomes impractical, and so vendors will ship a kernel with a device tree (or a bundle of device trees) appended to it.
You can get the 'dtc' binary by installing the 'device-tree-compiler' package on Ubuntu, or just use 'kernel/scripts/dtc' if you've got a kernel built.
zainifame said:
@ketut.kumajaya on step 2 you using this value D00DFEED, and what is that value mean? Is that value for dtb header or what? Can u explain sir, thanks
Click to expand...
Click to collapse
Instead of using that tool, use this one, it requires no arguments - https://github.com/dianlujitao/split-appended-dtb.
Hope it helps
Can anyone explain to me, how to extract touchscreen firmware from kernel binary? Thanks
This is in relation to this and my post on xda.
The main reason I want to make a custom kernel is to gain root and once I successfully have then add other CPU governors, and since this is considered a low activity device on xda I will have to do this myself. Also I you are just gonna say use twrp to flash SuperSU, well I can't as it seems to not work with the device when its running Lollipop 5.1.1
Device Specifications:
Current Android Version: Android Lollipop 5.1.1
Chipset: Marvell Armada PXA1908 (Note: Due to this being a rarely used chip, the CF-Auto root won't work)
Custom Recovery Status: TWRP 3.0.2-0 (More on this later on)
Root Status (This is why I am here): Android KitKat 4.4.4 (Root) , Android Lollipop 5.1.1 (NO ROOT Yet)
ARMv8 64-bit
Now let's get into my steps up to the point and then my problem.
Note: In the kernel readme it states to use the toolchain 4.8 but when I use it, it complains of not being able to find gcc. Also in the read me it states "get Toolchain download and install arm-eabi-4.8 toolchain for ARM EABI.(64bit)" and when reading up on it, https://developer.android.com/ndk/guides/standalone_toolchain.html#syt , it says to use aarch64 for ARM 64 Bit devices.
Device Source Code can be found at Here
Code:
cd ~/android
export CROSS_COMPILE=~/android/ndk/toolchains/aarch64-linux-android-4.9/prebuilt/linux-x86_64/bin/aarch64-linux-android-
cd ~/android/kernel
make ARCH=arm64 pxa1908_xcover3lte_eur_defconfig
make ARCH=arm64
This outputs: Image, Image.gz, .dts and .dtb files.
Where's the kernel readme (I believe this hasn't been update since kitkat) says the output will be,
- Kernel : Kernel/arch/arm/boot/zImage
- module : Kernel/drivers/*/*.ko
Note: when trying to compile with the 32- bit ARM toolchain it fails, as the config is found in arm64, wheres other configs are found in arm.
So know I have a kernel (Image or Image.gz), and some .dts and .dtb files. Now to unpack boot.img, this is where problems occur. When trying to use tools like abootimg or the various different versions of unmkbootimg, they complain about non-standard boot.img.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
or
While also try saving it as a zImage when its meant to be a Image.gz, or they extract it without throwing any errors, but when looking at the extracted files with a hex editor, it is all 00 throughout the files, therefore a useless file.
So their for I tried manually unpacking with a hex editor and managed to get the kernel. Left is my Compiled and Right is the hex version.
Notice the difference in size, is this because the kernel in boot.img is stripped of its debugging items while mine isn't? If so I should look up on how to fix that.
But am having troubles trying to extract the ramdisk via hex.
So is anyone able to either:
a) Help me extract the boot.img properly (with tools like unmkbootimg or with a hex editor)
or
b) do this for me and explain how you achieved it so I myself is am able to do it when needed.
I have attached necessary files if you want to have a look at them yourself.
Any help is appreciated.
FIles(XDA attachments not working): https://drive.google.com/file/d/0B_5mtquWAP3MZjJQay1ERFprbnM/view?usp=sharing
After Numerous trial and error, I finally managed to output ramdisk.cpio.gz.
The start of a Gzip file in hex is, 1F 8B 08, therefor when using the search function in you had editor application you can narrow down your results to 1 or 2 files (2 Files for me as my kernel and ramdisk are both gzipped). You then follow it all the way down till you find a big bunch of zeros(seems like they are passing between files). When you reach the bunch of zeros include the first "00" at the end of the other hexidecial. E.G. End of one of my gzip files is "CE 24 00 00 00....00 (ZERO PADDING BETWEEN FILES), Threaded the end of my file is "CE 24 00".
Knowing this I was able to successfully extract and verify both my kernel and ramdisk files are correct.
Perl script for unpacking
Code:
#!/usr/bin/perl
######################################################################
#
# File : split_bootimg.pl
# Author(s) : William Enck <[email protected]>
# Description : Split appart an Android boot image created
# with mkbootimg. The format can be found in
# android-src/system/core/mkbootimg/bootimg.h
#
# Thanks to alansj on xda-developers.com for
# identifying the format in bootimg.h and
# describing initial instructions for splitting
# the boot.img file.
#
# Last Modified : Tue Dec 2 23:36:25 EST 2008
# By : William Enck <[email protected]>
#
# Copyright (c) 2008 William Enck
#
######################################################################
use strict;
use warnings;
# Turn on print flushing
$|++;
######################################################################
## Global Variables and Constants
my $SCRIPT = __FILE__;
my $IMAGE_FN = undef;
# Constants (from bootimg.h)
use constant BOOT_MAGIC => 'ANDROID!';
use constant BOOT_MAGIC_SIZE => 8;
use constant BOOT_NAME_SIZE => 16;
use constant BOOT_ARGS_SIZE => 512;
# Unsigned integers are 4 bytes
use constant UNSIGNED_SIZE => 4;
# Parsed Values
my $PAGE_SIZE = undef;
my $KERNEL_SIZE = undef;
my $RAMDISK_SIZE = undef;
my $SECOND_SIZE = undef;
my $DT_SIZE = undef;
######################################################################
## Main Code
&parse_cmdline();
&parse_header($IMAGE_FN);
=format (from bootimg.h)
** +-----------------+
** | boot header | 1 page
** +-----------------+
** | kernel | n pages
** +-----------------+
** | ramdisk | m pages
** +-----------------+
** | second stage | o pages
** +-----------------+
**
** n = (kernel_size + page_size - 1) / page_size
** m = (ramdisk_size + page_size - 1) / page_size
** o = (second_size + page_size - 1) / page_size
** p = (dt_size + page_size - 1) / page_size
**
** 0. all entities are page_size aligned in flash
** 1. kernel and ramdisk are required (size != 0)
** 2. second is optional (second_size == 0 -> no second)
** 3. load each element (kernel, ramdisk, second) at
** the specified physical address (kernel_addr, etc)
** 4. prepare tags at tag_addr. kernel_args[] is
** appended to the kernel commandline in the tags.
** 5. r0 = 0, r1 = MACHINE_TYPE, r2 = tags_addr
** 6. if second_size != 0: jump to second_addr
** else: jump to kernel_addr*/
=cut
my $n = int(($KERNEL_SIZE + $PAGE_SIZE - 1) / $PAGE_SIZE);
my $m = int(($RAMDISK_SIZE + $PAGE_SIZE - 1) / $PAGE_SIZE);
my $o = int(($SECOND_SIZE + $PAGE_SIZE - 1) / $PAGE_SIZE);
my $p = int(($DT_SIZE + $PAGE_SIZE - 1) / $PAGE_SIZE);
my $k_offset = $PAGE_SIZE;
my $r_offset = $k_offset + ($n * $PAGE_SIZE);
my $s_offset = $r_offset + ($m * $PAGE_SIZE);
my $t_offset = $s_offset + ($o * $PAGE_SIZE);
(my $base = $IMAGE_FN) =~ s/.*\/(.*)$/$1/;
my $k_file = "kernel.gz";
my $r_file = "ramdisk.gz";
my $s_file = "second.gz";
my $t_file = "dt.img";
# The kernel is always there
print "Writing $k_file ...";
&dump_file($IMAGE_FN, $k_file, $k_offset, $KERNEL_SIZE);
print " complete.\n";
# The ramdisk is always there
print "Writing $r_file ...";
&dump_file($IMAGE_FN, $r_file, $r_offset, $RAMDISK_SIZE);
print " complete.\n";
# The Second stage bootloader is optional
unless ($SECOND_SIZE == 0) {
print "Writing $s_file ...";
&dump_file($IMAGE_FN, $s_file, $s_offset, $SECOND_SIZE);
print " complete.\n";
}
# The DT.img stage is optional
unless ($DT_SIZE == 0) {
print "Writing $t_file ...";
&dump_file($IMAGE_FN, $t_file, $t_offset, $DT_SIZE);
print " complete.\n";
}
######################################################################
## Supporting Subroutines
=header_format (from bootimg.h)
struct boot_img_hdr
{
unsigned char magic[BOOT_MAGIC_SIZE];
unsigned kernel_size; /* size in bytes */
unsigned kernel_addr; /* physical load addr */
unsigned ramdisk_size; /* size in bytes */
unsigned ramdisk_addr; /* physical load addr */
unsigned second_size; /* size in bytes */
unsigned second_addr; /* physical load addr */
uint32_t dt_size; /* device tree size in bytes */
uint32_t dt_addr; /* device tree address in bytes */
unsigned tags_addr; /* physical addr for kernel tags */
unsigned page_size; /* flash page size we assume */
unsigned char name[BOOT_NAME_SIZE]; /* asciiz product name */
unsigned char cmdline[BOOT_ARGS_SIZE];
unsigned id[8]; /* timestamp / checksum / sha1 / etc */
};
=cut
sub parse_header {
my ($fn) = @_;
my $buf = undef;
open INF, $fn or die "Could not open $fn: $!\n";
binmode INF;
# Read the Magic
read(INF, $buf, BOOT_MAGIC_SIZE);
unless ($buf eq BOOT_MAGIC) {
die "Android Magic not found in $fn. Giving up.\n";
}
# Read kernel size and address (assume little-endian)
read(INF, $buf, UNSIGNED_SIZE * 2);
my ($k_size, $k_addr) = unpack("VV", $buf);
# Read ramdisk size and address (assume little-endian)
read(INF, $buf, UNSIGNED_SIZE * 2);
my ($r_size, $r_addr) = unpack("VV", $buf);
# Read second size and address (assume little-endian)
read(INF, $buf, UNSIGNED_SIZE * 2);
my ($s_size, $s_addr) = unpack("VV", $buf);
# Read dt size and address (assume little-endian)
read(INF, $buf, UNSIGNED_SIZE * 2);
my ($t_size, $t_addr) = unpack("VV", $buf);
# Ignore tags_addr
read(INF, $buf, UNSIGNED_SIZE);
# get the page size (assume little-endian)
read(INF, $buf, UNSIGNED_SIZE);
my ($p_size) = unpack("V", $buf);
# Read the name (board name)
read(INF, $buf, BOOT_NAME_SIZE);
my $name = $buf;
# Read the command line
read(INF, $buf, BOOT_ARGS_SIZE);
my $cmdline = $buf;
# Ignore the id
read(INF, $buf, UNSIGNED_SIZE * 8);
# Close the file
close INF;
# Print important values
printf "Page size: %d (0x%08x)\n", $p_size, $p_size;
printf "Kernel size: %d (0x%08x)\n", $k_size, $k_size;
printf "Ramdisk size: %d (0x%08x)\n", $r_size, $r_size;
printf "Second size: %d (0x%08x)\n", $s_size, $s_size;
printf "dt size: %d (0x%08x)\n", $t_size, $t_size;
printf "Board name: $name\n";
printf "Command line: $cmdline\n";
# Save the values
$PAGE_SIZE = $p_size;
$KERNEL_SIZE = $k_size;
$RAMDISK_SIZE = $r_size;
$SECOND_SIZE = $s_size;
$DT_SIZE = $t_size;
}
sub dump_file {
my ($infn, $outfn, $offset, $size) = @_;
my $buf = undef;
open INF, $infn or die "Could not open $infn: $!\n";
open OUTF, ">$outfn" or die "Could not open $outfn: $!\n";
binmode INF;
binmode OUTF;
seek(INF, $offset, 0) or die "Could not seek in $infn: $!\n";
read(INF, $buf, $size) or die "Could not read $infn: $!\n";
print OUTF $buf or die "Could not write $outfn: $!\n";
close INF;
close OUTF;
}
######################################################################
## Configuration Subroutines
sub parse_cmdline {
unless ($#ARGV == 0) {
die "Usage: $SCRIPT boot.img\n";
}
$IMAGE_FN = $ARGV[0];
}
The reason why none of tools support our image is because it has different header format. For example mkbootimg:
Code:
unsigned tags_addr; /* physical addr for kernel tags */
unsigned page_size; /* flash page size we assume */
unsigned unused[2]; /* future expansion: should be 0 */
but we need for our kernel such a code
Code:
unsigned dt_size; /* device tree size in bytes */
unsigned dt_addr; /* device tree address in bytes */
unsigned tags_addr; /* physical addr for kernel tags */
unsigned page_size; /* flash page size we assume */
akuhak said:
Perl script for unpacking
The reason why none of tools support our image is because it has different header format. For example mkbootimg:but we need for our kernel such a code
Click to expand...
Click to collapse
Yes @akuhak I had realised that about a week ago (header sizes), also another thing is most of these tools deal with a zImage, where's I boot.img has a hOmage (which is a 64 byte uImage header followed by the kernel. I have succesfully unpacked this boot.img (the kernel, ramdisk and dt.img).
Now if this script works it will be good for other users, but for me my need has already been done.
I am just having trouble trying to get this booting up on my phone when I repack it (I haven't been paying to much attention to this project becuse of exam revision)
Edit: I have tested it and verified thatvit works by comparing the files produced by hand and the files produced by this script via the sha1sum command. I have uploaded it onto my xCover3 post linking back here and giving the credit to you for posting it here. Thanks for your help
It easier to found already existing tool. Our device (I am owning Xcover 3 too) has pxa1088 board. It is known that similar boards has similar structure. So i found these thread github(dot)com/kumajaya/degas-mkbootimg (he has also topic here in xda with his researchs)
It has the same board so these tools works fine for us The only difference I noticed - header unknown value is 0x03000000 for our device and 0x02000000 for Galaxy Tab 4. Maybe something wrong with dtb image - I didn't check these yet.
BTW our phone has same characteristics as Samsung SM-G531F Galaxy Grand Prime (same board, same cpu, same gpu, only screen a bit different) and grandprimevelte has 5.1.1 android onboard and working TWRP recovery (I was trying to flash it but was unsuccessful).
As for same board - For Example Xcover 3 Value Edition has completely different board (exynos3475 with mali-t760mp8 gpu). The same characteristics as for Samsung SM-J200 Galaxy J2. So we can use root methods from j2lte. This means - flash TWRP then install SuperSu zip archive - thats all.
But we cannot use TWRP from VE cause of very different hardwares.
Now Im working on improving degas utilities...
akuhak said:
It easier to found already existing tool. Our device (I am owning Xcover 3 too) has pxa1088 board. It is known that similar boards has similar structure. So i found these thread github(dot)com/kumajaya/degas-mkbootimg (he has also topic here in xda with his researchs)
It has the same board so these tools works fine for us The only difference I noticed - header unknown value is 0x03000000 for our device and 0x02000000 for Galaxy Tab 4. Maybe something wrong with dtb image - I didn't check these yet.
BTW our phone has same characteristics as Samsung SM-G531F Galaxy Grand Prime (same board, same cpu, same gpu, only screen a bit different) and grandprimevelte has 5.1.1 android onboard and working TWRP recovery (I was trying to flash it but was unsuccessful).
As for same board - For Example Xcover 3 Value Edition has completely different board (exynos3475 with mali-t760mp8 gpu). The same characteristics as for Samsung SM-J200 Galaxy J2. So we can use root methods from j2lte. This means - flash TWRP then install SuperSu zip archive - thats all.
But we cannot use TWRP from VE cause of very different hardwares.
Now Im working on improving degas utilities...
Click to expand...
Click to collapse
TWRP for xcover3 value editio came out about 7 says ago, and apparently one user has tried it and is working on their value edition version. (When I had a quick look at the source code yesterdau I happenend to notice it was a exynos board). I had previously tried the dagas scripts and they didn't work for our image at the time, yet your providerd version does. Great idea for searching up the board name (Marvell) as that is one of the only things I hadn't thought to Google.
Feel free to compile TWRP under android 5.1.1 branch. I can/will chime in with relevant info, as well as you can use info from TWRPs source code on the other twrp versions of our device. The only reason I haven't tried it as of yet is becuse i using my my mobile data 99% of the time and just don't have the data to so are downloading source code.
As for the dt.img, I veriefed the scripts output to my on manually extraction and it's the same for both files. (Sha1). But there is a little bit of trailing data (anything past SEANDROIDENFORCING) which is ignored, I am not sure id it's importance as of yet(other then SuperSu omits it from the boot.img when using SuperSu.zip.
Will pop back into here later today.
Ok I completed my tools collection for pxa1088
Source Code: github(dot)com/AKuHAK/pxa1088-mkbootimg
All necessary utilities can be achieved via my modified android_img_repack_tools repo: github(dot)com/AKuHAK/android_img_repack_tool
By just typing ./configure and make
If you are scared by traffic I released tools in one archive: github(dot)com/AKuHAK/android_img_repack_tools/releases/tag/1st.
How to use? I created README in github: github(dot)com/AKuHAK/pxa1088-mkbootimg/blob/master/README
Tools can extract and than pack back boot.img and recovery.img from XCover3. If you didn't extract uImage and dtb.img you can repack boot.img (recovery.img) without hash sum changes. If you extract zImage from uImage and than pack again in uImage your resulting uImage will be different cause uIimage header contain timestamp which will be taken from your PC settings. But resulting uImage still HAVE to be valid.
akuhak said:
Ok I completed my tools collection for pxa1088
Source Code: github(dot)com/AKuHAK/pxa1088-mkbootimg
All necessary utilities can be achieved via my modified android_img_repack_tools repo: github(dot)com/AKuHAK/android_img_repack_tool
By just typing ./configure and make
If you are scared by traffic I released tools in one archive: github(dot)com/AKuHAK/android_img_repack_tools/releases/tag/1st.
How to use? I created README in github: github(dot)com/AKuHAK/pxa1088-mkbootimg/blob/master/README
Tools can extract and than pack back boot.img and recovery.img from XCover3. If you didn't extract uImage and dtb.img you can repack boot.img (recovery.img) without hash sum changes. If you extract zImage from uImage and than pack again in uImage your resulting uImage will be different cause uIimage header contain timestamp which will be taken from your PC settings. But resulting uImage still HAVE to be valid.
Click to expand...
Click to collapse
Cool, will have a look tomorrow, it's hitting 1am for me now. Just one quick correction in the above post of yours. You mention zImage is extracted from the uImage. That is incorrect, is is in fact just a gzipped kernel image (Image.gz) not a zImage.
Yes I know both types of formats are compressed, but our device runs a armv8 cpu which is 64 bits (albeit our kernel is using a 32 but instruction set not a 64 bit instruction set and this means or OS is also 32 bits then). Apon reading the documentation found in the source code, you will realise that it can only handle a) the uncompressed kernel image (Image) or b) a compressed version of the image in gzip format (Image.gz). This is further proven when looking at the boot.img with a hex editor as you can clearly see 2 Files that start with the gzip header format (1F 8B 08) which are the gzipped kernel (also if you go back by 64 bytes then you will be at the start of the uImage header which holds or the appropriate info about the kernel.uImage file) and our ramdisk.
So hopefully you may have just made a mistake in the above post, but if not then you are outputting the incorrect file, which may confuse some users of they don't know much but just wanted to compile the kernel from source.
Sorry about the above rant, will now have a quick look at your github. Thanks for your work you have put into this phone.
Edit: when you mention the android img repack tools, did you use this, http://forum.xda-developers.com/showthread.php?t=2600364 , and if so what modification have you done since I already have the downloaded (used the last of my mobile data last month to get it)
EDIT2: Gonna have a mess around with them tomorrow. One question, sorry for sounding like a noon, but how does the compression differs between normal gzip and minigzip, how will these differences affect a repacked ramdisk and what got you onto that piece of info.
And I had a quick look at your github, seen all your ps2 back related source code.you using FMCB, a hardmod (a chip) or a internal hardrive via an Ethernet adapter. I see sp193, doctorxyz, have commuted to your repo, so sounds like your a ps2 dev, which is cool as ****
1) About zImage. Maybe I need to be more clear: Xcover 3 kernel has uImage onboard with gzip compression. You can extract kernel from that gzipped uImage - I just thought that zImage is name for extracted kernel Sorry if I made mistake in this case.
uImage can be created with use of u-boot tool (denx(dot)de/wiki/U-Boot/WebHome)
For example
Code:
mkimage -I boot.uImage
will provide such an information for our device
Code:
Image Name: pxa1928dkb linux
Created: Wed May 18 15:13:06 2016
Image Type: AArch64 Linux Kernel Image (gzip compressed)
Data Size: 6616640 Bytes = 6461.56 kB = 6.31 MB
Load Address: 01000000
Entry Point: 01000000
This information is extracted from uImage kernel (64 bytes). After header we will see our gzipped kernel - you are right. I just simply extracted it with 7zip from boot.img-uImage.
The difference is that your way didn't use uImage header at all - so you will be unable to pack it back without mistakes - or your gzipped kernel have to be completely the same in size which is almost impossible to achieve. With use of mkimage you can alter kernels (of course only if samsung doesnt check something else) and get correct uImage in output.
2) About difference between minigzip and gzip. In fact I don't know why its happened but I didn't found a reason why ramdisk have to be packed exactly with minigzip. I tried almost all flag combinations with gzip but I get the same result that was in output file only with minigzip
As about kernel it is packed with maximum compression without name with normal gzip.
So assuming minigzip for ramdisk, gzip -n -9 for kernel. But Im completely sure that we can use any combination of gzipers and image still will be valid (but of course will be different in hash). We need to use exactly this combination only if we need to get the same file.
3) Yes Im using exactly this kitchen - I just removed all branches except 5.1.1 added minigzip, my tools and u-boot mkimage tool generation.
4) Yes Im one of still alive ps2 developers I just realized that my phone isn't rooted and started to dig what I can do with it.
akuhak said:
1) About zImage. Maybe I need to be more clear: Xcover 3 kernel has uImage onboard with gzip compression. You can extract kernel from that gzipped uImage - I just thought that zImage is name for extracted kernel Sorry if I made mistake in this case.
uImage can be created with use of u-boot tool (denx(dot)de/wiki/U-Boot/WebHome)
For example will provide such an information for our device
This information is extracted from uImage kernel (64 bytes). After header we will see our gzipped kernel - you are right. I just simply extracted it with 7zip from boot.img-uImage.
The difference is that your way didn't use uImage header at all - so you will be unable to pack it back without mistakes - or your gzipped kernel have to be completely the same in size which is almost impossible to achieve. With use of mkimage you can alter kernels (of course only if samsung doesnt check something else) and get correct uImage in output.
2) About difference between minigzip and gzip. In fact I don't know why its happened but I didn't found a reason why ramdisk have to be packed exactly with minigzip. I tried almost all flag combinations with gzip but I get the same result that was in output file only with minigzip
As about kernel it is packed with maximum compression without name with normal gzip.
So assuming minigzip for ramdisk, gzip -n -9 for kernel. But Im completely sure that we can use any combination of gzipers and image still will be valid (but of course will be different in hash). We need to use exactly this combination only if we need to get the same file.
3) Yes Im using exactly this kitchen - I just removed all branches except 5.1.1 added minigzip, my tools and u-boot mkimage tool generation.
4) Yes Im one of still alive ps2 developers I just realized that my phone isn't rooted and started to dig what I can do with it.
Click to expand...
Click to collapse
1) yes a zImage is one type of you can get when compiling for ARM Devices, you Device is ARM64 so thierare differences. As for extracting the kernel I have always include the 64 byte header (since the middle of last week when I realised that it was there after running binwalk against the file). So yea your assumption was correct up untill a week ago.
2) Interesting. I will be sure to make changes accordingly.
3) cool I have 2 out of four so will download accordingly
4) cool, that the development scene is still going since the ps2 reached it 16 birthday this year.
5) as for root on this device chainfire has needed to go Systemless after/on 6.0 device or 5.1.1. Samsung devices, so to achive root on those devices it requires the modification of boot.img. what his SuperSu.zip does is patch the sepolicy file to allow 3 rules to run in permissive, modify other bits of the ramdisk accordingly to allow for it to run services and mount su.img at boot and it creates and place the necessary files inside su.img. I have completed all that by hand after reading his update-script numerous times. My only roadblock has been try to get the boot.img to boot.I was currently in the process, of try (I have tried alot of different ways including mkbootimg etc.) Manuallying replacing the ramdisk contents with the modified version, and then modify the bootmimg header to continue any modifed value (ramdisk size and dt offset) but am only partially done as I haven't had the chance the last few days to do it.
Awesome tool, unpack, repacked without a single modification and then ran "sha1sum" to both boot.img's and they are exactly the same. You are amazing . I have referenced your tools in this thread (http://forum.xda-developers.com/android/development/4-4-4-5-1-1-6-0-1-samsung-xcover3-t3465132 ) straight to your github. Now to try my modified ramdisk and see If my phone can boot it. Will post results soon.
======
Yes I can boot custom boot.img, without the SEANDORIDENFORCEING showing up. I can see my ramdisk changes, work, I can type adb root and I don't get the product in build message, but trying to do anything that requires root e.g. trying to push su.img to /data or /cache, gets me the error permission denied, but hey I am half way there to getting root.
A youtube video on this guide
Watch video
Hello guys,
I rarely write guide and tutorials .so neglect my typos and gramatical mistakes
Today im gonna show you how to unpack sparsed system.img files (system_1.img+system_2.img+............+system_*.img)
supports system / cache / userdata / persist / vendor / cust / odm /oem partitions from QFIL firmwares
Lets get started
LINUX
Things Needed:
1) Packsparseimg
2) Imgextractor.exe -Need wine for this
Procedure:
1) First of all extract you device firmware in which you have sparse system.img files in a folder.
(folder path ex:~/Desktop/firmware)
2) Copy the downloaded packsparseimg_v1.1 and Imgextractor.exe in the same folder where you extracted your firmware
(ex:~/Desktop/firmware)
3) Open terminal and enter below commands.
4)
Code:
chmod 0755 packsparseimg_v1.1
5)This command will pack sparse system_1.img....files to system.raw
Code:
./packsparseimg_v1.1
you can use these commands to pack sparse cache and userdata persist,vendor,cust,odm partitions
Code:
Usage of ./packsparseimg_v1.1:
-o string
output dir path (default "./")
-t string
image to unsparse: system / cache / userdata / persist / vendor / cust / odm / oem (default "system")
-x string
xml file to load (default "./rawprogram_unsparse.xml")
6) After joining of sparse system.img's finishes you will get system.raw file
7) Use below commands to unpack system.raw to system folder
Note: You need wine on your linux to run imgextractor.exe
Code:
wine imgextractor.exe system.raw
8) Hell Yeah! you have successfully unpack those system_1,2,3,4....imgs
now you can make your own stock deodexed rom
Downloads For linux:-
[MOD EDIT: URL REMOVED]
Password:innfinite4evr
Imgextractor.exe
WINDOWS
Things Needed:
1) packsparseimg_v1.1
2) Imgextractor.exe
Procedure:
1) First of all extract you device firmware in which you have sparse system.img files in a folder.
(folder path exesktop/Myfirmware)
2) Copy the downloaded packsparseimg_v1.1 and Imgextractor.exe in the same folder where you extracted your firmware
(exesktop/Myfirmware)
3) Open Command Prompt (cmd.exe) and enter below commands.
PS: you can open command propmt by any of these methods. Here method 1 is preferred
Method 1: Most suitable method for this guide
hold down shift key while pressing the right mouse onto the folder you want to open "command prompt" then a new menu item will appear in your context menu offering you exactly that: "open command prompt here" select it and command prompt will open.
Method 2:Search is very helpful. In Windows 7, open the Start Menu and type command or cmd. Then, click or tap the Command Prompt
Method 3ne of the quickest ways to launch the Command Prompt is to use the Run window (press Win+R on your keyboard and type cmd and press enter to open it).
i guess three methods are enough for windows users
4) AFter command prompt opens enter below comamnds to proceed further
5)This command will pack sparse system_1.img....files to system.raw
Note default is "system"
Code:
packsparseimg
you can use these commands to pack sparse cache and userdata persist,vendor,cust,odm partitions
Code:
Usage of packsparseimg:
-o string
output dir path (default "./")
-t string
image to unsparse: system / cache / userdata / persist / vendor / cust / odm (default "system")
-x string
xml file to load (default "./rawprogram_unsparse.xml")
6) After joining of sparse system.img's finishes you will get system.raw file
7) Use below commands to unpack system.raw to system folder
Code:
imgextractor.exe system.raw
8) Now you will get unpacked system folder
Hell Yeah! you have successfully unpack those system_1,2,3,4....imgs
now you can make your own stock deodexed rom
Downloads for windows:-
Imgextractor.exe
Password:innfinite4evr
[MOD EDIT: URL REMOVED]
Changelog:-
in update v1.1
now supports system / cache / userdata / persist / vendor / cust / odm /oem partitions from QFIL firmwares
Credits:
kidd for initially making packsparseimg binary
@and_pDA for imgextractor,exe(Based on sources ext4_unpacker)
@Innfinite4evr for testing this method and write this guide
Great work bro :good: Nice job and thanks for this
great work man. thanks
can you share code?
There is another way to unpacj that instead of using wine.
Code:
mount -o loop -t ext4 system.img [path]
Replace:
[Path] with path to the output directory you want (ex: ~/sys-img)
ext4: This might be different, check it by yourself, but most device now using ext4
Thanks for the info, btw
Please can somebody tell me how to revert the process? To create again sparse images and flash via qfil? Thanks in advance!
cofface said:
can you share code?
Click to expand...
Click to collapse
only prebuilts
cofface said:
can you share code?
Click to expand...
Click to collapse
only prebuilts
I get this error on Ubuntu:
bash: ./packsparseimg: cannot execute binary file: Formato eseguibile non valido
What is the procedure to do the reverse?
How to repack as parts
sir i was trying to repack system folder to system_1.img system_2.img etc.
is there any way for that?
i need to repack and flash to my phone
Doesn't seem to work for Oreo a/b system
@Innfinite4evr Hi there, can you add vendor, cust and odm support ?
AL_IRAQI said:
@Innfinite4evrHi there, can you add vendor, cust and odm support ?
Click to expand...
Click to collapse
Yes there is.
Im thinking to update this stuff
AL_IRAQI said:
@Innfinite4evrHi there, can you add vendor, cust and odm support ?
Click to expand...
Click to collapse
Ive updated the tool, maybe you can try for odm partition.
Innfinite4evr said:
Ive updated the tool, maybe you can try for odm partition.
Click to expand...
Click to collapse
I've try to buy, with all my2 credit card (master card and american express)
I was addebited 1€ in my mastercard, but it always give me error and I can't download the program.
I do not want the refund, I'd like to have the tool!
Samuele Bonzio
I give you my phone number by PM if that need!
Thank you!
Thread closed. PM me when you have download links that don't require payment to be added to the OP.