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

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.

Related

How to extract contents of *.img (boot/recovery/system/userdata) for adp1 on host

Hi,
After downloading the official image with android-1.5 (also known as
signed-dream_devphone_userdebug-img-150275.zip) for adp1 from the link
(http://www.htc.com/www/support/android/adp.html#s3) provided by HTC
and unzipping the image into someplace you want in the terminal, and
then four files with the same extension of .img will be got, as shown
below.
boot.img
recovery.img
system.img
userdata.img
Here's a discussion mainly focused on how to extract these contents of
the last two images for adp1 on host.
With respect to how to extract these contents of the first two images
for adp1 on host, please refer to the following link. Meanwhile,
thanks for the community efforts as well!!
http://forum.xda-developers.com/showthread.php?t=443994
http://android-dls.com/wiki/index.php?title=HOWTO:_Unpack,_Edit,_....
1> system.img
==> the unyaffs2 tool is used to extract the contents from system.img
on host.
For the tool, you can access its source code with the license of GPLv3
located at the link (http://code.google.com/p/unyaffs/) and download
the source code and its binary.
2> userdata.img
While using the aforementioned tool extracting these contents of
userdata.img, the contents fail to be got on host and just a message
of "end of image" is shown up in the terminal, as follows.
$ chmod a+x unyaffs
$ unyaffs userdata.img
end of image
So, the problem to be asked is about how to extract contents of
userdata.img for adp1 on host!!
Any input will be greatly appreciated!!
for the official rom, userdata should be empty isn't it?
You could flash userdata and then boot into recovery, mount data, and adb pull /data.
I'm also interested in extracting boot and recovery images, so any hints please post here
First off, thanks for your reply, billc.
As regards the issuse that if the image of userdata.img is empty, the two methods are taken, as follows. (so sorry that the below is too long. )
1. checking that with bash command in the terminal
$ ls -lh
total 57M
-rw-r--r-- 1 samuel samuel 1.6M 2009-01-01 00:00 boot.img
-rw-r--r-- 1 samuel samuel 1.8M 2009-01-01 00:00 recovery.img
-rw-r--r-- 1 samuel samuel 54M 2009-01-01 00:00 system.img
-rw------- 1 samuel samuel 2.1K 2009-07-02 08:23 userdata.img
With the first scenario, the size of "userdata.img" is shown as "2.1K", which seems to indicate that the image of "userdata.img" isn't empty, instead of with the size.
2. checing that with programs (unyaffs.c[1]/unyaff.h[2]) for the tool of "unyaffs"
[1]http://unyaffs.googlecode.com/files/unyaffs.c
[2]http://unyaffs.googlecode.com/files/unyaffs.h
(NOTE: the instruction of complicatioin is "gcc -o unyaffs unyaffs.c" with the version 4.2.4 of gcc)
After compiling, the executable tool is got in your directory, also known as "unyaffs". And then, type the instruction with the terminal below.
$ unyaffs userdata.img
end of image
Unfortunately, there is nothing out there after extracting contents of "userdata.img" with the size of "2.1K"(-the length really includes what contents?). Only a message of "end of image" is shown up with the terminal.
To get more information about the message of "end of image, therefore, diving into the C file used to generate the tool of "unyaffs", getting the following connents. Meanwhile, please also pay more attention to the lines with the bold.
int read_chunk()
{
ssize_t s;
int ret = -1;
memset(chunk_data, 0xff, sizeof(chunk_data));
s = read(img_file, data, CHUNK_SIZE + SPARE_SIZE);
if (s == -1) {
perror("read image file\n");
} else if (s == 0) {
printf("end of image\n");
} else if ((s == (CHUNK_SIZE + SPARE_SIZE))) {
ret = 0;
} else {
fprintf(stderr, "broken image file\n");
}
return ret;
}
And then, indexing the function in the Linux Programmer's Mannual with the command of "man read" in the terminal to get more info, as shown below. In the meantime, please pay more attention to the lines with the bold as well.
$man read
...
...
NAME
read - read from a file descriptor
SYNOPSIS
#include <unistd.h>
ssize_t read(int fd, void *buf, size_t count);
DESCRIPTION
read() attempts to read up to count bytes from file descriptor fd into
the buffer starting at buf.
If count is zero, read() returns zero and has no other results. If
count is greater than SSIZE_MAX, the result is unspecified.
RETURN VALUE
On success, the number of bytes read is returned (zero indicates end of
file), and the file position is advanced by this number.
...
...
Just judging from the combination of the snippet of "unyaffs.c" and the mannual of "read" above, the conclusion below can be come to.
The real contents of "userdata.img" with the size of "2.1k" is exactly empty ending up with "end of file".
When compared the two conclusions as mentioned above, it's found that the both are just contrary, the former ISN'T empty while the latter IS empty.
So, there are a set of problems about the above confusion herein.
Q1: What contents exactly does the "userdata.img" with the size of "2.1k" mean?
Q2: What contents and from which position does the function of "read" read in the file? In the case of "userdata.img", what are"what contents" and "from which position" respectively?
Q3: According to the above two scenarios, what steps to take are to judge if the file is really empty?
Looking forward to your replies, thanks!!
to jubeh,
As to extracting the images of boot and recovery from adp1/g1, you can refer to the following links. hope that that's helpful.
http://forum.xda-developers.com/showthread.php?t=443994
http://android-dls.com/wiki/index.php?title=HOWTO:_Unpack,_Edit,_and_Re-Pack_Boot_Images

[GUIDE][UTIL][MT65xx] Create Scatter File and Dump Full ROM

[GUIDE][UTIL][MT65xx] Create Scatter File / Dump Full ROM
For any MT65xx device, no matter how obscure.
I will discuss a method for:
* making your own SPFT scatter file
* dumping your entire ROM (without root)
* dicing up your entire ROM into partition blocks
This is somewhat of a manual process. rua1's MTK Droid Root & Tools circumvents the need for doing most of this. I applaude his work, it's a big undertaking and he supports it well.
Here are a few reasons to use the method I discuss here:
* you want a ROM dump without rooting
* you want a ROM dump without your OS booted (clone cold system is safe)
* you want a guaranteed way to restore exactly current state (safety and return to store)
* you are just plain worried something will go wrong
-------------------------------------
I have two methods for creating a scatter file.
Method #1
Find your scatter information in SP Flash Tool's Logs
Well first, you have to make SP Flash Tool happy enough to give you some information about your device.
* Obtain a SPFT ROM that is known good for any phone/tablet, preferrably with the same chip as yours. Make sure that scatter file loads into SPFT without error, SPFT checks the PRELOADER and DSP_BL and if they aren't in the scatter directory, it will fail and maybe crash.
* Close SPFT, now modify the MT*scatter.txt file and introduce a few errors in the partition names, but don't change PRELOADER or DSP_BL. An example, instead of "ANDROID" replace it with "DEADBEEF". You ask why? Well you want to make SURE that the "Download" feature fails. You DON'T want the "Download" to actually work and write your random SPFT ROM to your new device. After loading the freshly broken scatter file, click "Download" and hook up your MTK device in preloader / META Mode. It will say your PMT block does not match the scatter file. ERROR:
* Go to SPFT's menu "Help / Open logs folder" and find the latest date. Open the BROM_DLL*.log in your text editor. Search for text that looks like this, I'd first search for "CMD_ReadPartitionInfo():
Code:
11/14/13 09:01:27.382 BROM_DLL[3836][2208]: DA_cmd::CMD_ReadPartitionInfo(): command is allowed. (FlashToolLib/sv5/common/generic/src/da_c
md.cpp:5242)
11/14/13 09:01:27.382 BROM_DLL[3836][2208]: DA_cmd::CMD_ReadPartitionInfo(): getting 20 partitions .. (FlashToolLib/sv5/common/generic/src
/da_cmd.cpp:5269)
11/14/13 09:01:27.397 BROM_DLL[3836][2208]: DA_cmd::CMD_ReadPartitionInfo(): dump 20 partitions (FlashToolLib/sv5/common/generic/src/da_cm
d.cpp:5279)
11/14/13 09:01:27.397 BROM_DLL[3836][2208]: PART[0 ](PRELOADER ) - offset (0x0000000000000000) - size (0x0000000000040000) - mask (0x0
000000000000000) (FlashToolLib/sv5/common/generic/src/da_cmd.cpp:5283)
11/14/13 09:01:27.397 BROM_DLL[3836][2208]: PART[1 ](DSP_BL ) - offset (0x0000000000040000) - size (0x00000000005C0000) - mask (0x0
000000000000000) (FlashToolLib/sv5/common/generic/src/da_cmd.cpp:5283)
11/14/13 09:01:27.397 BROM_DLL[3836][2208]: PART[2 ](MBR ) - offset (0x0000000000600000) - size (0x0000000000004000) - mask (0x0
000000000000000) (FlashToolLib/sv5/common/generic/src/da_cmd.cpp:5283)
11/14/13 09:01:27.413 BROM_DLL[3836][2208]: PART[3 ](EBR1 ) - offset (0x0000000000604000) - size (0x000000000005C000) - mask (0x0
000000000000000) (FlashToolLib/sv5/common/generic/src/da_cmd.cpp:5283)
11/14/13 09:01:27.413 BROM_DLL[3836][2208]: PART[4 ](__NODL_PMT ) - offset (0x0000000000660000) - size (0x0000000000400000) - mask (0x0
000000000000000) (FlashToolLib/sv5/common/generic/src/da_cmd.cpp:5283)
11/14/13 09:01:27.413 BROM_DLL[3836][2208]: PART[5 ](__NODL_NVRAM ) - offset (0x0000000000A60000) - size (0x0000000000300000) - mask (0x0
000000000000000) (FlashToolLib/sv5/common/generic/src/da_cmd.cpp:5283)
11/14/13 09:01:27.413 BROM_DLL[3836][2208]: PART[6 ](__NODL_SECCFG ) - offset (0x0000000000D60000) - size (0x0000000000020000) - mask (0x0
000000000000000) (FlashToolLib/sv5/common/generic/src/da_cmd.cpp:5283)
11/14/13 09:01:27.413 BROM_DLL[3836][2208]: PART[7 ](UBOOT ) - offset (0x0000000000D80000) - size (0x0000000000060000) - mask (0x0
000000000000000) (FlashToolLib/sv5/common/generic/src/da_cmd.cpp:5283)
11/14/13 09:01:27.413 BROM_DLL[3836][2208]: PART[8 ](BOOTIMG ) - offset (0x0000000000DE0000) - size (0x0000000000600000) - mask (0x0
000000000000000) (FlashToolLib/sv5/common/generic/src/da_cmd.cpp:5283)
11/14/13 09:01:27.413 BROM_DLL[3836][2208]: PART[9 ](RECOVERY ) - offset (0x00000000013E0000) - size (0x0000000000600000) - mask (0x0
000000000000000) (FlashToolLib/sv5/common/generic/src/da_cmd.cpp:5283)
11/14/13 09:01:27.413 BROM_DLL[3836][2208]: PART[10](SEC_RO ) - offset (0x00000000019E0000) - size (0x0000000000600000) - mask (0x0
000000000000000) (FlashToolLib/sv5/common/generic/src/da_cmd.cpp:5283)
11/14/13 09:01:27.413 BROM_DLL[3836][2208]: PART[11](__NODL_MISC ) - offset (0x0000000001FE0000) - size (0x0000000000060000) - mask (0x0
000000000000000) (FlashToolLib/sv5/common/generic/src/da_cmd.cpp:5283)
11/14/13 09:01:27.413 BROM_DLL[3836][2208]: PART[12](LOGO ) - offset (0x0000000002040000) - size (0x0000000000300000) - mask (0x0
000000000000000) (FlashToolLib/sv5/common/generic/src/da_cmd.cpp:5283)
11/14/13 09:01:27.413 BROM_DLL[3836][2208]: PART[13](__NODL_EXPDB ) - offset (0x0000000002340000) - size (0x00000000000A0000) - mask (0x0
000000000000000) (FlashToolLib/sv5/common/generic/src/da_cmd.cpp:5283)
11/14/13 09:01:27.413 BROM_DLL[3836][2208]: PART[14](EBR2 ) - offset (0x00000000023E0000) - size (0x0000000000004000) - mask (0x0
000000000000000) (FlashToolLib/sv5/common/generic/src/da_cmd.cpp:5283)
11/14/13 09:01:27.413 BROM_DLL[3836][2208]: PART[15](FAC ) - offset (0x00000000023E4000) - size (0x0000000010000000) - mask (0x0
000000000000000) (FlashToolLib/sv5/common/generic/src/da_cmd.cpp:5283)
11/14/13 09:01:27.413 BROM_DLL[3836][2208]: PART[16](ANDROID ) - offset (0x00000000123E4000) - size (0x0000000020100000) - mask (0x0
000000000000000) (FlashToolLib/sv5/common/generic/src/da_cmd.cpp:5283)
11/14/13 09:01:27.413 BROM_DLL[3836][2208]: PART[17](CACHE ) - offset (0x00000000324E4000) - size (0x0000000020100000) - mask (0x0
000000000000000) (FlashToolLib/sv5/common/generic/src/da_cmd.cpp:5283)
11/14/13 09:01:27.413 BROM_DLL[3836][2208]: PART[18](USRDATA ) - offset (0x00000000525E4000) - size (0x0000000020100000) - mask (0x0
000000000000000) (FlashToolLib/sv5/common/generic/src/da_cmd.cpp:5283)
11/14/13 09:01:27.413 BROM_DLL[3836][2208]: PART[19](FAT ) - offset (0x00000000726E4000) - size (0x0000000000000000) - mask (0x0
000000000000000) (FlashToolLib/sv5/common/generic/src/da_cmd.cpp:5283)
Make sure you aren't looking at a dump of your scatter, but looking at the partition dump from your device. (If it contains DEADBEEF flag from above, you are looking at the wrong part of the log.) You can manually create a scatter file from that, or you can paste the lines with partition info into a text file and run this shell script:
Code:
cat pastedlog.txt | sed -n 's/.*](\([^ ]*\)[^(]*(\([^)]*\).*)/\1 \2\n{\n}/p' | sed 's/x00000000/x/g' > mynewscatter.txt
This will get you really close, but the last entry you see in a typical scatter file is BMTPOOL. I don't know much about BMTPOOL or __NODL_BMPPOOL other than it's not a real partition. It might not even be required? (You might be able to fake that entry if you look at similar scatter files. If not, read on)
Method #2
An alternate and supplemental way of getting scatter info is to use ADB on a running device. I'm sure this is similar to MTK Droid Root & Tools method.
Code:
adb pull /proc/dumchar_info
Now that you have that file local on your PC, you can run this python script:
Code:
import sys
import string
import re
ins = open( "dumchar.txt", "rb" )
outs = open( "scatter.txt", "wb" )
for line in ins:
linesp = re.split('\W+', line)
name = linesp[0].upper()
start = int(linesp[2],16)
block = linesp[5]
if block != 'misc':
start = start + 0x600000
outs.write(name + " " + string.replace(hex(start), "L", "") + "\n{\n}\n")
ins.close()
outs.close()
This method gives you the BMTPOOL entry that the other method does not, but it lacks the __NODL_ designator for all partitions. If you aren't familiar with that prefix, SPFT uses that to know if it should typically allow you to DownLoad over the top of the paritition.
With both scatter files, throw them side-by-side in a text editor (or diff tool) and with a brain, it's easy enough to merge one with the __NODL_ prefix and the one with the BMTPOOL entry.
Scatter file complete!
PS - Possibly another way, is to use SPFT to do a "Read back" (read memory) at 0x660000 of size 0x400000. Save this as the PMT block and analyse it with a hex editor. I believe the PMT block is always at address 0x66000 judging from a dozen different scatter files.
Dump Full ROM
Perfect Total Backup of your Firmware
The safe way to do this with or without a proper scatter file is the "Read back" feature of SP Flash Tool. There are MANY reasons to dislike MediaTek, but this feature is so nice that I can forgive them for most of their wrong doing.
Most of this section I will generalize from my Lenovo A2107A Guide.
Here is a cookbook for doing a total backup of your MTK device with MediaTek's SP Flash Tool. No rooting, you might even do this before you ever boot! I have basically done this with both of my devices before I fiddled too much. I recommend doing it before you do anything really.
1. Install VCOM Drivers.
2. Install SP Flash Tool.
3. Grab an SPFT ROM, really anything should work, you just have to make SP Flash Tool happy. SPFT validates the scatter file against some of the image files, so you have to calm SPFT down by giving it something it can make sense of. We won't use the scatter file or image files while we do the "Read back" operation.
4. Run SP Flash Tool, Open Scatter File
5. Don't play with anything, go into the "Read back" tab (This will read your flash to a file on your PC)
6. Click on any items in the list, then click the "Remove" button
7. Now click the "Add" button
8. Double click on the "N/A" under Read Flag
9. Type a file name to write to, like "WHOLE_ROM"
10. Now it will popup a window "Readback block start address"
11. Leave "Hex" selected, Start Address" 0x0000, Length: 0x40000000, Click OK (NOTE: this will get the first GIG of flash)
12. Click the "Read back" button
13. SPFT now waits for you to connect your device and put it in Meta Mode
14. Without plugging your phone/tablet in, tap the Reset Button or make sure it's fully off
15. Hold VolUp, plug in USB, Release VolUp (putting it in Meta Mode) <--- Important
16. You will see the progress bar moving. Total backup takes forever, because in this mode SPFT seems to not do USB HIGHSPEED
That's IT! It'll take a few hours, so go to bed.
If you ever restore, just go into Recovery and Wipe Data and Cache. (as these are large and we probably didn't back them up above)
Note: "Length" in Step 11 is probably long enough for most devices. You can reference the scatter file you made above to make sure get everything, but you don't need USRDATA or CACHE, as those get wiped anyway.
Dicing up Full ROM image into partition images
I've made a little bash shell script to dice up a whole ROM according to a scatter file. This creates files exactly the size of the partitions. Some post processing needs done below the script:
dice.sh
Code:
#!/bin/bash
scatterfile=$1
rom=$2
pdir=raw.partitions
rm -rf $pdir
mkdir $pdir
cat $scatterfile | grep "x" | while read line; do
name=$(echo $line | sed 's/ .*//g')
name=$(echo $name | sed 's/^__NODL_//g')
start=$(echo $line | sed 's/.* //g')
# echo $name
if [[ -n $last_name ]]; then
echo "Processing: $last_name"
echo " start: $last_start"
size=$(( $start - $last_start ))
if [[ $size -lt 0 ]]; then
size=0xFFFFF000
else
size=0x$(echo "obase=16; $size" | bc)
fi
echo " size: $size"
short_start=$(echo $last_start | sed 's/000$//g')
short_size=$(echo $size | sed 's/000$//g')
echo dd if=$rom of=$pdir/$last_name bs=$(( 0x1000 )) \
skip=$(( $short_start )) count=$(( $short_size ))
dd if=$rom of=$pdir/$last_name bs=$(( 0x1000 )) \
skip=$(( $short_start )) count=$(( $short_size ))
fi
last_name=$name
last_start=$start
done
Now there is some post processing done. Truncate MBR, EBR1, EBR2 to 512 bytes. And remove trailing bytes of 0000 or FFFF on the end of PRELOADER and DSP_BL.
Here is a one off script for example use:
clean.sh
Code:
#!/bin/bash
pdir=raw.partitions
odir=out
rm -rf $odir
mkdir $odir
dd if=$pdir/PRELOADER of=$odir/preloader.bin bs=$(( 0x800 )) skip=1
./trim.sh $odir/preloader.bin
./trimFF.sh $odir/preloader.bin
dd if=$pdir/DSP_BL of=$odir/DSP_BL bs=$(( 0x8000 )) count=1
./trimFF.sh $odir/DSP_BL
dd if=$pdir/MBR of=$odir/MBR bs=512 count=1
dd if=$pdir/EBR1 of=$odir/EBR1 bs=512 count=1
dd if=$pdir/EBR2 of=$odir/EBR2 bs=512 count=1
cp $pdir/UBOOT $odir/uboot.bin
cp $pdir/LOGO $odir/logo.bin
./trim.sh $odir/logo.bin
cp $pdir/SEC_RO $odir/secro.img
cp $pdir/RECOVERY $odir/recovery.img
cp $pdir/BOOTIMG $odir/boot.img
cp $pdir/FAC $odir/fac.img
cp $pdir/ANDROID $odir/system.img
cp MT*.txt $odir/
And quickly, Here is my hack to remove 0000 and FFFF from the end of files:
trim.sh
Code:
#!/bin/bash
truncate -s $(( 4 + $(cat $1 | hexdump -v -e '/4 "%_ad: " ' -e '4/1 "%02X" "\n"' \
| grep -v ": 00000000" | tail -n 1 | sed 's/:.*//') )) $1
trimFF.sh
Code:
#!/bin/bash
truncate -s $(( 4 + $(cat $1 | hexdump -v -e '/4 "%_ad: " ' -e '4/1 "%02X" "\n"' \
| grep -v ": FFFFFFFF" | tail -n 1 | sed 's/:.*//') )) $1
You should be able to read the clean.sh script and figure out only in just those few cases, is special post processing needed. If you don't post process, SPFT will give errors.
I hope this helps. If you have any questions, ask... I'll try to clarify this first post.
syserr said:
[GUIDE][UTIL][MT65xx] Create Scatter File / Dump Full ROM
For any MT65xx device, no matter how obscure.
Dicing up Full ROM image into partition images
I've made a little bash shell script to dice up a whole ROM according to a scatter file. This creates files exactly the size of the partitions. Some post processing needs done below the script:
dice.sh
Code:
#!/bin/bash
scatterfile=$1
rom=$2
pdir=raw.partitions
rm -rf $pdir
mkdir $pdir
cat $scatterfile | grep "x" | while read line; do
name=$(echo $line | sed 's/ .*//g')
name=$(echo $name | sed 's/^__NODL_//g')
start=$(echo $line | sed 's/.* //g')
# echo $name
if [[ -n $last_name ]]; then
echo "Processing: $last_name"
echo " start: $last_start"
size=$(( $start - $last_start ))
if [[ $size -lt 0 ]]; then
size=0xFFFFF000
else
size=0x$(echo "obase=16; $size" | bc)
fi
echo " size: $size"
short_start=$(echo $last_start | sed 's/000$//g')
short_size=$(echo $size | sed 's/000$//g')
echo dd if=$rom of=$pdir/$last_name bs=$(( 0x1000 )) \
skip=$(( $short_start )) count=$(( $short_size ))
dd if=$rom of=$pdir/$last_name bs=$(( 0x1000 )) \
skip=$(( $short_start )) count=$(( $short_size ))
fi
last_name=$name
last_start=$start
done
Click to expand...
Click to collapse
hi syserr,
i m tryin to run the script dice.sh and this is the trace i get
Code:
[email protected] ~/TESTbcup $ sh -x ./dice.sh
+
: not found2: ./dice.sh:
+ scatterfile=
+ rom=
+ pdir=raw.partitions
+
: not found6: ./dice.sh:
+ rm -rf raw.partitions
+ mkdir raw.partitions
+
: not found9: ./dice.sh:
./dice.sh: 37: ./dice.sh: Syntax error: end of file unexpected (expecting "then")
[email protected] ~/TESTbcup $
any advice would be welcome. I dumb a complete rom and try to dice it.
thank you syserr
fragargon said:
hi syserr,
i m tryin to run the script dice.sh and this is the trace i get
Code:
[email protected] ~/TESTbcup $ sh -x ./dice.sh
+
: not found2: ./dice.sh:
+ scatterfile=
+ rom=
+ pdir=raw.partitions
+
: not found6: ./dice.sh:
+ rm -rf raw.partitions
+ mkdir raw.partitions
+
: not found9: ./dice.sh:
./dice.sh: 37: ./dice.sh: Syntax error: end of file unexpected (expecting "then")
[email protected] ~/TESTbcup $
any advice would be welcome. I dumb a complete rom and try to dice it.
thank you syserr
Click to expand...
Click to collapse
Sorry Sorry Sorry. It takes 2 arguments, I should do some error checking and make sure the user supplies them.
Code:
./dice.sh scatterfile.txt FULLROM.img
It might have some syntax that is specific to bash, so "sh" might throw errors too.
Dumchar.txt
I did dumchar_info, I've renamed it dumchar.txt.
Run script , and it gives me error(He created and an scatter.txt), but empty - see image
Dumchar.txt
What happens and what is the solution?
Alex1948 said:
I did dumchar_info, I've renamed it dumchar.txt.
Run script , and it gives me error(He created and an scatter.txt), but empty - see image
Click to expand...
Click to collapse
I'm sorry, I didn't see this message before, I'm following about 10 threads and this got lost.
I also copied this over from the rua1 thread. I don't think he appreciates our conversation over there, mainly because it's somewhat off topic.
Alex1948 said:
For @syserr
I do not know what all you write here, Python, etc.start adress + lenght , I think we know how to add two numbers in base 16 , no other ....MTKdroid is a software that solves everything,In Python a script of yours, gives me error.
I posted a picture of treadh and you did not answer why(Or you can not quite explain , and we do not understand) - see image
Click to expand...
Click to collapse
Answers:
I've never run it without putting it in a file. Put that python text in dumchar2scatter.py, or something like that. I'm 99% sure that will get rid of the error and give you stuff in your scatter file. You are using Python2, that is good!
You are free to PM me why you feel I didn't see a post. Again, sorry.
Because I think you are genuinely interested in learning, I will describe what my little script is doing. (btw, this is about my third program/script in Python ever)
Code:
import sys
import string
import re
ins = open( "dumchar.txt", "rb" ) [COLOR=Blue]# creates a file handle (ins) to read in dumchar.txt[/COLOR]
outs = open( "scatter.txt", "wb" ) [COLOR=Blue]# creates a file handle (outs) to write to scatter.txt[/COLOR]
for line in ins: [COLOR=Blue]# loops through each line of the input file and puts each line in variable "line"[/COLOR]
linesp = re.split('\W+', line) [COLOR=Blue]# this splits the line varable based on whitespace/spaces, results go into linesp array[/COLOR]
name = linesp[0].upper() [COLOR=Blue]# grabs the first thing in the line, uppercases it, puts it in a varable called name[/COLOR]
start = int(linesp[2],16) [COLOR=Blue]# start variable gets the value of the 3rd thing in the line, but also converts it to an int from text[/COLOR]
block = linesp[5] [COLOR=Blue]# block variable gets 6th thing in line - usually misc or blk[/COLOR]
if block != 'misc': [COLOR=Blue]# if the block variable is NOT 'misc' (only preloader and dsp_bl are these) then ...[/COLOR]
start = start + 0x600000 [COLOR=Blue]# add the offset to the start variable[/COLOR]
outs.write(name + " " + string.replace(hex(start), "L", "") + "\n{\n}\n") [COLOR=Blue]# write out name with start address followed by { } on newlines[/COLOR]
ins.close() [COLOR="Blue"]# just close the file handles here, to clean up, outs might need last writes to be flushed to file.[/COLOR]
outs.close()
I've previewed the code block above on this forum. Why is it so narrow, sorry you will need to use the scrollbar a lot.
UPDATE: Also it's important to have SPACES in a python file, not tabs. And the spaces are critical for python to know code blocks, it acts like {} in Java/C. So, when you make your python file, use spaces to make sure lines line up just right.
syserr said:
I'm sorry, I didn't see this message before, I'm following about 10 threads and this got lost.
I also copied this over from the rua1 thread. I don't think he appreciates our conversation over there, mainly because it's somewhat off topic.
Answers:
I've never run it without putting it in a file. Put that python text in dumchar2scatter.py, or something like that. I'm 99% sure that will get rid of the error and give you stuff in your scatter file. You are using Python2, that is good!
You are free to PM me why you feel I didn't see a post. Again, sorry.
Because I think you are genuinely interested in learning, I will describe what my little script is doing. (btw, this is about my third program/script in Python ever)
Code:
import sys
import string
import re
ins = open( "dumchar.txt", "rb" ) [COLOR=Blue]# creates a file handle (ins) to read in dumchar.txt[/COLOR]
outs = open( "scatter.txt", "wb" ) [COLOR=Blue]# creates a file handle (outs) to write to scatter.txt[/COLOR]
for line in ins: [COLOR=Blue]# loops through each line of the input file and puts each line in variable "line"[/COLOR]
linesp = re.split('\W+', line) [COLOR=Blue]# this splits the line varable based on whitespace/spaces, results go into linesp array[/COLOR]
name = linesp[0].upper() [COLOR=Blue]# grabs the first thing in the line, uppercases it, puts it in a varable called name[/COLOR]
start = int(linesp[2],16) [COLOR=Blue]# start variable gets the value of the 3rd thing in the line, but also converts it to an int from text[/COLOR]
block = linesp[5] [COLOR=Blue]# block variable gets 6th thing in line - usually misc or blk[/COLOR]
if block != 'misc': [COLOR=Blue]# if the block variable is NOT 'misc' (only preloader and dsp_bl are these) then ...[/COLOR]
start = start + 0x600000 [COLOR=Blue]# add the offset to the start variable[/COLOR]
outs.write(name + " " + string.replace(hex(start), "L", "") + "\n{\n}\n") [COLOR=Blue]# write out name with start address followed by { } on newlines[/COLOR]
ins.close() [COLOR="Blue"]# just close the file handles here, to clean up, outs might need last writes to be flushed to file.[/COLOR]
outs.close()
I've previewed the code block above on this forum. Why is it so narrow, sorry you will need to use the scrollbar a lot.
UPDATE: Also it's important to have SPACES in a python file, not tabs. And the spaces are critical for python to know code blocks, it acts like {} in Java/C. So, when you make your python file, use spaces to make sure lines line up just right.
Click to expand...
Click to collapse
OK, I get it("" I don't think he appreciates our conversation over there, mainly because it's somewhat off topic.""
, and why I posted here.
I do not know python, but try to understand more about these phones and their software.
A carefully read what I've written for other questions, as I have, and across from method 1, and there I have some questions.
Especially that last for hours at a READ BACK ,Dump Full ROM , with start adress and lenght by you.
I understand your explanation, written in the program right lines.I did not need them, I know what each instruction written there.
I do not know python but I want to understand .Look - I send you dumchar_info and firmware.info , with partitions start adress and lenght and see what you get.
And finally you get scatter file , my SCATTER FILE , block info - start adress , size , etc.
It's OK. ?As we do not just theory.
I liked your idea, what you wrote but I want to see it completed
Crashes
I did as you said. Look :
Send and dumchar.txt and dumchar2scatter.py
It's ok, I'm sorry you do not answer.I also sent a file and I wanted to enlighten and method 1.
I feel that all that script and dump rom are stupid
I think you should post here on this thred, not on MTKDroid Tool.
Sorry, if you prove me wrong
I'm sorry special excuse but if the script does not work , I posted the file dumchar.txt ,the idea that a fix you
It again sorry, did not mean to upset
Scatter.txt
Successful scatter.txt.As shown in the picture has the same start adress with MTKDroid scatter file , without __NODL_ to 10 partitions.
SP Flash Tool , scatter - loading , load all - see image 2.
For Read Back why use it or one obtained with MTKDroid(see image 3)
Tks.
Alex1948 said:
It's ok, I'm sorry you do not answer.
Click to expand...
Click to collapse
Hi Alex, I figured out why I wasn't catching your posts here. I'm normally looking at my Subscribed threads, and I hadn't subscribed to this thread. I should subscribe and look at my notifications too.
I will look at your messages today. My script is "dumb" as it's looking for a certain path for the block device in the output of dumchar. If that output changes, my script will probably fail.
Alex1948 said:
Successful scatter.txt.As shown in the picture has the same start adress with MTKDroid scatter file , without __NODL_ to 10 partitions.
SP Flash Tool , scatter - loading , load all - see image 2.
For Read Back why use it or one obtained with MTKDroid(see image 3)
Tks.
Click to expand...
Click to collapse
I see it's working for you now. Great. We could make great tools, but MediaTek is changing things that cause problems for even rua1's MTKDRT. Personally, I think it's good to understand things. I'm glad you want to understand too.
Nice share :fingers-crossed:
WHOLE_ROM
4. Run SP Flash Tool, Open Scatter File :
- What scatter file upload ? images 1(that obtained with MTKDroid) or scatter.txt (renamed) and otained with dumchar , script pyton....see images 2. ???
- Start adress is 0x00000000 , but Lenght can pass 0xE7F20000 (start adress FAT=0xC81C0000+FAT lenght=0x1FD60000) END adress FAT ???
With this file, probably higher, than 1GB ,WHOLE_ROM - without extension , What do I do next ?
- to get all the MTKDroid A5_Duo_130806_ForFlashtoolFromReadBack_131007-212823 - see image 3(for this we used start adress 0x00000000 and Lenght 0x3c9c0000 - my CACHE start adress) and My ROM_0 has - 969 MB
And another CWM recovery, more personalized for this phone with can be done?Android-Kitchen-0.224 ? Need 2 files(system.img and boot.img)
I installed and cygwin but does not work, crashes
Alex1948 said:
4. Run SP Flash Tool, Open Scatter File :
- What scatter file upload ? images 1(that obtained with MTKDroid) or scatter.txt (renamed) and otained with dumchar , script pyton....see images 2. ???
- Start adress is 0x00000000 , but Lenght can pass 0xE7F20000 (start adress FAT=0xC81C0000+FAT lenght=0x1FD60000) END adress FAT ???
With this file, probably higher, than 1GB ,WHOLE_ROM - without extension , What do I do next ?
- to get all the MTKDroid A5_Duo_130806_ForFlashtoolFromReadBack_131007-212823 - see image 3(for this we used start adress 0x00000000 and Lenght 0x3c9c0000 - my CACHE start adress) and My ROM_0 has - 969 MB
And another CWM recovery, more personalized for this phone with can be done?Android-Kitchen-0.224 ? Need 2 files(system.img and boot.img)
I installed and cygwin but does not work, crashes
Click to expand...
Click to collapse
#3 and #4 go hand in hand. You just need to make SPFT happy. In all my testing, the scatter and img files can be WRONG... *IF* all you are doing is using "Read back" and "Write memory". It makes sense that to do raw reads and writes, you wouldn't need to know the structure. But this tool forces you to have a scatter and images so it will perform the read/write tasks.
On your second issue, the "FAT" block is not very important and at least on ICS 4.0.4 on my device, if it is all zeros, then on first boot Android will ask to format it. On 4.0.3, I think I had to create a FAT image, which is pretty easy on Linux.
I used this "tool".
But with clean.sh I get a error about DSP_BL. In my scatterfile (MT6589) it is not there. I attached scatterfile.
Is there another "replacement" which i need to clean ?
Thanks for the guide!
Lost calibration data - Unresponsive screen
Hey guys, I have Star N9800 phone. During the last week I've been trying hard to fix my touchscreen driver since I flashed a stock ROM. The problems I was facing were checking and comparing lk.bin (lcm driver) with other people who also have same phone, downloading different ROMs and boot images, tried almost everything. I even opened my phone and disconnected the digitizer to check if it's the problem. When it's connected it says: touchscreen: ili2113a when I check version in factory mode (VOL- + HOME + POWER). When it's disconnected it says: touchscreen: (null), so obviously digitizer is working fine.
Today I think i've found the problem. While using SP Flash Tool I've used manual format from 0x00000000 to whatever it said. It deleted calibration data. And apparently calibration data is stored in nvram.bin which can be backed up using MTK Droid Tools while running a working ROM.
I have flashed original stock ROM now, I'm rooted and I can control my phone from the PC but can't use the screen. It's fully unresponsive. I've checked some answers here on XDA and some guy said I should make a nvram backup of stock ROM and then flash userdata_nvram_only.tar as USERDATA in SP Flash Tool. When I tried unzipping that .tar it clearly has /data/nvram/ folder which also contains some calibration and other files. But when I flashed that .tar as USERDATA my phone isn't booting anymore. I've tried flashing different boot.img but the problem is still here.
Does anybody know how to fix my touchscreen?
I contacted few people on www.NeedRom.com to upload userdata_nvram_only.tar for me, but I don't know whether they are going to do it or not.
I appreciate all help I can get, and I'd seriously hate if I had to send the phone back to china. I wouldn't really do it.
Posted my reply to his PM:
JoeSip said:
Wow you cleared some things for me now. I have Star N9800 smartphone. I've flashed 15 ROMs and tried disconnecting and connecting back the digitizer but screen is still unresponsive. It doesn't react at all. It could be because I used Format option and manual format option in SP Flash tool. Do you have any clue how to get my screen working again? Apparently when doing manual format from adress 0x00000000 calibration data gets removed. Please help me, i'm really desperate.
I can ask people from www.NeedRom.com to help me. They already tried because some of us have the same problems...
You could be the saviour of us all.
Click to expand...
Click to collapse
I think you are totally on track. The NVRAM block/partition is special and it really bugs me that I didn't know this up front when I killed my first MTK device, and people I trusted (ahead of me) didn't talk about it. (FYI, I bought an identical device to repair my device's NVRAM block)
The trick here is... most MTK SP Flash ROMs available don't have the NVRAM block. This is because, they are unique to the device (IMEI and MAC) and if you don't Format with SP Flash, then you don't need them.
What you need... someone with an identical device that is willing to run SP Flash and do a "Read Memory" on the address range of NVRAM block. You would get the address range from the scatter file.
JoeSip said:
Hey guys, I have Star N9800 phone. During the last week I've been trying hard to fix my touchscreen driver since I flashed a stock ROM. The problems I was facing were checking and comparing lk.bin (lcm driver) with other people who also have same phone, downloading different ROMs and boot images, tried almost everything. I even opened my phone and disconnected the digitizer to check if it's the problem. When it's connected it says: touchscreen: ili2113a when I check version in factory mode (VOL- + HOME + POWER). When it's disconnected it says: touchscreen: (null), so obviously digitizer is working fine.
Today I think i've found the problem. While using SP Flash Tool I've used manual format from 0x00000000 to whatever it said. It deleted calibration data. And apparently calibration data is stored in nvram.bin which can be backed up using MTK Droid Tools while running a working ROM.
I have flashed original stock ROM now, I'm rooted and I can control my phone from the PC but can't use the screen. It's fully unresponsive. I've checked some answers here on XDA and some guy said I should make a nvram backup of stock ROM and then flash userdata_nvram_only.tar as USERDATA in SP Flash Tool. When I tried unzipping that .tar it clearly has /data/nvram/ folder which also contains some calibration and other files. But when I flashed that .tar as USERDATA my phone isn't booting anymore. I've tried flashing different boot.img but the problem is still here.
Does anybody know how to fix my touchscreen?
I contacted few people on www.NeedRom.com to upload userdata_nvram_only.tar for me, but I don't know whether they are going to do it or not.
I appreciate all help I can get, and I'd seriously hate if I had to send the phone back to china. I wouldn't really do it.
Click to expand...
Click to collapse
I'll say a couple more things:
Yes, right now your NVRAM block is probably all zeros. And yes, you can use MTK Droid Tools to back up a good NVRAM... I like using SP Flash Tool to read the memory range of the NVRAM block, then I know it's in a shutdown state etc. All MKDRT is doing is running an adb command and doing something like "dd if=/dev/mc***** of=nvram.bin bs=1M count=1"... You could do that too with adb.
You don't need the USERDATA block at all. I would correct your request, to just ask for NVRAM. As USERDATA/USRDATA/DATA (all aliases of the same thing) is a block for your installed apps and data. It is what gets wiped when you do a Factory Reset with typical ROMs or with CWM etc.
Thank you very much man!
So now I'm supposed to just get backup of NVRAM that someone has done in MTK Droid Tools and not the whole ROM?
What if I flash full backup of someone's whole ROM? Will that save me too?

[Development] MKBOOTIMG TOOLS

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

[Q] Second stage bootloader

I'm working on a little project that involves measuring kernel attributes at boot time. Not having source, modifying the stock bootloader looks a little challenging and dangerous. Instead, the idea was to add a second stage bootloader to the boot image.
According to bootimg.h, the struct boot_img_hdr includes the fields:
unsigned second_size; /* size in bytes */
unsigned second_addr; /* physical load addr */
and then there is a comment at the bottom of the file stating:
** 6. if second_size != 0: jump to second_addr
** else: jump to kernel_addr
So I wrote a one line (un)bootloader (ubl.s)
_start: b _start
which spins forever. I push ubl.s through the gnu/arm assembler and then:
objcopy -O binary -R .comment -S ubl.o ubl.bin
to create a binary suitable to be included in the boot image. I then unbundled my working boot image (unmkbootimg) and rebundled the kernel and ramdisk adding the second stage bootloader with mkbootimg. Unbundling the result confirmed that the second stage bootloader was in place and header correct. Then the usual steps:
adb reboot bootloader
fastboot boot myboot.img
and it booted the kernel from ram ... but shouldn't have.
Am I getting this all wrong or is the Nexus 5 bootloader ignoring the second stage bootloader entry in the boot image?

[TUTORIAL/REFERENCE] Building the android kernel (Mac OS)

Many people have MacBooks and they MacBooks have a terminal. This terminal runs bash and other unix commands, so why can't we compile a kernel. That's what I thought at first... Then the errors started...
I will not be responsible if you bork, brick, or blow up your devices in the process​
Notes: This is using clang, gcc should also work using this procedure, just with a few alterations exactly like compiling on linux
This guide is intended to help people compile their kernel on OSX
Step 1: Getting the dependencies and setting up build environment
Installing package managers:
Xcode HAS to be installed for this to work! If you just want the command line tools, type "xcode-select --install". To set the OS to use the command line tools from the app, type "xcode-select --switch /Applications/Xcode.app/Contents/Developer"
Install homebrew here: http://brew.sh
Install macports here (Follow source instructions): http://https://guide.macports.org/chunked/installing.macports.html
Set up build environment:
The android developers website gives great instructions on how to do this, but they use macports, which I tend to stay away from. However, this guide will use macports until I can figure out the homebrew alternatives for these packages
MacPorts packages: gmake libsdl git gnupg bison (exclude the git packages if you already have them)
Reference site: https://source.android.com/setup/build/initializing
Case Sensitive disk image - Android anything won't build unless the filesystem is case sensitive (APFS isn't), so we need to create a sparseimage for it
Go into disk utility and hit file, new image, blank image or Command-N
Set (in this order) Image Format: sparse disk image, Format: Mac OS Extended (Journaled, case-sensitive), Size: 20GB, Name: Android
Create the new image
Edit your bash profile by entering "open -a TextEdit ~/.bash_profile" and make a mountAndroid function
mountandroid() { hdiutil attach ~/android.sparseimage -mountpoint /Volumes/android; }
Open a new terminal window and type mountandroid
Your new disk image is mounted at /Volumes/android
Setting the PATH:
Open your bash_profile
add this line:
export PATH="/usr/local/bin:$PATH"
export PATH="/opt/local/bin:$PATH"
Save and open a new window
Step 2 - Cloning the kernel: I don't know where you get your kernels from, but you should know the basics on how to clone a source, clone the source to /Volumes/android
Step 3 - Getting the Toolchain: For now, I use prebuilts via the NDK, However, Crosstool-ng is a viable option
Download the NDK here https://developer.android.com/ndk/downloads/
Make a standalone Toolchain inside your case sensitive image (For arm64 devices: use the guide for BOTH arm and arm64)
https://developer.android.com/ndk/guides/standalone_toolchain
Step 4 - Linking it all together:
Creating a script to use (inside kernel source folder)
make O=out ARCH=arm64 **Your_defconfig**
make -j4 O=out ARCH=arm64 CC='/Volumes/android/**Toolchain folder**/bin/clang' CLANG_TRIPLE=aarch64-linux-gnu CROSS_COMPILE_ARM32='/Volumes/android/**Toolchain arm folder**/bin/arm-linux-androideabi-' CROSS_COMPILE='/Volumes/android/**Toolchain arm folder**/bin/aarch64-linux-android-'
The arm64 devices have to use the CROSS_COMPILE_ARM32 line, if you don't have this, just omit the line
Then just type ./**Script Name**.sh (make sure to chmod +x or 755 it first) and you're good to go!
Step 5 - Errors... Those stupid errors!: There are a few known errors that can be easily fixed, but they're very annoying
elf.h error - Open the file /usr/local/include and make a new file, elf.h
Paste this in there:
#include "../opt/libelf/include/libelf/gelf.h"
#define R_386_NONE 0
#define R_386_32 1
#define R_386_PC32 2
#define R_ARM_NONE 0
#define R_ARM_PC24 1
#define R_ARM_ABS32 2
#define R_MIPS_NONE 0
#define R_MIPS_16 1
#define R_MIPS_32 2
#define R_MIPS_REL32 3
#define R_MIPS_26 4
#define R_MIPS_HI16 5
#define R_MIPS_LO16 6
#define R_IA64_IMM64 0x23 /* symbol + addend, mov imm64 */
#define R_PPC_ADDR32 1 /* 32bit absolute address */
#define R_PPC64_ADDR64 38 /* doubleword64 S + A */
#define R_SH_DIR32 1
#define R_SPARC_64 32 /* Direct 64 bit */
#define R_X86_64_64 1 /* Direct 64 bit */
#define R_390_32 4 /* Direct 32 bit. */
#define R_390_64 22 /* Direct 64 bit. */
#define R_MIPS_64 18
#define EF_ARM_EABIMASK 0XFF000000
#define EF_ARM_EABI_VERSION(flags) ((flags) & EF_ARM_EABIMASK)
vdsomunge.c errors (all fixed with this simple file from torvalds himself)
Replace your arch/arm/vdso/vdsomunge.c file with this one
vdso_offset_sigtramp undeclared (shows signal.c in terminal)
change the file arch/arm64/vdso/gen_vdso_offsets.sh
Replace the last line to this - 's/^\([0-9a-fA-F]*\) . VDSO_\([a-zA-Z0-9_]*\)$/\#define vdso_offset_\2 0x\1/p'
This removes the "t" in the "2t0x" part
So, after this, your kernel should be built without any complications! I have some requests in the post below, so help me out and gimme a thanks!
Things I need help finding:
Building crosstool-ng on mac
building Dragon TC on mac or a clang 8.0 toolchain
Please put your solutions in the comments so I can include them in the main thread
thanks for the guide!
I'm having one problem though
Code:
Undefined symbols for architecture x86_64:
"_OPENSSL_init_crypto", referenced from:
_main in cc6WbheD.o
ld: symbol(s) not found for architecture x86_64
I posted a complete revision alongside a recent kernel, but below is a summary of the changes / updates for using this guide in 2021
StarKissed/StarKissed_I005_1
Contribute to StarKissed/StarKissed_I005_1 development by creating an account on GitHub.
github.com
Disclaimer: As of June 2021, Android no longer supports building on Mac
arch/arm64/vdso/gen_vdso_offsets.sh =>
arch/arm64/kernel/vdso/gen_vdso_offsets.sh
Code:
brew install gnu-sed
export PATH=/usr/local/opt/gnu-sed/libexec/gnubin:$PATH
readlink: illegal option -- f
usage: readlink [-n] [file ...]
Code:
brew install coreutils
export PATH=/usr/local/opt/coreutils/libexec/gnubin:$PATH
find: -printf: unknown primary or operator
Code:
brew install findutils
export PATH=/usr/local/opt/findutils/libexec/gnubin:$PATH
Homebrew alternatives
Code:
brew install make
brew install sdl
brew install gnupg
brew install bison
Quick Homebrew Alternatives
Enter "homebrew [command name]" in google search
Enter command from https://formulae.brew.sh/formula/
juampapo546 said:
thanks for the guide!
I'm having one problem though
Code:
Undefined symbols for architecture x86_64:
"_OPENSSL_init_crypto", referenced from:
_main in cc6WbheD.o
ld: symbol(s) not found for architecture x86_64
Click to expand...
Click to collapse
Code:
brew install openssl
export PKG_CONFIG_PATH=/usr/local/opt/[email protected]/lib/pkgconfig:$PKG_CONFIG_PATH
You may also need to explicitly include in scripts/Makefile
Code:
HOST_EXTRACFLAGS += -I$(srctree)/tools/include
ifeq ($(shell uname),Darwin)
HOST_EXTRACFLAGS += -I/usr/local/opt/[email protected]/include -L/usr/local/opt/[email protected]/lib
endif

Categories

Resources