This is really a big topic that no one asks, everyone just asks how to fix it but I want to know what exactly happens to Android system in deep that cause hard brick and unable to start the device. Previously when I had a Chinese phone, it was so simple to downgrade and upgrade stuff without bricking because there was no bootloader at all. Everytime I check it said "Unkonwn Bootloader". I'd be happy if someone explain or just drop links about the bootloader and why hard brick happens due to downgrade. I am thinking a way to fix the hard brick device in a way that will fix it all the time with just a simple procedure, doesn't matter if you had downgraded or rekt system stuff or you're on any Android version, it will be fixed. It sounds stupid but I think there must be a way, if we go more deeper into Android system, we can make it working.
I'll have a go at answering this...
It's generally not the downgrading of stock Motorola firmware that bricks a device, often times it's the usage of OTA updates following a downgrade that causes the hard brick.
From what I've seen of many hard bricks (on Moto G4/Plus, G5 Plus, Z Play, though probably a similar scenario on other devices from other manufacturers):
1)You have your system firmware and your bootloader. E.g. The C1:14 version bootloader comes with the Feb 2018 7.1.1 stock Nougat firmware/OTA update. Normally, they would be matching (so you'd have the 7.1.1 Feb 2018 firmware with the C1:14 bootloader). Using OTA updates would be no problem.
2)If you downgrade your stock firmware (custom ROMs usually are not applicable in this case, regardless of the custom ROM security patch/version), you may be able to flash older stock firmware but your bootloader cannot be downgraded. E.g. you flashed the August 2017 7.1.1 stock firmware on a device previously updated to Feb 2018 stock firmware. You'd have the August 2017 system firmware but a Feb 2018 bootloader. Your device may run okay and the flash may have gone okay besides some 'security version downgrade' errors with the bootloader and GPT.
3)So your downgraded device runs okay and you get an OTA prompt to the Sept 2017 security patch OTA. This is where the problems start. OTA updates appear to only be verified by your system version, and looking through the updater scripts for various OTA updates, they check if your system partition, OEM, boot (kernel) etc are fully stock and are of the correct build to flash to. Tellingly, the OTA script does not seem to check for your bootloader version , I think the OTA assumes your bootloader and the system are of the same matching versions/patch levels. As you've downgraded your device, this assumption does not hold. Should there be a check for the bootloader version if it was possible? Perhaps.
4)Your device reboots and begins flashing the Sept 2017 OTA. So far, the OTA is checking and verifies your device is running the August 2017 firmware, and begins patching. However, the OTA can patch your bootloader with older images without verification, which means it applies Sept 2017 images to a Feb 2018 bootloader, corrupting the bootloader and thus hard bricking your device.
(EDIT - reading this page, it suggests that there are multiple bootloaders in your device, each one verifying each other to ensure integrity. https://forum.xda-developers.com/android/general/info-android-device-partitions-basic-t3586565 My guess is that applying the old OTA images to a newer bootloader changes the signature of the bootloader we see - e.g. changing the signature of the secondary bootloader/SBL or having an old aboot image in the newer bootloader - and so fails the upstream verification, hence a hard brick.)
I'm not sure how your old device's bootloader is different, maybe it's a lot less stringent. Was it running a Qualcomm bootloader or a Mediatek bootloader?
However, with Qualcomm bootloaders, if the bootloader image is corrupted they appear to fall back to a emergency download mode (you can read more here: https://alephsecurity.com/vulns/aleph-2017028 ). To recover, you often need crytographically signed images from the appropriate OEM (Motorola in this case) to rescue a device in such a state. As I understand it, these images - including the often requested blankflashes - include methods to communicate with your device (via the sahara protocol) https://github.com/openpst/sahara and a programmer to verify your device and bootloader are suitable for repairing, before flashing a new bootloader: https://forum.xda-developers.com/showpost.php?p=62191317&postcount=2112 https://forum.xda-developers.com/showpost.php?p=63490742&postcount=17 We cannot make these, and any attempts to modify them would likely break the cryptographic signatures on the files, so would be rejected (else you could inject your own compromised bootloader, or downgraded bootloader as per the paper, which would be dangerous for security). This security issue is likely why OEMs do not release blankflashes or other such repair files.
If the blankflash is too old or older than the corrupted bootloader, the programmer appears to fail to rescue the device. Short of having the actual, signed files in a blankflash or similar, that are as new or newer than your current corrupted bootloader, it becomes very hard to rescue a device. That's likely why we've seen quite a few Z Play devices on 7.1.1 or 8.0 that downgraded and got corrupted by an OTA that are not rescuable at the moment - we simply do not have updated tools. Motorola (and likely other OEMs) seems to regard these blankflashes as internal development tools and as such won't give them out - all we have are leaks. I imagine Motorola's point of view also includes that since your bootloader was unlocked, you assume responsiblity for anything that happens.
If you do hard brick then I recall there are a few options:
a)Hope that a blankflash or updated MSM8953 programmer/signed images for Motorola devices is leaked. Must be as new or newer than your corrupted bootloader (recall you cannot downgrade bootloaders). No guarantee of being released if at all.
b)Hope that someone finds a JTAG or other board level repair.
c)Pay for a motherboard replacement (expensive, 60-80% of the device cost sometimes) - perhaps you may be covered by local consumer laws.
d)Buy a new device, forget about repairing this one.
As I mentioned above, hard bricks are very difficult to recover from without the correct tools. However, they are avoidable if users do not flash older stock firmware, only flashing the same stock firmware as they had on their device (matching their bootloader) or newer stock firmware. If they do downgrade, then not using OTA updates whatsoever may also save them from a hard brick (though in that case you must use the latest stock firmware to update with). Alternatively, if you unlocked your device bootloader, you could just use TWRP flashable stock ROMs and forget about using stock firmware at all - TWRP flashables in general should not affect the bootloader.
Any further comments or corrections welcome.
echo92 said:
I'm not sure how your old device's bootloader is different, maybe it's a lot less stringent. Was it running a Qualcomm bootloader or a Mediatek bootloader?
.
Click to expand...
Click to collapse
Yes indeed it was a mediatek device and thank you so much for your answer, I really appreciate it.
So a patched bootloader will able to bypass the verification step and the update will be flashed easily but the problem is with the security. BTW, what kind of security concerns? Will my device become vulnerable to hackers and viruses?
And if the patching bootloader is a pain then is there any way to patch the OTA itself? A patched OTA which doesn't requires verification and won't cause hard bricking. So if a person who has downgraded to predecessor version and have a bootloader of successor version can get the successor version of Android through side loading the patched OTA.
I was thinking about the JTAG stuff but it's overall not economically feasible.
I think patched Ota update is a good way to get around but is it possible?
Manish355 said:
Yes indeed it was a mediatek device and thank you so much for your answer, I really appreciate it.
So a patched bootloader will able to bypass the verification step and the update will be flashed easily but the problem is with the security. BTW, what kind of security concerns? Will my device become vulnerable to hackers and viruses?
And if the patching bootloader is a pain then is there any way to patch the OTA itself? A patched OTA which doesn't requires verification and won't cause hard bricking. So if a person who has downgraded to predecessor version and have a bootloader of successor version can get the successor version of Android through side loading the patched OTA.
I was thinking about the JTAG stuff but it's overall not economically feasible.
I think patched Ota update is a good way to get around but is it possible?
Click to expand...
Click to collapse
Good questions.
1)In theory, a patched bootloader may let you bypass the verification step, though the upstream bootloaders (including those burned into your device's memory) may still stop that bootloader from running, as it fails the 'chain of trust' as Google puts it. https://source.android.com/security/verifiedboot/verified-boot
As for security concerns, well, who knows? If you could put a compromised bootloader onto your device with the correct authorisations, it could do anything. That's likely why blankflashes are not around, plus the fact they have to be signed by the issuing OEM to be valid. Else, that could be a potential vector to breaking security. If you can't trust the guardian of your device (which the bootloader can act as), what can you then trust about that device?
2)In theory, again, you could patch the OTA, but the OTA is signed, and thus any modification may break the signing. This would then cause rejection by the stock recovery https://source.android.com/devices/tech/ota/sign_builds
I have seen OTA updates modified to work with TWRP, though I think they may not update your bootloader (e.g. have a look here: https://forum.xda-developers.com/g5-plus/how-to/npn25-137-33-stock-firmware-t3577081/page12 ) However, in that case, you may be better off staying with TWRP flashables of the stock ROM and forget about using stock ROM firmware if you are worried about the bootloader.
So in summary, if you want to avoid a hard brick, some ways are:
1)Ensure you only flash the latest firmware onto your device that is as new or newer than your bootloader. If your bootloader is locked, that should apply automatically (as the bootloader will block downgrades).
2)If you do choose to flash older stock firmware that is older than your bootloader version, please do not use OTA updates. Only use newer stock firmware to update (and ensure it's the correct build for your region/software channel).
3)If you so wish and you have an unlocked bootloader, forget about using stock firmware, use the TWRP flashables of the stock firmware (e.g. https://forum.xda-developers.com/moto-z-play/development/rom-nov-patch-npns26-118-22-2-8-t3717037) Of course, OTA updates are not usable.
echo92 said:
Good questions.
1)In theory, a patched bootloader may let you bypass the verification step, though the upstream bootloaders (including those burned into your device's memory) may still stop that bootloader from running, as it fails the 'chain of trust' as Google puts it. https://source.android.com/security/verifiedboot/verified-boot
As for security concerns, well, who knows? If you could put a compromised bootloader onto your device with the correct authorisations, it could do anything. That's likely why blankflashes are not around, plus the fact they have to be signed by the issuing OEM to be valid. Else, that could be a potential vector to breaking security. If you can't trust the guardian of your device (which the bootloader can act as), what can you then trust about that device?
2)In theory, again, you could patch the OTA, but the OTA is signed, and thus any modification may break the signing. This would then cause rejection by the stock recovery https://source.android.com/devices/tech/ota/sign_builds
I have seen OTA updates modified to work with TWRP, though I think they may not update your bootloader (e.g. have a look here: https://forum.xda-developers.com/g5-plus/how-to/npn25-137-33-stock-firmware-t3577081/page12 ) However, in that case, you may be better off staying with TWRP flashables of the stock ROM and forget about using stock ROM firmware if you are worried about the bootloader.
So in summary, if you want to avoid a hard brick, some ways are:
1)Ensure you only flash the latest firmware onto your device that is as new or newer than your bootloader. If your bootloader is locked, that should apply automatically (as the bootloader will block downgrades).
2)If you do choose to flash older stock firmware that is older than your bootloader version, please do not use OTA updates. Only use newer stock firmware to update (and ensure it's the correct build for your region/software channel).
3)If you so wish and you have an unlocked bootloader, forget about using stock firmware, use the TWRP flashables of the stock firmware (e.g. https://forum.xda-developers.com/moto-z-play/development/rom-nov-patch-npns26-118-22-2-8-t3717037) Of course, OTA updates are not usable.
Click to expand...
Click to collapse
Wow, you're the man. I was expecting that because when I looked into the OTAs, I found it's hard to modify the OTA to work on signed bootloader. It's like a lock and key system that makes the OTA possible. Thanks for your help, it has saved me not of time.
BTW, the stock ROM (Oreo) replaces the build prop everytime I reboot? I am trying to modify the build prop but no results till now. Is it because of magisk? Because magisk is a systemless root so it prevents system modifications?
Manish355 said:
Wow, you're the man. I was expecting that because when I looked into the OTAs, I found it's hard to modify the OTA to work on signed bootloader. It's like a lock and key system that makes the OTA possible. Thanks for your help, it has saved me not of time.
BTW, the stock ROM (Oreo) replaces the build prop everytime I reboot? I am trying to modify the build prop but no results till now. Is it because of magisk? Because magisk is a systemless root so it prevents system modifications?
Click to expand...
Click to collapse
Hmm, if you're following this rooting guide, https://forum.xda-developers.com/moto-z-play/how-to/guide-how-to-magisk-root-xposed-oreo-8-t3743273 it could well be dm-verity which is still enabled on your device. As I understand it, dm-verity is there to prevent modifications to your system partition (which build.prop is part of) and other key partitions, or if it detects modifications, to stop your device from booting. Others have reported the same issue on other devices https://forum.xda-developers.com/mate-9/help/mount-writable-twrp-t3685867 https://source.android.com/security/verifiedboot/ I think dm-verity is strictly enforced on Nougat and I imagine the same applies to Oreo, if not more so.
However, looking at the magisk help documentation, attempting to disable dm-verity with the stock kernel (stock = the Motorola hudsoncm kernel in this case) can cause odd instabilities on devices https://www.didgeridoohan.com/magisk/MagiskIssues so you may have to look into flashing an Oreo based custom kernel, if one is available (which hopefully has the F2FS fix integrated, and has dm-verity disabled or not present) if you wish to modify your system. However, that custom kernel probably will have to wait for the Oreo stock kernel source to be released by Motorola, as you'll need the Motorola Oreo kernel source to build a compatible kernel for stock Oreo ROMs from what I understand.
echo92 said:
Hmm, if you're following this rooting guide, https://forum.xda-developers.com/moto-z-play/how-to/guide-how-to-magisk-root-xposed-oreo-8-t3743273 it could well be dm-verity which is still enabled on your device. As I understand it, dm-verity is there to prevent modifications to your system partition (which build.prop is part of) and other key partitions, or if it detects modifications, to stop your device from booting. Others have reported the same issue on other devices https://forum.xda-developers.com/mate-9/help/mount-writable-twrp-t3685867 https://source.android.com/security/verifiedboot/ I think dm-verity is strictly enforced on Nougat and I imagine the same applies to Oreo, if not more so.
However, looking at the magisk help documentation, attempting to disable dm-verity can cause odd instabilities on devices https://www.didgeridoohan.com/magisk/MagiskIssues so you may have to look into flashing an Oreo based custom kernel, if one is available (which hopefully has the F2FS fix integrated, and has dm-verity disabled or not present) if you wish to modify your system. However, that custom kernel probably will have to wait for the Oreo stock kernel source to be released by Motorola, as you'll need the Motorola Oreo kernel source to build a compatible kernel for stock Oreo ROMs from what I understand.
Click to expand...
Click to collapse
There's an option in magisk that says "Preserve AVB 2.0/dm-verity", should unchecking it will work?
Or rooting with SuperSU would work? I tried SuperSU 2.82, it all flashed but stuck on boot at the last. Do you know how can I root my device using SuperSU, safety net is not an issue.
Manish355 said:
There's an option in magisk that says "Preserve AVB 2.0/dm-verity", should unchecking it will work?
Click to expand...
Click to collapse
I honestly do not know, though it's possible unchecking that may cause a bootloop if magisk tries to disable dm-verity on the stock kernel. I'm hoping you could boot into recovery and enable dm-verity then re-flash magisk to get your device running if you do bootloop.
echo92 said:
I honestly do not know, though it's possible unchecking that may cause a bootloop if magisk tries to disable dm-verity on the stock kernel. I'm hoping you could boot into recovery and enable dm-verity then re-flash magisk to get your device running if you do bootloop.
Click to expand...
Click to collapse
Rooting with SuperSU would work? I tried SU 2.82 but my device got stuck at boot after long time and several bootloops. Do you know how to root using superSU? I don't mind safety net fail or pass, I don't use apps that requires safety net either.
Manish355 said:
Rooting with SuperSU would work? I tried SU 2.82 but my device got stuck at boot after long time and several bootloops. Do you know how to root using superSU? I don't mind safety net fail or pass, I don't use apps that requires safety net either.
Click to expand...
Click to collapse
I'm not familiar with rooting with SuperSU on the Z Play - for my G4 Plus, the easiest way was to flash a custom kernel (ElementalX courtesy of flar2 or vegito) which had dm-verity removed from the kernel. That way, when you flashed magisk or SuperSU, there was less risk of boot issues. There were dm-verity disablers but I recall they had to be modified for each new stock firmware and sometimes had boot issues if the patch didn't work properly.
I have absolutely no idea if this will work on the Oreo stock kernel, in theory you could unpack the kernel, disable dm-verity and re-pack the kernel: https://forum.xda-developers.com/showpost.php?p=69558535&postcount=7912
However, I think the most compatible and reliable path would be to compile a custom kernel, without dm-verity, from the Z Play Oreo kernel source, then flash that to your device then flash magisk/SuperSU.
echo92 said:
I'm not familiar with rooting with SuperSU on the Z Play - for my G4 Plus, the easiest way was to flash a custom kernel (ElementalX courtesy of flar2 or vegito) which had dm-verity removed from the kernel. That way, when you flashed magisk or SuperSU, there was less risk of boot issues. There were dm-verity disablers but I recall they had to be modified for each new stock firmware and sometimes had boot issues if the patch didn't work properly.
I have absolutely no idea if this will work on the Oreo stock kernel, in theory you could unpack the kernel, disable dm-verity and re-pack the kernel: https://forum.xda-developers.com/showpost.php?p=69558535&postcount=7912
However, I think the most compatible and reliable path would be to compile a custom kernel, without dm-verity, from the Z Play Oreo kernel source, then flash that to your device then flash magisk/SuperSU.
Click to expand...
Click to collapse
I haven't tried compiling a kernel, I am not a developer (I had ported ROMs for my old MTK device but none for this device, I am not very much familiar with snapdragon devices) so i think I should just flash a custom ROM, that would work, right?
Manish355 said:
I haven't tried compiling a kernel, I am not a developer (I had ported ROMs for my old MTK device but none for this device, I am not very much familiar with snapdragon devices) so i think I should just flash a custom ROM, that would work, right?
Click to expand...
Click to collapse
If you really want access to your /system partition and build.prop, custom ROMs are an option, yes, as their kernels shouldn't have dm-verity on and so are easier to root. Ensure you have the stock firmware to revert back to if you so wish and back up your data, as a custom ROM flash will usually mandate a data wipe/factory reset.
Alternatively, wait for the Z Play Oreo kernel source and for a developer to release a custom kernel built on that source.
echo92 said:
Alternatively, wait for the Z Play Oreo kernel source and for a developer to release a custom kernel built on that source.
Click to expand...
Click to collapse
Ya, this seems like a good option. BTW, unchecking the dm-verity in magisk won't do anything, after reboot it checks again. Thanks for the help.
Driver Installation
Does anyone know how to update the drivers to reflect that the device is a Moto phone? I bricked my device (exactly as described here; downgraded then OTA bricked). When I plug in to my computer it recognizes it as a USB driver Qualcomm HS-USB QDLoader 9008. Would it help any to download a driver to have it identify as a phone?
Tweedledope said:
Does anyone know how to update the drivers to reflect that the device is a Moto phone? I bricked my device (exactly as described here; downgraded then OTA bricked). When I plug in to my computer it recognizes it as a USB driver Qualcomm HS-USB QDLoader 9008. Would it help any to download a driver to have it identify as a phone?
Click to expand...
Click to collapse
Unfortunately, the only way is to somehow repair your bootloader as the bootloader is (part of ) what identifies your device to your computer as a phone. That Qualcomm HS-USB 9008 is your device in emergency mode - usually when your bootloader is corrupted (by a bad OTA update) or non-existent and now it's in a fail-safe boot state.
The only ways to get your device recognised again are to find a working blankflash to repair your device bootloader, try to boot from a cloned image of a working device (and then perform a firmware flash to repair the damage) or pay for a motherboard replacement.
Related
Krassermensch's Firmware Update Tool
My situation:
I'm too young to buy the Sunshine App to set my device S-Off but I want to update my device's firmware every time a firmware update's available. Since I compile ROMs and cannot do that via OTA updates the only acceptable way for me is to install signed firmwares in a locked bootloader. After doing that manually I thought I should write a tool that installs the right firmware for your device automatically. As I'm already running the latest firmware on my device after doing the procedure manually I cannot test if the flash part works correctly. Anyway, I achieved to read out the CID as well as the current firmware version and my tool reports that I'm running the latest firmware version I integrated for my device what's correct. So this part works well.
How the tool works:
The tool asks you if you've already installed the HTC USB drivers on your computer. If you haven't you can install it easily using my tool. After that the tool explains you how to set up your phone to be detected by the computer. Then it checks which device you have and checks which firmware's currently installed on it. Right after that the tool installs all the firmwares newer than the one that's currently installed on your phone one after another until the latest firmware my tool is shiped with runs on your device. The procedure doesn't wipe your data since signed firmware-updates are installed.
Requirements:
- An HTC 10
- A computer running windows
- An internet connection
- An unlocked bootloader
- An installed TWRP
Who is this tool for?
All the people who can't or don't want to set their device S-Off while running a non-stock ROM.
Why should I use this tool?
- It updates your firmware to the latest one available for your device automatically
- It doesn't wipe your storage
- You don't need to be S-Off
Download
https://www.androidfilehost.com/?fid=745425885120704223
When the file is downloaded just extract it on your Windows computer and run the batch file. Everything else will be explained.
Important to know
Your boot and recovery partitions will be replaced by the stock ones so after successfully updating your firmware you need to reflash TWRP as well as your Boot partition.
This process is performed automatically now. No need to do that manually.
Tools using ADB just like mine may interfere with other tools that also use ADB. Make sure all these tools are disabled.
Now I need your feedback to be able to optimize the tool! I'll add new firmwares from time to time. I'm looking forward to your reviews
GitLab
https://gitlab.com/Feulner/Firmware-Update-Tool-HTC10
If you like my work consider a donation to support me in financing computer-components which are meant to replace the defect ones in my broken PC.
If you donate you'll donate to my father who will gimme the money. Thank you really much!
This works with unsigned firmware?
Good job, though irrelevant to me
xunholyx said:
This works with unsigned firmware?
Good job, though irrelevant to me
I would guess that you would have to have matching CID and MID of course.
Click to expand...
Click to collapse
No no, not unsigned firmware. I'll explain it more detailed tomorrow or so. The tool just checks your device's CID as well as your device's current firmware version and updates it to the most current firmware version I integrated in my tool. If your firmware is very old the tool also updates again and again until you have the lässt firmware automatically.But it uses signed firmware packages. The biggest advantage is that it should work fully automatic. Try it out and let me know what you think. I go to bed now...
krassermensch said:
No no, not unsigned firmware. I'll explain it more detailed tomorrow or so. The tool just checks your device's CID as well as your device's current firmware version and updates it to the most current firmware version I integrated in my tool. If your firmware is very old the tool also updates again and again until you have the lässt firmware automatically.But it uses signed firmware packages. The biggest advantage is that it should work fully automatic. Try it out and let me know what you think. I go to bed now...
Click to expand...
Click to collapse
I'm s-off since the day after I got my phone, so.......
It sounds like a great idea. I'm sure lot of people will appreciate this. If it does work like you say, WAY better than going back to stock.
xunholyx said:
I'm s-off since the day after I got my phone, so.......
It sounds like a great idea. I'm sure lot of people will appreciate this. If it does work like you say, WAY better than going back to stock.
Click to expand...
Click to collapse
Since when do you have to go back to stock to "fastboot flash zip some_firmware.zip" (as this tool does)?
--beaups
Hm sounds good, but i wont use it until we have some more information what it actually does.
As far as i know, theres no way to just update your firmware with signed zips without partly wiping your device. I had to reflash Viper10 (or restore a nandroid backup) the last time i updated my firmware, cause boot and recovery partitions got replaced. Not completely sure if this affects stock devices, it may work there, but not for devices which are modified with a custom ROM. For this you need a NoWipe firmware from sneakyghosts thread, but these cant be flashed while s-on.
So please explain in more details what your tool does, of course when youve got your sleep .
It most likely flashes firmware zips from OTA updates since those do not wipe the device. He already said it does that, he said if you're on a very old firmware it will keep updating your firmware progressively until you're on the latest version. So if you've never updated before, and there have been three updates since then, the tool will flash the firmware zip of each OTA one after the other.
Updated the main post, hopefully everything's clear now. I need your reviews now. I'm also thinking about an automatic bootloader lock with backup solution so you don't need to lock your bootloader manually and also don't lose your data partition.
Why it doesn't work with unlocked bootloader?
CroCop18 said:
Why it doesn't work with unlocked bootloader?
Click to expand...
Click to collapse
I didn't try but normally your HTC 10 would block the installation if the bootloader is unlocked. Could you try it out and report. It's a bit hard to try it out by myself currently... It will most probably report that your new firmware's flashed but it actually will not be flashed after that if your bootloader's unlocked. If it's flashed anyway it'd be perfect since I'd not have to make a backup solution in that case. But I guess that the 10 isn't different to the M9 for example when it comes to firmware flashing. I read that you can have an unlocked bootloader if your device is S-Off but those are things I haven't been able to try out so far...
krassermensch said:
I didn't try but normally your HTC 10 would block the installation if the bootloader is unlocked. Could you try it out and report. It's a bit hard to try it out by myself currently... It will most probably report that your new firmware's flashed but it actually will not be flashed after that if your bootloader's unlocked. If it's flashed anyway it'd be perfect since I'd not have to make a backup solution in that case. But I guess that the 10 isn't different to the M9 for example when it comes to firmware flashing. I read that you can have an unlocked bootloader if your device is S-Off but those are things I haven't been able to try out so far...
Click to expand...
Click to collapse
Really? You don't know how to unlock your bootloader? You don't need S-Off for it.
This answers the question I had wondered about. How does this install OTAs with a custom recovery? It doesn't, correct?
You need to be stock for this. The first thing you do after unlocking the bootloader (which pretty much anyone here has done) is to flash a custom recovery.
This tool will only work for users who are still completely on stock.
IO would test myself, but I'm already S-Off/unlocked bootloader/custom recovery/modified firmware/custom ROM|, and I don't want to take the time to go back to stock and incrementally update the steps to see what won't work. I think as soon as you flash custom recovery, you can't use this method.
If you want to unlock your bootloader, HTC provides the method and instructions at htcdev.com
xunholyx said:
Really? You don't know how to unlock your bootloader? You don't need S-Off for it.
This answers the question I had wondered about. How does this install OTAs with a custom recovery? It doesn't, correct?
You need to be stock for this. The first thing you do after unlocking the bootloader (which pretty much anyone here has done) is to flash a custom recovery.
This tool will only work for users who are still completely on stock.
IO would test myself, but I'm already S-Off/unlocked bootloader/custom recovery/modified firmware/custom ROM|, and I don't want to take the time to go back to stock and incrementally update the steps to see what won't work. I think as soon as you flash custom recovery, you can't use this method.
If you want to unlock your bootloader, HTC provides the method and instructions at htcdev.com
Click to expand...
Click to collapse
Sure I know how to unlock a boitloader. If you watch my profile you can see I'm a ROM maintainer. I have to use custom recoveries to do that. People interpret my posts wrongly sometimes. I dunno why. Anyway, I use TWRP but after flashing a recovery or any other image file I lock my bootloader again for safety reasons. You just need to have a locked bootloader to use my tool currently... And no, u don't need to be stock. This tool just requires a locked or relocked bootloader. U can use whatever ROM u like. U just need to have a locked bootloader and my tool installs the latest firmware I integrated for your HTC 10 model. I know what I do. You should just read my posts a bit more carefully to prevent yourself from contending wrong things...
krassermensch said:
Sure I know how to unlock a boitloader. If you watch my profile you can see I'm a ROM maintainer. I have to use custom recoveries to do that. People interpret my posts wrongly sometimes. I dunno why. Anyway, I use TWRP but after flashing a recovery or any other image file I lock my bootloader again for safety reasons. You just need to have a locked bootloader to use my tool currently...
Click to expand...
Click to collapse
" I read that you can have an unlocked bootloader if your device is S-Off" quote from you
I did read it wrong. I was thinking that you meant you needed soff to unlock bootloader.\
And yes, now that I understand what you meant, with S-Off you shouldn't need to re-lock your bootloader.
xunholyx said:
" I read that you can have an unlocked bootloader if your device is S-Off" quote from you
I did read it wrong. I was thinking that you meant you needed soff to unlock bootloader.\
And yes, now that I understand what you meant, with S-Off you shouldn't need to re-lock your bootloader.
Click to expand...
Click to collapse
Yeah, dude, I think I wouldn't be able to write a batch tool with fastboot and adb if I didn't know the whole stuff. My broken Nexus 4 has teached me a lot over the last 3½ years
Just to confirm... and thanks for the tool
I have a HTC 10 and nothing has been done to it since I bought it (Stock everything) will this tool keep it that way but give me the latest OTA?
Milamber said:
Just to confirm... and thanks for the tool
I have a HTC 10 and nothing has been done to it since I bought it (Stock everything) will this tool keep it that way but give me the latest OTA?
Click to expand...
Click to collapse
You do not need this tool if you are Stock everything, unless you unlocked your bootloader.
Milamber said:
Just to confirm... and thanks for the tool
I have a HTC 10 and nothing has been done to it since I bought it (Stock everything) will this tool keep it that way but give me the latest OTA?
Click to expand...
Click to collapse
No, I could write a tool for manual OTA flashing, too, but I don't want to do that since OTAs are for stock devices which are notified about OTA updates automatically. If you want to flash OTAs quicker: there's a thread here on xda where OTA zips are shared with an explaination how to flash it manually... This tool can be used by stock device's owners but it wouldn't be necessary...
krassermensch said:
I didn't try but normally your HTC 10 would block the installation if the bootloader is unlocked. Could you try it out and report. It's a bit hard to try it out by myself currently... It will most probably report that your new firmware's flashed but it actually will not be flashed after that if your bootloader's unlocked. If it's flashed anyway it'd be perfect since I'd not have to make a backup solution in that case. But I guess that the 10 isn't different to the M9 for example when it comes to firmware flashing. I read that you can have an unlocked bootloader if your device is S-Off but those are things I haven't been able to try out so far...
Click to expand...
Click to collapse
Thanks for your explanations, now i understand your tool a bit more.
But if it only works with a locked/relocked bootloader i cant use it. Really no offense and i dont want to sound rude (!), but isnt it already a design problem? You said the tool is designed for people with non-stock ROMS, but that does imply that you have an unlocked bootloader to flash and keep your ROM and recovery up to date. To use your tool you have to relock the bootloader after flashing the ROM. But to update the ROM to a newer version you have to unlock the bootloader again via HTCDev (and loosing your data while doing this)? Sounds a bit weird to me...or did i miss something?
So which adb commands are you using? Didnt have the time to check your script yet (sorry!). Because im S-On with my bootloader unlocked an i COULD flash a signed firmware.zip i extracted from an official OTA via ADB. This wiped my boot and recovery partitions, but not data. Just had to restore the two partitions to get everything working again.
-Vulture- said:
Thanks for your explanations, now i understand your tool a bit more.
But if it only works with a locked/relocked bootloader i cant use it. Really no offense and i dont want to sound rude (!), but isnt it already a design problem? You said the tool is designed for people with non-stock ROMS, but that does imply that you have an unlocked bootloader to flash and keep your ROM and recovery up to date. To use your tool you have to relock the bootloader after flashing the ROM. But to update the ROM to a newer version you have to unlock the bootloader again via HTCDev (and loosing your data while doing this)? Sounds a bit weird to me...or did i miss something?
So which adb commands are you using? Didnt have the time to check your script yet (sorry!). Because im S-On with my bootloader unlocked an i COULD flash a signed firmware.zip i extracted from an official OTA via ADB. This wiped my boot and recovery partitions, but not data. Just had to restore the two partitions to get everything working again.
Click to expand...
Click to collapse
So you could flash the firmware-update.zip from the OTA without relocking your bootloader?
And it was really updated after that?
krassermensch said:
So you could flash the firmware-update.zip from the OTA without relocking your bootloader?
And it was really updated after that?
Click to expand...
Click to collapse
Thats what i did, bootloader was unlocked and flash successfully. I extracted the firmware.zip from an official OTA (TMOB-101) for my device and flashed it via ADB from my PC. Since the firmware.zip is signed, it can be flashed. Doesnt work with modified zips however, like the ones from sneakyghosts thread. He removed unnecessary stuff like the flash command for boot and recovery which my broke my phone initially. Thats why you need TWRP to restore them later.
As you already said with your tool, its also important here to get the right file to flash and not to skip a firmware update in between. You have to go from very old -> old -> current without skipping old.
I used the step-by-step instructions from here:
http://forum.xda-developers.com/htc-10/how-to/2016-05-27-fastboot-flashing-firmware-t3387520
** STOP & DO NOT **
Pass Go (... or collect 200 dollars ...)
Attempt this without reading the first page entirely at least
Attempt this without knowledge of how to recover from softbrick status
Flash any non official Firmware if you're banking on a warranty claim later {It may or may not work}
Post in this thread, any super negativity, disbelief, or naysaying.
Blame any Project/Thread contributor(s) for what YOU did, when YOU flashed your device. Please, no one forced you to press start in ODIN.
Preface
*****
[FOR THE LATEST UPDATE: GO TO POST #185 for the next steps towards rev 4/5 bootloaders.]
https://forum.xda-developers.com/showpost.php?p=79764173&postcount=185
Bootloader v3 and v4 devices currently on MM or Nougat can use the Factory Binary for their particular bootloader version in order to install a 5.1.1 based ROM that can have an untethered full root. To downgrade back to 5.1.1 use the combination firmware available for your bootloader revision. From there you CAN root 5.1.1 un-tethered.
** I do believe using the Binary 5 Combination Firmware, you can still root using the method for the v4 Bootloader, if you don't mind downgrading back to 5.1.1 and being on the combination firmware.
** I still haven't got a root method for fully rooting 6.0.1, or rooting 7.0 at all. These root methods will have your device ending up on a 5.1.1 build of Android.
For rooting Bootloader v4, please see @droidvoider 's Post #110, Post #110
Since there have been many threads scattered throughout the N920A forums about how to root 6.0.1/5.1.1, and how to downgrade the AT&T Galaxy Note 5 MM Builds back to LL builds, I've decided to collect up all the information I've had time to gather. This thread pertains to downgrading marshmallow builds to lollipop builds, and it covers gaining a tethered root system. What I am also going to cover is what I've discovered about the Factory Binary Firmware for this device. This includes what I call the Eng Modem & Eng Sboot, and how the PB2 Eng Kernel can be used with all three of the above.
Throughout all of my testing on the device, I have never once tripped my KNOX counter. The warranty remained valid on the device and it has been persistently rooted.
@TechNyne66 has outlined {proven} instructions for attaining a Tethered Root. I know there are already a few threads circulating the forum here about Root Status & Progress of the Note 5, and I hate just adding one more to the mix, but this isn't meant to be a general discussion thread.
I spent a lot of time reading over the last two years about the Exynos7420 SoC and I am always trying to learn more than high level google searches can give to me. There are a lot of hardware level topics involved I need more information on, hopefully the devs on XDA with this kind of knowledge would contact me. Because google does not always have the answers we search for when it comes to mobile hardware. It is in the minds of the devs here, and not always posted publicly. Not everyone in the world who wants the abilities granted by root access, is ready/able to deal with the potential hazards and security risks to their Device & Personal Lives. But they never will be ready, if we cannot study what those risks are in the first place.
Just remember, there is a reason things like SuperSu exist in the first place. Without a method to manage access to root privelages by installed apps, you'd be using an Open Source Universal Remote that knows everything about you, its surrounding environment, and knows how to manipulate said data. Given the nature of the Exynos7420's 64bit Architecture, all known variants of the SM-G920, SM-G925, and SM-N920 should theoretically be able to run or boot any code we could ever write for a computing device. We have the build-tools. It's just a matter of using a specific version of a particular tool depending on the timing & current context. Ideally.
My Device Results
*****
The firmware that was initially installed on my particular AT&T Note 5 when I first got it, was the August 1st 2016 build "UCS3BPH4". I have the Full ODIN Package, as well as the OTA.zip that upgrades PE6 to PH4. I also have the OTA.zip for upgrading PB2 to PE5.
I really need, if anyone has some, any unreleased official OTA updates for adb instead of just all ODIN files. I'd also like some advice on how examine how the bootloader loads a kernel, and what it looks for when it does. The update chain of OTAs to the PE5 build would be great. The N920A is odd in the sense that AT&T released two different update paths for their devices. Some devices ended up on the left path, and some on the right path.
When I flashed the Unlocked PH4 Modem, my device became carrier unlocked and opened the APN Editor. I consider it an Eng Modem.
When I flashed the Eng PH1 Sboot.bin from the Factory Binary and the Eng PB2 Kernel, I became able to Flash+Root a Lollipop Build that would stick on rebooting. Using a device with a Version 3 Bootloader. If there are other ways to downgrade to lollipop from marshmallow without using the Eng Sboot, please tell me.
I'm not trying to say at this point that the 3APH1 Firmware is actually a real eng binary like they found for the S8. But the system image on the firmware does have some interesting tidbits I haven't seen in any other Factory Binary I've messed with. It's more than normal.
If you cannot find any of the items I'm referring to in the links below. PM Me.
*****
What I understand about 3BPH4
Included Files in Full ODIN Package:
AP_N920AUCS3BPH4_CL7563702_QB10603229_REV00_user_low_ship.tar.md5
BL_N920AUCS3BPH4_CL7563702_QB10603229_REV00_user_low_ship.tar.md5
CP_N920AUCS3BPH4_CL7563702_QB10603229_REV00_user_low_ship.tar.md5
CSC_ATT_N920AATT3BPH4_CL7563702_QB10603229_REV00_user_low_ship.tar.md5
NOBLELTE_USA_ATT.pit
If I remember reading correctly, ODIN FW whose CSC file does not include a 'hidden.img' in their Cache.img are technically Unbranded ROMs. If this is still true today, then this firmware minus CSC is actually unbranded but uses the AT&T multi-cert CSC. Unless I didn't look hard enough, I did not find a hidden.img when I used CacheRipper to unpack the Cache.img -- I don't remember what post I read this in, I read many threads all the time, I can't confirm at this moment this assumption still holds in modern builds or this device series. Still testing other theories.
I'm not sure about other N920a's, but I have a multi-CSC cert on the device, meaning it should be able to accept any firmware compatible within the same series. At least that's how I remember it being. Same goes for my VZW S5 & S6 Edge. -- I don't know how common Multi-CSC certs are still. I honestly can't remember NOT having a Multi-CSC on any of the Samsung Devices I've owned. Mine all have them. I just have some intuitive feeling the Multi-CSC is basically a requirement for Unlocking.
I have successfully downgraded the AP file many times to earlier builds by flashing the AP by itself. I have successfully done a full cold boot after downgrading the PH4 AP file to PB2, OJ1, and OGG. I successfully flashed the PE6 AP file as well.
I have successfully downgraded the CSC file many times when downgrading the AP file as well. I cannot remember at this moment if I had success downgrading the CSC by flashing only the earlier FW CSC file. The One time I can remember, I flashed only the '.PIT' file included with PH4 & the CSC file of the earlier FW. I do know that I've downgraded the AP file and not the CSC with no errors. I have NOT yet tried to downgrade the CSC file by itself to an earlier version than the Installed AP. -- It remains to be tested in more detail how the AP File and PIT File affect the flashing of a different CSC.
The PH build series is the first publicly available FW for the N920A to use a Level 3 Bootloader Binary. I notice this change from Binary 2 to Binary 3 on most devices going from 5.1.1/6.0 to 6.0.1 Builds on Samsung Devices. With the Exception of Verizon, who has been using a Level 4 Bootloader Binary for quite some time, most Carriers are just now getting around to Level 3 Binaries in their Firmware. Leading many people to believe it is completely locked to a level 3 and can never boot anything designed for an earlier binary. -- While I have so far not been able to test a method for fully downgrading all parts of the BL File from Binary 3 to Revision 1 or 2, a Revision 3 bootloader can still boot a Binary 2 ROM. Although I'm told it is possible to fully downgrade all parts of the PH4 bootloader to an earlier version, but have not successfully done so.
I have successfully downgraded the 3BPH4 sboot.bin included within the BL File of the Full ODIN Package. I did it by packaging the earlier sboot.bin into a tar by itself and flashing in the BL slot of ODIN (3.10.6). Anytime I try to flash a full revision 2 bootloader it quite expectedly fails the flash at param.bin. It trips the alarm in Download Mode by stating the error Binary 2 Device 3. In my successes here, Download Mode still showed Official Device Status, Valid KNOX Bit/Warranty Status, Passing DM-Verity Verification. In all my flashes thus far I've never tripped KNOX. Once, the device status changed from Official to Custom, but KNOX was still showing valid. It wouldn't boot due to an error about invalid kernel length, but everything was valid status under the hood. -- The two downgrades I'm referring to, are the downgrades from
N920AUCS3BPH4 sboot -> N920AUCU3APH1 engsboot
Using the Bootloader from the Factory Binary, we can downgrade from Android 6.0.1 to 5.1.1. I also have the N920C_XXU3API1_ENGSBOOT, but ODIN wouldn't even start to flash it before failing. I don't have the param.bin or cm.bin for either of the ENGSBOOT files. If they even exist publicly or privately.
N920AUCS3BPH4 sboot -> N920AUCU2APB2 sboot
Like I mentioned above, I downgraded the sboot from a binary 3 to a binary 2, by flashing only the sboot.bin and not trying to downgrade the param.bin or cm.bin. But I think having the stock PH4 param.bin & cm.bin could be what is leading to a couple roadblocks. While the flash to PB2 sboot went off without a hitch, and did successfully do a full boot, it only lasted for about 20 minutes. When more tests caused it to stick in a bootloop to prevent itself from tripping the KNOX warranty bit due to invalid kernel length causing failed boot. This is also the only time in all my tests that my Device changed from Official to Custom status. Reflashing the Full PH4 package returned everything back to Stock. I also flashed Systemless Root (Which worked btw! But Verity Caught it, hence why the session lasted only 20 minutes or so) during this test session which could have also done it potentially.
My Best experience flashing most of the files I've tried successfully, came from using ODIN v3.10.6, and it does not seem to be a standard ODIN. Instead of just Odin3.exe & Odin3.ini, these are the files that came bundled inside the Odin zip:
Odin Downloader Release Notes.xlsx
Odin3 v3.10.6.exe
Odin3.ini
S1PlugIn.bundle_141117.zip
SS_DL.dll
But it seems like this version of ODIN has some kind of FTP mode within it for grabbing something I have no idea at this moment. So insights from someone smarter than me would be nice. I think FTP mode was enabled by connecting the Device to odin, while in RNDIS USB Mode. If not, I know that connecting to ODIN in that connection mode did something odd in one of the ODIN versions I have. ALSO, what are all the modded versions running around supposed to be used for exactly? And how were they modded? Often times they fail to flash simple things this v3.10.6 flashes successfully without blinking.[/color]
*** *** ***
Rooting/Downgrading Files Involved
I.Note5 Online Repo - https://drive.google.com/folderview?id=0B4PoJYLnmv1BNzY2OXB3QlFfcVk
** This is the folder where I'm keeping all files referenced here + other N920A related material.
II. Binary 3 Lollipop Bootloader (N920AUCU3APH1 sboot.bin, FRP eng Bootloader) - https://drive.google.com/folderview?id=0B4PoJYLnmv1BQ19qeVFUd2cxaWM
** This sboot can be flashed overtop of the Stock PH4 sboot.bin and IT WILL NOT trip KNOX. This is the only "binary 3" bootloader for our device I've found that will boot 5.1.1 based ROM's or Kernels. Using this bootloader, you can flash 5.1.1 based ODIN AP Firmware Files (ROMS) & continue to have Official Device status for Warranty/KNOX Purposes.
III. 2APB2 Lollipop Eng Kernel - https://drive.google.com/folderview?id=0B4PoJYLnmv1BQVBfQUdYeE5IR1U
** This is a 5.1.1 based, rooted kernel. As far as I know this is a leaked Engineering Kernel from the 2APB2 build. Flashing this Kernel and the PH1 eng sboot, overtop of Stock PH4, gives access to an ADB Root Shell during the bootloop/failure. Flashing this kernel overtop of a stock LL based Kernel allows a bootable rooted system.
IV. Metalcated g920a 5.1.1 Root v4 -
** This is Metalcated's Root Method for the Galaxy S6. This zip is used for the Root-Install & Root-Boot script files. The Root-Install command should be ran once the PB2 Kernel has been flashed and successfully rebooted the first time. Afterwards, the Root-Boot command should be ran during the device's next boot process, to continue using the PB2 Kernel & maintain a bootable system.
*** *** ***
6.0.1 Downgrading Instructions (tested using full Stock PH4 FW)
1.) Enable Developer Options
2.) Enable OEM Unlock
3.) Enable USB Debugging (For a safe bet I make sure to "always remember the device" by saving the RSA Key)
4.) Power Off then Boot into Download Mode
5.) Flash the Binary 3 Lollipop Bootloader using the "BL" slot in ODIN. (Listed Above)
6.) Once Bootlogo Appears, reboot into download mode by holding, VOL Down + HOME + POWER
7.) Now Flash the AP File of the Lollipop FW you want to install. (The OGG ROM, has no DM-Verity in Recovery Mode)
8.) Boot into Recovery Mode
9.) Wipe Data/Factory Reset
10.) Reboot
*** *** ***
5.1.1 Tethered Root Instructions (tested on PB2 & OJ1 ODIN AP FW/ROM's)
1.) Enable Developer Options
2.) Enable OEM Unlock
3.) Enable USB Debugging (For a safe bet I make sure to "always remember the device" by saving the RSA Key)
4.) Power Off then Boot into Download Mode
5.) Flash the PB2 eng Kernel (Listed Above)
6.) Once Booted, recheck steps 1-3, then run the "root-Install" script (.cmd for Windows, .sh for Linux) from Metalcated's zip archive.
7.) During Device Boot Up, make sure the device the connected to your PC, and run the "root-Boot" script from Metalcated's zip archive. And the device should finish booting successfully with the PB2 eng Kernel still intact.z
removed outdated information about Note 5 source codes.. Please see links by Delgoth for updated info
** too many words on someone elses thread **
I think the main problem for you is that you are on a binary 4. I have not tested any of this using a device that starts on binary 4.
But thank you for this, and I will go over these a little later today. I do already have the MM sources for the N920A/V/C and am working on that this week.
Flashing the PB2 flashed a LL rooted kernel, thats why on a device with MM installed it will hang. But during that hang plug it into the pc and open ADB
See if you have root shell.
Just wondering if anyone got anywhere with this. I know nothing about what you guys are talking about but I have N920AUCS4CPL1 and was wondering if anyone figured out a root for it
We have another thread up in the General Android Q&A Forum. I currently have adb shell with eng kernel running Lollipop U1AOGG AP running the U3APH1 eng bootloader.
I also have Busybox support, and can make persistent changes to the /system & /data directories
Droidvoider has also created a type of custom odin/heimdall flashing application used during runtime.
This is big stuff!!!
https://forum.xda-developers.com/android/help/injecting-root-setting-selinux-stages-t3573036/page2
in binray 3 not working, tested
What do you mean when you say it did not work for binary 3? Which FW build did you test? And how did you use ODIN when you flashed?
What tests of yours failed specifically? Because I've successfully downgraded to Lollipop from both the PHA & PH4 builds. I haven't actually tried PJ1. But with the corrupt bootloader issue people have mentioned. It would depend on if you upgraded to a Binary 4 sboot or not.
Sent from my Galaxy Note5 using XDA Labs
Does this thread only apply to the at&t note 5?
shawtypanda said:
Does this thread only apply to the at&t note 5?
Click to expand...
Click to collapse
Yes! This isn't going to work on Verizon.
Actually it could potentially work for Verizon.
If you substitute the Verizon Combination Firmware for the AT&T and apply the same principles accordingly.
So you're saying that there could be a root for the verizon version of this phone?
shawtypanda said:
So you're saying that there could be a root for the verizon version of this phone?
Click to expand...
Click to collapse
I need a Verizon tester for my stuff. Your security patch level can not exceed October, 2016. Please check in Settings|Device|About what your security patch level is. If your patch level is 2017, it is not likely I will be attempting to gain root. Unless there are reports of issues such as battery drain, or if enough people complain about not being able to switch carriers again. freddierice connected the dots with his tools which I have altered to be mine.
Greyhat Root Project - Root Console is a tool which executes commands from a text file, not a root shell
trident is freddierice's tool exactly being converted for the Note 5 (yes verizon also) It is a root shell so to speak, but I'm still working on sepolicy injection (read no context hack yet, limited by context)
Greyhat Root Project -- Root Console
Build a cmd_list.txt to issue commands as root. It also replaces screencap with dirtycow so you can use dirtycow with the two contexts. root + system_server or install_recovery. From install_recovery I am able to switch to init context, maybe a couple others, this feature is being finalized today. But ultimately until I finish trident we don't have reload init, can't reload policy
trident Note 5 version
This is still being converted it does work but the INIT_OFFSET needs to be worked out still, then it should reload init which will reload sepolicy correctly.
edit
The binaries for Greyhat Root Project -- Root Console are specific to each build of Android. You can certainly try the Android 6 or Android 5 toolbox / applypatch on your device but if it fails I need to compile a version specifically for your build. Please PM me with build number, obtain as follows
1. Plug in your device and ensure you can connect to adb shell
2. adb shell getprop ro.build.id
(if you're in the shell already leave off the adb shell) getprop ro.build.id
3. PM me that number, should look like MMB29K
I'm on the latest ota update so I'm assuming I don't qualify but if there's a way for me to downgrade or something so I can test this then I will. But how's the progress? I'm curious
What's this funny stuff about us being able to root our EQC6 (Did we have this update? I don't remember) firmware lol ?? I'm not sure this is even close to the truth, I can already see the bricks happening to mislead ppl. Check it out and tell me (us) what we really wanna hear or give us the sad but real truth
http://www.teamandroid.com/2017/05/...d-70-att-galaxy-note-5-n920a-nougat-firmware/
If someone need I can test verizon version if it ever will be..
I'm on 5.1.1. Was waiting for root, but now thinking of upgrading to nougat. Would be a good idea if waiting for root, or should just stick with 5.1.1
Aurey24 said:
What's this funny stuff about us being able to root our EQC6 (Did we have this update? I don't remember) firmware lol ?? I'm not sure this is even close to the truth, I can already see the bricks happening to mislead ppl. Check it out and tell me (us) what we really wanna hear or give us the sad but real truth
http://www.teamandroid.com/2017/05/...d-70-att-galaxy-note-5-n920a-nougat-firmware/
Click to expand...
Click to collapse
Yeah that looks to be an auto generated page.
I think we're almost done. Basic Shell root is achieved. I had SuperSU half installee before I reflashed. On MM builds.
But on the Note 5 and S6 edge it is coming quickly. Ive just been too busy the last two weeks to check out the signatures.
just recently got my hands on a Note 5 but didn't realise that the N920A was near impossible to root. I was just about to update this phone to the stock nougat but then found this thread today and it looks promising.
Currently running the PB2 firmware. If this root ends up being successful, will it only allow for a permanent root on 5.1.1 or 6.0.1? Or will you be able to flash a ROM like Nougat Nemesis and everything will be okay? Understandable that time will only tell. I'm currently using the Nemesis Nougat on my s6 Edge as my daily driver but would much rather use the Note 5 with Nemesis as my daily driver.
I can see why people love the Note. It truly is a great phone.
is this still a thing?
Dear all
There are so many people looking for exactly samething that iam looking for but unfortunately there is not any proper tutorial available.
Could you confirm if there is anyway to install any other ROM on chinese moto z play ? i don't mind if i have to install each OTA manually.
If so could you please guide step by step guide how to perform this?
If there so no any ROM that can work with chinese variant is there any custom ROM that would and support Moto Mods?
You can read my thread: https://forum.xda-developers.com/moto-z-play/help/problem-reteu-firmwares-chinese-t3619235
Briefly:
1) If you unlock your bootloader you will be able to flash full image of any firmware throug fastboot (with ordinary instruction)
2) OTA at the moment can't be installed even manually due to different device name (addison_retcn vs addison)
I'm looking through different ways to fix device name with no luck at the moment (but I am sure it is possible)
freeman_g said:
You can read my thread: https://forum.xda-developers.com/moto-z-play/help/problem-reteu-firmwares-chinese-t3619235
Briefly:
1) If you unlock your bootloader you will be able to flash full image of any firmware throug fastboot (with ordinary instruction)
2) OTA at the moment can't be installed even manually due to different device name (addison_retcn vs addison)
I'm looking through different ways to fix device name with no luck at the moment (but I am sure it is possible)
Click to expand...
Click to collapse
Did you try editing build.prop?
jameelmemon said:
Did you try editing build.prop?
Click to expand...
Click to collapse
I see that you has not even tried to look through my thread (link was provided in previous post). Suggest to do that (espesially the very end) before further questions / discussion
I have gone through almost all threads including your befiore posting or asking you that question
you are referring to
2) target script is probably /device/company_name/device_name/init.device_name.usb.rc
3) there is a string in that script: write /sys/class/android_usb/android0/iProduct ${ro.product.model}
aactualy {ro.product.model} is variable in build.prop so that script (/device/company_name/device_name/init.device_name.usb.rc) from build.prop
Actually, not there. I have pushed build.prop with adb and has not found any signs of "addison_retcn" there
Hovewer AIDA64 (as well as adb once you try to sideload OTA) will display "addison_retcn" so it is somewhere else
I do not thing that script take the name from build.prop as, for example, it also obtains serial number with the same way and it is the first recommendation on recovering serial (in case it is lost during the some flashing procedure) to manually set it in that script
Finally i manage to install 7.1.1
My phone is addison after installing RETAIL version (7.0)
I installed RETAIL version then downloaded ota then installed 7.1.1 OTA from this thread https://forum.xda-developers.com/moto-z-play/how-to/official-android-7-1-1-download-how-to-t3616352
phone should not be locked/encrypted or protected at least i bricked it and it was not booting up.
Now need to change two things those are in bootloader (SKU and ro.carrier) fastboot getvar all
So just install retail version and sideload OTA through ADB?
I see that my phone is encrypted, shall I decrypt it first?
In any case any news on how you managed to boot 7.1.1 are appreciated
Just found ro.carrier comes from kernel and will be taken from kernel each time devices boots up. so we need someone to customize the kernel and add retru or retus to kernel as ro.carrier.
sku i can not change as i am getting error of command is not allowed
can anyone help regarding this?
So what is the result? You have managed to sideload 7.1.1 аnd it is not booting?
Or everything works fine and you tried to change SKU/channel for further updates?
freeman_g said:
Actually, not there. I have pushed build.prop with adb and has not found any signs of "addison_retcn" there
Hovewer AIDA64 (as well as adb once you try to sideload OTA) will display "addison_retcn" so it is somewhere else
I do not thing that script take the name from build.prop as, for example, it also obtains serial number with the same way and it is the first recommendation on recovering serial (in case it is lost during the some flashing procedure) to manually set it in that script
Click to expand...
Click to collapse
freeman_g said:
So just install retail version and sideload OTA through ADB?
I see that my phone is encrypted, shall I decrypt it first?
In any case any news on how you managed to boot 7.1.1 are appreciated
Click to expand...
Click to collapse
Just install fresh retail version then sideload first ota via adb then boot your phone do not complete setup.
then install 7.1.1 then do factory restore then you are good to go
and it have so many great features you can view them here specially camera app
freeman_g said:
So what is the result? You have managed to sideload 7.1.1 аnd it is not booting?
Or everything works fine and you tried to change SKU/channel for further updates?
Click to expand...
Click to collapse
Initally it didn't work and stuck on bootloader unlock warning but later it worked perfect and iam using 7.1.1 and now trying to figure out how we can change sku and channel to get official OTA.
Sku (XT1635-03) is in bootloader but i can't write is with Fastboot, channel (retcn) is in kernel.
Lucky you I still have the same problem
Yesterday I tried to start with flashing stock retail 7.0 (the link you have provided earlier) but due to fact I had already flashed image with April security patch I didn't manage to downgrade bootloader and gpt (security downgrade issue)
Despite this fact phone boots but small OTA with April security patch did not agree to flash for the same reason: wrong name "addison_retcn"
So I believe the problem is in bootliader and I will probably manage to fix it only with full 7.1.1 retail image.
Glad to see you guys are making some progress. I'll try flashing the retail version on my Chinese Z Play. I'm currently on Epsilon rom (stock rooted 7.0) with January patch. Can I flash retail and then the ota?
I woulf suggest the following:
1) At your current firmware install Aida64 and check if you have addison or addison_cn product name in System section. If you see only addison - then you may install retail firmware and OTAs
2) If you still have addison_cn here then try to install retail firmware provided above (bootloader can be upgraded) and then check product name in Aida64 again. If it changed to addison - you can sideload OTAs. If still addison_cn - then you can't
Thanks @freeman_g
Here is a screenshot of AIDA64 on my device: https://imgur.com/gallery/Or2JF
I guess I should be good to go, right?
Yes, should work
What I can't understand why I still with addison_retcn. Probably, will have to wait for full 7.1.1 retail image
Sorry for the noobie question, but how did you guys with XT1635-03 flash the XT1635-02 firmware? Did you use this script? Did you flash the full rom, including partition, fsg, and modem, no restrictions? I bought my device at Banggood. I know it will come with a shop rom and I would like to install the stock firmware. I want to be prepared when it arrives. Don't want to take the risk of brick it and would like to leave the custom roms for later.
Ok, I have finally found why some people (and myself) have problems with 7.1.1 OTA on xt1635-03
As I mentioned before, OTA just refuses to install mentioning wrong device name (addison_retcn vs addison)
The problem is standard instuction for flashing any firmware with fastboot missing these lines:
fastboot flash dsp adspso.bin
fastboot flash oem oem.img
After flashing these files I saw correct "addison" name in Aida64 and managed to install 7.1.1 OTA on my XT1635-03
People who use RSD Lite did not have such problem as this program use xml file contained both commands (oem and dsp)
It is better to have unlocked bootloader as at first attempt OTA was flashed with some mistake and the phone did not boot. After restoring full image (7.0) with fastboot I managed to sucessfully sideload OTA and now have 7.1.1 on my Chineese device.
Hope this helps
freeman_g said:
Ok, I have finally found why some people (and myself) have problems with 7.1.1 OTA on xt1635-03
As I mentioned before, OTA just refuses to install mentioning wrong device name (addison_retcn vs addison)
The problem is standard instuction for flashing any firmware with fastboot missing these lines:
fastboot flash dsp adspso.bin
fastboot flash oem oem.img
After flashing these files I saw correct "addison" name in Aida64 and managed to install 7.1.1 OTA on my XT1635-03
People who use RSD Lite did not have such problem as this program use xml file contained both commands (oem and dsp)
It is better to have unlocked bootloader as at first attempt OTA was flashed with some mistake and the phone did not boot. After restoring full image (7.0) with fastboot I managed to sucessfully sideload OTA and now have 7.1.1 on my Chineese device.
Hope this helps
Click to expand...
Click to collapse
Awesome, many thanks for sharing. Does this mean you'll receive future OTAs?
OTA - You may BRICK your phone if you have a modified recovery(TWRP,etc) and you try to take an OTA.
OTA will fail if magisk is present.
see
https://forum.xda-developers.com/mo...p-flashing-t3813498/post77011495#post77011495
bump
hello
bumpsi
It is well known since ages, at least since Android 4 where this block oriented OTA was first implemented, that OTA will fail if recovery, boot or system partition is modified. Any root solution modifies at least boot or system and will prevent OTA to run through. Modified recovery should also stop the OTA (do not flash TWRP since long time, so I am not that sure about this on newer Android, at least until Android 6 Lollipop it did).
So: No one could ever successfully take OTA without uninstalling root and twrp if installed. This is valid and well known for nearly all Android devices, not only Motorola. It is known.
Brick on Moto devices is dangerous. It happens if you downgrade your system, but bootloader never is able to get downgraded. So the OTA tries to update the bootloader assuming it is old, but it already is current. This may result in a hard brick where flashing is not possible anymore. You are on the safe side if you do not restore a backup of a system with a previous bootloader, and do not flash older firmware.
So: No one is supposed to brick the Motorola smartphone via OTA if no firmware downgrade ever is done.
Just doing OTA with root will NOT do a greater harm than a failed OTA. There will be some installation log mentioning "there is partition xyz modified, I will not install the OTA". The system will run as before without update. If it doesn't because of some error in the update mechanism, it will suffice to flash the currently installed or some newer firmware to recover the device, there should occur no brick. Root is not the reason for brick in combination with OTA. Older firmware is.
So: What is your reason to bump this wrong worded warning?
KrisM22 said:
bumpsi
Click to expand...
Click to collapse
Kris, please stop spamming the forum. You bumped two threads, repeatedly
many thanks for bumping this important post!
interesting sig.
It have tried endless times trying to get root access via magisk by patching my retail Canada boot.img file. My phone has an unlocked bootloader and I definitely have the right boot image as I tried another boot image from another firmware and got a startup failure which I fixed by flashing the retail Canada boot.img. It patches okay and flashes okay (except for message "image signed with key bad key") but no root access and no installed Magisk. If anyone has a solution, has gained root access some other way or knows for a fact that magisk does not work with this model phone I would be very interested to know. This is the firmware I used the boot file from : XT1952-4_CHANNEL_RETCA_9.0_PPY29.105-57
Thanks
Bad Key is normal after you unlock the boot loader. Have you tried side loading the Magisk apk along with a copy of the boot.img and have the app mod the boot.img? Then move the modded boot image back to your pc and fastboot it on to the phone. That's what I did with my G7Power.
Side loading
Not sure what side loading is but I did patch the boot file with Magisk manager, put it on my PC and fastbooted it to my phone with no results. The ROM for the G7 Play is different than older androids. I tried to create a makeshift recovery for it but my ROM does not have a recovery.img or other older android ROM files for that matter. I will have to wait for some kind of workaround for magisk or someone takes on the challenge to create a recovery for the different file system. I installed a recovery for my Moto G4 plus and rooted no problem. I should have researched more before I purchased the G7 Play and unlocked the bootloader so now I am at the mercy of development.
Thanks for your reply.
Nothing
I tried rooting the phone with the Magisk... Nothing.
I tried to relock the bootloader... Nothing.
What works on the other Moto G7s does not work on our G7 Play.
Hello,
relocking Moto G7 play:
* first reflash the 'boot.img' from the correct firmware file - 'fastboot flash boot boot.img' (in the Internet there are official images to the smartphone)
* then you can lock the bootloader again with 'fastboot oem lock'.
"bad key" is gone, SafetyNet test passed and OTA is working again.
Best regards
realsine said:
Hello,
relocking Moto G7 play:
* first reflash the 'boot.img' from the correct firmware file - 'fastboot flash boot boot.img' (in the Internet there are official images to the smartphone)
* then you can lock the bootloader again with 'fastboot oem lock'.
"bad key" is gone, SafetyNet test passed and OTA is working again.
Best regards
Click to expand...
Click to collapse
Do you have a g7 play and did that? So show us because I could not.
When you use this command an error occurs because the "oem unlocking" option is not checked. And it is not checked because the system disables this option after we unlock the bootloader.
So, unless there is another way to check this option, it's not possible to relock the bootloader. That's what I think.
Marcondes BR said:
Do you have a g7 play and did that? So show us because I could not.
When you use this command an error occurs because the "oem unlocking" option is not checked. And it is not checked because the system disables this option after we unlock the bootloader.
So, unless there is another way to check this option, it's not possible to relock the bootloader. That's what I think.
Click to expand...
Click to collapse
Yes, I have a Motorola Moto g7 play.
When I open the bootloader, I can't close it immediately. I get a "bad key" (or something like that). I have to flash the matching original boot.img first.
So in the bootloader:
* fastboot flash boot boot.img
And if that was successful, then afterwards (without restart)
* fastboot oem lock
Possibly the last command must be entered a second time, but this will be output when
If the command works, then the smartphone boots automatically at this point and the bootloader is closed again.
I assume that you have the correct boot.img and must flash.
I have performed this procedure several times successfully.
Information: at every LOCK and at every UNLOCK the data is reset (Factory reset?).
relock bootloader confirm
I can confirm this does work. I just relocked and unlocked my bootloader with those instructions. Again if anybody has successfully rooted this phone I would love to know.
Any update on this ? I would love to buy this phone but not till I know for sure that it can be rooted.. Any insight into this would be greatly appreciated !!
thetesterman said:
Any update on this ? I would love to buy this phone but not till I know for sure that it can be rooted.. Any insight into this would be greatly appreciated !!
Click to expand...
Click to collapse
This device is definitely rootable -- there is no doubt as to proof of concept. It's just a matter of a viable root method being ironed out. The developer of Magisk (topjohnwu) has stated that the current difficulty with installing systemless root on the Moto G7 Play (via patched boot image) is due to the particular A/B partition index of the device. He is actually working on a universal resolution now. It also appears that TWRP custom recovery is being compiled by the guys over at TeamWin, not to mention unofficial builds being compiled by other dedicated devs (which will likely come first). I went ahead and bought a G7 Play and am just patiently waiting for the imminent resolution for root, TWRP, and hopefully, full-on ROM development. In other words, it's not a matter of if; it's just a matter of when.
I expect the devs to release an unofficial version of twrp soon for g7 play. I already tried the same thing with patching my boot img and flashing in fastboot but still no dice. Just bought the the phone so I hope it gets released soon so we can finally root!
avf90m said:
I expect the devs to release an unofficial version of twrp soon for g7 play. I already tried the same thing with patching my boot img and flashing in fastboot but still no dice. Just bought the the phone so I hope it gets released soon so we can finally root!
Click to expand...
Click to collapse
Amen to that.
Root is all that this phone needs. It's amazing. I'm so happy with it. I can't believe what you get for the price. Why would you buy anything else?
If someone can confirm the current root method for the g6 play could work with the g7 play id happily make a guide for y'all at least. If assuming this device also auto encrypts. Try just booting twrp first, press cancel, swipe right to allow system modifications, go to wipe, push the format button next to the advanced wipe button, type yes, go back into bootloader and flash twrp and internal storage should be readable from there adb push the encryption disabler then magisk. And just in case someone here trys to use the twrp for the g6 play I'm feeling you now it won't work in case that needs to be said. Try using magisk beta also if stable doesn't work I noticed we had to use beta for a little bit before we could use stable
LexusBrian400 said:
Root is all that this phone needs. It's amazing. I'm so happy with it. I can't believe what you get for the price. Why would you buy anything else?
Click to expand...
Click to collapse
Couldn't agree more, fantastic phone ( wish it had wireless charging though ) and all I need is root.
ninjakira said:
If someone can confirm the current root method for the g6 play could work with the g7 play id happily make a guide for y'all at least. If assuming this device also auto encrypts. Try just booting twrp first, press cancel, swipe right to allow system modifications, go to wipe, push the format button next to the advanced wipe button, type yes, go back into bootloader and flash twrp and internal storage should be readable from there adb push the encryption disabler then magisk. And just in case someone here trys to use the twrp for the g6 play I'm feeling you now it won't work in case that needs to be said. Try using magisk beta also if stable doesn't work I noticed we had to use beta for a little bit before we could use stable
Click to expand...
Click to collapse
The G6 Play root method will not work on the G7 Play. The G7 Play uses the A/B partition index. There are currently a few developers ironing out a viable root method and also working on a stable TWRP build. Many Moto G7 Play owners have hard bricked their devices by trying root strategies intended for devices with standard GPT partition tables.
I only recently bought my G7 Play and I am curious as to whether my firmware version is all the way up to date. I have the Boost Mobile variant (xt1952-4) and I'm on the PCY29.105-59 firmware build with a March 1, 2019 security patch level. According to my System Update check in Settings, this is the current build. However, it would seem that with a device so recently manufactured, there would be a more current firmware version available. Are there any Sprint, Virgin, or Boost variant owners who can clarify this? And I apologize if this is off topic.
Viva La Android said:
I only recently bought my G7 Play and I am curious as to whether my firmware version is all the way up to date. I have the Boost Mobile variant (xt1952-4) and I'm on the PCY29.105-59 firmware build with a March 1, 2019 security patch level. According to my System Update check in Settings, this is the current build. However, it would seem that with a device so recently manufactured, there would be a more current firmware version available. Are there any Sprint, Virgin, or Boost variant owners who can clarify this? And I apologize if this is off topic.
Click to expand...
Click to collapse
I'm on OPENMX channel and there is currently a June 1st update waiting to be installed. I'm reluctant to install it because I don't know if it will interfere with the root process down the line.
GatoDeNieve said:
I'm on OPENMX channel and there is currently a June 1st update waiting to be installed. I'm reluctant to install it because I don't know if it will interfere with the root process down the line.
Click to expand...
Click to collapse
Ok thanks for the info. I would guess an OTA update for my variant is imminent within the next couple of weeks at least.
Motorola is not in the practice of patching root exploits via OTA updates. The company actually supports both OEM Unlocking and Android development. I don't think you would have any future issues with root by installing your pending OTA. But at the same time I don't blame you for holding off. When in doubt, don't update. Again, I do thank you for the info.
The xt1952-4 (Sprint, Boost, Virgin) variant is rolling out with PCY29.105-134 with June 1 security patches. I just got notification about ten minutes ago.