I installed ota on my rooted device, now everytime it boot it opens twrp. I don't know how to reckver my phone ..Please help!!!!!!
[GUIDE] Sucsessful OTA-Update after Rooting + other system changes
- Thread starter Bender1987
- Start date
You must reinstall stock recovery
Enviado do meu Moto G4 Plus através do Tapatalk
Just used OP's instructions to update from Marshmallow to Nougat and was successful but lost root. Head's up to anyone else doing it.
Generally, re-flashing the stock ROM will cause you to lose root and TWRP - the custom modifications are over-written by the stock ROM flash. You can however flash TWRP and proceed to re-root on your newly updated device.
Bear in mind that rooting on stock Nougat requires flashing a custom kernel, such as ElementalX, before rooting. Unlike on stock Marshmallow, attempting to root the stock kernel likely results in a soft bootloop (presumably as you've tripped the anti-rooting protections in the kernel, which are more strictly enforced in stock Nougat).
If you still wish to root, boot/flash TWRP, then backup your device in TWRP. Flash ElementalX v2.0 (or vegito), then your root manager of choice. Wipe cache/Dalvik, then reboot.
Last edited:
I think I can finally answer my own question. I found the cause of the problem here on the TWRP site:
https://twrp.me/faq/whattobackup.html
On most devices shipping with Android 6.0 or higher, the device maker has enabled dm-verity as a security measure. The device will signature check blocks of data on the system partition during boot at the block level. The usage of dm-verity prevents TWRP from being able to successfully restore a normal system backup. On most of these devices, you will see an option on the backup page for System Image. A system image backup takes up more space than a regular system backup, but the system image backup is a bit-perfect backup that, when restored, will not break dm-verity (assuming that you don't break dm-verity before making the backup).
I have TWRP 3.0.2-0, 3.1.1-0, and 3.2.1-0 and only 3.2.1-0 supports system image backups, which my Moto G4 Plus appears to need to permit an OTA update. Furthermore, Flashfire warns that mounting the system partition read/write, instead of read-only, only once can break future OTA updates. See the "Mount /system read/write" checkbox warning here:
Hmm, so for both procedures, seems that in order for a backup to be possibly OTA friendly, you'd have to take an exact partition copy before 'swipe to allow modifications' or anything else that would change the read-only flag/modify the system in any way, and even then dm-verity causes headaches. That makes sense, as the block based OTAs check the cryptographic signatures of the /oem, /system, and other partitions prior to flashing. If the OTA checks reveal a partition not reporting the correct signature (e.g. read-write system partition) then the OTA will fail. https://twrp.me/faq/officialota.html https://source.android.com/devices/tech/ota/nonab/blockI think I can finally answer my own question. I found the cause of the problem here on the TWRP site:
https://twrp.me/faq/whattobackup.html
On most devices shipping with Android 6.0 or higher, the device maker has enabled dm-verity as a security measure. The device will signature check blocks of data on the system partition during boot at the block level. The usage of dm-verity prevents TWRP from being able to successfully restore a normal system backup. On most of these devices, you will see an option on the backup page for System Image. A system image backup takes up more space than a regular system backup, but the system image backup is a bit-perfect backup that, when restored, will not break dm-verity (assuming that you don't break dm-verity before making the backup).
I have TWRP 3.0.2-0, 3.1.1-0, and 3.2.1-0 and only 3.2.1-0 supports system image backups, which my Moto G4 Plus appears to need to permit an OTA update. Furthermore, Flashfire warns that mounting the system partition read/write, instead of read-only, only once can break future OTA updates. See the "Mount /system read/write" checkbox warning here:
Mind you, these checks are likely necessary as the OTA updates for our devices are block based - not many full files to save space. Else, attempting to patch a device with blocks not in the expected position or with unexpected contents would likely lead to severe corruption of the system.
Seems that the easiest route to revert back to stock and ensure your device is OTA friendly is to re-flash the same stock ROM as the build you currently have, whilst removing TWRP, ElementalX, magisk and other modifications. Most if not all the stock firmware we have should be cryptographically signed by Motorola, else the bootloader would likely reject the firmware if you tried to flash unsigned firmware (especially an unsigned bootloader). Furthermore, if the firmware is signed with release keys, these are usually only provided by Motorola or someone with access to their private keys. Whilst someone could try to interfere with the chain of trust by altering the bootloader, that may brick devices as the bootloader may not be verifiable by the hardware key/primary bootloader burnt into the device. If you see users being able to lock and boot their devices with a certain firmware, it's likely genuine for the aforementioned reasons. If someone was able to compromise Motorola's private keys and sign builds in their authority, that could mean OTA updates would no longer be safe.
Unless you can guarantee that your TWRP backup was made without modifications - i.e. a system image made with official v3.2.1 , in which case you may be able to use the backup on an unlocked bootloader (but dm-verity might give you hassle!)
Last edited:
Yes. I think your conclusions are correct, echo. Another pitfall scenario to ponder: I assume that Android uses a Linux/POSIX "accessed" file date/time stamp. If a filesystem is mounted r/w and even a single file is merely read but once (even by the system), would not that action also break the cryptographic signature check and OTA?
Thanks for the links. I have been reading the entire TWRP FAQ repeatedly and trying to fully understand all the points myself over the last day or so.
Agreed, but I believe the main difficulty is Lenovo/Motorola only releases the original ROM image. New ROMs are created with OTA updates and the entire chain of them must be applied each time a user wishes to revert back to stock and update. I suspected that this might be the case when I rooted for my second time and I archived all the OTA in the chain to that point.
From the TWRP FAQ:
Though the OEM trust feature and mechanism is always broken as soon as we root (particularly with the need for a 3rd party kernel), I believe there are greater security hazards in following the above advice instead of rebuilding the entire chain of OEM OTAs, updating with newly released ones, and then re-rooting with the minimum un-trusted software as possible!
Last edited:
I think any scenario where your system is mounted read-write, as in the scenario you present, would cause a change in the overall hash used to calculate that particular partition, and cause the verification to fail. So, yes - I imagine this is to keep manufacturers/general users/financial institutions/regulatory and government authorities happy, to maintain as strict security as possible. Unfortunately, it seems that users wanting root/more power are increasingly outnumbered by the number of users/organisations wanting a device they can trust in terms of security, and that's just been increasingly so as Android is updated, hence the increasingly stringent security implemented and Google's efforts to make rooting harder. This post from Chainfire, developer of SuperSU, might prove enlightening: https://forum.xda-developers.com/showpost.php?p=68424605&postcount=2
Technically, even Motorola has not released any stock ROMs barring the few on its website - recently, many of the stock ROMs are leaks from the Motorola firmware server (as I understand it, mainly for service centres). Motorola builds the new ROMs, signs them, then uploads them, where they appear to be captured for our use.
Of course, it's good to be wary of the source of these stock ROMs, though the inbuilt cryptographic key signing and the security certificates should verify to your device that the firmware is genuine. As I understand it, bootloaders, especially locked bootloaders, can reject firmware not signed with the right keys/certificate, as described here: http://newandroidbook.com/Articles/aboot.html and here: https://www.usenix.org/system/files/conference/woot17/woot17-paper-hay.pdf If a user attempts to lock their device with non-genuine firmware, the lock should fail. Furthermore, dm-verity may block your device from booting if you did have unsigned files/partitions on your device with a locked bootloader, as the overall hashes would not match that expected by the bootloader and the chain of trust. The bootloader seems to be also verified by the hardware OEM key, so unless you've got access to the private keys by Motorola, it seems quite unlikely that the stock ROMs are not genuine if users have reported they can lock their bootloaders and boot with that particular firmware. Furthermore, OTA updates appear to be signed by Motorola, so if your base firmware is not modified but not genuine, I imagine then the OTA update would fail as the certificate may not match that from your firmware https://source.android.com/devices/tech/ota/sign_builds However, from the Moto G4 Plus stock ROMs I've flashed on my XT1642 from the various links on XDA (MPJ24.139-63, NPJ25.93-14, NPJS25.93-14-4, NPJS25.93-14-8, NPJS25.93-14-10), each of them has accepted OTA updates from Motorola with no issue, suggesting that they are genuine. Of course, caveat emptor.
However, you need to be very careful if you're attempting to flash older stock firmware than what you have on your device, then update via OTA updates. We have had multiple instances where users have downgraded their stock firmware, and then hard bricked their devices when taking stock OTA updates.
This appears to be as a result of downgrading, which does not downgrade your bootloader. So you've got an older system but a newer bootloader. Now, when the OTA update is installed, the signature checks are applied to your /system and /modem partitions, for example (I can upload an updater script file for you to look at, or any OTA update file, in the zip file, it's under META-INF/com/google/android/ ) so the update verifies it's flashing to the right system and the partitions are not modified.
Tellingly, the OTA update does not check if your bootloader is the correct patch level - I'm guessing the assumption is that your device firmware and your bootloader are of the same patch levels.
Normally, that would be the correct assumption. However, by downgrading your stock firmware, this assumption no longer holds and the OTA - as it appears to have authorisation, perhaps from having the correct keys - can flash the older bootloader files (raw aboot, sbl/sbl1 images, for example) to your bootloader, corrupting it in the process and causing your device to fail to boot whatsoever.
We do have a blankflash to help try rescue your device, but as Motorola updates the bootloader, this may not work. Custom ROMs should not touch the bootloader, and I notice you've mentioned possibly moving to them, so if you don't wish to mess around with stock firmware, it's an option.
Last edited:
Wow and thanks! I was not aware of this hazard so I guess the only safe way to get OTA updates on a rooted or modified phone (in the manners we've been discussing) is to do a factory reset and only then re-install the entire OTA update chain and rooting process.
Yes. I think 3rd party re-worked and rooted stock ROM images (as suggested on the TWRP FAQ) or a custom ROM are in my future!
Factory resets only should wipe your data and apps. It may not restore your device to a stock firmware configuration (i'm not sure if our devices even have a restore partition). One way to restore back to OTA friendly stock status, as similarly described in the first post, would be to re-flash the system, OEM, logo, kernel and recovery partitions from a stock ROM of the same build. Though you'd remove TWRP, root and any other modifications, your device should be clean and still have your data. Furthermore, your device should then be on the same patch level (including your bootloader) as you only flashed the same firmware as what was on your device, so your device should be ready for OTA.
Alternatively, you can fully flash a newer stock firmware (ensuring it's for your region), without locking your bootloader and without fastboot erase userdata. Afterwards, restore TWRP/ElementalX/root.
The OP doesn't cover the issue of downgrading while retaining a non-downgraded bootloader (and it doesn't instruct the reader to flash bootloader.img from the original ROM in step 2. Restore the stock ROM images).
Would it always be safe to downgrade to the original stock ROM images, as described in the OP step 2, if bootloader.img is also flashed? Is there any downside in always downgrading the bootloader in the process of restoring the original /system, boot.image, recovery.img, and logo.bin in preparation for installing an OTA series of updates?
Thanks for you explanation of factory reset WRT /data and /system.. Wiping data doesn't seem to be a necessary step in a safe OTA update method. Given that I'm just about certain that dm-verity will fail again if I just restore /system from TWRP backups (as it did the first time I unrooted and had to follow this guide to take OTA updates), would it be safe for me to follow this guide again, but make sure I flash bootloader.img this time? BTW, I unlocked my bootloader a couple of rooting-update-re-rooting sessions ago and I've never locked it since.
I'm trying to decide whether to try to downgrade my system to the original ROM again and then update via OTAs to December 1 level and re-root, or just install a non-stock ROM or perhaps a 3rd party packaged and already updated ROM.
Last edited:
1)The opening post does not cover the act of downgrading a stock ROM, that's correct. Rather, it only appears to cover flashing back to the same build you had when you rooted (i.e. re-flashing the same stock ROM build, or rather the parts that get modified by TWRP and rooting), as mandated by this warning in the opening post:
As the message stipulates you need the same build number, you do not have to flash the bootloader if you don't wish to, as there should have been no changes to the bootloader/GPT/modem caused by rooting (only stock firmware/OTAs can touch this level of firmware). Since you're flashing the same build and only restoring the partitions touched by TWRP and root, the bootloader should be and stay on the same patch level. You can flash it if you want to, though you'd be re-flashing the same bootloader. Flashing the bootloader is only critical if you're flashing a newer build than what you had.
2)You cannot downgrade the bootloader in most if not all cases by flashing older device firmware, especially with the newer (B1:05 and above) bootloaders. Attempts to do so are generally blocked by your device bootloader as a security downgrade/pre-flash validation error. Furthermore, as you have the NPJ25.93-14.5 build, you also should have the B1:06 bootloader. B1:05 bootloaders and above appear to be a cause of hardbricks, perhaps because the bootloaders are sufficiently different to older bootloaders that, if overwritten by old OTA updates, they will fail the upstream verification boot checks and cause a hard brick. Also, B1:06 had a bootloader vulnerability patch, so it could well be Motorola blocks downgrades to stop users from re-opening the bootloader vulnerability. In my view, it's not a good idea to downgrade or mess with the core part of the firmware that permits your entire device to boot anyway...
3)You could follow this guide and flash bootloader, only if you're flashing the same build of stock ROM however for the reasons mentioned above. I understand your reluctance for flashing NPJ25.93-14.5 as we can't fully verify the integrity of this stock ROM and you'd like to maintain as little untrusted software, I've not seen any malicious reports for the stock ROM builds from the Motorola Firmware Team however: https://androidfilehost.com/?a=show&w=files&flid=72578
I'd suggest downloading the NPJ25.93-14.5 stock ROM, then following the flashing instructions as described in the opening post to revert the rooting changes. Afterwards, you should receive and be able to install a Motorola OTA, which may go some way to verifying the stock ROM's authenticity (else an unofficial or altered/manipulated stock ROM would likely fail the OTA update).
Instead of the opening post flashing instructions, I'd suggest the following commands (to cover flashing /oem and erasing cache - you can always append the bootloader flashing command to the beginning as well)
Code:
fastboot flash logo logo.bin
fastboot flash boot boot.img
fastboot flash recovery recovery.img
fastboot flash dsp adspso.bin
fastboot flash oem oem.img
fastboot flash system system.img_sparsechunk.0
fastboot flash system system.img_sparsechunk.1
fastboot flash system system.img_sparsechunk.2
fastboot flash system system.img_sparsechunk.3
fastboot flash system system.img_sparsechunk.4
fastboot flash system system.img_sparsechunk.5
fastboot flash system system.img_sparsechunk.6
fastboot flash system system.img_sparsechunk.7
fastboot erase cache
fastboot rebootCustom ROMs, by their nature, do not affect the bootloader (and should not have any means to either), usually only the system partition, so you should be safer with custom ROMs in regards to flashing. I'd suggest reading up on custom ROMs that attract you to be aware of bugs/limitations - generally, they are good though. Also, with a custom ROM, they appear to only apply security patches in the system/user space, any underlying security issues in the device firmware itself would only likely be resolvable by Motorola patches/updates.
Last edited:
Okay--let's see if your tutelage is finally working on me, echo! :fingers-crossed: It seems like a basic underlying concept or rule or two should be sufficient to keep me out of trouble!
The OTA update system is designed and intended for step-wise, forward-direction updates only. At times, it will block regression in the interest of precluding the installation of an outdated and insecure bootloader (as you described and warned). It is also dangerous to go around the OTA step-wise behavior and "flash ahead" to a ROM revision that embodies more than a single OTA step, because an older installed bootloader may not be compatible with newer ROM content.
If the above is not quite right, at least I hope I am getting close to correctness and truth, and I very much appreciate your patience with me!
What is the difference between NPJ... and NPJS...? Are "S" ROMs for Europe? From reading the xda forums, I believe AMZ_NPJ is a ROM for India.
The OTA update system is designed and intended for step-wise, forward-direction updates only To the best of my understanding, yes. I do not think that Motorola, and perhaps other OEMs, ever designed their OTA system to account for device downgrades, hence why in the OTA update description they mention you cannot downgrade after flashing this. Also perhaps why, at least for Motorola, you assume responsibility for anything that happens to your device after the first bootloader unlock.
At times, it will block regression in the interest of precluding the installation of an outdated and insecure bootloader (as you described and warned).
I don't think OTA updates block regression of your device firmware, the regression block seems to be from your device bootloader. Your device bootloader will simply block flashing of bootloaders older than your current bootloader, which is half the danger of downgrading as this results in the mismatched system/bootloader that sets you up for a brick.
I'm not sure what you mean by this 'It is also dangerous to go around the OTA step-wise behavior and "flash ahead" to a ROM revision that embodies more than a single OTA step, because an older installed bootloader may not be compatible with newer ROM content.' though. If I've understood you, flashing a newer stock ROM in full (including GPT/bootloader) should be okay, provided the stock ROM is for your device variant/region. There's nothing to stop you directly flashing NPJ25.93-14.7 or NPJ25.93-14.7-3 (Dec 2017) onto your device, provided it's a full flash since it's a forward flash as you've mentioned - i.e. you're flashing newer firmware onto your device. This full flash does not have to erase your data, but always wise to back up. The fastboot files replace the required partitions with full copies (incorporating the OTA patches) rather than the block based patching of the OTA, so it's useful to perform and a mandatory flash for updating on downgraded devices. Thus, you'd be updating your bootloader to the same patch level by doing a full flash (of course, provided you trust the firmware enough). As you're full flashing (and in most other cases when you're flashing stock boot/recovery/system/OEM/logo), you'll be wiping TWRP, root and custom kernels/logo/modifications from your device, so no need to unroot from your root manager. The flash of stock files for those particular partitions should wipe out root.
Flashing ahead is not a problem, it's if you flash behind (i.e. flashing a stock firmware many OTA levels/builds older than your existing firmware and definitely if it's much older than your bootloader patch level) that sets you up for a hard brick. E.g. in your case, it'd be similar to flashing MPJ24.139-64/65 (Marshmallow 6.0.1) or NPJ25.93-14 (December 2016 Nougat), then attempting to take OTA updates. If you reverted to NPJS25.93-14-4 however, the directly preceding build to NPJ25.93-14.5 (as I remember), taking the OTA to NPJ25.93-14.5 may be safe as the OTA would be flashing the same bootloader files as what you have now.
As for builds: NPJ is Nougat (the first N is Nougat, as is M for Marshmallow and O for Oreo), whereas NPJS should denote a security update. However, Motorola's naming convention is somewhat inconsistent. AMZ_NPJ stock ROMs, or any firmware with AMZ in their title/file name are for Amazon Prime devices (with the locked bootloader, adverts on the lock screen, and cheaper than retail devices). You probably don't want AMZ ROMs on your retUS device.
Last edited:
If the bootloader exhibits this behavior (blocking an older bootloader), it seems like some 3rd party software should be able to flash the old bootloader along with the down-rev ROM images while the phone is still rooted. Upon boot, everything would be safely restored to the desired and un-rooted downgraded level.
My thinking was the bootloader plays a role in updates and blocks older bootloaders so perhaps it might have a similar problem with update attempts that are not step-wise.
Again, it seemed to me that this upgrade situation is the same as when downgrading with a full flash of a down-rev ROM. In both cases the bootloader image is compatible with the full copy image set, but I now understand the difference is the bootloader will permit flashing a newer bootloader in the upgrade case, but not the older bootloader in the downgrade case.
That's what I thought and I had no trouble when following the guide of the OP without un-rooting. Thanks for answering all my other questions too!
In theory, you could dd the partitions pertaining to a bootloader in TWRP/root. However, you'd need a trusted copy of the dd partitions, as any modifications could hard brick your device if you were to interfere with the security chain between the bootloader and the upstream bootloader. I also don't see the benefit of attempting to downgrade with 3rd party tools in this manner, as how could you verify that the tool is safe, and not compromising the bootloader in some way? I thought this whole exercise was to maintain the chain of security, not try to break it.
This paper shows here that in the past the bootloader could be compromised https://www.usenix.org/system/files/conference/woot17/woot17-paper-hay.pdf and in theory you could get root (though the hole has been patched in B1:06 and above bootloaders if I recall), as well as downgrading your bootloader. However, malicious actors could also use this to compromise your device too...
Yes--the tool must be trusted, but the approach solves the problem of untrusted 3rd party published "stock" ROMs, because a trusted original OEM ROM image and trusted OTA updates could be used exclusively to un-root and update a phone before re-rooting. I previously saved all my downloaded OTA zips with the incorrect belief that I could use fastboot and the stock recovery to regress back to the original ROM (and bootloader) and then reproduce and advance the update chain with OTA updates whenever I needed. However, in one of your previous replies, you point out that successfully taking even a single OTA update after installing a 3rd party published stock ROM probably validates the security of the ROM so downloading 3rd party published stock ROMs now appears to be the best option (which is actually the method recommended by the TWRP FAQ)
Thanks for the link. The paper appears to be very educational and interesting. I'll take a close look at it tomorrow.
Last edited:
@up
On this screen, press POWER and VOL+ for a while.
Wysłane z mojego Moto G (4) przy użyciu Tapatalka
On this screen, press POWER and VOL+ for a while.
Wysłane z mojego Moto G (4) przy użyciu Tapatalka
Our Apps
Get our official app!
The best way to access XDA on your phone
Nav Gestures
Add swipe gestures to any Android
One Handed Mode
Eases uses one hand with your phone