Related
This is my own completely Off Topic Discussion thread.
A place where I will bring HW related discussions, that do not fit into
specific threads or discussions.
Please, do not post here with general questions or other junk that I have not initiated myself.
Also do not ask where to find files/programs mentioned in this thread, because if I have not linked to them, I don't know!
They will be removed. (Thanks for understanding.)
See you.
<< Better reserve for more dragons >>
Didn't see that anyone mentioned it and I'm not sure if the S4 modems are as well, but the initial container that the modems are in on the HTC used S3 chips is a fat16 format. I saw that with a simple hex editor showed it and I was able to see the modem file structure as well. I'll snag a few S4 modems later today and take a look. Couldn't unpack and repackaged though, which is probably the EFS formatting with it.
Off topic goes in off topic
Sorry it took so long
I had intended to do this at least a week ago, but had not the chance. Both the S3 HTC Radios and the S4 HTC Radios are fat 16 imgs.
As you see in the Rezound screenshot, in the first few lines of the HEX table in the bottom left mentions no volume label and a fat 16 label on the type. in addition when I use IMG viewers it shows the same with both the MDM9K image and the main IMG. This should theoretically enable us to possibly use amss imgs or other parts of the radios with other devices or even cross the modem over to other Samsung devices with the same modem chips.
In addition as per the Ville screenshot, this is the One S modem for one of the European basebands. Again the HEX shows Fat 16 as the file type, but the file structure and amount of files are much more plentiful. If this can become of any use, great. If not, oh well... but it is good food for thought either way.
On other notes, I did try to copy files from the LTE baseband (MDM9k) from the Vivid and move them to the MDM9k IMG for the rezound, but the IMG bloated. I haven't had enough time to try and mount the images in my Ubuntu environment, but doing it in Winblows caused the IMG to bloat up too much and caused radio issues and IMEI unknown blanks.
Happy perusing and happy hunting!
Very nice, but I doubt you'll be able to mix modem files (between different devices) unless you're absolutely sure that the device modem and AP HW is the same. Apparently from another recent conversation, it seem that HTC and Qualcomm are both moving to unified source code for their devices. So it can still be true that many of those files are the same across devices.
Could you write a few lines on how you go about this extraction and do it for the HTC One X (LTE)?
Also don't forget that US HTC One X (or S, or whatever) is not the same hardware and the European one!
On second thought, I think this is what you got..right?
Pretty much. Seems like another situation where I should have spoke up when I first saw it with Qualcomm S3 modems in May. On moving files though, I was planning to stay in family. S3 w/ S3 ect.
^^ BTW. Could you tell if there are any structural differences (content wise) between files of same prefix, but sequential postfix? What is strange is that they are all very different sizes, which indicate they probably have very different content...
If it was just one solid piece of firmware, it would just have been chopped up into equal sized pieces...
I'll look closer on that. I do remember that most of the sequential pieces were the same size minus either the first or the last, holding with your theory.
Maybe not the right place, but have you looked at the pit files?
COM_TAR2MSM8960
MODEM non-tlos.bin
sbl1.mbm
sbl2.mbm
sbl3.mbm
aboot.mbm
rpm.mbm
BOOT boot.img
TZ
PAD
PARAM
EFS efs.img (ext4)
MODEMST1 nvrebuild1.bin
MODEMST2 nvrebuild2.bin
system.img (ext4)
userdata.img (ext4)
persist.img (ext4)
cache.img (ext4)
recovery.img (ext4)
FOTA
BACKUP
FSG
SSD
GROW
PGPT pgpt.img
PIT MSM8960.pit
MD5 md5.img
SGPT sgpt.img
I know it is not really new, but I hadn't seen the img names.
The ones I took screenshots of were for 3rd and 4th Gen Snapdragon processors, radio.imgs for HTC devices. The Samsung pit files may give good cross references though. I'll re-unbox my Amaze this evening and check the mounts to see any information on the single file broken into pieces theory.
"eMMC Partition tools usage for msm7x30/msm8x60"
(A repost from Anyclub...)
In the eMMC boot, there are some changes in eMMC partitioning.
Code:
[SIZE=2]partition.xml - Everything begins with this file, which describes the number of
partitions desired, and how many sectors each one should be.
PartitioningTool.py - translates partition.xml into binary partitions
msp.exe - writes binary partitions to SD/eMMC cards using card reader
mjsdload.cmm - writes binary partitions to SD/eMMC cards using Trace32
msp.py - writes binary partitions to a single image file
QPST - writes binary partitions to SD/eMMC cards on Target
[/SIZE]
Helper /Debug Tools:
Code:
[SIZE=2]parseBinaryPartitionFile.pl - Decodes MBR partition tables. Run:
"Perl parseBinaryPartitionFile.pl partition.bin"
to generate the partition information
parseGPT.pl - Decodes GPT partition tables
[/SIZE]
partition.xml
These are the property entries that can be added in new partiton.xml to specify the configuration.
Code:
[SIZE=2]<parser_instructions>
WRITE_PROTECT_BOUNDARY_IN_KB = 0
GROW_LAST_PARTITION_TO_FILL_DISK = false
ALIGN_ALL_LOGICAL_PARTITIONS_TO_WP_BOUNDARY = false
</parser_instructions>[/SIZE]
WRITE_PROTECT_BOUNDARY_IN_KB: Typical boundaries are 64MB, i.e. 65536 KB. This
means that a 256MB eMMC card has 4 write protect boundaries. Any or all of
them can be marked as read-only. Different vendors allow for different sized
boundaries.
GROW_LAST_PARTITION_TO_FILL_DISK: In partition.xml the size of each partition
is specified. If this field is TRUE, then the last partition size is ignored
and set to 0. Then during patching this size is updated such that the last
partition extends to use all remaining space.
ALIGN_ALL_LOGICAL_PARTITIONS_TO_WP_BOUNDARY: To allow total flexibility, it
could be that a partition that is currently writeable might need to be marked
as read-only. This can only happen *if* that partition begins on a write
protect boundary (i.e. 64MB). Thus if this field is TRUE, then all logical
partitions are positioned such that they begin on a write protect boundary.
PartitioningTool.py
Is a new tool used to generate the the partition.xml
When run, it will output following 5 files:
1. emmc_lock_regions.xml
This hold the sector ranges that need to be marked as read-only by the
operating system (this is from readonly="true" in partition.xml) i.e. modem
code and boot images are typically on read-only partitions Typical
Write-Protect boundary is 64MB = 131072 sectors = 0x20000 sectors. The file
below is protecting the very first 64MB region of the card,
Boundary #0
Starting at sector 0
Ending at sector 131071 (for a total of 131072 sectors)
Code:
[SIZE=2]<?xml version="1.0" ?>
<protect>
<!-- NOTE: This is an ** Autogenerated file ** -->
<!-- NOTE: Sector size is 512bytes, WRITE_PROTECT_BOUNDARY_IN_KB=0, WRITE_PROTECT_BOUNDARY_IN_SECTORS=0 -->
<!-- NOTE: "num_sectors" in HEX "start_sector" in HEX, i.e. 10 really equals 16 !! -->
<program boundary_num="0" num_boundaries_covered="1"
num_sectors="20000" num_sectors_dec="131072" physical_partition_number="0"
start_sector="0" start_sector_dec="0"/>
<information WRITE_PROTECT_BOUNDARY_IN_KB="0"/>
</protect>
[/SIZE]
2. partition0.bin
This holds the partition tables, i.e. MBR followed by all EBRs. This is the
partition table in binary format. It is copied over to the storage device in a
1 to 1 manner. I.e. how it looks in partition0.bin is exactly how the
partition table will look on the storage device. partition0.bin is a "generic"
file meant to fit on *any* size SD/eMMC card, as a result, there are 0's that
need to be patched,such as EXT partition and last partition size.
3. patch0.xml
Contain the patching instructions to tailor each partition table
"partition0.bin" to a specific SD/eMMC card. I.e. the partition0.bin
partition tables can be applied to any size storage device As a result,
there are empty values (zeros) in the partition tables that must be filled
in with a specific cards sector size
There are two ways to apply this patch:
a) (patch before) When you patch the "zeros" in the partition tables held in the file partition0.bin, and then write it to the card
b) (patch after) When you write partition0.bin to the card (which still has "zeros" in it), and then patch the cards partition tables directly
4. rawprogram0.xml
precise sector details of all partitions and what files (if any) need to
be placed there. In addition to writing partition tables onto a device,
often times it is desired to write one or more files into the partition
area as well, The File has partition name (i.e. label), where it begins
(start_sector) and how big it is (num_partition_sectors). It also
describes what file(s) to write to this partition, as well as any
offsets.
Example:
Code:
[SIZE=2]<program file_sector_offset="0" filename="partition0.bin" label="MBR"
num_partition_sectors="1" physical_partition_number="0"
size_in_KB="0.5" start_sector="0"/>
<program file_sector_offset="1" filename="partition0.bin " label="EXT"
num_partition_sectors="2" physical_partition_number="0"
size_in_KB="1.0" start_sector="779"/>
[/SIZE]
The 1st line describes taking the 1st sector from partition0.bin, and writing it to sector 0 of the card.
The 2nd line describes taking the 2nd and 3rd sector from partition0.bin and writing it to sector 779 of the card.
I.e. file_sector_offset = 2 and num_partition_sectors=2
5. loadpt.cmm
This is used by the mjsdload.cmm to flash the image.
msp.exe
This is used to apply the patches
This program will program a memory card (SD/eMMC) attached to the PC as USB mass storage device
Use -d to detect the path of the memory card if you are unsure what to do first
Commands list:
Code:
[SIZE=2]-h (Print this help message) Ex. msp -h
-d (Detect which storage device ID is active) Ex. msp -d
-p (Print partition information) Ex. msp -p /dev/sdb
-pp (Print partition information - DETAILED) Ex. msp -pp /dev/sdb
-x (Write files as outlined in rawprogram.xml) Ex. msp -x rawprogram.xml /dev/sdb
-xx (Write files as outlined in rawprogram.xml - DETAILED) Ex. msp -xx rawprogram.xml /dev/sdb
-s (Write SINGLE IMAGE "singleimage.bin" as outlined in rawprogram.xml) Ex. msp -s rawprogram.xml 8192
-v (Verify file written correctly as outlined in rawprogram.xml) Ex. msp -v rawprogram.xml boot.img /dev/sdb
-f (Program single file as outlined in rawprogram.xml) Ex. msp -f rawprogram.xml boot.img /dev/sdb
[/SIZE]
To program the SD/eMMC with msp.exe in mass storage mode:
Code:
[SIZE=2]STEPS Complete example (patch after)
-------------------------------------------------------------
parse partition.xml python PartitioningTool.py partition.xml
Detect your device msp -d
Program your device msp -x rawprogram0.xml /dev/sdb
Patch your device msp -xx patch0.xml /dev/sdb
STEPS Complete example (patch before)
-------------------------------------------------------------
parse partition.xml python PartitioningTool.py partition.xml
Detect your device msp -d
Patch your files msp xx patch0.xml 15758336 (patch the 8GB card offline,this will change the partition0.bin)
Program your device msp x rawprogram0.xml /dev/sdb
[/SIZE]
The msp.py program can also used to patch the files.
For example:
python msp.py patch0.xml 15758336
This will patch the 8GB card offline, and change the partition0.bin.
Qualcomm DBL format (source Anyclub)
DBL is combined by three images.
dbl.bin - the raw DBL image
dbl.hd - the dbl header image
dbl_preamble.mbn - the preamble image with following format:
Code:
[SIZE=2]+------------+
|Dbl-preamble|
+------------+
|Dbl-header |
+------------+
|Dbl.bin |
+------------+
[/SIZE]
PBL is using the dbl_preamble to detect the NAND page size. The NAND controller
can detect 512 byte and 2 Kbyte page size automatically, but for NAND page size
more than 2K, PBL needs preamble to determine the page size, so for 512/2K
NAND,eMMC,eSD,oneNAND , the preamble is optional.
For the dbl_preamable, the first two words are same as dbl header, they are
codeword and magic,
ref image_header.c
Code:
data_ptr = autodetectpage;
*data_ptr = sbl_header.codeword;
data_ptr++;
*data_ptr = sbl_header.magic;
data_ptr++;
*data_ptr = AUTODETECT_PAGE_SIZE_MAGIC_NUM;
the third one is auto page size detection magic number.
The usage of the auto detection magic number is as below description To
understand this more clearly, for example ,if the dbl_preamble is 8KB. When we
detect the NAND page size > 2KB, we will set the default page size as 2K, then
try to read the preamble image from NAND flash, in case the page size is 4KB,
when read, can get 2 magic number in 8K size because page size will increase
with 4K byte steps, so page size is detected and that is 8K/2 = 4. For the 8K
page NAND, 1 magic number is read from the 8K size preamble image, so the page
size will be 8K/1 = 8K.
Dbl_preamble layout:
Code:
[SIZE=2]+-------------------------------------------------+
| codeword|magic|autodetection_ magic|............|
2K------------------------------------------------|
| codeword|magic|autodetection_ magic|............|
4K------------------------------------------------|
| codeword|magic|autodetection_ magic|............|
6K------------------------------------------------|
| codeword|magic|autodetection_ magic|............|
8K------------------------------------------------|
| codeword|magic|autodetection_ magic|............|
+-------------------------------------------------+
[/SIZE]
E:V:A said:
parse partition.xml python PartitioningTool.py partition.xml
Detect your device msp -d
Program your device msp -x rawprogram0.xml /dev/sdb
Patch your device msp -xx patch0.xml /dev/sdb
Click to expand...
Click to collapse
Hello, where i can find these files, i have qpst but there are no such files.
So does this explain why the pit references: pgpt.img, md5.img, sgpt.img but they aren't on any partition, (they should be after GROW blk0p23)
dviguha said:
Hello, where i can find these files, i have qpst but there are no such files.
Click to expand...
Click to collapse
I think it could be part of the Qualcomm Development Acceleration Resource Toolkit (QDART), as it supersedes QPST. But I'm not sure...
joederp said:
So does this explain why the pit references: pgpt.img, md5.img, sgpt.img but they aren't on any partition, (they should be after GROW blk0p23)
Click to expand...
Click to collapse
Where do you find these references?
I don't know, so if you find out let us know.
http://forum.xda-developers.com/showthread.php?t=1848267
If you dump the pit file you can see the references if you open in hex editor. Since it defines partition locations it appears they are either after last partition.. I haven't looked into technical pit stuff.
Sent from my SGH-T999 using xda app-developers app
Photo Place Holder Post
All images that I have not yet posted goes here...
Where can i find parseBinaryPartitionFile.pl or parseGPT.pl ?
vache said:
Where can i find parseBinaryPartitionFile.pl or parseGPT.pl ?
Click to expand...
Click to collapse
You tell me!
If you interested in extracting the kernel image from the Samsung Galaxy S5 ROM, you should follow the following steps.
This is was tested with the G900VVRU1ANCG_G900VVZW1ANCG_VZW stock ROM firmware.
The first is extracting the files from the ROM firmware file, this is explained in many places and won't be covered here.
Extract the boot.img to some directory, using the Android unpackbootimg utility:
Code:
unpackbootimg -i boot.img -o boot/
After extracting the boot.img file you will usually end up with the following file list:
Code:
boot.img-base
boot.img-cmdline
boot.img-pagesize
boot.img-ramdisk.gz <- this includes the root (/) files, like init*.rc and SELinux policy files
boot.img-zImage <- compressed image of the Android Linux kernel
Next step will be extracting the compressed kernel image from the zImage file. The Android kernel is a self-extracting compressed file, while different devices use different compression methods. While looking at the file contents using hex editor, you can see the decompression code at the beginning, and then at some point the compressed data begins. The compressed image begins where you find the LZO magic header.
Code:
static const unsigned char lzop_magic[9] = {
0x89, 0x4c, 0x5a, 0x4f, 0x00, 0x0d, 0x0a, 0x1a, 0x0a
};
Save the data from the LZO magic header to the end of the file with the zImage.kernel file name.
This firmware and kernel are using LZO compression, and there is an easy to use utility called lzop that is used for the decompression of the file. Just run the following command to decompress the kernel from the zImage.kernel file:
Code:
lzop -d -c zImage.kernel > zImage.kernel.decompressed
And now you have the decompressed kernel for the device ready for exploration, which is also attached to this post.
Note:
I've tried using different scripts that do the job, including galaxys2_kernel_repack and http://forum.xda-developers.com/showthread.php?t=901152 but both failed while extracting the kernel image, although were able to extract the begin position for the LZO compression header.
But it does trip KNOX after flashing, doesn't it?
roman.blachman said:
If you interested in extracting the kernel image from the Samsung Galaxy S5 ROM, you should follow the following steps.
This is was tested with the G900VVRU1ANCG_G900VVZW1ANCG_VZW stock ROM firmware.
The first is extracting the files from the ROM firmware file, this is explained in many places and won't be covered here.
Extract the boot.img to some directory, using the Android unpackbootimg utility:
Code:
unpackbootimg -i boot.img -o boot/
After extracting the boot.img file you will usually end up with the following file list:
Code:
boot.img-base
boot.img-cmdline
boot.img-pagesize
boot.img-ramdisk.gz <- this includes the root (/) files, like init*.rc and SELinux policy files
boot.img-zImage <- compressed image of the Android Linux kernel
Next step will be extracting the compressed kernel image from the zImage file. The Android kernel is a self-extracting compressed file, while different devices use different compression methods. While looking at the file contents using hex editor, you can see the decompression code at the beginning, and then at some point the compressed data begins. The compressed image begins where you find the LZO magic header.
Code:
static const unsigned char lzop_magic[9] = {
0x89, 0x4c, 0x5a, 0x4f, 0x00, 0x0d, 0x0a, 0x1a, 0x0a
};
Save the data from the LZO magic header to the end of the file with the zImage.kernel file name.
This firmware and kernel are using LZO compression, and there is an easy to use utility called lzop that is used for the decompression of the file. Just run the following command to decompress the kernel from the zImage.kernel file:
Code:
lzop -d -c zImage.kernel > zImage.kernel.decompressed
And now you have the decompressed kernel for the device ready for exploration, which is also attached to this post.
Note:
I've tried using different scripts that do the job, including galaxys2_kernel_repack and http://forum.xda-developers.com/showthread.php?t=901152 but both failed while extracting the kernel image, although were able to extract the begin position for the LZO compression header.
Click to expand...
Click to collapse
I tried that and was given a warning of trailing bytes by `lzop`. Later when i do a `file` command on the resulting uncompressed file, it is not a vmlinux ELF image, rather it is a data file. How are we able to repack this image back into zImage? Any advise is appreciated thanks.
What i do if i have boot.img-kernel and boot.img-kernel_offset?
DGKG said:
What i do if i have boot.img-kernel and boot.img-kernel_offset?
Click to expand...
Click to collapse
The boot.img-kernel is your zimage file
What Source you used for Unpack?
Can you share link for you Scripts? or can you provide link to scripts for unpacking and repacking Note 9 Exynos Kernel?
Thanks
Typically users beat me to the punch on things such as this. But no one has yet to do so, so here it is.
How to extract your param partition:
Code:
It's located in /dev/block/sda4. On device terminal or in adb terminal as root run,
dd if=/dev/block/sda4 of=/sdcard/param.bin bs=4096
Now that your param partition has been dumped you can copy it off the device as I do to work with it. Untar it with this command on linux:
Code:
mkdir /param
cd param
tar xf /path/to/param.bin
Once its untared to the param directory, you will see the contents. logo.jpg being the file you wish to change.
Once you have found/made a proper logo/splash in the proper resolution of 1440x2560 copy it to the param folder overwriting the old logo.jpg, and run this command in the param folder to pack it back up:
Code:
tar cf - `ls | sort -t.` > /path/to/where/you/want/to/save/param.bin
NOTE: The param partition has limited space, so keep this in mind. I have successfully used a 400kb jpeg with out issues. I wouldn't go much more then that.
Place the param.bin back on your sdcard and run the following to flash it:
Code:
dd if=/sdcard/param.bin of=/dev/block/sda4 bs=4096
Reboot and enjoy.
Users wishing to deploy all these commands on device (if you don't run linux) here is a script I made, tested and working to do so. Place files on device accordingly.
Code:
#!/sbin/busybox sh
# Extracting param partition
dd if=/dev/block/sda4 of=/sdcard/param.bin bs=4096
mkdir /sdcard/param
cd /sdcard/param
tar xf /sdcard/param.bin
# Replaceing logo.jpg, repacking and writing back to device
cp -f /sdcard/logo.jpg /sdcard/param/logo.jpg
rm -f /sdcard/param.bin
tar cf - `ls | sort -t.` > /sdcard/param.bin
dd if=/sdcard/param.bin of=/dev/block/sda4 bs=4096
Attached you will find a flashable zip of a custom boot screen i made. You're all welcome to use. As well as the Stock param.bin in case users wish to go back. And the image I made for the custom boot splash I'm attaching.
-Mr. X- said:
Typically users beat me to the punch on things such as this. But no one has yet to do so, so here it is.
How to extract your param partition:
Code:
It's located in /dev/block/sda4. On device terminal or in adb terminal as root run,
dd if=/dev/block/sda4 of=/sdcard/param.bin bs=4096
Now that your param partition has been dumped you can copy it off the device as I do to work with it. Untar it with this command on linux:
Code:
mkdir /param
cd param
tar xf /path/to/param.bin
Once its untared to the param directory, you will see the contents. logo.jpg being the file you wish to change.
Once you have found/made a proper logo/splash in the proper resolution of 1440x2560 copy it to the param folder overwriting the old logo.jpg, and run this command in the param folder to pack it back up:
Code:
tar cf - `ls | sort -t.` > /path/to/where/you/want/to/save/param.bin
NOTE: The param partition has limited space, so keep this in mind. I have successfully used a 400kb jpeg with out issues. I wouldn't go much more then that.
Place the param.bin back on your sdcard and run the following to flash it:
Code:
dd if=/sdcard/param.bin of=/dev/block/sda4 bs=4096
Reboot and enjoy.
Users wishing to deploy all these commands on device (if you don't run linux) here is a script I made, tested and working to do so. Place files on device accordingly.
Code:
#!/sbin/busybox sh
# Extracting param partition
dd if=/dev/block/sda4 of=/sdcard/param.bin bs=4096
mkdir /sdcard/param
cd /sdcard/param
tar xf /sdcard/param.bin
# Replaceing logo.jpg, repacking and writing back to device
cp -f /sdcard/logo.jpg /sdcard/param/logo.jpg
rm -f /sdcard/param.bin
tar cf - `ls | sort -t.` > /sdcard/param.bin
dd if=/sdcard/param.bin of=/dev/block/sda4 bs=4096
Attached you will find a flashable zip of a custom boot screen i made. You're all welcome to use. As well as the Stock param.bin in case users wish to go back. And the image I made for the custom boot splash I'm attaching.
Click to expand...
Click to collapse
Very nice! Thanks
If your phone is showing the "Custom (unlocked)" icon, will this override that?
Does this overwrite the carrier boot screen.
cambunch said:
If your phone is showing the "Custom (unlocked)" icon, will this override that?
Click to expand...
Click to collapse
In download mode? no it will not.
Thoth33 said:
Does this overwrite the carrier boot screen.
Click to expand...
Click to collapse
If the carrier put their logo in the param yes. if its a kernel boot animation no.
-Mr. X- said:
In download mode? no it will not.
Click to expand...
Click to collapse
During a regular boot. This is the first image that you see when powering on a phone, correct?
cambunch said:
During a regular boot. This is the first image that you see when powering on a phone, correct?
Click to expand...
Click to collapse
correct
This looks awesome! I'll have to prep an image to try out!
Edit:
After giving this a try, I appear to have managed to brick my phone. It seems that the only thing I can boot into is Download mode, and reflashing the firmware has not fixed this. Any ideas on how to resolve this? Much appreciated!!
Edit 2:
I saved myself with the Smart Sync (or whatever it's called) program on my PC. I was only able to do it though because I had written down the "Serial Number" for "just in case" purposes some time ago. I'm actually going to do a separate post to make this point for anyone who has similar issues but not from modifying boot splash.
The attached zip files work perfect on my S6 Edge. I unzipped the file, copied param.bin to my sdcard and used dd from the shell. Still trying to get a custom image to work. Getting a grey screen when I replace logo.jpg with my own. Any ideas?
Thanks again for sharing this -Mr. X-.
@-Mr. X-
Could you tell me which software you used to make your custom logo.jpg? I'm using photoshop on mac, however, everything made on this leads to the gray screen.
Thank you.
Can you please add 'powered by android' with new bugdroid icon on the bootsplash
Sent from my SM-G920I using Tapatalk
Will this work on the 925T edge?
I used Gimp, then i opened the picture in Microsoft Paint and re-saved it. I also ran into this but didn't know if Gimp was the cause but., this method worked for me.
It should also work on the edge but ensure your param partition is sda4 just to be safe.
-Mr. X- said:
I used Gimp, then i opened the picture in Microsoft Paint and re-saved it. I also ran into this but didn't know if Gimp was the cause but., this method worked for me.
It should also work on the edge but ensure your param partition is sda4 just to be safe.
Click to expand...
Click to collapse
Will do
The grey screen seems to be an issue while packing the files back with tar on Mac. I used photoshop on mac to make logo.jpg and packed it using tar on ubuntu. Works on 925I. And sda4 is the partition on edge as well for the bootsplash. Thanks for the help.
How to you get this to work little confused. Do you unzip the file or do you flash the zip
UAAO
Enviado desde mi SM-N910C mediante Tapatalk
Confuse bro .
Splaind tutorial
Can seone explaim how to change the splash screen thanls
ob1silvia said:
Can seone explaim how to change the splash screen thanls
Click to expand...
Click to collapse
Hi,
You can flash the zip file in post 1, with custom recovery..
Work perfect here, thx @-Mr. X-
Hi all,
I am trying to get an insecure kernel for Nexus 6, marshmallow 6.0, and I stuck at a bootloop.
The AOSP tag android-6.0.0_r1 builds without any errors. Then I flash the produced insecure boot image on a nexus 6, which had the latest 6.0 factory images.
Has anyone managed to do this procedure?
Btw, I am compiling the AOSP sources, and not the kernel sources.
In AOSP, I think, the kernel/zImage is precompiled, and the aosp build system bundles it into a boot image.
So, if someone has managed to build a working insecure boot.img from any marshmallow branch please let me know.
Or has done the same thing from kernels sources, also let me know.
EDIT:
How to compile an insecure kernel:
0. This will use the precompiled kernel found in aosp sources.
So we are not actually compiling. But this title might help some folks googling the topic.
2. modify device/<maker>/<codename>/fstab.<codename>/, and remove verify tag from system
3. make -jN bootimage
Alternatively, you can follow the procedure by ziddey, and removing the verify tag from fstab.shamu, allows the kernel to be booted!
NOTE: insecure kernel is not permissive.
How to compile a permissive kernel:
0. Now we will actually compile the kernel.
1. Download the kernel sources, and checkout the branch you want. Do these modifications.
Finally compile the kernel. (There are many tutorials for kernel compilation online)
2. copy the kernel (arch/arm/boot/zImage-dtb) to your aosp_dir/device/<maker>/<codename>-kernel/
3. Disable verification (as w/ insecure kernel)
4. make -j8 bootimage
How to compile an insecure and permissive kernel:
Not sure about this. I 'd play with configurations in aosp_dir/device/<maker>/<codename>,
or maybe try an eng build. If anyone knows just post it!
I have tried these with the kernel branch "android-msm-shamu-3.10-marshmallow-mr1",
and the aosp tag "android-6.0.1_r21".
I have also tried to unpack and repack the boot.img using unpackbootimg and mkbootimg from https://github.com/osm0sis/mkbootimg.
I have extracted ramdisk, edited the default prob, repacked ramdisk, and packed using:
Code:
mkbootimg --kernel su_boot.img-zImage --ramdisk su_boot.img-ramdisk.gz --cmdline 'console=ttyHSL0,115200,n8 androidboot.console=ttyHSL0 androidboot.hardware=shamu msm_rtb.filter=0x37 ehci-hcd.park=3 utags.blkdev=/dev/block/platform/msm_sdcc.1/by-name/utags utags.backup=/dev/block/platform/msm_sdcc.1/by-name/utagsBackup coherent_pool=8M' --base 00000000 --pagesize 2048 --kernel_offset 00008000 --ramdisk_offset 02000000 --tags_offset 01e00000 --board "" -o ins_su_boot.img
Have I missed anything?
*EDIT* also tried w/ 'abootimg'. Still no luck.
Screwing around with random files found on the internet is not going to solve your problem. Use the program from *AOSP*. And make sure your parameters match (I'm not going to verify them for you). Bootloops are always cute, what did you change? Typically running make bootimg should make you a good bootimg from AOSP sources.
Well, turns out that in this case, that assumption is not correct.
The first issue is that the verity keys are not present in a custom built boot.img. At least not ones without also involving an entire system build (not that they would match the system partition that you already have).
So to solve that, edit the fstab file in the shamu device tree to remove the verify parameter from the system partition. Once that is done, it should no longer randomly reboot.
UNFORTUNATELY, that may not be enough to make the whole thing work properly still, since there appears to be some other differences between the AOSP userdebug's boot.img and the google user build. You will be able to adb in, but the android subsystem won't run.
These utilities I have used were the ones that have been successfully used to pack/unpack boot images by others. I have also done this successfully in the past, for another device running earlier versions.
Yeap. That's the problem. A kernel build from AOSP sources does not work out of the box with the rest of the system, if it is a production build. This used to work for Lollipop, but I guess they tighten security up.
Building zImage from kernel sources is still not a solution for me, as I can't properly pack/unpack a Marshmallow boot.img
The problem might be something very stupid, OS specific, and I don't want to waste any more time on this.
For now I will live with SuperSu and adbd insecure.
Maybe at some point I might try to remove the verification to see whether the rest of the stuff play nicely.
Thanks for your time!
[edit]
Answer is root. http://forum.xda-developers.com/showpost.php?p=64110288&postcount=1283
[/edit]
I spent a while tonight trying to figure this out as well. Simply dumping boot.img and recreating it works fine. But something goes wrong when unpacking/repacking the ramdisk. Stripping bootsize from bootimg.cfg so abootimg recalculates it doesn't help.
1. I did find that mkboot "works": https://github.com/ModdingMyMind/mkbootimg_tools
Simply run `mkboot boot.img boot` to dump to dir boot. Make changes to ramdisk, and then run `mkboot boot newboot.img` to create a new image. However, for whatever reason, this causes at least one issue for me. The sbin dir, despite being 755 in the ramdisk is 750 again in Android. Not sure what's going on here since I can redump newboot.img and confirm that sbin is 755.
2. I looked at seSuperuser/super-bootimg and found https://github.com/seSuperuser/super-bootimg/blob/master/scripts/bootimg.sh
The relevant part is in doneBootImgEdit(). Looking at the comments, Husson found that appending the changes to the inflated ramdisk cpio and then deflating it works. I just tested this and indeed it does work.
Husson only appends new/changed files; as a test, I tried appending the entire new ramdisk onto the old one, and sure enough, it bugs out again. Will have to investigate why this happening later, but for now, this is good enough.
As well, abootimg also comes with the tools abootimg-pack-initrd and aboot-unpack-initrd, which takes care of gzip/cpio. Of course, since the packing part doesn't work, we can't use it.
So, here's an example. Say you want to change fstab.shamu (to remove /system verification and/or /data forced encryption):
Code:
# extract boot.img
abootimg -x boot.img
# unpack the extracted initrd.img to ramdisk dir
abootimg-unpack-initrd
cd ramdisk
# make your changes to ramdisk/fstab.shamu here....
echo fstab.shamu | cpio -o -H newc > ../initrd2
cd ..
# inflate initrd.img
cp initrd.img initrd.gz
gunzip initrd.gz
# append and create new initrd.img
cat initrd initrd2 |gzip -9 -c > newinitrd.img
# strip bootsize from bootimg.cfg
sed 1d bootimg.cfg > newbootimg.cfg
# create new boot.img
abootimg --create newboot.img -f newbootimg.cfg -k zImage -r newinitrd.img
newboot.img should be a working boot image. If modifying multiple files, it may be easiest to create a different dir with those files and use find . |cpio -o -H newc > ../initrd2
Hope this helps. And if anyone can explain why this is necessary / how to recreate initrd from scratch, I can continue being lazy.
Thanks @phhusson
[edit]
Damn. I tried applying a different init file and it ate ****.
[/edit]
ziddey said:
I spent a while tonight trying to figure this out as well. Simply dumping boot.img and recreating it works fine. But something goes wrong when unpacking/repacking the ramdisk. Stripping bootsize from bootimg.cfg so abootimg recalculates it doesn't help.
1. I did find that mkboot "works": https://github.com/ModdingMyMind/mkbootimg_tools
Simply run `mkboot boot.img boot` to dump to dir boot. Make changes to ramdisk, and then run `mkboot boot newboot.img` to create a new image. However, for whatever reason, this causes at least one issue for me. The sbin dir, despite being 755 in the ramdisk is 750 again in Android. Not sure what's going on here since I can redump newboot.img and confirm that sbin is 755.
2. I looked at seSuperuser/super-bootimg and found https://github.com/seSuperuser/super-bootimg/blob/master/scripts/bootimg.sh
The relevant part is in doneBootImgEdit(). Looking at the comments, Husson found that appending the changes to the inflated ramdisk cpio and then deflating it works. I just tested this and indeed it does work.
Husson only appends new/changed files; as a test, I tried appending the entire new ramdisk onto the old one, and sure enough, it bugs out again. Will have to investigate why this happening later, but for now, this is good enough.
As well, abootimg also comes with the tools abootimg-pack-initrd and aboot-unpack-initrd, which takes care of gzip/cpio. Of course, since the packing part doesn't work, we can't use it.
So, here's an example. Say you want to change fstab.shamu (to remove /system verification and/or /data forced encryption):
Code:
# extract boot.img
abootimg -x boot.img
# unpack the extracted initrd.img to ramdisk dir
abootimg-unpack-initrd
cd ramdisk
# make your changes to ramdisk/fstab.shamu here....
echo fstab.shamu | cpio -o -H newc > ../initrd2
cd ..
# inflate initrd.img
cp initrd.img initrd.gz
gunzip initrd.gz
# append and create new initrd.img
cat initrd initrd2 |gzip -9 -c > newinitrd.img
# strip bootsize from bootimg.cfg
sed 1d bootimg.cfg > newbootimg.cfg
# create new boot.img
abootimg --create newboot.img -f newbootimg.cfg -k zImage -r newinitrd.img
newboot.img should be a working boot image. If modifying multiple files, it may be easiest to create a different dir with those files and use find . |cpio -o -H newc > ../initrd2
Hope this helps. And if anyone can explain why this is necessary / how to recreate initrd from scratch, I can continue being lazy.
Thanks @phhusson
[edit]
Damn. I tried applying a different init file and it ate ****.
[/edit]
Click to expand...
Click to collapse
My guess, and the reason why I tried appending without further thinking, is that the new initramfs files contains SELinux labels, which standard GNU/Linux cpio tool doesn't support.
One would have to investigate the changes in mkbootfs done recently.
Also, I guess mkboot is using Android's mkbootfs, which forces the permissions by itself I think.
Though the fact that extracting back give the result you expected is weird.
In super-bootimg I chose to change init.rc to chmod /sbin
Wow. http://forum.xda-developers.com/showpost.php?p=64110288&postcount=1283
Just tested and sure enough, everything is working.
Thanks @shoey63
Hopefully a final update:
The difference is in ownership. Unpacking (cpio -i) as a regular user will not preserve the ownership. However, repacking (cpio -o) does.
To repack, add -R 0.0 to cpio (i.e. --owner root.root).
e.g.
Code:
find . |cpio -o -H newc -R 0.0 | gzip -9 > ../newinitrd.img
I just tested and this works just fine without being root.
ziddey said:
Hopefully a final update:
The difference is in ownership. Unpacking (cpio -i) as a regular user will not preserve the ownership. However, repacking (cpio -o) does.
To repack, add -R 0.0 to cpio (i.e. --owner root.root).
e.g.
Code:
find . |cpio -o -H newc -R 0.0 | gzip -9 > ../newinitrd.img
I just tested and this works just fine without being root.
Click to expand...
Click to collapse
Erf that's weird, I'm pretty sure I always ran the script as root...
Anyway, thanks for the info! I'll probably update my scripts with it
I just wanted to post that using root to extract the cpio file fixed the boot failure for me on my Nexus 9 with 6.0.1. You also need to use root to find the files and create the cpio file because some files are only accessible by root of course. I guess that should have been obvious (usually needed for /dev nodes) as @phhusson said, but this time I didn't do that until reading here.
To unpack the boot.img file I used: https://github.com/osm0sis/mkbootimg.git
To pack the boot.img file I used: https://android.googlesource.com/platform/system/core/+/master/mkbootimg
I'm not sure you need the official google packer, but I just happened to use when it worked.
EDIT: I needed to update boot.img and I tried it using the osm0sis packer and it worked.
Hey guys. Thanks for the replies!
I needed a permissive kernel this time, and I have played around with the sources and your recommendations and got it working. :good:
The post by ziddey might be the easiest way to make any kernel bootable, by disabling the verification from fstab.
(and uses just one packing/unpacking tool)
You can do the same thing from sources, again by modifying the fstab on aosp.
You can build an insecure kernel by using the pre-built kernel (is aosp),
or compile and then pack a permissive one.
This procedure wasn't working for me back then when I tried it (hence this thread). I am not sure if it was my fault or the initial marshmallow release had differences from the sources. More info on the first post.
I have a ROM that I can flash on Samsung S10 5G(Qualcomm) successfully. My goal is to check whether I can modify `system.img` file of the ROM or not but before modification, I just want to verify that the AP file can be flashed after unpacking and packing of the `system.img`. To check this I have tried following:
Unpack-Pack AP file:
A) `tar` flashing:
1. Extracted AP file using `tar -xf AP...tar.md5` command.
2. Compress the extracted files using `tar -cvf AP...tar *`
3. Flash it with Odin3 v3.13.
B) `tar.md5` flashing:
- Get tar by following steps in A) and then run `md5sum -t AP...tar >> AP...tar` and `mv AP...tar AP...tar.md5`
Both `Ap...tar` and `AP...tar.md5` flashed successfully.
Unpack-Pack `system.img.ext4.lz4`
1. Extracted AP file using `tar -xf AP...tar.md5` command. Extracted files are "*boot.img.lz4*, *meta-data*, *userdata.img.ext4.lz4*, *carrier.img.ext4.lz4*, *persist.img.ext4.lz4*, *vbmeta.img.lz4*, *dqmdbg.img.ext4.lz4*, *recovery.img.lz4*, *vendor.img.ext4.lz4*, *dtbo.img.lz4*, *system.img.ext4.lz4*".
2. Extract system file using `unlz4 system.img.ext4.lz4` command. This is giving me a `system.img.ext4` Android sparse image.
3. Tried following commands to compress `system.img.ext4` without doing any modification:
lz4 system.img.ext4 system.img.ext4.lz4 - Default Compression
lz4 -9 system.img.ext4 system.img.ext4.lz4 - High Compression
lz4 -l system.img.ext4 system.img.ext4.lz4 - Default Compression in Legacy format
lz4 -l -9 system.img.ext4 system.img.ext4.lz4 - High Compression in Legacy format
lz4 -0 -l system.img.ext4 system.img.ext4.lz4 - No Compression in Legacy format
lz4 -B4 system.img.ext4 system.img.ext4.lz4 - Default Compression with Block size 4
lz4 -B5 system.img.ext4 system.img.ext4.lz4 - Default Compression with Block size 5
lz4 -B6 system.img.ext4 system.img.ext4.lz4 - Default Compression with Block size 6
lz4 --no-frame-crc system.img.ext4 system.img.ext4.lz4 - Default Compression with no crc frame
Click to expand...
Click to collapse
and make an AP file by replacing the original `system.img.ext4.lz4` file with the compressed file from above command(one at one time) and tried to flash it but every time it fails with **"Odin FAIL! LZ4 is invalid"**
LZ4 command detail:
1. Working on Ubuntu 18
2. Using "LZ4 command line interface 64-bits r128, by Yann Collet (Apr 3 2018)"
Tried with "LZ4 command line interface 64-bits v1.9.2, by Yann Collet" but get the same result.
`file system.img.ext4.lz4` output:
- Original file: `system.img.ext4.lz4: LZ4 compressed data (v1.4+)`.
- My version with both LZ4 (r128 and v1.9.2):
1. For file compressed with legacy flag(-l): `system.img.ext4.lz4: LZ4 compressed data (v0.1-v0.9)`
2. For file compressed without legacy flag(-l): `system.img.ext4.lz4: LZ4 compressed data (v1.4+)`
So, I think it means the file should be compressed without legacy flag.
Size
1. With `-9` flag i.e. High Compression the output file is of 3.3 GB.
2. Without `-9` flag i.e. Default Compression the output file is of 3.6 GB.
The Original file is of size 3.6 GB so, I think high compression should not be used.
But still the same error throws by Odin.
Any suggestion why it is happening?
having the same problem here.anyone have a solution?
Why Ya dont use "lz4 -m *.lz4" command after Extract with tar, its Decompress all Files in one Process!!
But iam have the same Problem i would a Existing Package tar.md5 Extract and Replace the system.img.lz4 with a newer Version, so i have Compress the IMG to LZ4 with these Command
"lz4 -B6 --content-size system.img system.img.lz4" and then Pack all to tar and add md5sum!! and Flash the Package it would like ya Failed at System Flash Process!!!