Database Info

[SCRIPTS] Unpack / repack MT65xx/MT83xx boot.img, recovery.img or logo.bin

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.

[Q] "FAILED (remote: dtb not found)" error when flashing image on Xperia Z3

Hello,
I am facing error when flashing image on Xperia Z3. I rooted the device using the link posted on "theunlockr.com"
Now, I am trying to flash a new image on the device. I am extracting the exisiting image from the device, modifying the init.rc file and repacking the image (myboot.img) and then flashing it using fastboot method. This is when it gives me this error.
When I flash the original image that I extracted, it works fine.
I tried following methods: -
1. Changing init.rc file and repacking the .img file and flashing it
When I extract initrd.img (using abootimg), it shows me only these files ( I usually find init.rc file when I extract initrd.img but not in this device, is this expected?): -
- XZ3-AdvStkKernel_DooMLoRD_ramdisk.gz
- logo.rle
- init (linking to sbin/init.sh)
- sbin/bootrec-device
- sbin/ramdisk-recovery-cwm.cpio
- sbin/busybox
- sbin/ramdisk.cpio
- sbin/init.sh
I extracted sbin/ramdisk.cpio file to get the init.rc file using the command: -
cpio -idmv < ramdisk.cpio
After modifying the init.rc file, I repacked the cpio file using the command: -
ls | cpio -ov > ramdisk.cpio
I made sure that none of the extra stuff was not there in the folder before repacking the cpio file.
Now that my ramdisk.cpio file is updated, I created new image using the command: -
find . | cpio -o -H newc | gzip -9 > ../newramdisk.cpio.gz
and created myboot.img using abootimg
When I flashed this image file, I get the "dtb not found" error
2. Second method that I tried was I simply unpacked the boot.img (original image) and repacked it using abootimg in to myboot.img without changing anything.
This also gives the same error.
It looks like there is some issue with the unpacking and repacking of the boot image.
Is there any other way to resolve this issue?

asurion.acc said:
Is there any other way to resolve this issue?
Click to expand...
Click to collapse
use this instruction and tools, but when you will build your boot.img, use this cmd line
Code:
./mkbootimg --base 0x00000000 --kernel zImage --ramdisk_offset 0x02000000 --tags_offset 0x01E00000 --pagesize 2048 --cmdline "androidboot.hardware=qcom user_debug=31 msm_rtb.filter=0xb7 ehci-hcd.park=3 dwc3.maximum_speed=high dwc3_msm.prop_chg_detect=Y" --ramdisk ramdisk.cpio.gz --dt dt.img -o boot.img
with that instruction all work fine. I've tested many times

Thanks for replying to me.
I just want to modify init.rc file to add few lines. The only file that I see is ramdisk.cpio which contains init.rc. I unpacked it , modified it and repacked ramdisk.cpio. Instead of creating new dt.img, I directly flashed the new img file onto the device and that soft bricked the device. :crying: The steps that you suggested mentions creating a new kernel and creating a new dt.img. Do I need to do that even though I just need to modify just init.rc file?
At this point, I am just trying to unbrick the device using flash tool. I tried cwmrecovery but it did not work so trying flashing tool now. once its done, if it is necessary to create a new dt.img and new zImage using toolchains, I will use that method. Please let me know if you think that is the step that I am missing which caused the device to brick.
Thanks a lot.

UPDATE:
Device is unbricked.!
I just need to root it again and follow the steps that you mentioned. Please confirm if I need new ZImage and dt.img even if I just need to edit init.rc.
Thanks a lot.

[HOW TO] Convert back Qualcomm's DTB to DTS file, extract kernel config

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

[Samsung] Unpacking 'Non-Standard' Boot.img Problems for 64 Bit Device

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.

carliv image kitchen repack boot.img

Repack imageHello,
I trying to repack the boot.img with carliv_image_kitchen-linux64 (https://github.com/alexax66/carliv_image_kitchen)
And i got this error here:
Code:
Processing the boot folder.
Repacking the image....
The kernel is: ./boot.img-kernel
Getting the ramdisk compression....
Compression used:
Getting the image repacking arguments....
Base: 0x40078000
Pagesize: 2048
Command line: bootopt=64S3,32N2,64N2 buildvariant=user
Kernel offset: 0x00008000
Tags offset: 0x07808000
Device tree blob: ./boot.img-dt
Executing the repacking command....
Repack image utility by [email protected]
Check and add the kernel
Check and add the ramdisk
Error: could not load ramdisk ''
>> Exit script
Press any key to continue...
How can i Repack image ??? i have try root and no root.
Thanks for your time

Does this video help?