Related
Allright, final ICS is out, but the stock bootloader still doesn't have fastboot oem unlock working. So, it's either HC bootloader or patched ICS bootloader. Please note that installing custom kernel / recovery on unpatched ICS bootloader will require recovering your device only with nvflash!
This bootloader can only be flashed using nvflash. You can use the guide here http://forum.xda-developers.com/showthread.php?t=1622425. There is also a post explaining nvflash in here: http://forum.xda-developers.com/showpost.php?p=22923662&postcount=9
YOU DO EVERYTHING AT YOUR OWN RISK!!!
Patched Bootloader V9 (V9-gbc410d4): (19/07/2013)
- based on latest Acer BL 0.03.14-ICS, it will pass 0.03.14-EXT to command line, along with V9-ga81f36b for revision
- booting from ext4 filesystem (see further for howto)
- grub style selection screen if multiple images are installed
- added font outline & kerning, uses updated skin application (by yaworski)
- GUI improvements
- haptic feedback
- OpenSuse 12.3 theme
- expanded fastboot commands
- fixed debug mode cmdline
Patched Bootloader V8: (07/06/2012)
- based on latest Acer BL 0.03.14-ICS, it will pass 0.03.14-MUL to command line
- fastboot handler is completely build from source code
- fastboot:
- A) download command will no longer write downloaded data to cache,
this means that on using flash and boot command, cache won't be wiped
- B) more convenient bootloader flashing (reboots right away to new BL)
- C) you won't have to have cache partition sized larger than other partitions,
in order to flash them
- D) maximum data size that can be send with fastboot is 700 MiB
- revamped GUI, now with fullscreen bootsplash and custom font, and themable
- added fastboot oem sbk command, which will print sbk on the tablet
- several small changes
Patched Bootloader V7: (31/05/2012)
- based on latest Acer BL 0.03.14-ICS, it will pass 0.03.14-MUL to command line
- one bootloader for both A500 / A501
- expanded bootmenu application (built from source) with handling several fastboot commands
- fastboot getvar serialno will return real serial number
- bootmenu has options to boot primary / secondary image on current boot
- attempting to boot invalid kernel image will result in being stuck in bootmenu
Patched Bootloader V6: (20/05/2012)
- based on latest Acer BL 0.03.14-ICS, it will pass 0.03.14-MUL to command line
- added simple boot menu (built from source)
Patched Bootloader V5: (18/05/2012)
- based on latest Acer BL 0.03.14-ICS, it will pass 0.03.14-MUL to command line
- dualboot (read lower for more information)
- added "fastboot flash bootloader bootloader.blob" command
Patched Bootloader V4: (13/05/2012)
- based on latest Acer BL 0.03.14-ICS, it will pass 0.03.14-UNL to command line
- allow bootlogo change (scroll down)
- allow unsigned update via bootloader.blob using CWM
- fixed: AKB partition is no longer used
- fixed: debug on / off works correctly
- fixed: bootloader will now boot to recovery if you erase boot (LNX) partition
- change: bootloader won't pass vmalloc parameter to cmdline
Patched Bootloader V3: (26/04/2012)
- no signature checks
- no "itsmagic" check
- based on latest Acer BL 0.03.12-ICS, it will pass 0.03.12-UNL to command line
- enabled fastboot (details lower)
- replaced bootlogo (moreover just testing that, need to allow bigger image)
FASTBOOT & BOOTMENU (since V6):
POWER + VOLUME DOWN will boot to recovery (won't erase cache).
POWER + VOLUME UP will boot to bootmenu.
In bootmenu, you can do:
A) Reboot
B) Go to fastboot mode
C) Toggle boot mode and set default kernel image on the selection screen
D) Toggle debug mode (modifies cmdline), forbid EXT4 boot in case of a bug in fs
E) Make selection screen include recovery and fastboot
E) Wipe cache (in case you get bad bootloader update and tablet won't boot)
To check for fastboot commands, see the README on the Github.
Here is CWM for ICS bootloader: http://forum.xda-developers.com/showthread.php?t=1654476 , you can flash it from fastboot after you flash the bootloader.
Do NOT run itsmagic on V5+ if you use dualboot, it will corrupt the secondary boot image.
BOOTLOGO CHANGE:
Changelog:
1.06 (19/07/2013)
- updated for V9
1.05 (07/06/2012)
- new application for V8
- customizes bootsplash and the colors
1.04 (31/05/2012)
- updated to support V7
1.03 (19/05/2012)
- updated to support coming V6
1.02 (18/05/2012)
- updated to support V5 as well
1.01 (14/05/2012)
- fixed blob loading & generation
- fix: require only .NET 2.0
1.00 (13/05/2012)
- Initial release
Download the tool from here:
Windows: http://skrilax.droid-developers.org/a500/nvflash/tools/A500BootLogo_106_v9_win.zip
Other OS (Mono): http://skrilax.droid-developers.org/a500/nvflash/tools/A500BootLogo_106_v9_mono.zip
Steps to change bootlogo:
(V4 - V7, applcation version 1.00 - 1.04)
A) Open the bootloader using File menu.
B) Open the image you want using Image menu (the image size must be 268x72)
C) Save the bootloader as *.blob
D) Flash it with a fastboot
(V8, applcation version 1.05)
(V9, applcation version 1.06)
A) Open the bootloader using File menu.
B) Open the image you want using Image menu (the image size must be 1280x800), note file limit max is 200 kB
C) If you wish, tick the checkbox for color customization and set the colors at your wish
D) Save the bootloader as *.blob
E) Flash it with a fastboot
Stock bootlogo is in attachment.
If you want to flash as *.blob, you have to create an update.zip for CWM and flash using this update script:
Code:
mount("ext4", "EMMC", "/dev/block/mmcblk0p3", "/system");
package_extract_file("bootloader.blob","/tmp/bootloader.blob");
unmount("/cache");
format("ext4","EMMC","/dev/block/mmcblk0p4","0");
run_program("/system/bin/dd","if=/tmp/bootloader.blob","of=/dev/block/mmcblk0p4");
unmount("/system");
mmcblk0p4 is cache partition. Please note that flashing a nonworking bootloader via *.blob will require recovery using nvflash.
MULTILBOOT:
Before I start, the bootloader will work correctly if you just use single kernel image as you were used to on previous versions. You can just use it the very same as the older versions.
In other words, you can just install it and not have to bother about this at all.
Allright, new feature of V5 is dualboot, i.e toggling to boot two different images and keeping the recovery intact, it is primarily intended to run both Android & Native Linux ported by sp3dev. In V9 this was extended with booting from EXT4 filesytem.
First, basic information:
Multiboot sets the booting partition with "permament effect" (i.e not like holding down a button to boot secondary partition, nothing like that). It is the parition that is highlighted by default on the selection screen.
Primary kernel image is LNX partition (/dev/block/mmcblk0p2, size 8 MB), or "boot" when using fastboot flash / erase command. This is the default partition, used by older bootloaders as well.
Secondary kernel image is AKB partition (/dev/block/mmcblk0p7, size 10 MB), or "secboot" when using fastboot flash / erase command. This parition used for storing checksums on HC bootloader. If this partition doesn't contain Android boot image, it will not show.
Further kernel images can be specified in the menu file for the bootloader.
Now, how to toggle between booting images:
A) Using bootloaderctl
B) Using fastboot:
- "fastboot oem set-boot-image 0" - sets to boot first kernel image
- "fastboot oem set-boot-image 1" - sets to boot second kernel image
- etc.
C) Using bootmenu GUI
Now, how to flash the secondary kernel image:
Either use "dd if=secboot.img of=/dev/block/mmcblk0p7" from within android or recovery, or in fastboot, you can use:
Code:
fastboot flash secboot secboot.img <- to flash
fastboot erase secboot <- to erase
DEV:
A) Dualboot
bootloaderctl can be used to modify bootloader settings. Source is in github, or use precompiled version for Android: http://skrilax.droid-developers.org/a500/nvflash/images/bootloaderctl
B) EXT4 FS boot
Since V9, there is also support for EXT4FS boot. Here is example menu.skrilax file for setting it up:
Code:
================================================================================
Example menu.skrilax file:
================================================================================
; commentary is prefixed with ';'
; .ini file structure
; First, three possibilities to boot from partitions
; LNX - primary image (always present, can specify title only)
[LNX]
title=Android
; AKB - secondary image (will not show if property AKB partition doesn't hold android image)
[AKB]
title=LUbuntu
; SOS - recovery image (will show if it's set by user)
title=CWM
; Properties for EXTFS booting
;
; title - text to show in menu
; cmdline - override cmdline (prefixing with @ will make the bootloader append the cmdline to the default one)
;
; Then there are two possibilities:
;
; A) boot android image
; android - path to android image (will be used if present)
;
; B) boot zImage with ramdisk (optional)
; zImage - path to zImage
; ramdisk - path to ramdisk (optional)
; First entry
[BOOT1]
title=EXT4FS Boot 1
android=APP:/boot/boot.img
; Second entry
[BOOT2]
title=EXT4FS Boot 2
zImage=APP:/boot/zImage
ramdisk=APP:/boot/ramdisk
Important to note is that path is in bootloader format i.e PARTITION:file_path_in_partition. For instance APP:/boot/boot.img would be for /system/boot/boot.img when mounted in Android. To see the partition list, see the readme on github.
Lastly you have to tell the bootloader the location of the file. Either boot to android and use bootloaderctl under root user (assuming that the file is under /system/boot/menu.skrilax):
Code:
bootloaderctl --set-boot-file APP:/boot/menu.skrilax
or use fastboot
Code:
fastboot oem set-boot-file APP:/boot/menu.skrilax
If you have problems with booting (stuck on BL screen w/o text showing anything) and have EXT4 FS boot setup, reboot to bootmenu and forbid EXT4 FS boot (it may get stuck if FS is corrupted).
C) Bootmenu
Bootmenu part of the bootloader is open source, with basic functions of the bootloader map. This includes full framebuffer access (hacked a bit as of V9), some standard library functions (you can use your own of course), partition handling, gpio (key handling), fastboot, reboot. Bootmenu currently acts as sub-bootloader, as it passes control back to the bootloader for booting the actual image.
Bootmenu is licensed GPL V3, you can find repository here: https://github.com/SkrilaxCZ/a500_bootmenu
Compile it by making "make", with CROSS_COMPILE set. You can also use "O=../obj" if you prefer obj folder like I do. Also for bootloaderctl either set NO_BOOTLOADERCTL=1 or LINUX_COMPILE and ANDROID_COMPILE for cross-compilers for Linux or Android.
FAQ:
Q: What are the main advantages over HC bootloader?
A: Mainly fastboot. Then more comfort, but for running a custom ROM, HC bootloader is just as fine. And since V5, the possibility of dualboot.
Q: Can I unbrick my A500 with nvflash?
A: Provided, that you saved CPUID to generate SBK and have mmcblk0_start backup, yes. You can recover by installing this bootloader over HC bootloader should you have SOS and LNX image checksum failure.
Q: What is the best way to install ICS bootloader?
A: First install the bootloader with nvflash. Then using fastboot (POWER + VOLUME UP) flash recovery. From there flash ROM for ICS bootloader. You can however install the recovery with nvflash too.
Q: How do I use fastboot?
A: Fastboot is part of Android SDK, you get it just as you get adb. To recover with fastboot, reset the tablet and hold POWER + VOLUME_UP, the tablet will say "Fastboot Mode". Open up command line in the directory where you have fastboot, and use:
Code:
fastboot flash boot boot.img <- flashes boot.img (to kernel partition - LNX)
fastboot flash recovery recovery.img <- flashes recovery.img (to recovery partition - SOS)
Basically, to unbrick it, use the one to flash recovery. Then boot to the recovery, and flash working backup / ROM, whatever you like.
Q: Fastboot oem debug on / off:
A: This has use only for kernel developers. Fastboot oem debug on / off will only change the cmdline to serial console (on) or null console (off). The console parameter can be edited on offset 0x87638, by default it is "console=ttyS0,115200n8".
Q: Updating BL via recovery:
A: Since V4 supports flashing custom bootloader.blobs. Trying to flash custom bootloader.blob on any other bootloader will result in update failed and bootloader not modified (so this part is safe). Flashing a bad bootloader via bootloader.blob will require recovering with nvflash.
Q: Factory reset:
A: Factory reset (Vol UP and switching the rot. lock) is not supported on patched bootloader, use recovery or "fastboot erase userdata".
Q: The tablet won't boot secondary kernel image, but I have working kernel image. What should I do?
Toggle boot partition in boot menu back to primary.
Q: The tablet doesn't boot after bootloader install.
Boot to bootmenu and wipe cache.
INSTALL:
There are four methods of installing:
A) Flashing the *.bin file using nvflash manually, providing as the bootloader_apx.bin to "-bl" argument
B) Using blackthund3r's tool, see guide here: (guide here: http://forum.xda-developers.com/showthread.php?t=1622425
C) If you have V4+ installed (or newer), you can flash the update.zip for CWM
D) If you have V5+ installed, then you can also use fastboot: "fastboot flash bootloader bootloader.blob". Please note that if you supply invalid block image, then you have to use "fastboot erase cache".
CREDITS:
Bootmenu uses code from following applications:
GRUB: jpg loading
SUSE: V8, V9 Splash screen image
yaworski: font outline / kerning
DOWNLOAD:
There are zip files with bootloaders for a500 / a501 - containing three files:
bootloader_apx.bin - this is bootloader binary to be booted when flashing via nvflash (use with -bl argument)
bootloader_hc.bin - this is HC bootloader, w/o signature and itsmagic checks
bootloader_ics_vx.bin - this is the ICS bootloader file
Please note that using old bootloader_apx.bin (from pre-V5 package) when updating manually will corrupt your secondary kernel image.
Alternatively, you can find there a500apx images for blackthund3r's tool (http://d-h.st/Fkt), there is also repository for the tool on this URL "http://skrilax.droid-developers.org/a500/nvflash", contains only bootloaders. They can be downloaded manually as well.
Download page: http://skrilax.droid-developers.org/a500/nvflash/images/
A500 / A501 ICS V9 BL:
Zip: http://skrilax.droid-developers.org/a500/nvflash/images/a500_a501_bootloaders_apx_ics_v9.zip
blackthund3r's tool package: http://skrilax.droid-developers.org/a500/nvflash/images/A500_A501_ICS_V9_bootloader.a500apx
Update.zip for CWM: http://skrilax.droid-developers.org/a500/nvflash/images/a500_a501_cwm_update_v9.zip
Wow, you found a way to boot into fastboot directly . Thank you. As for bigger logo I think that it would require to extend the space where the logo resides in bootloader file and that would require to recalculate all addresses after that area. I don't have sufficient knowledge in this area to even guess if this is possible .
This with strra , bat makes it so easy .
Thanks !!!!!!!!!!!
EDIT:
Maybe and I think it is a stupid question but anyway gonnan ask it.
I installed this and it runs fine , I can go into recovery and all but not into to fastboot ,( it says fastboot starting..............) = STUPID me need to type commands so it does sommething
And if I check my bootloader it still shows 3.01 HC ?
Do I need to flash the official leak first and then run this unlocked patch ?
I will try some different stuff , new to this nvflashing things on a tab , did it 100+ times on GPU's but never on my tab.
It pass the flash thing but then I get in red : secure boot : image LNX checksum fail !
EDIT2:
After flashing some more all is well , but still want to know what the following line means after I installed the V3 bootloader : secure boot : image LNX checksum fail !
If I check my bootloader version now it is 0.03.12-UNL and I got the Thor 1.7 recovery for ICS bootloader users running.
I can flash custom roms and all so no problems here.
Again thanks for the work !! Just a nvflash noob asking some side info !
EDIT3: Question
If I make a update .zip with only bootloader.blob and then the user runs this with the strra packages will that do the trick to make it easy to update to unlocked bootloader and custom recovery?
What I did:
See attachment ; you find what I used and your V3 is in the package , I followed the guide and links by jm77 but I used the stuff in the attachments.
Make sure you got your uid (CPUuid) so you can get your SBK. (you find this in your cwm backup folder or follow instructions from jm77 guide)
Going back to HC roms is not possible just so you know.
yaworski said:
Wow, you found a way to boot into fastboot directly . Thank you. As for bigger logo I think that it would require to extend the space where the logo resides in bootloader file and that would require to recalculate all addresses after that area. I don't have sufficient knowledge in this area to even guess if this is possible .
Click to expand...
Click to collapse
Yeah, I rewrote the fuction setting the boot mode. Well, I wasn't thinking of full screen bootlogo, just purging the other unused images and using the space for a single logo. Full logo is over 4 M.
civato said:
Do I need to flash the official leak first and then run this unlocked patch ?
I will try some different stuff , new to this nvflashing things on a tab , did it 100+ times on GPU's but never on my tab.
It pass the flash thing but then I get in red : secure boot : image LNX checksum fail !
Click to expand...
Click to collapse
We're using the HC bootloader when you communicate with nvflash (for some reason, ICS will not work). This means that after flashing, don't continue booting, just power off the tablet (as HC bootloader will fail booting on the checksums) and then power it back on.
To upgrade:
1) flash the bootloader with nvflash
2) boot to fastboot (POWER + VOLUME UP), flash CWM via fastboot
3) flash ROM via CWM
civato said:
If I make a update .zip with only bootloader.blob and then the user runs this with the strra packages will that do the trick to make it easy to update to unlocked bootloader and custom recovery?
Click to expand...
Click to collapse
No, that can't be used to install unlocked bootloader. The bootloader is checked for signature that way. Only nvflash.
Ignore this post. Quoted myself by accident.
Skrilax_CZ said:
We're using the HC bootloader when you communicate with nvflash (for some reason, ICS will not work). This means that after flashing, don't continue booting, just power off the tablet (as HC bootloader will fail booting on the checksums) and then power it back on.
To upgrade:
1) flash the bootloader with nvflash
2) boot to fastboot (POWER + VOLUME UP), flash CWM via fastboot
3) flash ROM via CWM
No, that can't be used to install unlocked bootloader. The bootloader is checked for signature that way.
Click to expand...
Click to collapse
Thanks , m8 , all went OK and works so no problems , got your V3 running and I got custom cwm .
Was just looking if it was possible to make the steps even more simple to the new users.
Can't we flash the bootloader ànd the cwm through nvflash anymore? I use a modified script from strra to flash back and forward between hc bootloader icw twrp and bootloader V2 icw the corresponding cwm.
Taptalked u see
Zatta said:
Can't we flash the bootloader ànd the cwm through nvflash anymore? I use a modified script from strra to flash back and forward between hc bootloader icw twrp and bootloader V2 icw the corresponding cwm.
Taptalked u see
Click to expand...
Click to collapse
Yes you can , I did it that way with the package I uploaded , it is strra package with this V3 in it.
Can you upload the HC bootloader for me so I can go back and fort if I want.
Skrilax_CZ said:
We're using the HC bootloader when you communicate with nvflash (for some reason, ICS will not work).
No, that can't be used to install unlocked bootloader. The bootloader is checked for signature that way. Only nvflash.
Click to expand...
Click to collapse
Could it be if we use the USB driver from the a200 ICS from Acer that is will work , communication with nvflash.
And not asking if it is possible to flash the patched bootloader with cwm.
Just a update zip with the original bootloader.blob flash it with cwm and then run nvflash to install the patched boot loader and custom recovery.
That way user won't have to download and install the whole original rom .
No, the error is in the nvflash interface in ICS bootloader itself. However it's pretty much irrelevant which bootloader you use to communicate with nvflash, if they all were working.
civato said:
And not asking if it is possible to flash the patched bootloader with cwm.
Just a update zip with the original bootloader.blob flash it with cwm and then run nvflash to install the patched boot loader and custom recovery.
That way user won't have to download and install the whole original rom .
Click to expand...
Click to collapse
Not entirely sure if I understand what you mean. If you flash original bootloader.blob with ICS, you have to have signed kernel / recovery flashed on the device. Otherwise the only way to recover from that is using nvflash. Easiest way is as I said in 1st post:
1) patched BL using nvflash
2) custom recovery with fastboot
3) ROM (or fixed boot.img for ICS bootloader)
Keep in mind, that in V2, you could only boot to fastboot via "adb reboot bootloader", POWER + VOL_UP to boot to fastboot is new in V3.
I wonder why they didn't enable OEM UNLOCK in this? Even he A510 has that capability. oh well. I'll be flashing this tonight.
THANKS!
PS. Good call on the 0.03.12-UNL version#. Thanks again!
civato said:
Yes you can , I did it that way with the package I uploaded , it is strra package with this V3 in it.
Can you upload the HC bootloader for me so I can go back and fort if I want.
Click to expand...
Click to collapse
See this post, I was looking for the same a week ago :http://forum.xda-developers.com/showthread.php?p=25175512
But I believe the bootloader.bin that is in strra's package is also the 3.01 bootloader, at least the size of the same.
Taptalked u see
Skrilax, did you check the BL in A501 latest leaks ?
Version is more recent than A500's (0.03.14-ICS), wondering what might have changed.
Oh didn't know. Rough checking by hex editor: don't see that oem unlock is enabled, and sending it through nvflash is still throwing error (just an annoyance moreless).
Skrilax_CZ said:
No, the error is in the nvflash interface in ICS bootloader itself. However it's pretty much irrelevant which bootloader you use to communicate with nvflash, if they all were working.
Not entirely sure if I understand what you mean. If you flash original bootloader.blob with ICS, you have to have signed kernel / recovery flashed on the device. Otherwise the only way to recover from that is using nvflash. Easiest way is as I said in 1st post:
1) patched BL using nvflash
2) custom recovery with fastboot
3) ROM (or fixed boot.img for ICS bootloader)
Keep in mind, that in V2, you could only boot to fastboot via "adb reboot bootloader", POWER + VOL_UP to boot to fastboot is new in V3.
Click to expand...
Click to collapse
OK thanks , didn't know about v2 as I never flashed that one.
V3 is running and doing his thing just fine .
And flashing with nvflash isn't that hard.
What I did wrong? I followed instruction and got new ICS boot v3 with fastboot, but when i try to enter into fastboot i only get text "fastboot starting ..." and nothing else.
Kh_Shad said:
What I did wrong? I followed instruction and got new ICS boot v3 with fastboot, but when i try to enter into fastboot i only get text "fastboot starting ..." and nothing else.
Click to expand...
Click to collapse
You gotta type in commands in cmd. First type fasboot devices, you will get a number or a "?" That is fine. Then you type in the commands.
Kh_Shad said:
What I did wrong? I followed instruction and got new ICS boot v3 with fastboot, but when i try to enter into fastboot i only get text "fastboot starting ..." and nothing else.
Click to expand...
Click to collapse
It doesn't print anything else (in the morning I revised it to rather say "Fastboot Mode"). Just connect it to PC and use fastboot.
civato said:
You gotta type in commands in cmd. First type fasboot devices, you will get a number or a "?" That is fine. Then you type in the commands.
Click to expand...
Click to collapse
OK so I'm pretty tech say. Lol but I'm kinda confused as to how to get to is bootloader. I don't know what nvflash is or where to find it as I have been through the links and can't find it. And just confusing with all the links and such. Could anyone PLEASE pm what I need to do exactly and links to exactly what I need. I would be forever greatful. Thank you one and all for whatever help you give me
Sent from my A500 using Tapatalk 2
warfenix said:
OK so I'm pretty tech say. Lol but I'm kinda confused as to how to get to is bootloader. I don't know what nvflash is or where to find it as I have been through the links and can't find it. And just confusing with all the links and such. Could anyone PLEASE pm what I need to do exactly and links to exactly what I need. I would be forever greatful. Thank you one and all for whatever help you give me
Sent from my A500 using Tapatalk 2
Click to expand...
Click to collapse
If I got time I do a wright up on the steps how I did it and with the test rom I used .
Only tip I want to give is ,if you flash the full leaked rom 1.031.00 ( same as what Acer is rolling out as ICS release now so it seems ) is to open it with winrar or 7 zip ( don't unpack ) and delete the recovery folder in it. Makes it easier on the recovery part.
And that is how I did I it.
But again I will do wright up as I understand that for some it is kinda scary to do this.
Hallo guys, curently I waiting confirmation from emma registration (5 days), never got confirmation so my registration is not complete and I can't login to emma to install openbootloader, so anybody here please give me binary file (or files) downloaded from emma and share it with me by pm?
I don't know which format use these files downloaded from emma but if anybody have it allready on his disk give me that please, if not, it can be dumped by adb shell in next way:
dd if=/dev/block/platform/msm_sdcc.1/by-name/gpt of=/data/local/tmp/gpt
dd if=/dev/block/platform/msm_sdcc.1/by-name/sbl1 of=/data/local/tmp/sbl1
dd if=/dev/block/platform/msm_sdcc.1/by-name/s1sbl of=/data/local/tmp/s1sbl
dd if=/dev/block/platform/msm_sdcc.1/by-name/dbi of=/data/local/tmp/dbi
dd if=/dev/block/platform/msm_sdcc.1/by-name/aboot of=/data/local/tmp/aboot
dd if=/dev/block/platform/msm_sdcc.1/by-name/rpm of=/data/local/tmp/rpm
dd if=/dev/block/platform/msm_sdcc.1/by-name/tz of=/data/local/tmp/tz
These seven files will be located under /data/local/tmp folder (gpt, sbl1, s1sbl, dbi, aboot, rpm, tz), add it to the archive and share them with me by pm (don't post it here please), thank you
munjeni said:
Hallo guys, curently I waiting confirmation from emma registration (5 days), never got confirmation so my registration is not complete and I can't login to emma to install openbootloader, so anybody here please give me binary file (or files) downloaded from emma and share it with me by pm?
I don't know which format use these files downloaded from emma but if anybody have it allready on his disk give me that please, if not, it can be dumped by adb shell in next way:
dd if=/dev/block/platform/msm_sdcc.1/by-name/gpt of=/data/local/tmp/gpt
dd if=/dev/block/platform/msm_sdcc.1/by-name/sbl1 of=/data/local/tmp/sbl1
dd if=/dev/block/platform/msm_sdcc.1/by-name/s1sbl of=/data/local/tmp/s1sbl
dd if=/dev/block/platform/msm_sdcc.1/by-name/dbi of=/data/local/tmp/dbi
dd if=/dev/block/platform/msm_sdcc.1/by-name/aboot of=/data/local/tmp/aboot
dd if=/dev/block/platform/msm_sdcc.1/by-name/rpm of=/data/local/tmp/rpm
dd if=/dev/block/platform/msm_sdcc.1/by-name/tz of=/data/local/tmp/tz
These seven files will be located under /data/local/tmp folder (gpt, sbl1, s1sbl, dbi, aboot, rpm, tz), add it to the archive and share them with me by pm (don't post it here please), thank you
Click to expand...
Click to collapse
Don't need registration for Emma. I don't have the info here, but search it. You just have to download a file and swap it in the Emma folder.
Found it - http://developer.sonymobile.com/services/flash-tool/how-to-download-and-install-the-flash-tool/
Thank you!
Ok got emma working but can't see openbootloader for amami
munjeni said:
Ok got emma working but can't see openbootloader for amami
Click to expand...
Click to collapse
Instructions here -
http://developer.sonymobile.com/201...for-a-range-of-unlocked-xperia-devices-video/
Everything is grayed out until you connect, then you get drop-down menus, one of which has 'ta update' option.
I can see TA update but can't see bootloader update! Whats going on with this? Is ta update mean bootloader update?
Got it now, interesting that these ta update enables recovery option Trim area is realy an misterious thing on xperia devices. Its just writen new Rhine S1 Boot Config Data aka TA unit 84F and freed unit 8FD ... realy interesting. We have only 16mb free space available for recovery:
partitions offsets on amami:
Code:
gpt - 0 to 0x0001FFFF lenght=0x00020000
ta - 0x00020000 to 0x0021FFFF lenght=0x00200000
sbl1 - 0x00220000 to 0x0029FFFF lenght=0x00080000
s1sbl - 0x002A0000 to 0x002DFFFF lenght=0x00040000
dbi - 0x002E0000 to 0x002EFFFF lenght=0x00010000
aboot - 0x002F0000 to 0x0036FFFF lenght=0x00080000
rpm - 0x00370000 to 0x003EFFFF lenght=0x00080000
tz - 0x003F0000 to 0x0046FFFF lenght=0x00080000
alt_sbl1 - 0x00470000 to 0x004EFFFF lenght=0x00080000
alt_s1sbl - 0x004F0000 to 0x0052FFFF lenght=0x00040000
alt_dbi - 0x00530000 to 0x0053FFFF lenght=0x00010000
alt_aboot - 0x00540000 to 0x005BFFFF lenght=0x00080000
alt_rpm - 0x005C0000 to 0x0063FFFF lenght=0x00080000
alt_tz - 0x00640000 to 0x006BFFFF lenght=0x00080000
boot - 0x006C0000 to 0x01ABFFFF lenght=0x01400000
ramdump - 0x01AC0000 to 0x024BFFFF lenght=0x00A00000
fotakernel - 0x024C0000 to 0x034BFFFF lenght=0x01000000
ddr - 0x034C0000 to 0x034C7FFF lenght=0x00008000
Probably we can resize any partition after alt_tz by modifying first part of the bootchain aka gpt partition table... hope somebody figure it out. For example add new EFI partition?
. .
is there any specyfic adventage of useing this Oficial AOSP Recovery provided on Sony Developer website over the CWM or TWRP?
Will it support all flashing all the zip. like twrp, with work no-problem for me?
Giving the fact that its official recovery i asume its way better and stable then TWRP, but maybe I'm wrong?
freeman94 said:
is there any specyfic adventage of useing this Oficial AOSP Recovery provided on Sony Developer website over the CWM or TWRP?
Will it support all flashing all the zip. like twrp, with work no-problem for me?
Giving the fact that its official recovery i asume its way better and stable then TWRP, but maybe I'm wrong?
Click to expand...
Click to collapse
It's not a recovery itself, but a new bootloader which enables real recovery. You still use TWRP, but before, the recovery was part of the kernel, not its own partition. The new bootloader changes that.
levone1 said:
It's not a recovery itself, but a new bootloader which enables real recovery. You still use TWRP, but before, the recovery was part of the kernel, not its own partition. The new bootloader changes that.
Click to expand...
Click to collapse
levone. are you using the new open boot loader?
Sent from my Nexus 7 using XDA Free mobile app
[email protected] said:
levone. are you using the new open boot loader?
Sent from my Nexus 7 using XDA Free mobile app
Click to expand...
Click to collapse
Yes. Updated with Emma a few months ago.
levone1 said:
It's not a recovery itself, but a new bootloader which enables real recovery. You still use TWRP, but before, the recovery was part of the kernel, not its own partition. The new bootloader changes that.
Click to expand...
Click to collapse
You are wrong! Thats not a new bootloader! We allready had recovery partition (fotakernel) but it was secured and only Sony signed binaries was abble to boot from that partition. Updating "openbootloader" you get everything the same, only trim area is updated (which disabled security on recovery partition so unsigned recoveries can boot now). Aosp recovery is not good, I sugest you to use something but not an AOSP recovery since it can't detect storage and lacks of options! Allso latest AOSP kernel (3.10.xxx) sometimes bootloop and phone locks without a way for restart (power + volumes have no efect, allso reset button under simcard slot have no efect, so in order to restart phone you must open back plate of the phone to remove battery connector or option two to wait until battery got empty! No way for restarting phone)!!!
Edit:
No need to open backplate, just simple longer wait on button combinations (volup+voldown+power) do phone restart. WTH
munjeni said:
You are wrong! Thats not a new bootloader! We allready had recovery partition (fotakernel) but it was secured and only Sony signed binaries was abble to boot from that partition. Updating "openbootloader" you get everything the same, only trim area is updated (which disabled security on recovery partition so unsigned recoveries can boot now). Aosp recovery is not good, I sugest you to use something but not an AOSP recovery since it can't detect storage and lacks of options! Allso latest AOSP kernel (3.10.xxx) sometimes bootloop and phone locks without a way for restart (power + volumes have no efect, allso reset button under simcard slot have no efect, so in order to restart phone you must open back plate of the phone to remove battery connector or option two to wait until battery got empty! No way for restarting phone)!!!
Click to expand...
Click to collapse
You're way ahead of me, and I love your roms, so I receive you fully. Thanks. I don't actually know much about any of it, I just repeat what I've read. I can help you with one thing though... I experienced the same problem with volume button power off not working while I was messing around with Omni, and I discovered that if you press sim-card-slot button while holding power off for 8 seconds, phone will reboot. Then, if you do it right away, you can use power button + volume down to power off. Try it out and let me know. If you can confirm, it might help others out. Keep up the good work.
Thanks pro
Gửi từ D5503 của tôi bằng cách sử dụng Tapatalk
Step-by-step instructions for reproducing this work will be in the second post.
Regardless of anyone's opinion about it being a good idea, some people prefer to run their device with a locked bootloader, whether for security, to avoid the 5-second wait on boot, or for some other reason. Unfortunately, it seems to be common knowledge around these forums that you cannot re-lock your bootloader on this device after installing a custom firmware or recovery, or at least you will "brick" your device by trying. After being re-locked, the bootloader appears to load your custom boot.img/recovery.img, fail to verify it (or crash in the process), and immediately reboot. So consensus is that everyone is stuck with the 5-second warning screen.
However, the blog post releasing the bootloader vulnerabilities shows proof (see the image halfway down the page) that at least one person was able to flash a modified boot image and still be able to boot with a locked bootloader. Taking advantage of the vulnerabilities in the OOS 4.0.1 bootloader described on that page, I did some research into why he was able to boot (albeit still with a warning) while everyone else gets stuck in a loop. I'll skip the process of experimentation, and go straight to the results.
The bootloader for this device is provided by Qualcomm/CAF (see https://github.com/OnePlusOSS/android/blob/bd6a70d6218dbc0e72f70740422e3dac2fdc82fb/default.xml#L32). Source is at https://source.codeaurora.org/quic/la/kernel/lk/tree/?h=LA.HB.1.3.1.c1.
The bootloader has two states, locked and unlocked. (If you read the slides linked below, you'll see that some Android bootloaders, such as Intel's, have a third "verified" state; ours does not). In the unlocked state, no verification of the boot image is performed at all, so the presence of a signature is not important. In the locked state, the bootloader expects a signature to be present just past the end of the boot image (calculated based on the lengths in the header), following the scheme described in this LWN article. Additional documentation from Qualcomm is here.
If the signature is valid, the device boots the kernel without warning.
If the signature is invalid (does not match the kernel or is not signed by the appropriate key), the device boots with a verification warning like the one seen here.
If the signature is missing (currently the case on all custom kernels and recoveries), the device immediately reboots.
When built from source, the signature is added by the boot_signer utility in system/extras/verity. This utility gets called from build/core/Makefile when PRODUCT_SUPPORTS_BOOT_SIGNER is set for the device. Normally this is enabled from build/target/product/verity.mk when dm-verity is enabled for the device, like it is on the stock firmware. However, since custom ROMs disable dm-verity, they end up disabling boot.img signing as well.
Thus, the purpose of this thread is to encourage custom ROM, kernel, and recovery developers to enable boot.img signing in their device tree, or to manually run boot_signer on their generated boot.img files, or even simply concatenate a valid (that is, parseable by the bootloader, while not cryptographically correct) signature to the end of the file. Note that for AnyKernel-like packages that run mkbootimg on the device, this will have to be done afterward. Even if developers do not start adding signatures to kernels they release, it should be possible to create a flashable zip that fake-signs any installed custom kernel, that way you can keep your bootloader locked without waiting for an update.
While this step will prevent bricking devices by locking the bootloader, a worthy goal in itself, it does not remove all boot delays/warnings. This should be possible by generating and flashing your own signing key to the keystore partition with fastboot, as described in the linked slides. I have not had a chance yet to try this. However, the current bootloader (as of OOS 4.0.3) is vulnerable to the bug fixed here. This means that if the size of the boot.img does not match the size reported in the signature, the bootloader does not attempt to verify it cryptographically and simply returns success. This allows custom kernels/recoveries to boot without any warning or prompt at all. This is how I have my device working right now.
Unfortunately, this is likely a very bad idea going forward. The device appears to use a different flash storage encryption key based on what security state the bootloader is in. This explains problems where people "without encryption" get prompted for a password after first installing TWRP, and threads such as this one. Once the bug is fixed, the bootloader will be in a red state (invalid signature) or at least a yellow state (non-OEM key) and will likely use the "untrusted" key, forcing everyone who uses this trick to wipe their data after updating the bootloader.
Documentation:
Android Verified Boot: https://source.android.com/security/verifiedboot/verified-boot.html
Android Keystore: https://developer.android.com/studio/publish/app-signing.html
Android Verified Boot: https://lwn.net/Articles/638627/
Qualcomm Bootloader: https://developer.qualcomm.com/download/db410c/little-kernel-boot-loader-overview.pdf
WARNING: Before playing around with any of this, enable OEM unlocking in Developer options and downgrade to the OOS 4.0.1 bootloader, or you may lock yourself out permanently!
How to extract the signature from a stock boot.img:
Find the end of the Android boot image data in the file. Use unpackbootimg (e.g. from LineageOS) and add up the size of the extracted "zImage" and "ramdisk.gz" files, or read the sizes of the kernel and initramfs directly from the boot image header. Round up each of these sizes to a multiple of 4096, since each section of the boot image data is always a multiple of the page size.
Add one page (4096 bytes) for the header at the beginning of the file.
The next bytes immediately following that will be the signature. From the documentation/bootloader source, it can vary in length, but OnePlus's signatures are around 1320 bytes long. The size of the signature is a variable-length integer starting with the second byte of the signature. In short, take 256*sig[2]+sig[3]+4 as full length of the signature data.
How to fool the current bootloader and bypass all warnings:
Concatenate any valid-format signature to the end of your boot image.
Flash your boot image with fastboot or in TWRP.
Profit.
Note that this method works for any modified kernel: TWRP, stock with Super-SU, LineageOS, franco.kernel, etc. (Well, almost any. The signature records the size of the boot image in it, and if that happens to match, you will get a warning, but it will still boot.)
The attached zip file will perform this operation on the currently-installed boot image.
I have added a zipfile (sha256sum c4a15c0d3d6f8efa4c4e14196b48790cdb86f6110bcb51e92dbfce32c959db11) to the second post that will "sign" the currently-installed boot image using the certificate from the OP3T beta 3 stock kernel (though any one will work). It is intended to be flashed last after installing your ROM or kernel. Unfortunately, you will have to do this after every update. It will be obvious if you forget, but the reboot cycle won't hurt anything (just use the button combo to get back to recovery).
I can't attach a fixed recovery because it's too large, but you can modify the zip to sign the recovery partition (the path at the top of the script). Of course, you would have to do this before locking your bootloader.
smaeul said:
How to extract the signature ....
... add up the size of ...
.. add one page (4096 bytes) ... then round up ...
.. The next bytes immediately following that will be the signature.
... OnePlus's signatures are 1320 bytes long. ...
... note that this method works for any modified kernel:
Click to expand...
Click to collapse
The above maths is fine for the boot.img of OP3 but the recovery.img leaves 5420 bytes (both are attached). When I compared these trailing 1320 and 5420 bytes, they seemed similar but the 5420 bytes extracted from recovery.img have a lot of trailing zeros. What explains this? (PS: I used the tail command on ubuntu to extract these bytes from 4.0.3 stock boot and recovery images).
rk2612 said:
The above maths is fine for the boot.img of OP3 but the recovery.img leaves 5420 bytes (both are attached). When I compared these trailing 1320 and 5420 bytes, they seemed similar but the 5420 bytes extracted from recovery.img have a lot of trailing zeros. What explains this? (PS: I used the tail command on ubuntu to extract these bytes from 4.0.3 stock boot and recovery images).
Click to expand...
Click to collapse
The math I provided earlier is also only right when the kernel or ramdisk happens to be a multiple of 4096 bytes. The correct algorithm for the offset (and I'll update the second post) is round_to_4096(kernel)+round_to_4096(ramdisk)+4096.
The size of the signature is actually encoded at the beginning of the DER data, as a variable-length integer (see the source). Pasted below is the first 64 bytes of the signature from the stock recovery. You can see that the first byte matches what the bootloader expects (line 106 of the code). The second byte tells us the signature length is two bytes long. The next two bytes are 0x0528 (hexadecimal), which is 1320 when converted to decimal. So those 4 bytes + the next 1320 are the signature. So the remaining 4096 bytes (exactly one flash page) is something else. It could be junk or some other (OnePlus-specific?) metadata.
Code:
00000000 30 82 05 28 02 01 01 30 82 03 fd 30 82 02 e5 a0 |0..(...0...0....|
00000010 03 02 01 02 02 09 00 97 0f 98 39 09 aa 89 49 30 |..........9...I0|
00000020 0d 06 09 2a 86 48 86 f7 0d 01 01 05 05 00 30 81 |...*.H........0.|
00000030 94 31 0b 30 09 06 03 55 04 06 13 02 55 53 31 13 |.1.0...U....US1.|
This matches what we expect from the boot.img, which has a signature that is 4+0x0524 = 1320 bytes long, and that is exactly the length of the extra data after the ramdisk. When we have the whole signature, we can use openssl to decode it:
Code:
openssl asn1parse -i -in signature.der -inform der
Oh, and I'll add this to the OP, I found the official Android description about how this all works: https://source.android.com/security/verifiedboot/verified-boot.html
smaeul said:
...
This matches what we expect from the boot.img, which has a signature that is 4+0x0524 = 1320 bytes long, and that is exactly the length of the extra data after the ramdisk. ...
Click to expand...
Click to collapse
But then comparing these 1320 bytes from recovery and boot images, aren't they different?
rk2612 said:
But then comparing these 1320 bytes from recovery and boot images, aren't they different?
Click to expand...
Click to collapse
Yes, of course. The last 256 bytes of the signature are an encrypted hash of the boot image. The bootloader is supposed to 1) calculate a hash of the boot image and 2) decrypt the hash in the signature using the public key from the certificate (also in the signature), and then verify that the two hashes match. The reason that we can just throw these existing signatures around is that, when the boot image is the wrong size, the bootloader doesn't even look at the hash in the signature.
The point of what you quoted was to say that the math that tells us how many bytes there should be, matched the actual number of bytes remaining in the file, so therefore the math was reasonable. The signatures from the two files do not match. They are not even the same size (though I haven't investigated why yet). But it doesn't matter what they contain, as long as they cause the bootloader to 1) not crash and 2) trigger the bug.
smaeul said:
Yes, of course. The last 256 bytes of the signature are an encrypted hash of the boot image. The bootloader is supposed to 1) calculate a hash of the boot image and 2) decrypt the hash in the signature using the public key from the certificate (also in the signature), and then verify that the two hashes match. The reason that we can just throw these existing signatures around is that, when the boot image is the wrong size, the bootloader doesn't even look at the hash in the signature.
The point of what you quoted was to say that the math that tells us how many bytes there should be, matched the actual number of bytes remaining in the file, so therefore the math was reasonable. The signatures from the two files do not match. They are not even the same size (though I haven't investigated why yet). But it doesn't matter what they contain, as long as they cause the bootloader to 1) not crash and 2) trigger the bug.
Click to expand...
Click to collapse
Thanks. Try concatenating the 5420 bytes from the stock recovery to TWRP and see the magic!!! I was brave enough to try with a locked bootloader. .....Of course with OOS 4.0.1 bootloader. Reminds me of Bump! on LG G3. Not sure if this will work with OOS 4.0.3 bootloader.
A few other things I tried which seem weird and quite likely to be a security loophole:
1. When you unlock a bootloader, it boots back into the security warning screen. At that time, the data partition is still not wiped!
2. The data partition is wiped when it starts to boot and goes into recovery. I think the code --wipe-data is used with a recovery script (openrecoveryscript or recovery.command) stored in cache.
3. Therefore, if a modified recovery is flashed immediately after unlocking and before it boots into recovery, then it possible to defeat the script (...can be done by either not mounting cache or by not mounting data partitions ... deleting mount points in fstab).
4. Even if an official TWRP is flashed immediately after unlocking, the data wipe does not wipe data/media as TWRP treats these wipes differently than stock recovery.
From a tigher security point of view, I would have expected fastboot to wipe the data partition rather than rely on recovery to do it. Therefore, this sounds like a security loophole but I do not have enough technical knowledge to say with full certainty as I consider myself a "cut-and-paste" developer.
And I also wonder whether this behaviour is specific to OnePlus 3 or if it is similar across all devices where bootloader can be unlocked.
rk2612 said:
Thanks. Try concatenating the 5420 bytes from the stock recovery to TWRP and see the magic!!! I was brave enough to try with a locked bootloader. .....Of course with OOS 4.0.1 bootloader. Reminds me of Bump! on LG G3. Not sure if this will work with OOS 4.0.3 bootloader.
A few other things I tried which seem weird and quite likely to be a security loophole:
1. When you unlock a bootloader, it boots back into the security warning screen. At that time, the data partition is still not wiped!
2. The data partition is wiped when it starts to boot and goes into recovery. I think the code --wipe-data is used with a recovery script (openrecoveryscript or recovery.command) stored in cache.
3. Therefore, if a modified recovery is flashed immediately after unlocking and before it boots into recovery, then it possible to defeat the script (...can be done by either not mounting cache or by not mounting data partitions ... deleting mount points in fstab).
4. Even if an official TWRP is flashed immediately after unlocking, the data wipe does not wipe data/media as TWRP treats these wipes differently than stock recovery.
From a tigher security point of view, I would have expected fastboot to wipe the data partition rather than rely on recovery to do it. Therefore, this sounds like a security loophole but I do not have enough technical knowledge to say with full certainty as I consider myself a "cut-and-paste" developer.
And I also wonder whether this behaviour is specific to OnePlus 3 or if it is similar across all devices where bootloader can be unlocked.
Click to expand...
Click to collapse
You wouldn't have to use a modified recovery. "fastboot erase cache" before booting into recovery mode should do the trick.
I'm on the latest open beta bootloader for the 3T (I haven't bothered to update since OOS 4.1.0 came out), and nothing has changed. Even if OnePlus does pull changes from Qualcomm and fix the bug, it will still boot, albeit with the warning shown here:
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Ironically, according to Google's documentation, the "red boot state" shown there should force the device to turn off after the delay (prevent booting).
Further explanation of the wiping comes from Google's verified boot documentation. Search for "Binding TEE root of trust". Basically, the disk encryption key is derived from the kernel signing key and the boot verification state, in addition to your password. So when you boot an unsigned (or signed-by-somebody-else) recovery/kernel, the encryption key will be different, even for the same password. That's what causes the impossible password prompt in TWRP, and how they can implement "wiping without actually wiping" once you break dm-verity or install a custom ROM.
Of course, since the bug lets you still be in the green bootstate, that means you can keep your data from stock, locked, unrooted OOS, since the keys stay the same. So, yes, this is a huge security vulnerability, because it allows somebody to install a malicious OS without triggering a wipe. For this and other reasons, security on this phone is a joke, and there's nothing we can do about it.
smaeul said:
You wouldn't have to use a modified recovery. "fastboot erase cache" before booting into recovery mode should do the trick.
Click to expand...
Click to collapse
Somehow that didn't work me. Maybe the wipe instruction are placed into cache again after the device starts booting.
---------- Post added at 07:10 AM ---------- Previous post was at 06:35 AM ----------
smaeul said:
....So when you boot an unsigned (or signed-by-somebody-else) recovery/kernel, the encryption key will be different, even for the same password. That's what causes the impossible password prompt in TWRP, and how they can implement "wiping without actually wiping" once you break dm-verity or install a custom ROM.
...For this and other reasons, security on this phone is a joke, and there's nothing we can do about it.
Click to expand...
Click to collapse
I used the following way to get around this impossible password:
1. After unlocking, immediately flashed a modified TWRP recovery which did not mount cache.
2. Backed up system and data with TWRP on usb-otg.
3. Flashed stock recovery, which did a factory reset at next boot (...because the script to wipe data was still there).
4. Flashed TWRP at the next startup (...device is without any data).
5. Used TWRP to flash a modified boot image (...with encryptable data partition and system verify deleted in boot fstab).
6. Restored backed up system from TWRP and set up the device as a fresh device (... data is unencrypted).
7. Booted back into TWRP and restored backed up data from TWRP and wiped cache.
8. Delected the 5 lock settings files in /data/system/.
9. Booted back into device with original data unencrypted and without any impossible password!
10. Booted into fastboot and flashed stock recovery (...to enable full data wipe if the device falls into not so experienced hands).
11. Locked bootloader and used fastboot oem disable_dm_verity using OOS4.0.1 bootloader (...because I am using a modified hosts file in my system).
12. Set up passwords again after booting into device.
(...I think this works because I had file encryption rather than full device encryption).
The security warning that you refer to is still showing but the device is locked and has original data. I think the data can be encrypted back again (...because boot fstab has a flag of encryptable). And then stock boot and system images can also be flashed back again (...unless system has modifications like a modified hosts file like mine). Perhaps without system modification and with original boot, this warning will also go away but I do not want to give up on my modified hosts file as yet.
Two things that are still bugging me:
1. Is there any way to get rid of security warning (...using a properly self signed boot image rather than an invalid signature)? I'm aware that with all the security loopholes in this device / bootloader / android, that does not grant full security but all I am trying to achieve is for the device to look unmodified so that not so experienced persons who find my device believes that confidential information cannot be extracted from it.
2. If I flash either of systemless or system SuperSu before locking, the device does not boot fully and gets stuck at the rotating dots animation. BTW, I do not miss root so much on nougat as hosts file can be replaced through TWRP and data control in nougat serves as an effective firewall. But I'm still looking for flexibility in case it is needed.
Any suggestions?
smaeul said:
.....though I haven't investigated why yet...
Click to expand...
Click to collapse
The signature on an Android verifiable boot image is an ASN.1 DER-encoded message (https://source.android.com/security/verifiedboot/verified-boot.html). This can be parsed using online tools (https://lapo.it/asn1js/#30820524020...B24FF93E4ADF5F5D7D4153F794D2EE9D87422AB8A2258) to show that 1320 bytes of the boot signature comprise of a 1316 byte length sequence.
Decoding the signature of the recovery block indicates that the differences are:
1. An extra page in the end (4096 bytes) in addition to the above (as you'd already pointed out)
2. Before that, recovery signature is 4 bytes longer because "/recovery" string takes 4 extra bytes to represent compared to "/boot" string.
3. Size of the recovery image (as mentioned within the 1324 bytes) is different from boot image as well.
rk2612 said:
Somehow that didn't work me. Maybe the wipe instruction are placed into cache again after the device starts booting.
Click to expand...
Click to collapse
It may be an kernel command-line argument or on the "persist" or "misc" partition instead of inside /cache. I haven't looked into it.
rk2612 said:
The security warning that you refer to is still showing but the device is locked and has original data. I think the data can be encrypted back again (...because boot fstab has a flag of encryptable). And then stock boot and system images can also be flashed back again (...unless system has modifications like a modified hosts file like mine). Perhaps without system modification and with original boot, this warning will also go away but I do not want to give up on my modified hosts file as yet.
Two things that are still bugging me:
1. Is there any way to get rid of security warning (...using a properly self signed boot image rather than an invalid signature)? I'm aware that with all the security loopholes in this device / bootloader / android, that does not grant full security but all I am trying to achieve is for the device to look unmodified so that not so experienced persons who find my device believes that confidential information cannot be extracted from it.
2. If I flash either of systemless or system SuperSu before locking, the device does not boot fully and gets stuck at the rotating dots animation. BTW, I do not miss root so much on nougat as hosts file can be replaced through TWRP and data control in nougat serves as an effective firewall. But I'm still looking for flexibility in case it is needed.
Any suggestions?
Click to expand...
Click to collapse
Is the security warning about dm-verity, or that it cannot verify the kernel/OS? (Post an image?) If it's dm-verity, see the verified boot documentation (search for "Recovering from dm-verity errors") for how that gets reset. I don't know which way device uses, since I haven't spent much time on a dm-verity enforcing ROM/kernel. If the warning is about something else, I don't know. My device never shows any warnings except with a modified stock kernel/recovery that matches the original size.
rk2612 said:
2. Before that, recovery signature is 4 bytes longer because "/recovery" string takes 4 extra bytes to represent compared to "/boot" string.
Click to expand...
Click to collapse
Well that makes perfect sense .
smaeul said:
It may be an kernel command-line argument or on the "persist" or "misc" partition instead of inside /cache. I haven't looked into it.
Click to expand...
Click to collapse
No, I think it is in the cache as the command does not execute if a modified recovery (which does not mount cache) is used. But the command may be getting pushed from devinfo partition (where I think fastboot related status is stored).
smaeul said:
Is the security warning about dm-verity, or that it cannot verify the kernel/OS? (Post an image?) If it's dm-verity, see the verified boot documentation (search for "Recovering from dm-verity errors") for how that gets reset. I don't know which way device uses, since I haven't spent much time on a dm-verity enforcing ROM/kernel. If the warning is about something else, I don't know. My device never shows any warnings except with a modified stock kernel/recovery that matches the original size.
Click to expand...
Click to collapse
The warning is the same one as in the image that you posted. And that's because I am using a modified kernel (no forced encryption and no verify for /system) for the time being. I doubt if there is a way to get rid of that warning and keep a modified kernel or system. Also, if I go back to stock kernel and have a modified system (...not yet ready to give up on hosts file ad-blocking after so many years), then I will have to rely on the fastboot oem disable_dm_verity and that may also trigger a warning I think. No?
rk2612 said:
The warning is the same one as in the image that you posted. And that's because I am using a modified kernel (no forced encryption and no verify for /system) for the time being. I doubt if there is a way to get rid of that warning and keep a modified kernel or system. Also, if I go back to stock kernel and have a modified system (...not yet ready to give up on hosts file ad-blocking after so many years), then I will have to rely on the fastboot oem disable_dm_verity and that may also trigger a warning I think. No?
Click to expand...
Click to collapse
Are you using the stock kernel that you unpacked and repacked? And are you using the signature from the stock kernel? That's the one case where you will get that warning. Since the repacked kernel is the exact same size as the original one, the bug in the bootloader isn't triggered, and the verification fails as it should. Try using the signature from the stock recovery with your kernel and see if the warning goes away.
smaeul said:
Are you using the stock kernel that you unpacked and repacked? And are you using the signature from the stock kernel? That's the one case where you will get that warning. Since the repacked kernel is the exact same size as the original one, the bug in the bootloader isn't triggered, and the verification fails as it should. Try using the signature from the stock recovery with your kernel and see if the warning goes away.
Click to expand...
Click to collapse
I'm currently using the stock kernel modified with a modified fstab (no verify for /system and encryptable instead of forced encryption for /data). When I repacked the kernel, it came to be a slightly different size even without the signature. The warning remains ....with or without a signature (from either boot or recovery).
What triggers the warning in your case?
rk2612 said:
I'm currently using the stock kernel modified with a modified fstab (no verify for /system and encryptable instead of forced encryption for /data). When I repacked the kernel, it came to be a slightly different size even without the signature. The warning remains ....with or without a signature (from either boot or recovery).
What triggers the warning in your case?
Click to expand...
Click to collapse
I was only able to trigger the warning by unpacking and repacking the stock kernel, and appending the original signature from the same stock kernel. Any custom kernel, SuperSU rooted stock kernel, recovery kernel, etc. signed with the stock kernel signature did not produce any warning/prompt at all. This is with the bootloader from OOS 4.0.1, 4.0.3, and 4.1.0 beta 3. I haven't updated to the 4.1.0 stable yet. What is your bootloader version.
Send me your modified boot.img and I'll create a signature for it that should avoid the warning.
SOLVED
smaeul said:
I was only able to trigger the warning by unpacking and repacking the stock kernel, and appending the original signature from the same stock kernel. Any custom kernel, SuperSU rooted stock kernel, recovery kernel, etc. signed with the stock kernel signature did not produce any warning/prompt at all. This is with the bootloader from OOS 4.0.1, 4.0.3, and 4.1.0 beta 3. I haven't updated to the 4.1.0 stable yet. What is your bootloader version.
Send me your modified boot.img and I'll create a signature for it that should avoid the warning.
Click to expand...
Click to collapse
Thanks. I'm using bootloader 4.0.1 but have modified boot and system from 4.0.3. Modified boot image attached.
EDIT: Reading your comment again, I realize what I missed. You mention that the warning comes after by unpacking and repacking the stock kernel (with modifications, I presume). That is the case with me as well. However, I have now locked the device and if I try to flash SuperSu 2.79SR3 (systemless) now, I get into a bootloop.
SOLVED: On a hunch, I hex edited the boot signature to reduce the size mentioned after the "/boot" and made it nearly half of the original boot.img size. And it worked without throwing up any warning!!! Thanks to you for pointing out that size variation triggers the bug which causes the warning not to be displayed. The size difference needs to be (perhaps) big enough for the warning not to be triggered (...maybe bigger than the 1,320 bytes being added / bigger than one page ).
rk2612 said:
Thanks. I'm using bootloader 4.0.1 but have modified boot and system from 4.0.3. Modified boot image attached.
EDIT: Reading your comment again, I realize what I missed. You mention that the warning comes after by unpacking and repacking the stock kernel (with modifications, I presume). That is the case with me as well. However, I have now locked the device and if I try to flash SuperSu 2.79SR3 (systemless) now, I get into a bootloop.
SOLVED: On a hunch, I hex edited the boot signature to reduce the size mentioned after the "/boot" and made it nearly half of the original boot.img size. And it worked without throwing up any warning!!! Thanks to you for pointing out that size variation triggers the bug which causes the warning not to be displayed. The size difference needs to be (perhaps) big enough for the warning not to be triggered (...maybe bigger than the 1,320 bytes being added / bigger than one page ).
Click to expand...
Click to collapse
If you flash a zip that modifies your boot image, like SuperSU, you should expect to get the boot loop. They work by running unpackbootimg and mkbootimg on your device, which will throw away any signature. If you flash the fakesign.zip from post 2 after flashing SuperSU (or adb pull the boot partition and manually add the signature yourself), it should work.
Try the boot image in the attached zip and see if it works or produces any warning.
Boot loops caused by SuperSu are not due to signature. If modified stock boot works without a signature and only a warning, why should be any different for further modifications to boot image by SuperSu?
rk2612 said:
Boot loops caused by SuperSu are not due to signature. If modified stock boot works without a signature and only a warning, why should be any different for further modifications to boot image by SuperSu?
Click to expand...
Click to collapse
Ah, this is the fun part, and something that had me confused for an hour or two as well. The modified stock boot image does not work without a signature. It only appears to, because the repacked image is the same size as the signed one, minus the signature at the end. I can guarantee this because you say you got the warning. This means that when you flash it, the original signature is still sitting there in flash!
The boot.img before the signature is a multiple of the page size long. Only the necessary flash pages are written by fastboot. So any part of the flash partition after that point will be untouched. Since the signature is on the next page, it doesn't get erased or changed.
Try a "fastboot erase boot" and then flashed the unsigned modified stock. It won't work, because the signature is erased. SuperSU doesn't work without re-signing because it adds several files to the ramdisk, thus increasing the size of the boot image and overwriting the residual in-flash signature. If the boot.img was modified to be smaller than the original, the signature would still be there, but not where the bootloader looks for it, so that case would fail as well.
I dont take responsibility for possible damages!'
1. When you unlock the bootloader, all your data will be erased!
2. When you try to lock the bootloader, your data will be erased and you will lose the API.
3. YOU CAN RECEIVE OTA UPDATES WITH THE BOOTLOADER UNLOCKED!
Download the tool: https://forum.xda-developers.com/mi-a2/how-to/mi-a2-toolkit-unlock-bootloader-root-t3834585
1. Unlock the bootloader (I will not go into detail, the tool is intuitive, follow the tool's instructions!.)
2. Start your phone and enable USB debugging.
3. Put your cellphone in Fastboot.
4. In the tool, use option 4 (This will not install TWRP, just start) (follow the tool's instructions!)
5. When entering TWRP, if prompted, check "Keep system read only".
6. Open in the tool folder "Open CMD here"
7. Run the command: adb shell
8. Now enter the following command: "setprop persist.camera.HAL3.enabled 1" without quotation marks, and enter. - This command enables the required core API for GCAM.
9. Now type "exit" to exit adb.
10. Go back to the phone, in TWRP -> Reboot -> System -> Do Not Install
Ready.
I did this tutorial quickly. Any questions, use the comments!
Just a note. That tool is working with August security patch, but a lot of us received already September Security patch. And how do you know that we will receive OTA. Did you test by yourself? And btw, looks very easy and clear explained. For now I will wait for stable patch from Xiaomi, and updated Tool from the link you recomended. Thank you.
kaiwanted said:
Just a note. That tool is working with August security patch, but a lot of us received already September Security patch. And how do you know that we will receive OTA. Did you test by yourself? And btw, looks very easy and clear explained. For now I will wait for stable patch from Xiaomi, and updated Tool from the link you recomended. Thank you.
Click to expand...
Click to collapse
The tool just has the August picture. But the functions used for the gcam works in the September patch.
Yes. I have.
when i want to launch the TWRP, my device already plugged in and in fastboot mode, but it says "could not detect the active partition used, please ensure your phone is plugged in and in fastbook mode". How to fix this? tks
asuturo said:
when i want to launch the TWRP, my device already plugged in and in fastboot mode, but it says "could not detect the active partition used, please ensure your phone is plugged in and in fastbook mode". How to fix this? tks
Click to expand...
Click to collapse
I'm stuck at this too, i got the september update, already unlocked the bootloader but still can't install the twrp
"could not detect the active partition used, please ensure your phone is plugged in and in fastbook mode"
Rafaelboxer said:
I'm stuck at this too, i got the september update, already unlocked the bootloader but still can't install the twrp
"could not detect the active partition used, please ensure your phone is plugged in and in fastbook mode"
Click to expand...
Click to collapse
I think the September update change the active partition from A to B ( the August is A). Thats why it doesn´t work.
I´m also with September Update, and camera2api is the only thing i want to enable on Mi a2 ( don´t want to root and lose OTA) until a relliable TWRP is relleased.
This command should tell you which slot is active:
fastboot getvar current-slot
ki69 said:
I think the September update change the active partition from A to B ( the August is A). Thats why it doesn´t work.
I´m also with September Update, and camera2api is the only thing i want to enable on Mi a2 ( don´t want to root and lose OTA) until a relliable TWRP is relleased.
Click to expand...
Click to collapse
I got the september boot.img from another topic and rooted
Still no working solution for the ones that have setember update, and don´t want to root or use magisk??? I think the problem is that TWRP does not work with september update. Any easy way to downgrade to August again??
I'm thinking of installing Camera2API/GCamera, but I wonder if it's worth it. What are the real benefits? Does this make the camera compatible with more applications (eg Snapchat), avoiding them from making a screen of the camera ?
Hey guys i have some doubts.
I saw many threads saying to flash twrp into a partition (A or B) but i don't get why we have to flash it... So can someone clarify for me some stuff?
1 - fastboot boot twrp.img
I don't recall where the persist properties are stored but i believe it's not a partition that the OEM or google will constantly modify, right? So why making changes to the persist props in TWRP doesn't make it persist when booting into system? Is it possible to make it store it not temp?
Why there are people saying that flashing TWRP into, eg. part A, and booting into it, and then changing to part B, is working to enable the camera2 API? This should be the same as fastboot boot TWRP and then reboot it.
2 - As far as i remember, su permissions might be allowed in boot.img (.props file), so i thought that magisk patched image would have some su privilegies, but after booting from a patched image, su doesn't return anything. Does anyone knows what is the patched image from magisk? I heard about an app showing up after booting, so the patch is just a runnable with root?
3 - I also saw many threads changing sys build.prop directly. Horrible choice, but, does anyone knows if it possible to have a build.prop in OEM partition? From what i know, the build.prop will be concat. from all the folders related to the booting process. Has anyone tried to throw a build.prop into OEM with the persist enable? I believe that, since the folder is related to OEM only, and since we have no OEM making apps or whatever in an Android One phone, i think it is more safe than other partitions
ricardohnn said:
Hey guys i have some doubts.
I saw many threads saying to flash twrp into a partition (A or B) but i don't get why we have to flash it... So can someone clarify for me some stuff?
1 - fastboot boot twrp.img
I don't recall where the persist properties are stored but i believe it's not a partition that the OEM or google will constantly modify, right? So why making changes to the persist props in TWRP doesn't make it persist when booting into system? Is it possible to make it store it not temp?
Why there are people saying that flashing TWRP into, eg. part A, and booting into it, and then changing to part B, is working to enable the camera2 API? This should be the same as fastboot boot TWRP and then reboot it.
Click to expand...
Click to collapse
If you did a search on that 'persist' command, you'd find that it does persist, to many of the tables that type of information is stored in. It does not change the info in the properties file in 'System'. It does change the 'Data' partition, but that's okay, as there's only 1 of those (used no matters which slot boots up). The reason for booting on the non-active partition is a twrp / dual slot phone type of thing. I know it works as I've done it, but the 'setprop persist' changes the one and only Data partition, which both slots use, that's why it works.
ricardohnn said:
2 - As far as i remember, su permissions might be allowed in boot.img (.props file), so i thought that magisk patched image would have some su privilegies, but after booting from a patched image, su doesn't return anything. Does anyone knows what is the patched image from magisk? I heard about an app showing up after booting, so the patch is just a runnable with root?
Click to expand...
Click to collapse
I thought the patched image would have some su capabilities also, but it doesn't. It only installs the Magisk stub, which you can further install magisk from. Magisk is a great and sophisticated app. Has numerous Magisk modules which do a wide variety of things. But if you don't need any of those things, and don't need root, it's pretty over the top for just setting the cam2api, imho.
ricardohnn said:
3 - I also saw many threads changing sys build.prop directly. Horrible choice, but, does anyone knows if it possible to have a build.prop in OEM partition? From what i know, the build.prop will be concat. from all the folders related to the booting process. Has anyone tried to throw a build.prop into OEM with the persist enable? I believe that, since the folder is related to OEM only, and since we have no OEM making apps or whatever in an Android One phone, i think it is more safe than other partitions
Click to expand...
Click to collapse
If you change 'System' directly you will not get any OTA updates, so yer right, don't change that. There's no need to consider changing it anywhere else, as the 'setprop persist etc' command populates all the tables for you. 'System' is not affected and OTA updates will continue. There's no removing Magisk, restoring boot image, reinstalling etc etc etc.
One thing I would warn others about, using the various 'Tools'. You don't know what commands they are running, so you can't be sure what they will do. I say that because one of the tools I recently downloaded and went through and found the commands in it. The first thing it did after booting TWRP was to mount 'System' as Read / Write!! Why does that matter? From what I've read, doing that stops OTA from happening. Just mounting it R/W will change the date stamp on it concerning modifications, and that's all the OTA needs to know to say 'it's been modified'.
good luck, cheers
Agree with the data persist, but why do you need to flash into the different partition and not only boot from it?
I don't disagree that it will work, i just want to know why not boot from fastboot directly instead of flashing into one of the backup partition. I know that fastboot boot command triggers different code than usual flow. But not that i remember that it would affect something.
Getprop | grep camera would return if enabled right? Or nope?
ricardohnn said:
Agree with the data persist, but why do you need to flash into the different partition and not only boot from it?
I don't disagree that it will work, i just want to know why not boot from fastboot directly instead of flashing into one of the backup partition. I know that fastboot boot command triggers different code than usual flow. But not that i remember that it would affect something.
Getprop | grep camera would return if enabled right? Or nope?
Click to expand...
Click to collapse
The dual partition thing is new to everyone, I only understand bits and pieces, like everyone. But we do know there's no more 'recovery' partition, like we use to know. And we also know the way the dual works is that when an update occurs, if the device then try's to boot it and fails, it will automagically switch to the previous partition and boot it. Pretty sure we also know that booting and flashing are different with dual slot devices, but I'm not 100% sure how different.
I've tried booting twrp and just ended in bootloops. And that may be because of diff versions of TWRP, or it may be because of basic code all TWRP's have, not sure. But TWRP is a recovery, not a boot image with the proper kernel, like the patched boot images.
I do know for sure I didn't want to brick my phone (duh). So when I found a Magisk install guide, mentioned in my Guide thread, they used TWRP to install it. It sounded like an authoritative guide to me, re the part of getting TWRP to work. So I used that just to be able to run the setprop commands. Worked perfectly. Having to use the other (non active) partition **may** have something to do with avoiding triggering any automatic code to switch partitions unnecessarily, not sure, but not going to experiment any further to find out
Again, do some research on that setprop command, one of the things you'll find is that it doesn't populate all the appropriate tables until 'after' the device has been rebooted. So doing a getprop directly after doing the setprop won't work, not until it's been rebooted.
cheers
AsItLies said:
I've tried booting twrp and just ended in bootloops. And that may be because of diff versions of TWRP, or it may be because of basic code all TWRP's have, not sure. But TWRP is a recovery, not a boot image with the proper kernel, like the patched boot images.
Click to expand...
Click to collapse
I did manage to boot the last version of TWRP only first time, every other time ended in bootloops.
And I can sorry say that ADB did not work in booted TWRP, adb did not recognized the phone, so no commands could be typed.
For me, it is easier to flash patched_boot.img and install root temporarily, and then when job is done with activating camera2, uninstall root.
But hey, there are two easy ways, and everyone can choose which one is best suitable for them to try.
It would be of course easiest to just boot TWRP and enable camera2, but it doesn't work for now.
minnuss said:
I did manage to boot the last version of TWRP only first time, every other time ended in bootloops.
And I can sorry say that ADB did not work in booted TWRP, adb did not recognized the phone, so no commands could be typed.
For me, it is easier to flash patched_boot.img and install root temporarily, and then when job is done with activating camera2, uninstall root.
But hey, there are two easy ways, and everyone can choose which one is best suitable for them to try.
It would be of course easiest to just boot TWRP and enable camera2, but it doesn't work for now.
Click to expand...
Click to collapse
Yes, just 'booting' twrp has been problems for everyone, "that" doesn't work (not just now, but probably never).
But, following the Guide I wrote, and 'flashing it' does work. Right Now.
AsItLies said:
The dual partition thing is new to everyone, I only understand bits and pieces, like everyone. But we do know there's no more 'recovery' partition, like we use to know. And we also know the way the dual works is that when an update occurs, if the device then try's to boot it and fails, it will automagically switch to the previous partition and boot it. Pretty sure we also know that booting and flashing are different with dual slot devices, but I'm not 100% sure how different.
I've tried booting twrp and just ended in bootloops. And that may be because of diff versions of TWRP, or it may be because of basic code all TWRP's have, not sure. But TWRP is a recovery, not a boot image with the proper kernel, like the patched boot images.
I do know for sure I didn't want to brick my phone (duh). So when I found a Magisk install guide, mentioned in my Guide thread, they used TWRP to install it. It sounded like an authoritative guide to me, re the part of getting TWRP to work. So I used that just to be able to run the setprop commands. Worked perfectly. Having to use the other (non active) partition **may** have something to do with avoiding triggering any automatic code to switch partitions unnecessarily, not sure, but not going to experiment any further to find out
Again, do some research on that setprop command, one of the things you'll find is that it doesn't populate all the appropriate tables until 'after' the device has been rebooted. So doing a getprop directly after doing the setprop won't work, not until it's been rebooted.
cheers
Click to expand...
Click to collapse
About the setprop, even after the reboot isn't returning the prop, so that's why i am not sure if it is actually keeping it after twrp boot.
About the AB partition... well...
it's more or less like this...
let's say some simple partition scheme....
Preloader
Boot
System
Vendor
ODM
Data
So the phone will probably have many boot images type... like the usual boot.img or recovery.img (before treble) etc.
The boot.img will have the kernel image bla bla bla... since this is a google update, i believe that the AB partition procedures starts here (meaning all the relevant code of checking whether is A or B)
Google wanted to make things faster for the OEM (Samsung, LG etc) so they wanted to separate their ****s from google's one.
So (if things didn't change) you will have the following partitions now (actually i am not sure if they kept the system AB, but i believe so, since it seems to be working in other phones like that )
BootA
BootB
SystemA
SystemB
VendorA
VendorB
OEMA
OEMB
Data
So let's say google wants to update some security patches, from kernel til android, it will have to update boot and system. So in a OTA (changes if it is a google phone or a branded phone) before treble, it would update like... download the image containing boot and system into cache partition or data partition (depending the OTA size), after the download the update manager apk would set as a update booting and reboot your phone. Once booted, the phone would copy the partitions to the correct place (not being detailed) and rereboot. After the rereboot, if everything went normal, it would delete the downloaded image from your data/cache partition.
Now it's different like... instead of sending the update to the data partition and copying. It has a flag to set whether you are in A or B partition.
If you are (for eg.) in A partition, it will download the OTA to the B partition. (consider that in an untouched phone, A and B would have identical copies). So after downloading it, the flag is set to the B partition and reboot the phone. When booting, this time, it will not follow the A booting flow, like...
Before the update booting process would be
BootA
SystemA
VendorA
ODMA
Data
After the update the boot process will be
BootB
SystemB
VendorB
ODMB
Data
But i didn't update the vendor or ODM... why not keep in A? Because it's too hard to manage it.
So if anything fails in this update, it can easily go back into A booting process (which means you have a backup of your old boot).
Since system is too big, i am not sure if the system AB exists (it would just take up too much space... but anyway...).
It is also not a way to prevent bootloop, it is related to update. If an update fails (say, the image is corrupted or has no signature etc) the boot will change back, but if the update is "correct" it will boot as it should, even if the image is bad.
So again... when we do the fastboot boot boot.img, we are copying this boot into some cache or data to boot up, instead of our original boot. When we reboot, it will use the original boot. So, is there a difference from using twrp flashed and booted?
I know that fastboot boot will trigger different booting process (meaning signatures verifying etc) but don't think that it will not mount a partition or something...
Well... anyway... so after the reboot, when you setprop in TWRP, the getprop returned the prop correctly? I recall something about getprop not returning the prop but camera2 was enabled anyway with the setprop... well... can you just confirm one thing for me?
The steps you used was... fastboot flash patchboot and then reboot into twrp and then reboot back to usual partition.
You didn't do fastboot boot patched boot -> twrp -> reboot
Right?
---------- Post added at 09:44 AM ---------- Previous post was at 09:42 AM ----------
AsItLies said:
Yes, just 'booting' twrp has been problems for everyone, "that" doesn't work (not just now, but probably never).
But, following the Guide I wrote, and 'flashing it' does work. Right Now.
Click to expand...
Click to collapse
Oh didn't see this one. OK...
Damn... hmm... strange... well thanks anyway...
---------- Post added at 09:50 AM ---------- Previous post was at 09:44 AM ----------
AsItLies said:
The dual partition thing is new to everyone, I only understand bits and pieces, like everyone. But we do know there's no more 'recovery' partition, like we use to know. And we also know the way the dual works is that when an update occurs, if the device then try's to boot it and fails, it will automagically switch to the previous partition and boot it. Pretty sure we also know that booting and flashing are different with dual slot devices, but I'm not 100% sure how different.
I've tried booting twrp and just ended in bootloops. And that may be because of diff versions of TWRP, or it may be because of basic code all TWRP's have, not sure. But TWRP is a recovery, not a boot image with the proper kernel, like the patched boot images.
I do know for sure I didn't want to brick my phone (duh). So when I found a Magisk install guide, mentioned in my Guide thread, they used TWRP to install it. It sounded like an authoritative guide to me, re the part of getting TWRP to work. So I used that just to be able to run the setprop commands. Worked perfectly. Having to use the other (non active) partition **may** have something to do with avoiding triggering any automatic code to switch partitions unnecessarily, not sure, but not going to experiment any further to find out
Again, do some research on that setprop command, one of the things you'll find is that it doesn't populate all the appropriate tables until 'after' the device has been rebooted. So doing a getprop directly after doing the setprop won't work, not until it's been rebooted.
cheers
Click to expand...
Click to collapse
Oh by the way, i saw one part
"But TWRP is a recovery, not a boot image with the proper kernel, like the patched boot images. "
I think this is wrong (at least if TWRP team didn't change stuff), but all images are bootable images... (by all images i mean... boot.img recovery.img Flashing.img).
I once thought that they used a common kernel image, but in fact, all the booting process image has the kernel image copied (literally) to prevent brick. So even with a corrupted boot img, you still can boot into recovery or into download mode.
So that's why TWRP must have a kernel.
@ricardohnn, you seem hell bent on getting twrp to boot. Good luck. Let me know how that works out for you. In the meantime I'll be enjoying my cam2api working
cheers
AsItLies said:
@ricardohnn, you seem hell bent on getting twrp to boot. Good luck. Let me know how that works out for you. In the meantime I'll be enjoying my cam2api working
cheers
Click to expand...
Click to collapse
Actually TWRP boots fine with fastboot boot...
ADB runs smooth, but it just won't keep.
But you've made me envy LOL
I will think about flashing... later...
ricardohnn said:
Actually TWRP boots fine with fastboot boot...
ADB runs smooth, but it just won't keep.
But you've made me envy LOL
I will think about flashing... later...
Click to expand...
Click to collapse
What version of TWRP did you use, there is now two versions, I used last one, from a few days ago, and in first try I did manage to boot from fastboot, not flash it, but ADB did not worked.
So, if adb did work for you, maybe it was earlier version ?
Anyway, as you say, it is not permanent setprop, maybe because the twrp is not stable one, or maybe it needs to be flashed to work, not just booted.
I personally do not have doubts that this tutorial works, I just did not want to flash twrp. :good:
TWRP Custom Recovery for the Onn Android Tablet series
This is the first fully-featured custom recovery for Walmart's MediaTek-based Onn tablets: ONA19TB002, ONA19TB003 and ONA19TB007. TWRP needs no introduction. If you have come here, you probably have some idea of what it is and what it's used for. This TWRP build does not need the bootloader unlocked or VBMeta verification disabled, although it's recommended that you at least unlock the bootloader.
DISCLAIMER
Everything described in this thread is done at your own risk. No one else will be responsible for any data loss, corruption or damage of your device, including that which results from bugs in this software.
FEATURES
Decrypted data partition
All USB modes functional: MTP, ADB, Mass Storage, OTG, Charging
Fast boot time
Adoptable storage mounting
Firmware image backup and restore
Works under locked bootloader
Android 9 build fits within the 16MB recovery partition -- no compromises or partition resizing necessary
INSTALLATION METHOD 1
Download the recovery to your PC and unzip the image
Unlock the bootloader (skip if you have already done this)
Enable OEM Unlock in Developer Options in Android Settings
Boot into fastboot mode either by holding vol. up+power to power it on and selecting "Fastboot mode", or by running the 'adb reboot bootloader' command from within Android.
Install fastboot and appropriate drivers on your PC if you have not set those up
Unlock the bootloader with the command
Code:
fastboot flashing unlock
...and follow the instructions on the screen. This will wipe your data.
Flash the custom recovery with
Code:
fastboot flash recovery twrp-3.3.1-ONA19TB002.img
(use the right file name path for your device)
Reboot to recovery with
Code:
fastboot oem reboot-recovery
INSTALLATION METHOD 2
This assumes you are familiar with SP Flash Tool or can figure it out on your own
Download the recovery to your PC and unzip the image
Get the appropriate scatter file for your device. The scatter file may be found in the device's firmware under /system/data/misc.
Set up SPFT Download tab as Download Only. Load your scatter file.
Under the recovery line, double-click Location and open your TWRP image.
Click Download and connect your powered-off tablet to your PC. SPFT will automatically flash the recovery to the emmc and disconnect when finished.
INSTALLATION METHOD 3
Head over to Amazing Temp Root for MediaTek ARMv8, read the requirements and directions, and grab the latest mtk-su.
Open a root shell with mtk-su
Flash the (unzipped) recovery with the command:
Code:
dd bs=1048576 if=twrp-3.3.1-0-ONA19TB002.img of=/dev/block/by-name/recovery
(replace the if= file name with your appropriate recovery image path)
Exit root shell
START RECOVERY
Three methods:
On a powered off tablet, hold Vol. up+power for about 3 seconds. In the menu that appears, select "Recovery mode"
With Android ADB, use the command 'adb reboot recovery'
From Android root shell, use the command 'reboot recovery' or just use any root app with OS reboot features
NOTES
Kind of important: Make a backup of your Crypto Footer as soon as you can. This is the encryption key to your data partition. When accessed from TWRP, this key can get "upgraded" so that you will get locked out of Android. TWRP uses a hacky workaround that saves and restores the original footer on every /data decrypt. But that method is not what I would call 100% reliable.
Make sure you have a backup of the untouched stock system and vendor images. There are no official firmware packages available to download.
Only mount system/vendor partitions in read/write mode if you have unlocked the bootloader. It is recommended to choose to leave system read-only at the startup prompt unless you have a specific reason to modify it. If the bootloader is locked, then dm-verity is enforced.* So merely mounting it once in r/w will cause a boot loop.
It's currently not possible to install incremental OTA updates using this TWRP. Use the stock recovery to update the FW. That will only work if you have never mounted system/vendor in write mode.
DOWNLOAD (Nov. 30, 2019)
Current version: 3.3.1-1
ONA19TB002 - Onn 8" model
ONA19TB003 - Onn 10.1" model
ONA19TB007 - Onn 10.1" w/keyboard model
Source code
ONA19TB002 | ONA19TB003 | ONA19TB007
ACKNOWLEDGEMENTS
The team behind TWRP & OmniROM
@tek3195 for testing and feedback on the 8" model
Please post feedback since these are still pretty new and not exhaustively tested. Let me know if I should port it to other models in the series.
Reserved also
grabbing this one too cuz why not
Very nice! I'll download and test the 003 one soon.
I also have a 007 model to experiment with.
I tried about a dozen times to build TWRP and failed miserably LOL. Closest I got was one that would boot but the rotation was all messed up, USB wouldn't work, didn't mount some partitions... Yeah, it was a hot mess.
Do you happen to have sources available?
Hi @NFSP G35,
I'll have the source code soon. Most of the tricks involved patching bootable/recovery. So I need to commit those changes and include the proper patch set from my tree....
Amazing!! Gonna install and test 8" right now.
Has anyone tried a GSI on these tablets yet?
MishaalRahman said:
Has anyone tried a GSI on these tablets yet?
Click to expand...
Click to collapse
I do know @tek3195 , the Onn 8 thread starter, has tried many of them as well as others here, somewhere on that thread he listed his tests and opinion of several of them.
I'm pretty sure others on that thread have also tried GSI's.
MishaalRahman said:
Has anyone tried a GSI on these tablets yet?
Click to expand...
Click to collapse
I did try both Phhuson vanilla and also Liquid Remix (I'm keeping this one for now). I didn't flash them through twrp, but using fastboot via bootloader.
WoW! AwEsOmE! I cannot wait to try this! THANK YOU!!!!!!
Hey,
This is a neat thing to see for the Onn tablets. I have a question though. I own a device based on the mt8163, and am trying to help people with another device I don't own (the powkiddy x18 which also uses the mt8163). One of the things I wanted to do was to make a custom rom for the x18, since it's stock firmware is horrible. And of course, one of the first steps to custom roms is twrp. So I have a question for you that I hope you can answer for me. How did you make this build of twrp? I have seen no device trees for this device so I was kinda curious. If you can help me in any way, I'd be so grateful, and I'm sure the other people with the x18 would be grateful for help.
@diplomatic
Is there a different procedure for installing TWRP on a locked bootloader?
I can confirm that using SP Flash to load your TWRP.img will produce a bootloop when installing to a device with the BL locked. Reflashing the original recovery.img makes the problem go away. You mentioned in the OP that this TWRP will work on a locked BL so I thought I would share my case study with you in following the procedure you defined.
MY SINCERE GRATITUDE FOR YOUR EFFORTS IN PORTING THIS TO THE ONN!
You're welcome, @Spatry.... Can you describe how you ended up with a locked BL? Was it unlocked before? Have you ever tweaked vbmeta? Also, when you say bootloop, do you mean for Android or just for recovery? I'm not going to insist that it works under locked BL. I tested it once and it did boot up...
diplomatic said:
You're welcome, @Spatry.... Can you describe how you ended up with a locked BL? Was it unlocked before? Have you ever tweaked vbmeta? Also, when you say bootloop, do you mean for Android or just for recovery? I'm not going to insist that it works under locked BL. I tested it once and it did boot up...
Click to expand...
Click to collapse
Presently, I am running stock with Magisk patched BOOT on locked bootloader, stock vbmeta. The boot loop was at the ONN Android screen, I could not get it to even boot into recovery.
At one time I did run with the bootloader unlocked (with --disable-verification on stock vbmeta) and I ran Phusson's AOSP, Liquid Remix and Bliss. I found there was no benefit to me in running the other mods so I reverted back to stock courtesy of @CaffeinePizza and the bootloader re-locked to get rid of that annoying 5 second orange state.
In each instance, I always used SP Flash tools to load all .img files. I only used fastboot to install magisk_patched.img onto the stock installation. Unlocking the bootloader erases all data and I did not feel like reinstalling everything again, so I figured I would try to install TWRP per your instruction to see if it would work while the BL was still locked... Restoring the original recovery got rid of the bootloop. I do want to try your TWRP so I will try it with BL unlocked when I get some free time to do so.
Spatry said:
Presently, I am running stock with Magisk patched BOOT on locked bootloader, stock vbmeta. The boot loop was at the ONN Android screen, I could not get it to even boot into recovery.
Click to expand...
Click to collapse
This sounds like you might have flashed a wrong/corrupt image to recovery. It may have to do with AVB checks rather than bootloader lock. But those conditions might be interdependent somehow so I can't tell you for sure. The fact that you are able to boot a patched image on a locked BL says it doesn't care too much about verification. I can tell you for sure that any recovery image must have avb metadata, not necessarily the required hash, for both Android and recovery to boot. Can you try to unzip the image file and flash it over again?
Hmm, the situation with the bootloader lock sounds eerily similar to the Nabi SE. The latter also had a similar implementation where there's not much in the way of locking things down, other than an (easily circumvented) SP Flash Tool signature check and different preloader keys. And here's the real kicker: the nearly-identical Fisher Price Nabi also ran on the MT8163, so it makes me wonder if it's possible to boot Pie on it, or perhaps a GSI assuming that Treble can be tacked onto it.
Also, do you have the source repo to this TWRP port of yours?
If anyone here gave me an XDA ad-free subscription, thanks a lot! I didn't get a notification of who it was. Using this site is a lot more bearable now.
diplomatic said:
If anyone here gave me an XDA ad-free subscription, thanks a lot! I didn't get a notification of who it was. Using this site is a lot more bearable now.
Click to expand...
Click to collapse
Where do I find crypto footer to backup
diplomatic said:
If anyone here gave me an XDA ad-free subscription, thanks a lot! I didn't get a notification of who it was. Using this site is a lot more bearable now.
Click to expand...
Click to collapse
Kinda cool without the ads isn't it. I know I sent one about a week ago or so. I think everybody ought to send you one, you deserve it. THANKS and AWESOME work.