This tool can be used to either decompile or compile ROMs for various Asus devices that used the ABI firmware format (Can also be used in O2 XDA Zest ). The current version can support P835 unencrypted ABI, and even encrypted ABI from updater EXE! Current finding is this tool also supports unreleased Garmin-Asus ROMs!
Thanks (Especially )Harshal and Leon in AsusPda for testing.
Usage:
- Decompiling ROM
1. p835abisplit2 <abi/exe file>
2. os.nb0 and extrom.img released (Only for Pre-P835 devices), os.nb0 cab be processed by imgfsfromnb or osnbtool, extrom.img can be processed by WinImage.
- Compiling ROM
1. First rename the new os.nb0 to os-new.nb0, and rename extrom.img to extrom-new.img (If the new files do not exist, then the compiler will use the parts from original ROM)
2. p835abisplit2 /b <abi/exe file>
3. out.abi releases, which can be used to flash directly (Only for Pre-P835 devices or Post-P835 devices with unencrypted ROM).
4. If you input the updater EXE to p835abisplit2, it will also produce out.exe with region locked patched which can be used to flash your new ROM directly on devices with any region!
- Note when building ROM
1. If you need to modify XIP, make sure the modded XIP is the same size as the original one before merging back to nb0, otherwise booting will fail
2. For Pre-P835 devices, current version can create big-storage ROMs with variable size of imgfs. If the new OS is smaller than the original one, the freed space will be allocated to user space (The left part as shown in Memory setting) after flashing. However the user space display will only reflect the change on second flash.
3. For Post-P835 devices, all partitions must be exactly same size with the original one (i.e. you need to pad the partition before putting it back), otherwise the device won't boot.
4. For Pre-P835 devices, you can modify ExtROM as you like, but not remove or rebuild the image file, otherwise you may get a brick! (Not able to enter bootloader)
Final Warning: Customizing a ROM always has risks, I won't be responsible for any damages lead to your custom ROM!
Release Notes:
v2.40:
- Added support for M930
v2.32:
- Support extraction of encrypted ABI file resource from P835 updater exe
- Support reconstruction of P835 updater exe
- When rebuild to exe, the produced out.exe is patched to install in devices of any region.
V2.20:
- Support extration and rebuilding of P835 ABI file (Note that not for ABI inside EXE)
- When rebuild with exe, OUT.EXE will be produced for direct flashing
starkwong said:
This tool can be used to either decompile or compile ROMs for various Asus devices that used the ABI firmware format (Can also be used in O2 XDA Zest ).
Thanks Harshal and Leon in AsusPda for testing.
Usage:
- Decompiling ROM
1. p565abisplit2 <abi/exe file>
2. os.nb0 and extrom.img released, os.nb0 cab be processed by imgfsfromnb or osnbtool, extrom.img can be processed by WinImage.
- Compiling ROM
1. First rename the new os.nb0 to os-new.nb0, and rename extrom.img to extrom-new.img (If the new files do not exist, then the compiler will use the parts from original ROM)
2. p565abisplit2 /b <abi/exe file>
3. out.abi releases, which can be used to flash directly.
- Note when building ROM
1. If you need to modify XIP, make sure the modded XIP is the same size as the original one before merging back to nb0, otherwise booting will fail
2. OS part doesn't need to be the same size as the original. If the new OS is smaller than the original one, the freed space will be allocated to user space (The left part as shown in Memory setting) after flashing. However the user space display will only reflect the change on second flash.
3. You can modify ExtROM as you like, but not remove or rebuild the image file, otherwise you may get a brick! (Not able to enter bootloader)
Final Warning: Customizing a ROM always has risks, I won't be responsible for any damages lead to your custom ROM!. Moreover, don't use it in P835 abi, it won't work
Click to expand...
Click to collapse
Nice we all waiting for it
Many Congrats for successfully ripping through the ROM !!
Partition offsets and checksums reported by the tool are :
Part #0002 sz:0003e000=>0003e000 cs:625f94b2=>625f94b2 of:000003a0=>000003a0
Part #0004 sz:00100000=>00100000 cs:ffe5f731=>ffe5f731 of:0003e3a0=>0003e3a0
Part #0103 sz:00452a8c=>00452a8c cs:99f65978=>99f65978 of:0013e3a0=>0013e3a0
Part #0104 sz:000fffc0=>000fffc0 cs:5e03943f=>5e03943f of:00590e2c=>00590e2c
Part #0005 sz:07e00000=>07e00000 cs:674f4072=>674f4072 of:00690dec=>00690dec
Part #0013 sz:00a00000=>00a00000 cs:56994bf9=>56994bf9 of:08490dec=>08490dec
I am a little scared to use this tool for following reasons :
1. Actually, the IMGFS & ExtROM offsets are '00690dfc' & '08490dfc' respectively.
2. Checksums( 674f4072, 56994bf9....) can not be located in the Header.
3. The Adler32 checksum for the ExtROM is '5ff94bfa', while your tool reports '56994bf9'.
Any clues ?
rishi2504 said:
Many Congrats for successfully ripping through the ROM !!
Partition offsets and checksums reported by the tool are :
Part #0002 sz:0003e000=>0003e000 cs:625f94b2=>625f94b2 of:000003a0=>000003a0
Part #0004 sz:00100000=>00100000 cs:ffe5f731=>ffe5f731 of:0003e3a0=>0003e3a0
Part #0103 sz:00452a8c=>00452a8c cs:99f65978=>99f65978 of:0013e3a0=>0013e3a0
Part #0104 sz:000fffc0=>000fffc0 cs:5e03943f=>5e03943f of:00590e2c=>00590e2c
Part #0005 sz:07e00000=>07e00000 cs:674f4072=>674f4072 of:00690dec=>00690dec
Part #0013 sz:00a00000=>00a00000 cs:56994bf9=>56994bf9 of:08490dec=>08490dec
I am a little scared to use this tool for following reasons :
1. Actually, the IMGFS & ExtROM offsets are '00690dfc' & '08490dfc' respectively.
2. Checksums( 674f4072, 56994bf9....) can not be located in the Header.
3. The Adler32 checksum for the ExtROM is '5ff94bfa', while your tool reports '56994bf9'.
Any clues ?
Click to expand...
Click to collapse
Tool works properrly.No harm is trying
starkwong, is there any tool to decompile P835's ROM in the same way?
New version posted.
rishi2504:
The image checksum is not calculated by plain Adler32, actually is uses the same formula as older Asus ROMs, however it is not a one-time calculation.
Checksums are inside header, given you decoded it correctly.
starkwong, here's what I get when trying to decompile a ROM:
Code:
v2.40 (Jun 16 2009 19:56:06)
ExtractABI(): Trying to load G5_ALL_V4.11.0_V3.6.12.P2_Ship_WWE_app_MYS00_V2.3.6.exe...
Module loaded, searching for BIN resource...
Found matching resource at BIN #211!
GetPartitions(): Getting Partition Information...
*** Encrypted ABI detected
ABI Version 0x00030012
Project Name: G5
Partition Type: 000f [email protected]
Partition Type: 000e [email protected]
Partition Type: 000e [email protected]
Partition Type: 0004 [email protected]
Partition Type: 0004 [email protected]
Partition Type: 000f [email protected]
Partition Type: 000f [email protected]
Partition Type: 0102 damage [email protected]
Partition Type: 0005 UnKnown [email protected]
Partition Type: 0002 [email protected]
Partition Type: 0003 [email protected]
ProcessABI(): Writing OS data...
* BIN(P835) Image Detected
Warning: OS.nb0/flash.bin is not a NB image, not modifying MSFLSH50 headers
ProcessABI(): No ExtROM partition found.
OK!
So it seems that partitions are not detected correctly, there's no os.nb0 at the output, and the flash.bin apperars to be of no use. Even when I found imgfs partition inside of it, there's still something wrong with it, e.g. bad start block offset, and everything else is also broken.
Can you help me with this?
In fact it is correct, as Asus uses B000FF image on P835, not a plain NB0 image.
You need to use osnbtool to get a nb0 with extra bytes, then use nbsplit -data 2048 -extra 8 to get a nb0 with sector size 0x800.
ginkage said:
starkwong, here's what I get when trying to decompile a ROM:
Code:
v2.40 (Jun 16 2009 19:56:06)
ExtractABI(): Trying to load G5_ALL_V4.11.0_V3.6.12.P2_Ship_WWE_app_MYS00_V2.3.6.exe...
Module loaded, searching for BIN resource...
Found matching resource at BIN #211!
GetPartitions(): Getting Partition Information...
*** Encrypted ABI detected
ABI Version 0x00030012
Project Name: G5
Partition Type: 000f [email protected]
Partition Type: 000e [email protected]
Partition Type: 000e [email protected]
Partition Type: 0004 [email protected]
Partition Type: 0004 [email protected]
Partition Type: 000f [email protected]
Partition Type: 000f [email protected]
Partition Type: 0102 damage [email protected]
Partition Type: 0005 UnKnown [email protected]
Partition Type: 0002 [email protected]
Partition Type: 0003 [email protected]
ProcessABI(): Writing OS data...
* BIN(P835) Image Detected
Warning: OS.nb0/flash.bin is not a NB image, not modifying MSFLSH50 headers
ProcessABI(): No ExtROM partition found.
OK!
So it seems that partitions are not detected correctly, there's no os.nb0 at the output, and the flash.bin apperars to be of no use. Even when I found imgfs partition inside of it, there's still something wrong with it, e.g. bad start block offset, and everything else is also broken.
Can you help me with this?
Click to expand...
Click to collapse
B000FF image cannot be modified without osnbtool or viewbin or cvrtbin tool..For Ext ROM there is no partition in the abi file which can b read as .nb0 Ext ROM is inside the OS and is not as a partition.So what the output u get from the tool is correct.Whatever ROMs u saw mine are from using the same tool
I hope this clarifies.
starkwong, Thank you so much, it worked perfectly!
Can't use this tool on my Asus M530w. Getting this message:
Copyright(C) 2009 Studio KUMA(starkwong). All rights reserved
v2.40 (Jun 16 2009 19:56:06)
ExtractABI(): Trying to load nk.abi...
Failed loading as module (193). Perhaps ABI?
Trying as ABI directly...
Creating file mapping...
GetPartitions(): Getting Partition Information...
Error: AES Key not suitable for this ROM
unencrypted vers encrypted
There is little bit mess in description.
If you will use unecrypted rom + p835abisplit2 you will get os.nb0.
With encrypted rom + p835abisplit2 you will get flash.bin.
starkwong said:
4. For Pre-P835 devices, you can modify ExtROM as you like, but not remove or rebuild the image file, otherwise you may get a brick! (Not able to enter bootloader)
Click to expand...
Click to collapse
Hi,
Can i add my own cab/xml files to this Ext_ROM, after removing the files not needed ?
rishi2504 said:
Hi,
Can i add my own cab/xml files to this Ext_ROM, after removing the files not needed ?
Click to expand...
Click to collapse
Don't bother dude , figured it out ...
Is there anyway I can extract the flash.bin file from a .abi file using this tool?
My P835 is unable to upgrade from the SD card with the .abi file on it.. so I wanted to extract the flash.bin and see if I can use the QPST tool to update the image with flash.bin file..
Sorry if I'm being stupid here (not unusual!). I'm trying to use this tool to get a .abi file out of O2's "Xda_Zest Firmware Update_V7.7.0S.WWE20.00_M4.6.5.P7_V2.1.4 GBR20.exe" so I can stick it on the SD card and flash the ROM, but of course I'm only ending up with the two files you mention, os.nb0 and extrom.img, no .ABI file. I can look in the extrom.img file with winrar, but the file only contains FINDMA~1.000 (300 bytes), 000dummy.001 (0 bytes) and _setup.xml (1205 bytes).
Plainly I'm thick - where am I going wrong, and how do I get the .ABI file?
Related
In the Excalibur forum we are struggling to flash a file to a particular offset in NAND (samsung onedisk flash). The file is 4Mbyte and was dumped with bkondisk (by itsme). Deploying pof's ideas, I have patched Excalibur SPL which bypasses vendor/model and signature checking and raises security level to 0. Using this SPL the flash commands can be used w/o restrictions
A similar patched bootloader exists for Vox S710. That SPL includes same commands as the Excalibur SPL.
The SPL offers 2 commands to interactively flash files from MTTY: ls ("load signed"??) and lnbs ("load new binary signed"??)
Afaik the commands are invoked as:
Code:
lnbs [pathname [StartAddr [Length [SkipOffset ["cp"]]]]]
ls [pathname [StartAddr [Length [SkipOffset ["cp"]]]]]
The question is what format the files must have and how to figure out start address. I found some info in the Hermes Wiki. I also suggested Excalibur various tests:
1. The file test3.nbs in this case has a 0x20 byte header ("R000FF") which includes data blocksize and signature size and flag. But somehow it doesn't like the start address of which I also don't know how to figure it out for the various ROM parts. How was that done for Hermes? (reversing SPL or sniffing USB)
Code:
Cmd>lnbs test3.nbs 500a0000
clean up the image temp buffer at 0x8C080000 Length 0x03900000
MTTYDownloadImage "test3.nbs"
:F=test3.nbs
start download
S
HAddress A0000000h Length 0040034Dh
Start Address out of boundary
checking image header
2. The file test.nb w/o any header, just the 4MB binary file with no modifications
Code:
Cmd>ls test.nb 500a0000
clean up the image temp buffer at 0x8C080000 Length 0x03900000
MTTYDownloadImage "test.nb"
:F=test.nb
start download
S
HAddress A0000000h Length 00400000h
Start Address out of boundary
checking image header
3. The file test2.nbh with a full .nbh header and given type 0x300 (GSM Radio code, although the 4MB file also includes config and simlock data etc.). This was actually the most succesful since it passed mosts tests in the SPL. So it seems a valid file, but it couldn't be confirmed that anything was flashed at all.
Code:
Cmd>lnbs test2.nbh 500a0000
clean up the image temp buffer at 0x8C080000 Length 0x03900000
MTTYDownloadImage "test2.nbh"
:F=test2.nbh
start download
S
HAddress 00000000h Length 0040054Dh
Start Address out of boundary
checking image headerFirst MTTY record empty
Image Download Finish... please check your image
Please reset the device to restart the program!!
DownloadImage success.
Can anyone with more knowledge about this subject please drop some feedback? Thx!
Cheers
JockyW
Edit: I totally forgot about the wdata command which is used by the official RUU. It can not be used interactive from MTTY, but it is possible to use it from self written programs. I think the idea is that only signed .nbh files (which include ROM type information in the header) can use be flashed using this command:
Code:
wdata length checksum
Once all data and the last signature (flag == 2) has been sent to SDRAM and all CRC and sig checks are passed the flashing process starts. The funny thing is that the help text of wdata suggests that also unsigned data can be flashed or be dropped at any memory location. Is this intentional deceiving by HTC ??
Code:
Cmd>wdata
Usage:
wdata [StartAddr Len]
Write data to memory(if write to ROM, need erase first).
StartAddr : Start address of memory.
Len : How many bytes will be written.
Length must not more than 0x10000 bytes(buffer limitation).
Write to RAM: 4 bytes(CRC checksum limitation).
1 byte(in user mode).
Write to ROM: 4 bytes(CRC checksum limitation).
2(16-bit)/4(32-bit) bytes(in user mode).
Write to ROM(16-bit data bus): 32 bytes(writebuffer mode).
Write to ROM(32-bit data bus): 64 bytes(writebuffer mode).
Length must be 4 bytes boundary(CRC checksum) if not in user mode.
After command execute, then send out the data to terminal.
Data format: HTCS(4 bytes)+DATA+checksum(4 bytes, if not in user mode)+HTCE(4 bytes).
while flashing test2.nbh, wlan data doesn't be modified.
jockyw2001's question is very important to find our wi-fi back. plz help us!Thanks!
details about our problem and what we have done can be seen at http://forum.xda-developers.com/showthread.php?t=328690
jockyw2001
You may use method imei-check - they for flash of the area CID have changed address of the flash splash screen - hereinafter they form file nbh (consists only of splash screen) with necessary area CID.
arc said:
jockyw2001
You may use method imei-check - they for flash of the area CID have changed address of the flash splash screen - hereinafter they form file nbh (consists only of splash screen) with necessary area CID.
Click to expand...
Click to collapse
Ah great! You've got a link as well? Thx!
Hi jocky,
interesting thing..
why don;t u try its utils for the above and check..
issue pdcocread -l command and get the header and rom address.
then try with lnbs or ls command to flash back.From whatever I know, lnb and lnbs/ls command can b used when yr device is Super CID.
While flahing ROM, RUU issues set le 1 command and write the ROM using wdata command.You can check these things, with USB monitor
hdubli
The commands lnb and lnbs different -
lnb - load the unsigned code.
lnbs- load signed code -have other structure and headline
hdubli said:
issue pdcocread -l command and get the header and rom address.
then try with lnbs or ls command to flash back.From whatever I know, lnb and lnbs/ls command can b used when yr device is Super CID.
Click to expand...
Click to collapse
hi,
pdocread -l returns:
Code:
>pdocread.exe -l
58.82M (0x3ad1000) DSK1:
| 2.09M (0x217400) Part00
| 3.20M (0x333000) Part01
| 53.53M (0x3586800) Part02
59.31M (0x3b4f000) DSK2:
| 59.06M (0x3b0e800) Part00
...
You mean the values in parantheses?
On excalibur only signed data is accepted by ls or lnbs (dunno the difference between the two. Anyone?).
I disassembled spl and found the startaddress boundary check routine. In it I see the hardcoded nand address boundaries which have no resemblance whatsoever with pdocread.
I'm now checking arc's hint to patch splash screen flashroutine in same way as imei-check does it. I just hope I can use ls and lnbs (with USPL of course), since that would be far more comfortable
I have written a updater-script to do this, but I am not sure whether it works. Can anybody give me some suggestion?
Code:
ui_print("Changing Moto Rom");
ui_print("Updating boot");
show_progress(0.330000,2);
assert(package_extract_file("boot.img", "/tmp/boot.img"),
write_raw_image("/tmp/boot.img", "/dev/block/mmcblk1p15"),
delete("/tmp/boot.img"));
ui_print("Updating devtree");
show_progress(0.330000,2);
assert(package_extract_file("devtree.img", "/tmp/devtree.img"),
write_raw_image("/tmp/devtree.img", "/dev/block/mmcblk1p12"),
delete("/tmp/devtree.img"));
ui_print("Updating stock recovery");
show_progress(0.340000,2);
assert(package_extract_file("recovery.img", "/tmp/recovery.img"),
write_raw_image("/tmp/recovery.img", "/dev/block/mmcblk1p16"),
delete("/tmp/recovery.img"));
ui_print("Changed");
And are the three img files generated only by change names of CG35.smg/ CG61.smg/ CG47.smg?
After we extract the smg files from a sbf file, we have many CG??.smg.
CG35.smg refers to the partition of boot.
CG61.smg refers to the partition of devtree.
CG47.smg refers to the partition of recovery.
Now I have two problems.
1. Does the boot&devtree&recovery in zip file have the same format as CG35&CG61&CG47? Such as the yaffs or ext?
2. Shall we use the code above to replace the partitions successfully considering the not-open bootloader and the secure signature?
i will try!
CG35.smg and CG47.smg are different. CG47 is Recovery and contains recovery software does not boot system, CG35 is boot and does not have ny recovery stuff only boots the system.
But I don't know anything about devtree and devtree_backup. but the name indicate that devtree_backup is a exact copy of devtree.
EDIT: CG35 and CG47 have different SHA1 hash and different signatures when extracted from the same (original) SBF file. if CG47 would have been a copy of CG35 the SHA1 hash would have been the same.
Febernacke said:
CG35.smg and CG47.smg are different. CG47 is Recovery and contains recovery software does not boot system, CG35 is boot and does not have ny recovery stuff only boots the system.
But I don't know anything about devtree and devtree_backup. but the name indicate that devtree_backup is a exact copy of devtree.
EDIT: CG35 and CG47 have different SHA1 hash and different signatures when extracted from the same (original) SBF file. if CG47 would have been a copy of CG35 the SHA1 hash would have been the same.
Click to expand...
Click to collapse
I am afraid you misunderstood me. I know that CG35 and CG47 are different.
After we extract the smg files from a sbf file, we have many CG??.smg.
CG35.smg refers to the partition of boot.
CG61.smg refers to the partition of devtree.
CG47.smg refers to the partition of recovery.
Now I have two problems.
1. Does the boot&devtree&recovery in zip file have the same format as CG35&CG61&CG47? Such as the yaffs or ext?
2. Shall we use the code above to replace the partitions successfully considering the not-open bootloader and the secure signature?
iaio72 said:
i will try!
Click to expand...
Click to collapse
I am waiting for your good news!
Just a warning guys, those CGXX.smg files are not the same as the .img files. SBF files pad the partitions with nulls so they reach multiples of 1024 bytes. The image files themselves can be extracted from the .smg files by removing the extra padding nulls from the end. Hex editors are your friend.
Hello,
I wanna share some information about param.lfs. As some people I tried to study this file. I tried to port j4fs driver to linux, but with no success yet.
But I have something. For those ROM-makers who want to insert their own logo right in the file for flashing it as a part of a ROM you can do the following:
1. Prepare your jpeg file, process it through jpeg optimizer (like xat.com JPEG optimizer). Size must not exceed 3FD1(HEX), or 16337Bytes. 480x800, 72dpi
2. Load this file (jpeg) in a HEX editor (WinHex) and copy it as a block
3. Load param.lfs
4. Overwrite two blocks in param.lfs by your image (just paste block in overwrite mode). First one - from offset B4000, second one - from 7F000. To double check - overwritten blocks should start with FF D8
That's all. Tar param.lfs as it used to do: tar -H ustar -с param.lfs > param.tar
and flash it via odin as PDA, or add to firmware then. You will obtain your own logo.jpg and logo_kor.jpg in /mnt/.lfs
So, you don't need to use special scripts to change splash-screen (mount .lfs and copy your logo.img into it). It will work with any kernel. Even on stock firmware you may have your own bootlogo.
Caution: Be careful. If you make something wrong, phone won't boot, because param.lfs is used by bootloader. At least /mnt/.lfs will be empty.
You may have black screen. Anyway you will be able to enter in 3-button mode to flash stock param.lfs back.
Of course that won't change bootlogo with yellow triangle because it "resides" in sbl.bin and very dangerous to be changed.
P.S. I was going to write a patch script, but decided not to do that.
Cheers
As a newbye, I found that very interesting to read
Thank you
1.
My original logo is 18.100 bytes and wonder if 3BB0(HEX) limit is accurate :/ :\ - while $B4000-$7F000=217.088 bytes
2.
On my param.lfs image, I searched for "FFD8 FFE0" and found other position for the JFIF files
Complete signature seems to be
"FFD8 FFE0"
"0010 4A46 4946 0001" for "..JFIF.."
3.
Linux support for j4fs would be great
4.
I wanted to know how to deal such a special "behaviour" into param.lfs partition: we can create files but not overwritten files...
Code:
[alpha] adb shell
$ su
# mount -o remount,rw -t j4fs /dev/block/stl6 /mnt/.lfs
# mount | grep ".lfs"
/dev/block/mmcblk0p4 on /mnt/.lfs type j4fs (rw,relatime)
#
# cd /mnt/.lfs
# rm -f logo.jpg
rm: can't remove 'logo.jpg': Operation not permitted
# echo "1. Impossible to delete logo.jpg"
1. Impossible to delete logo.jpg
#
# cp /mnt/sdcard/logo.jpg /mnt/.lfs/logo0.jpg
# ls -l /mnt/.lfs/logo0.jpg
-rwxrwxrwx 1 root root 19524 Jan 1 1970 /mnt/.lfs/logo0.jpg
# echo "2. copy onto /mnt/.lfs/ is possible"
2. copy onto /mnt/.lfs/ is possible
#
# cp -f logo0.jpg logo.jpg
cp: can't create 'logo.jpg': File exists
# echo "3. copy onto logo.jpg is impossible"
3. copy onto logo.jpg is impossible
#
# chattr -i logo.jpg
chattr: reading flags on logo.jpg: Not a typewriter
# rm -f logo.jpg
rm: can't remove 'logo.jpg': Operation not permitted
# exit
$ exit
[alpha] echo "Really strange for a file system ?"
Really strange for a file system ?
Is there a simple way to delete logo.jpg ?
Ivan_Belarus said:
Caution: Be careful. If you make something wrong, phone won't boot, because param.lfs is used by bootloader. At least /mnt/.lfs will be empty. You may have black screen. Anyway you will be able to enter in 3-button mode to flash stock param.lfs back.
Click to expand...
Click to collapse
First of all, thanks for sharing the info.
I tried it, no dice. Seems B4000 in the param.lfs I'm using (KI8) isn't the beginning of a JPEG. Tried other addresses that start with FF D8, with and w/o Exif, to no avail. All I have is an empty .lfs folder (as you said) and a boot message saying "logo.jpg" draw failed, but it boots eventually.
What am I missing?
TIA
param.lfs I'm using: http://www.mediafire.com/file/jw0x36z04fvp4eg/param.lfs
EDIT:
Wow! It took me a couple of hours, but I've finally found it in that param.lfs (XWKI8)!!!
In XWKI8 logo.jpg starts @ 7D800. Don't go beyond the length of the file you have already (in XWKI8, +/-15K), otherwise you'll get the "draw failed" boot error and an empty /mnt/.lfs - in this case, just reflash the stock param.lfs and you'll be ok.
Works great! I can sleep now!
Once more, thx a bunch Ivan_Belarus for sharing the info!
cheers!!!
geekmarc said:
1.My original logo is 18.100 bytes and wonder if 3BB0(HEX) limit is accurate :/ :\ - while $B4000-$7F000=217.088 bytes
2.On my param.lfs image, I searched for "FFD8 FFE0" and found other position for the JFIF files
Complete signature seems to be
"FFD8 FFE0"
"0010 4A46 4946 0001" for "..JFIF.."
4.I wanted to know how to deal such a special "behaviour" into param.lfs partition: we can create files but not overwritten files...
Is there a simple way to delete logo.jpg ?
Click to expand...
Click to collapse
1. Wrong operation. I have given the offsets only: for logo.jpg and logo_kor.jpg. I you want full addressing they are: B4000-B7FCF. It comes to 3FCF+2=3FD1. The second one is: 7F000-839B2. It comes to 49B2+2=49B4. (I've written 3BB0 - sorry I looked at my own block size. Fixed)
2. Yep, the jpeg header is bigger than word FF D8. You can google for jpeg header. But main two bytes are FF D8. The end is marked by FF D9. There are many jpeg files inside. I provided offsets for two ones.
4. You may look at Init.V scripts of Siyah kernel for example (/sbin/siyah/imports.sh)- there you may find all the commands for replace logo.jpg
I attached my original param.lfs (unchanged). I used it without problems on KI8
Heh, I didnt compare different param.lfs but now I see that there are different builds of param.lfs (thnx to rizdroid). So, I guess we're able to locate quickly the required offsets via block sizes and names. We need to find two blocks of size 3FD1 (starts with FF D8, ends with FF D9) and 49B4. They will be logo.jpg and logo_kor.jpg images. Before these blocks (about -7E1) you can find text 'logo.jpg' and 'logo_kor.jpg' accordingly. Don't try to locate them only by name!
someone help me out here... im trying to do this for the galaxy nexus but whenever i open my param.lfs file in a hex editor all i get is 0's theres nothing in it
Ivan_Belarus said:
1. Wrong operation. I have given the offsets only: for logo.jpg and logo_kor.jpg. I you want full addressing they are: B4000-B7FCF. It comes to 3FCF+2=3FD1. The second one is: 7F000-839B2. It comes to 49B2+2=49B4. (I've written 3BB0 - sorry I looked at my own block size. Fixed)
2. Yep, the jpeg header is bigger than word FF D8. You can google for jpeg header. But main two bytes are FF D8. The end is marked by FF D9. There are many jpeg files inside. I provided offsets for two ones.
4. You may look at Init.V scripts of Siyah kernel for example (/sbin/siyah/imports.sh)- there you may find all the commands for replace logo.jpg
I attached my original param.lfs (unchanged). I used it without problems on KI8
Heh, I didnt compare different param.lfs but now I see that there are different builds of param.lfs (thnx to rizdroid). So, I guess we're able to locate quickly the required offsets via block sizes and names. We need to find two blocks of size 3FD1 (starts with FF D8, ends with FF D9) and 49B4. They will be logo.jpg and logo_kor.jpg images. Before these blocks (about -7E1) you can find text 'logo.jpg' and 'logo_kor.jpg' accordingly. Don't try to locate them only by name!
Click to expand...
Click to collapse
WOOOOOOOOOOOOOOOOOOO !!!!! YEAH !!!!!! :good::good::good::victory::victory::victory:
@Ivan_Belarus, Thank you very much for the guide and help !!!!!
I was stack with that process of HEXing the param.lfs you provided because the image i made is SMALLER then 16337Bytes.
So I solved the "'logo.jpg' draw failed" problem I got ( becuase I changed only part of logo.jpg ) by filling "20" ( hex value ) all the cells between after my image FF D9 ( not included) and the original logo.jpg END ( FF D9 included ) as you wrote in your post: 1st jpg end is at B7FCF and the second is at 839B2.
I used the param.rar you provided.
To be clearer, for an example, let say I got this original param.lfs HEX segment:
Code:
[COLOR="red"]FFD8[/COLOR]FFE100184578EE55184D5331DA8831930800450007[COLOR="red"]FFD9[/COLOR]
But the image i want to implant is SMALLER , so it starts with "FFD8" and ends EARLIER with "FFD9" like:
Code:
[COLOR="red"]FFD8[/COLOR]FFE1008374597335734753745[COLOR="red"]FFD9[/COLOR]
So, I need to change param.lfs HEX segment so that it will include "20" after my image "FFD9":
Code:
[COLOR="red"]FFD8[/COLOR]FFE1008374597335734753745[COLOR="red"]FFD9[/COLOR][U][COLOR="Blue"]202020202020202020[/COLOR][/U]
About the need to TAR the param.lfs, because i'm on windows I used 7zip, so no need for linux of any sort.
rizdroid said:
First of all, thanks for sharing the info.
I tried it, no dice. Seems B4000 in the param.lfs I'm using (KI8) isn't the beginning of a JPEG. Tried other addresses that start with FF D8, with and w/o Exif, to no avail. All I have is an empty .lfs folder (as you said) and a boot message saying "logo.jpg" draw failed, but it boots eventually.
What am I missing?
TIA
param.lfs I'm using: http://www.mediafire.com/file/jw0x36z04fvp4eg/param.lfs
EDIT:
Wow! It took me a couple of hours, but I've finally found it in that param.lfs (XWKI8)!!!
In XWKI8 logo.jpg starts @ 7D800. Don't go beyond the length of the file you have already (in XWKI8, +/-15K), otherwise you'll get the "draw failed" boot error and an empty /mnt/.lfs - in this case, just reflash the stock param.lfs and you'll be ok.
Works great! I can sleep now!
Once more, thx a bunch Ivan_Belarus for sharing the info!
cheers!!!
Click to expand...
Click to collapse
Sorry to resurrect a REALLY old thread, but how did you manage to flash PARAM partition. It is in my .pit file from heimdall, but when I flash the partition, I simply see the old bootscreen.
hackintosh5 said:
Sorry to resurrect a REALLY old thread, but (...) .
Click to expand...
Click to collapse
It is OK to ask questions even if the thread is sooo old
But unfortunately I can't help you.
Iluvatar2000 said:
It is OK to ask questions even if the thread is sooo old
But unfortunately I can't help you.
Click to expand...
Click to collapse
Its fine! Thanks for your time!
This guide purpose is to introduce you with edify scripting language used by Android to run updater-scripts. this guide is based on an article on this web http://www.freeyourandroid.com/guide/introdution_to_edify
why should you read this?
this guide will be usefull for someone who want to make a patch, install an apk, or modify a rom with a simple update.zip file. most of android devices are using edify script instead of amend script. this guide will be applicable in almost every android devices. a simpe example of these script we can found on installer for theme. while the complicated one is aroma installer which are used for GUI installation for rom.
below are examples of functions used in an Edify Updater-script:
Function Name: mount
Function Syntax: mount(fs_type, partition_type, location, mount_point)
Parameter Details:
fs_type = yaffs2 ext4 ext2 ext3 rfs vfat
partition_type="MTD" | "EMMC"
location = partition | device
mount_point = target folder to mount FS.
Action: Mounts a filesystem to the defined mount point
Returns: The mount point if successful, null if failed
Click to expand...
Click to collapse
/system partition is automatically mounted. this command is needed when you need to mount another partition beside /system or in any condition when recovery mode failed to mount your system partition. the system's location is /dev/stl9, cache /dev/stl10, and data /dev/stl11 (all partition type commonly rfs, will be differ if you have custom kernel or rom). if you want to mount sdcard, the location is mmcblk0pX with x is the partition number.
Function Name: is_mounted
Function Syntax: is_mounted(mount_point)
Parameter Details: mount_point = string, mount point to check if is mounted
Action: Checks if a filesystem is mounted.
Returns: The mount point if mounted, otherwise, returns null
Click to expand...
Click to collapse
Function Name: unmount
Function Syntax: unmount(mount_point)
Parameter Details: mount_point = string, mount point to unmount
Action: Unmounts the filesystem
Returns: The mount point that was dismounted if successful, otherwise it returns null
Click to expand...
Click to collapse
Function Name: format
Function Syntax: format(fs_type, partition_type, location)
Parameter Details:
fs_type = string,yaffs2 ext4 ext2 ext3 rfs vfat
partition_type= string, "MTD" | "EMMC"
location = string, partition | device
Action: Formats a filesystem as specified
Click to expand...
Click to collapse
Function Name: delete
Function Syntax: delete(file1, file2, ..., fileN)
Parameter Details: string, file to delete
Action: Deletes a file. Must specify at least one file; multiple files can be specified as multiple arguments
Click to expand...
Click to collapse
Function Name: delete_recursive
Function Syntax: delete_recursive(dir1, dir2,...,dirN)
Parameter Details: string, directory to recursively delete
Action: Deletes a folder and all of its contents. At least 1 directory must be specified; multiple directories can be specified as additional arguments.
Click to expand...
Click to collapse
Function Name: show_progress
Function Syntax: show_progress(frac, sec)
Parameter Details:
frac = fraction of progress completed
sec = total seconds
Action: Displays flashing progress in the recovery system
Click to expand...
Click to collapse
Function Name: set_progress
Function Syntax: set_prograss(frac)
Parameter Details: frac=fraction of progress
Click to expand...
Click to collapse
Function Name: package_extract_dir
Function Syntax: package_extract_dir(package_path, destination_path)
Parameter Details:
package_path = string, directory in package to extract
destination_path = string, target point to extract files to
Action: Extract the all of the files in a directory in the package to the target specified.
Click to expand...
Click to collapse
this command is the usefull one for app/mod installation. don't worry about same filename, the newer one will automatically delete the old one. if you want to make your file easier to use, you can use 'package_extract_dir("system", "/system")'. in this way, you don't need to make multiple command to copy your files and folders into system partition. everything under system folder will be copied into your system partition. see my example file below for further details.
Function Name: package_extract_file
Function Syntax:
package_extract_file(package_path)
or
package_extract_file(package_path, destination_path)
Parameter Details:
package_path = string, file in the package you want to extract
destination_path, target folder to extract the file to.
Action: Extracts a single file from your update package to the target specified
Click to expand...
Click to collapse
Function Name: file_getprop
Function Syntax: file_getprop(file, key)
Parameter Details:
file = string, filename to check
key = string, key in file to return the value of
Action: Checks for a value in a file?
Click to expand...
Click to collapse
Function Name: symlink
Function Syntax: symlink(target, src1, src2, ..., srcN)
Parameter Details:
target = string, the target of the symbolic link
srcX = the symbolic link to create that points to the target
Action: Unlinks any existing symbolic links before creating the new symbolic links.
Click to expand...
Click to collapse
Function Name: set_perm
Function Syntax: set_perm(uid, gid, mode, file1, file2, ..., fileN)
Parameter Details:
uid = user id
gid = group id
mode = permission mode
fileX = file to set permission on
Action: Sets permissions of a file or set of files specified. At least one file must be specified (the first four parameters are required)
Click to expand...
Click to collapse
Function Name: set_perm_recursive
Function Syntax: set_perm_recursive(uid, gid, dirmode, filemode, dir1, dir2, ...dirN)
Parameter Details:
uid = user id
gid = group id
dirmode = permission to set to directories contained within the specified directory
filemode = permission to set to files contained within the specified directory
dirX = directory to set permission on
Action: Set permissions of a directory or set of directories and all files and folders within them. At least one directory must be specified (The first 5 parameters are required)
Click to expand...
Click to collapse
Function Name: getprop
Function Syntax: getprop(key)
Parameter Details: key = string, the property you want the system to return
Action: This function returns the value of the property specified. This is used to query platform information from the build.props file.
Click to expand...
Click to collapse
Function Name: write_raw_image
Function Syntax: write_raw_image(file, partition)
Parameter Details:
file - string, the source .img file to be read from
partition - string, the destination partition to write the .img file to
Description: This function writes an img file to a partition.
Click to expand...
Click to collapse
this command usually used to install kernel. somehow it doesn't work for sgy. you'll need to run bmlunlock program to install the kernel on sgy. check faqbly's kernel installer for further information.
Function Name: apply_patch
Function Syntax: apply_patch(srcfile, tgtfile, tgtsha1, tgtsize, sha1_1, patch_1, ..., sha1_x, patch1_x)
Parameter Details:
srcfile - string, source file to be patched (file to read in)
tgtfile - string, destination file to write the patched file to
tgtsha1 - string, sha1 hash of the target file as it should hash out after the patches apply properly
sha1_x - string, sha1 hash of the patch data that's to be written to the target file
patch1_x- string, actual patch to apply to the target file
Action: This function is used to apply patches to a file.
Click to expand...
Click to collapse
Function Name: apply_patch_check
Function Syntax: apply_patch_check(file, sha1_1, ..., sha1_x)
Parameter Details:
file - string, file to check
sha1_x - hash to check for?
Action: Either checks if a file has been properly patched, or checks if a file can be patched. Need to check the source code of the "applypatch_check" function that is called from here.
Click to expand...
Click to collapse
Function Name: apply_patch_space
Function Syntax: apply_patch_space(bytes)
Parameter Details: bytes = number of bytes to check for
Action: Checks the cache to verify that there is enough space to write the patched files to it and returns something. Need to test this function to verify.
Click to expand...
Click to collapse
Function Name: read_file
Function Syntax: read_file(filename)
Parameter Details: filename - string, the filename to read the contents of
Action: This function returns the contents of a file.
Click to expand...
Click to collapse
Function Name: sha1_check
Function Syntax:
sha1_check(data)
or
sha1_check(data, sha1_hex, ..., sha1_hexN)
Parameter Details:
data - the contents of file to calculate the sha1 hash of - must be in the read_file format
sha1_hexN - A particular sha1_hex string that you want the file data to match
Action: If only data is specified, then the function returns the sha1_hex string of the data. The optional parameters are used if you want to verify that the file you are checking for is one of a list of hashes. It reutrns the hash it matches, or returns nothing if it doesn't match any of the mentioned hashses.
Click to expand...
Click to collapse
Function Name: ui_print
Function Syntax: ui_print(msg1, ..., msgN)
Parameter Details: msg - String, message to be outputted to the user during the patch process
Action: This function prints/echos a message to the console while the script is running. At least 1 parameter needs to be specified, you can specify additional msg parameters and they will be concatenated to the output.
Click to expand...
Click to collapse
Function Name: run_program
Function Syntax: run_program(prog, arg1, .., argN)
Parameter Details:
prog - string, program to execute
argN - string, arguments for the program that is being executed
Description: Executes a program with the arguments specified. Returns a string, I assume it is the buffer of the stdout of the program executed, need to test.
Click to expand...
Click to collapse
Function Name: ifelse
Function Syntax: ifelse(condition, truecondition, falsecondition)
Parameter Details:
condition - an expression to evaluate
truecondition - Edify script block to execute if true
falsecodnition - Edify script block to execute if false
Description: This is the if-then construct of the Edify scripting language. The truecondition or falsecondition arguments can be a single edify command or a script block. Script blocks can be formed by enclosing the parameter with parenthesis, and seperating the commands with semicolons\
Click to expand...
Click to collapse
Function Name: abort
Function Syntax: abort()
Parameter Details: no paremeters
Description: Aborts script execution.
Click to expand...
Click to collapse
Function Name: assert
Function Syntax: assert(condition)
Parameter Details: condition - boolean
Description: If condition evaluates to false, stops script execution, otherwise continues processing.
Click to expand...
Click to collapse
to run the script you'll need a binary file for edify script. you can find an example of the update.zip with the binary file here http://www.mediafire.com/download.php?rti5lc5358w51nn
this one is an example of updater script for roms
http://www.mediafire.com/download.php?nxgiz0993brp9re
NOTE:
1. that file used to enable bootanimation on dxlb or newer firmware. it is still in progress so don't install it. you can use that file as a base to create your own installer zip with edify script.
2. don't use notepad to edit the file. you can use notepad++ instead.
3. all syntax inside () is always within ". for an example, syntax for mount is 'mount(fs_type, partition_type, location, mount_point)', so if we want to mount the system partition we'll type 'mount("rfs", "EMMC", "/dev/block/stl19", "/system")'.
Wow, it's so long, but i try.
whoaa...you're right. I don't know that this post will be this long (lol)
btw, don't worry about those script. in most cases you only need 2-3 of them.
wow this is really awesome!! I would appreciate if you could give examples of commands commonly used
you're already used to work with custom roms. everything you need to know is already inside your rom. for a simple updater script used to install app or file I always use these script.
Code:
ui_print("Installing");
package_extract_dir("system", "/system");
ui_print("Completed");
ui_print("have a nice day");
ui_print("[email protected]");
bookmarked
will try this sooner or later
this is epic dude! I really needed em! thanx!!
Nice ....tanks
Pressed :thumbup::thumbup::thumbup:
Thanks. Nice one again kuro
Sent from my GT-S5360 using xda premium
thanks ....... really great guide...
Sent from my GT-S6102 using Tapatalk 2
awesome,im waiting so long for a good guide.thanks for this bro
GREEEEEEEETZ!!!
thanks for your support guys
Hi Kuro, great tutorial as usual.
Listen, any idea why in the S5570I stock recovery with the stock kernel the format command requires 4 parameters instead of 3?
Code:
format () expects 4 args. got 3
Do you know which one is the correct syntax? Also, what's the difference between EMMC and MTD??
I feel more and more about throwing this phone out of the window. The iPhone 5 is very tempting.
that problem comes from the binary file. I've found at least three version of the binary file. in my guide the syntax is format(fs_type, partition_type, location) or in an example format("EXT4", "MTD", "/dev/block/stl19") but some binary file need to specify more about the partition. the syntax in an example will be format("EXT4", "MTD", "/dev/block/stl19", "/system"). the differences between EMMC and MTD is the hardware of the memory device. an sdcard is an EMMC device, so that we should use EMMC. however, different phone vendor have different type of internal memory device. MTD is commonly used but in some case they use EMMC.
you can try this one. http://www.mediafire.com/download.php?if08rvj22mw9abp it comes from maroc.
Ok, thanks. I've found another couple of update-binary as well in the meantime. One with the 3 parameters format coming from a CM for the Galaxy Min/Pop/Next. Another with a TWO (!!) parameters format, or at least it seems so, coming straight from the Samsung latest CSC for my phone (you know about that :laugh. In the CSC updater-script the syntax is following (but it is commented out):
Code:
# format("MTD", "system");
# mount("MTD", "system", "/system");
Do they really love to make the most trivial things impossible with Android? Not even a well defined, fixed syntax? At least they could rename the update-binary. This software is blasphemy for a computer scientist!!! (sorry. It really makes me needing to blow out).
Code:
# format("MTD", "system");
# mount("MTD", "system", "/system");
it seems that there's a differences between the binary file comes from the factory the one come from community. the script from a factory always in a form like above. the one comes from community always comes in a form like format(fs_type, partition_type, location). IMO its not the factory fault if we found a lot of binary version. everyone can make their own update binary if they know the source code.
Oh, I get it now. I stupidly thought they all came from Google. Let's say that a mechanism to use different names for the update-binary could be put in place (or there is one?). So one could name the update-binary with its version. Like CM7.2-binary, Merruk-binary and so on.
I'll check if I can run them from the phone, to see if they give out any version info, and maybe an help with a list of commands, so I can get the one I think is the best and use it once for all. We keep getting flashing problems in our phone, so we must investigate the issue at 360 degrees. Thanks again.
I doubt that. we can't rename the update binary into something else. even aroma which is using his own binary file still have to rename it to update-binary. in recovery mode it seems that when we flash a file, system will command "exec update-binary". while in update-binary it has something like "see the content of updaters-script then run it". if we made our own binary file, we can easily modify the second part. in aroma, the dev change the second part into "see the content of aroma-config then run it". in other hand, the first part is stored inside our recovery stuff. modfying it is hard and a lil bit risky so that no one ever interested to do it.
Kuro, do you own a thread where we can freely discuss about kernel compilations? I have 4 or 5 questions, nothing complex, just about the gzip/lzma compression and the RAM disk size limit that are driving me crazy. A couple of kernels compile but then when I install them I get blank screens. With other details that I'd like to specify in a dedicated thread.
/off-topic
you can discuss that everywhere
you can make a new one or simply chat like as we did in maroc's thread. ah yes, our kernel max size is about 5024kb or about 4,88Mb. quite small indeed, but we can gain more spaces when we use lzma compression. btw, I got less problem when compiling a zImage file. as long as we didn't make a major change on the source, our kernel will eventually working. nevertheless, I got a lot of problem when trying to modify ramdisk. even a slight change on ramdisk in several occasieon made the kernel didn't work. you might want to test your zImage with a ramdisk from stock kernel or a working custom kernel available for your device to check whether if the problem comes from zImage or ramdisk. if you want to know more about ramdisk modification you can ask savie or yahya (maroc). they sure know better than me in that aspect.
After extracting the ramdisk from the stock boot image of OSS5.0 / Android O 8.0 for Oneplus3, I noticed that fstab.qcom file is no longer there in the ramdisk. Until OSS4.5.1 / Android N 7.1 this file was present and could be edited to set the flag for data partition to encryptable and to also remove the verity flag ...both of which I found to be very useful.
Appreciate if someone can please help me understand what has changed in the Android O 8.0 and what would be the method to achieve the above?
Looking at https://forum.xda-developers.com/oneplus-3t/how-to/disable-dm-verity-force-encryption-op3t-t3688748 and https://forum.xda-developers.com/attachment.php?attachmentid=4302571&d=1507993390, it appears that the fstab.qcom file has moved to /system/vendor/etc/fstab.qcom in Oreo in keeping with Android O / 8.0 specifications. Changing that file means modifying the system partition, which I don't mind as I like to modify the hosts file as the barest minimum change even in my daily use device. But still wondering if the same can be achieved by Magisk and how. Appreciate if someone can help me understand this.
Today's learning:
1. Android O kernel specifications include early mounting of some partitions and Oneplus 3 specifies the system partition in its device tree blobs (dtb).
2. These dtb are part of (...appended to) the real kernel image and not on a separate partition / blob.
3. There are 13 dtb appended to Oneplus 3 kernel and each of them has an entry relevant to fstab which mounts system with the verify flag.
4. Again, in keeping with Android O specifications, fstab.qcom (...now located in the /vendor/etc/ directory) does not include a line for the system partition (...commented out) as mounting the system partition is already taken care of through the dtb in the kernel.
5. That means system modifications cannot be done until the dtb are cleaned of verify flag .... or perhaps the whole of the code mounting the system partition in dtb is deleted and then fstab.qcom is restored in the ramdisk.
Haven't yet tried this and it will be helpful if someone more knowledgeable can confirm that these are the steps to be done to modify the system partition.
@rk2612 great findings and write up!
Just saw your post at magisk beta thread. I'm facing same problem on xperia device with Oreo, and I think we need to change the flag as you stated there.
I've already tried flashing magisk, but dm-verity is still being triggered and phone falls in a bootloop after it reboots.
I'd like to try this method out on my xperia, but I don't know how to convert dtb into dts, and vice versa. Any help on this would be great! Thanks in advance!!
serajr said:
@rk2612...
I've already tried flashing magisk, but dm-verity is still being triggered and phone falls in a bootloop after it reboots.
I'd like to try this method out on my xperia, but I don't know how to convert dtb into dts, and vice versa. ...
Click to expand...
Click to collapse
Have you tried patching with Magisk Beta v1456? That seems to take care of the verity flag in the dtb of OnePlus 3.
On Ubuntu, you can install dtc (device tree compiler ...Refer http://manpages.ubuntu.com/manpages/xenial/man1/dtc.1.html ) to handle conversion from dtb to dts or vice versa.
rk2612 said:
Have you tried patching with Magisk Beta v1456? That seems to take care of the verity flag in the dtb of OnePlus 3.
On Ubuntu, you can install dtc (device tree compiler ...Refer http://manpages.ubuntu.com/manpages/xenial/man1/dtc.1.html ) to handle conversion from dtb to dts or vice versa.
Click to expand...
Click to collapse
Thank you bro!
Yes, I had, latest beta v1456!
Gonna try it out and report back here later!!
serajr said:
...
I'd like to try this method out on my xperia, ....
Click to expand...
Click to collapse
serajr said:
Thank you bro!
Yes, I had, latest beta v1456!
Gonna try it out and report back here later!!
Click to expand...
Click to collapse
According to https://github.com/topjohnwu/Magisk/blob/master/scripts/boot_patch.sh (...line 93 onwards) Sony devices may not be handled well by Magisk.
rk2612 said:
According to https://github.com/topjohnwu/Magisk/blob/master/scripts/boot_patch.sh (...line 93 onwards) Sony devices may not be handled well by Magisk.
Click to expand...
Click to collapse
Bro, this is an known issue for all xperia users. Always before we flash magisk (os SuperSU), we do need to convert xperia stock kernel (elf format) to boot.img (aosp format), and fastboot it!
And for the records, this is exactly what I've found with dtc:
Code:
firmware {
android {
compatible = "android,firmware";
fstab {
compatible = "android,fstab";
vendor {
compatible = "android,vendor";
dev = "/dev/block/platform/soc/7464900.sdhci/by-name/vendor";
type = "ext4";
mnt_flags = "ro,barrier=1,discard";
fsmgr_flags = "wait";
status = "disabled";
};
system {
compatible = "android,system";
dev = "/dev/block/platform/soc/7464900.sdhci/by-name/system";
type = "ext4";
mnt_flags = "ro,barrier=1,discard";
fsmgr_flags = "wait[B][COLOR="Red"],verify[/COLOR][/B]";
status = "ok";
};
};
};
};
Removed ,verify and conveted back to dtb. Gonna test it out (report you back later)!
Thank you!
i have a one plus 5T and i dont see an DTB files in the boot.img
can someone post a walk through on how to do this manually without magisk or supersu?
i know i can modify the fstab in system/vendor/etc
but what are the dtb files exactly? and where are they located / how are they extracted?
virtyx said:
i have a one plus 5T and i dont see an DTB files in the boot.img
can someone post a walk through on how to do this manually without magisk or supersu?
i know i can modify the fstab in system/vendor/etc
but what are the dtb files exactly? and where are they located / how are they extracted?
Click to expand...
Click to collapse
DTB are Device Tree Blobs / Binary and not files. These are appended to the kernel in the boot.img.
On Ubuntu, you can install dtc (device tree compiler ...Refer http://manpages.ubuntu.com/manpages/...an1/dtc.1.html ) to handle conversion from dtb to dts or vice versa.
You can also hex edit the boot.img and delete the text ",verify" at each instance it is found. Or use Linux command line to do that if you're familiar with that.
Sorry, don't have the spare time right now to write a detailed walk through. Maybe this weekend.
rk2612 said:
DTB are Device Tree Blobs / Binary and not files. These are appended to the kernel in the boot.img.
On Ubuntu, you can install dtc (device tree compiler ...Refer http://manpages.ubuntu.com/manpages/...an1/dtc.1.html ) to handle conversion from dtb to dts or vice versa.
You can also hex edit the boot.img and delete the text ",verify" at each instance it is found. Or use Linux command line to do that if you're familiar with that.
Sorry, don't have the spare time right now to write a detailed walk through. Maybe this weekend.
Click to expand...
Click to collapse
thank you
is it possible to extracat the DTB files on a windows machine?
i know after OS install the fstab is located at /system/etc/vendor which we can edit before first boot
but id prefer to edit the DTB files in the boot, and add mounting flags for each partition.
virtyx said:
thank you
is it possible to extracat the DTB files on a windows machine?
i know after OS install the fstab is located at /system/etc/vendor which we can edit before first boot
but id prefer to edit the DTB files in the boot, and add mounting flags for each partition.
Click to expand...
Click to collapse
I didn't look around for a windows tool to extract DTBs.
In Oreo, fstab file contains the mount points for all other partitions except /system and you can edit the fstab file as in previous android versions. The only partition which is mounted early through the DTBs is /system and you will see that the /system mount entry in fstab is commented out as that is not needed.
To mount /system with verity disabled, you will need to remove the flag "verify" from the DTBs. I'm attaching a text version of one of the 13 DTBs contained in OnePlus 3's boot image as an example. You will notice the following code
Code:
fsmgr_flags = "wait,verify"
...and you need to remove ",verify" to make it
Code:
fsmgr_flags = "wait"
To remove ",verify" from the DTBs, you can either:
1. Hex edit the boot image but this will leave the verity key in the ramdisk (...may work but I haven't tried).
2. (a) Unpack the boot image; (b) hex edit the kernel (to which dtbs are appended) and remove ",verify"; (c) extract ramdisk and remove verity.key; (d) repack ramdisk; and (e) repack the boot image: should work
3. (a) Unpack the boot image, (b) extract the dtb appended to kernel / zImage; (c) convert the dtb to dts (text format); (d) text edit the dts to remove ",verify"; (e) then reconvert dts to dtb; (f) append all the modified dtbs to the kernel; and finally (g) repack the boot image (...also remove the verity.key from the ramdisk before repacking the boot image): this would be the cleanest approach but more cumbersome.
Tools needed on Ubuntu machine with Python installed:
1. Unpack and repack boot image: use unpackbootimg and mkbootimg scripts (Python) from lineageos code: https://github.com/LineageOS/android_system_core/tree/cm-14.1/mkbootimg
2. Extract kernel and dtbs using python script: https://github.com/PabloCastellano/extract-dtb
3. Convert dtb to dts and back: use Ubuntu package dtc: http://manpages.ubuntu.com/manpages/xenial/man1/dtc.1.html
rk2612 said:
I didn't look around for a windows tool to extract DTBs.
In Oreo, fstab file contains the mount points for all other partitions except /system and you can edit the fstab file as in previous android versions. The only partition which is mounted early through the DTBs is /system and you will see that the /system mount entry in fstab is commented out as that is not needed.
To mount /system with verity disabled, you will need to remove the flag "verify" from the DTBs. I'm attaching a text version of one of the 13 DTBs contained in OnePlus 3's boot image as an example. You will notice the following code
Code:
fsmgr_flags = "wait,verify"
...and you need to remove ",verify" to make it
Code:
fsmgr_flags = "wait"
To remove ",verify" from the DTBs, you can either:
1. Hex edit the boot image but this will leave the verity key in the ramdisk (...may work but I haven't tried).
2. (a) Unpack the boot image; (b) hex edit the kernel (to which dtbs are appended) and remove ",verify"; (c) extract ramdisk and remove verity.key; (d) repack ramdisk; and (e) repack the boot image: should work
3. (a) Unpack the boot image, (b) extract the dtb appended to kernel / zImage; (c) convert the dtb to dts (text format); (d) text edit the dts to remove ",verify"; (e) then reconvert dts to dtb; (f) append all the modified dtbs to the kernel; and finally (g) repack the boot image (...also remove the verity.key from the ramdisk before repacking the boot image): this would be the cleanest approach but more cumbersome.
Tools needed on Ubuntu machine with Python installed:
1. Unpack and repack boot image: use unpackbootimg and mkbootimg scripts (Python) from lineageos code: https://github.com/LineageOS/android_system_core/tree/cm-14.1/mkbootimg
2. Extract kernel and dtbs using python script: https://github.com/PabloCastellano/extract-dtb
3. Convert dtb to dts and back: use Ubuntu package dtc: http://manpages.ubuntu.com/manpages/xenial/man1/dtc.1.html
Click to expand...
Click to collapse
ah i see
i guess i should really dual boot this machine haha
i found the mounting options in hex editor for the boot.img (/system and /vendor, i think 13 instances of both)
also the verity.key can be delete when unpacking the boot.img and repacking it with no verity.key.
thank you, i think im able to modify it on a windows machine, ill try it out as soon as a stable oreo comes out for the 1+5T
I already have the dtb edited. how can I add them back to the zImage or the boot.img?
Thank you very much
kenet said:
I already have the dtb edited. how can I add them back to the zImage or the boot.img?
Thank you very much
Click to expand...
Click to collapse
Actually the appending should be done like
Code:
cat zImage [I][U]<DTB_FILE_NAME>[/U][/I].dtb > zImage-dtb
So you can get a zImage with dtb