I found this post on a blog about a vulnerability with the Qualcomm boot. I can't even begin to explain it but could this help us find a way to root?
LINK: https://bits-please.blogspot.com/20...howComment=1462371232579#c7966216604060424834
Fredo2000 said:
I found this post on a blog about a vulnerability with the Qualcomm boot. I can't even begin to explain it but could this help us find a way to root?
LINK: https://bits-please.blogspot.com/20...howComment=1462371232579#c7966216604060424834
Click to expand...
Click to collapse
This is a trustzone vulnerability that requires root to exploit it. No way to gain root through it
jcase said:
This is a trustzone vulnerability that requires root to exploit it. No way to gain root through it
Click to expand...
Click to collapse
Ah damn. Thanks for letting me know anyways
Not so - this vulnerability requires "mediaserver" permissions to execute and can be used to achieve root (see latest blog post).
Also, I'm releasing another exploit which allows escalation from zero permissions to "mediaserver" which works on all Android versions and phones.
Wow that's an impressive exploit. Congrats for finding it and explaining it in your write up. Have you been able to use it on an unrooted device like ours to gain root? What about the S7 edge that is chained down at the moment? Sounds like you might have an opportunity to cash in on the large bounties for both devices! Once again great work!!
Sent from my LG-H830 using XDA-Developers mobile app
Thanks. I've used the exploit to gain kernel code execution (better than root, since you can disable SELinux, etc.). The QSEE payload I provided should work as-in, since it's symbol-less (finds all the symbols directly in memory). As for the QSEE exploit; you'll need to change the symbols (under symbols.h) to match the Widevine application on your phone. As for the S7 edge - I know nothing about it (have never checked), but I can take a look in a couple of days when I'm at home.
How long did it take to discover and work on this exploit? I'm just a lay person that likes to root phones but I imagine this takes a ton of time to work on. I hope you submit your work and publish a root method and cash in on ~$5000 worth of bounties for all your hard work. And I hope Google implements your fixes soon to patch the holes you have discovered.
Sent from my LG-H830 using XDA-Developers mobile app
laginimaineb said:
Thanks. I've used the exploit to gain kernel code execution (better than root, since you can disable SELinux, etc.). The QSEE payload I provided should work as-in, since it's symbol-less (finds all the symbols directly in memory). As for the QSEE exploit; you'll need to change the symbols (under symbols.h) to match the Widevine application on your phone. As for the S7 edge - I know nothing about it (have never checked), but I can take a look in a couple of days when I'm at home.
Click to expand...
Click to collapse
Wow... This is all some seriously great stuff! If you have some time I would love to talk with you about how to get this working on the Sprint G5
laginimaineb said:
Thanks. I've used the exploit to gain kernel code execution (better than root, since you can disable SELinux, etc.). The QSEE payload I provided should work as-in, since it's symbol-less (finds all the symbols directly in memory). As for the QSEE exploit; you'll need to change the symbols (under symbols.h) to match the Widevine application on your phone. As for the S7 edge - I know nothing about it (have never checked), but I can take a look in a couple of days when I'm at home.
Click to expand...
Click to collapse
If you can modify the kernel, can you disable dm-verity?
If so, I think you might have just found root for our device...
I suggest that you first check if the G5 is even vulnerable to the QSEE vulnerability I disclosed... (extract the "system_" files from the KDZ and the DZ and search for the string "PRDiag"). Since I disclosed the vulnerability a few months ago, it could be patched on the latest version, but might still be vulnerable on previous ones.
Also, as for dm-verity - the QSEE exploit allows full system memory RW (which allows you to patch a running kernel and basically inject arbitrary code). But (!) you probably want to disable dm-verity at boot, which would require a bootloader unlock.
...Which brings me to my last point - If the LG G5 is vulnerable to the QSEE exploit I disclosed, I'm also releasing a QSEE to TZBSP (TrustZone kernel) exploit, which means you can blow any QFuse you like (which is the standard way to disable secure boot).
laginimaineb said:
I suggest that you first check if the G5 is even vulnerable to the QSEE vulnerability I disclosed... (extract the "system_" files from the KDZ and the DZ and search for the string "PRDiag"). Since I disclosed the vulnerability a few months ago, it could be patched on the latest version, but might still be vulnerable on previous ones.
Also, as for dm-verity - the QSEE exploit allows full system memory RW (which allows you to patch a running kernel and basically inject arbitrary code). But (!) you probably want to disable dm-verity at boot, which would require a bootloader unlock.
...Which brings me to my last point - If the LG G5 is vulnerable to the QSEE exploit I disclosed, I'm also releasing a QSEE to TZBSP (TrustZone kernel) exploit, which means you can blow any QFuse you like (which is the standard way to disable secure boot).
Click to expand...
Click to collapse
My god... you are the MAN!!! I'll check for the files ASAP (currently doing mother's day stuff) and report back.
Also, how can I donate to you?
jcase said:
This is a trustzone vulnerability that requires root to exploit it. No way to gain root through it
Click to expand...
Click to collapse
so you are wrong then? this CAN be used to get root?
laginimaineb said:
Not so - this vulnerability requires "mediaserver" permissions to execute and can be used to achieve root (see latest blog post).
Also, I'm releasing another exploit which allows escalation from zero permissions to "mediaserver" which works on all Android versions and phones.
Click to expand...
Click to collapse
Correct, bad wording on my part. However on this phone it really makes no difference, it is actually easier to gain execution as root than it is on mediaserver. This phone is /BAD/ as far as security is concerned. Multiple bootchain backdoors, beyond broke backup system, known kernel vulns left unpatched, heavily (and poorly) modified stagefright as well. We already have root on the phone, root was never the issue, issue was code signing (which was being worked on until someone shared my root knowing i didnt want it shared). LG is enforcing signature validation and dm-verity on this device, just a heads up.
If you release anything compatible with this phone, make sure the users know not to alter laf/recovery/boot/system. They will anyways, and blame you, but at least you warn them.
I sold my G5 after the drama here, so I am no longer working on it.
Syndicate0315 said:
so you are wrong then? this CAN be used to get root?
Click to expand...
Click to collapse
I was technically be wrong, but really makes little difference if the starting point is media server or root. It is honestly easier to get exec as root on this phone than media server. I have already demonstrated that root is not an issue on this device, issue is code signing. This vulnerability does not give you what you guys want, similar to the one of mine that everyone is passing around and emailing me daily about after I put in the read me that it will not do what you want. No one listens.
laginimaineb said:
I suggest that you first check if the G5 is even vulnerable to the QSEE vulnerability I disclosed... (extract the "system_" files from the KDZ and the DZ and search for the string "PRDiag"). Since I disclosed the vulnerability a few months ago, it could be patched on the latest version, but might still be vulnerable on previous ones.
Also, as for dm-verity - the QSEE exploit allows full system memory RW (which allows you to patch a running kernel and basically inject arbitrary code). But (!) you probably want to disable dm-verity at boot, which would require a bootloader unlock.
...Which brings me to my last point - If the LG G5 is vulnerable to the QSEE exploit I disclosed, I'm also releasing a QSEE to TZBSP (TrustZone kernel) exploit, which means you can blow any QFuse you like (which is the standard way to disable secure boot).
Click to expand...
Click to collapse
Blowing fuses is the standard way of enabling secure boot, not disabling. These phones already have that fuse blown. The more recent LG phones have used a signed blob to "unlock" (as far as the ones I've looked at), they are not following the motorola method of blowing a fuse.
The TMobile LG G5 is actually unlocked, all these guys need to do is pack twrp into a TOT (pretty much a raw image with a header) and flash it in download mode.
Fredo2000 said:
If you can modify the kernel, can you disable dm-verity?
If so, I think you might have just found root for our device...
Click to expand...
Click to collapse
He can modify the kernel at run time with this exploit, but not the binary image of it, nor the ram disk that has the settings to enforce dm-verity. It would still need an exploit to get exec in the proper user/context as well as a codesigning exploit
jcase said:
Correct, bad wording on my part. However on this phone it really makes no difference, it is actually easier to gain execution as root than it is on mediaserver. This phone is /BAD/ as far as security is concerned. Multiple bootchain backdoors, beyond broke backup system, known kernel vulns left unpatched, heavily (and poorly) modified stagefright as well. We already have root on the phone, root was never the issue, issue was code signing (which was being worked on until someone shared my root knowing i didnt want it shared). LG is enforcing signature validation and dm-verity on this device, just a heads up.
If you release anything compatible with this phone, make sure the users know not to alter laf/recovery/boot/system. They will anyways, and blame you, but at least you warn them.
I sold my G5 after the drama here, so I am no longer working on it.
I was technically be wrong, but really makes little difference if the starting point is media server or root. It is honestly easier to get exec as root on this phone than media server. I have already demonstrated that root is not an issue on this device, issue is code signing. This vulnerability does not give you what you guys want, similar to the one of mine that everyone is passing around and emailing me daily about.
Click to expand...
Click to collapse
sorry if this is me just being ignorant, but if we gain root on a device with an unlocked bootloader (t mobile), can't we flash root from an app on the phone, boot into recovery, and then flash the disable-dm-verity zip provided on the other thread?
And also, how is gaining root not a problem? Is it through the LAF backdoor?
Syndicate0315 said:
sorry if this is me just being ignorant, but if we gain root on a device with an unlocked bootloader (t mobile), can't we flash root from an app on the phone, boot into recovery, and then flash the disable-dm-verity zip provided on the other thread?
And also, how is gaining root not a problem? Is it through the LAF backdoor?
Click to expand...
Click to collapse
Pack TWRP in tot, flash in download mode. I've said this since day one, you dont need an exploit to root the tmobile variant. Writing an exploit for tmobile lg g5 is a waste of time and resources. Pack TWRP in TOT, flash tot, be done.
Root isn't a problem because the device has multiple publicly known vulnerabilities (and at least one written exploit) that work on it.
jcase said:
Pack TWRP in tot, flash in download mode. I've said this since day one, you dont need an exploit to root the tmobile variant. Writing an exploit for tmobile lg g5 is a waste of time and resources. Pack TWRP in TOT, flash tot, be done.
Root isn't a problem because the device has multiple publicly known vulnerabilities (and at least one written exploit) that work on it.
Click to expand...
Click to collapse
ahhhh OK that makes MUCH sense...
i have the Sprint variant, what would be the best way for me to go about finding a permanent root? would any of these methods work?
Syndicate0315 said:
ahhhh OK that makes MUCH sense...
i have the Sprint variant, what would be the best way for me to go about finding a permanent root? would any of these methods work?
Click to expand...
Click to collapse
Dig through the bootchain, looking for a vulnerability you can use to bypass the secureboot (or otherwise bypass signing requirement of boot.img), or look at LG's code in regards to unlock, i wouldnt be surprised if a route existed there, LG is notoriously bad at "security" features.
jcase said:
Pack TWRP in tot, flash in download mode. I've said this since day one, you dont need an exploit to root the tmobile variant. Writing an exploit for tmobile lg g5 is a waste of time and resources. Pack TWRP in TOT, flash tot, be done.
Root isn't a problem because the device has multiple publicly known vulnerabilities (and at least one written exploit) that work on it.
Click to expand...
Click to collapse
hate to see you've sold your G5. unfortunately, there is no tot for h830. however, sprint has one. I am unsure as to how one can create a tot.
Related
I know that the Verizon bootloader is almost impenetrable as is, but would it be plausible to completely go over the head of the firmware and directly write an image with JTAG that would allow for custom software? If so, would it be possible to use the firmware from another carrier like USC or would it have to be a custom image?
EDIT: summary of the method and everything I have thusfar discovered
So, this method after a bit of evolution, got to the point it basically entailed the following: Using the SD Card debrick method (popularized by the galaxy s3 LTE variants) a modified firmware image would be written to an SD Card, and the phone would boot from that image. The main problem I ran into: it would not let me flash anything that could brick the phone, nor was I able to pull the usb cord at the right moment and try and manually brick it. I was able to flash firmware and stock tars from other variants of the phone (such as the one that runs on T-mobile), but what I found out through that is a couple things:
1. The stock tars seem mostly carrier independent, and I was without any modification able to flash a T-mobile bootloader, system image, and pit file, but within recovery and download mode it would show that because of integrated CSC, it would still change back to the original variant. This could have implications for a very simple method of removing bloat from the phone, but I'm not so sure
2. It must have a very low level method of injecting information and file verification that is not located anywhere on eMMC
The latter led me to research a TON, eventually finding that the most likely culprit is the use of Qualcomm Qfuses, non-volatile pre-set memory located directly on the SoC, to check how the bootloader is signed. They consist of a couple blocks of registers, and definitely aren't readily writable. The trusted base of the entire secure system, the same system that KNOX invokes on other systems, is within a series of Qfuses. From what I have deduced, however, they must be at some software level writable, as although the Knox counter is an e-fuse, the others (such as the warrantee bit) have been both changed upon their void and reverted when brought back to a service center. This must mean that the entire block is possible to modify in both directions, unlike a fuse or breaker; It seems to act more like flash memory than a "fuse." This is very good, mainly because if the service center can change it it means that jtag has not been disabled by those flags, and is enabled in at least some form. What this also means is that without another MAJOR exploit within unfortunately simple, clean code or a leak of several RSA keys from verizon, either current workarounds such as safestrap are the answer for the foreseeable future, or a method of manually changing a simgle Qfuse (the one that controls the "Qualcomm Secureboot" flag) could be used.
What I'm hopefully going to start at some point here is research into finding a way of accessing and changing that Qfuse via JTAG. I have no money for a JTAG box at the moment, so it'll have to wait, but if anyone who already has one wants to use it, hopefully this info helps
P.S. I figured out exactly what T-flash does in odin: it flashes the files that you input into odin to the currently inserted SD Card (or so it seems, I could be wrong but that's what it did for me)
P.P.S. Verizon, I respectfully request that...oh never mind, profanity is definitely frowned upon here
Also, I'm in ongoing discussion with the FCC as to block C violations by Verizon of aspects of the regulations that upon research have not really been argued to any substantial extent, so if that comes to fruition hopefully there'll be simple ODIN flashable patches for this stuff :fingers-crossed:
UPON REFLECTION: if the phone could be bricked, either by very subtly corrupted file or by interrupting a flash at the right moment, then could the debrick image from a tmobile galaxy s5 with an unlocked bootloader be used as not a method of flashing the on-board bootloader but as a kind of external boot, so a permenantly installed SD Card that would be permissive of modified kernels and such but still accepted as a boot device by the phone?
I was wondering something similar. It would be interesting to see if we could do something similar to what we did for the droid x.
tr4nqui1i7y said:
I was wondering something similar. It would be interesting to see if we could do something similar to what we did for the droid x.
Click to expand...
Click to collapse
what was done with the droix x? Did they use a direct JTAG patch?
I just realized something. From reading here: http://forum.gsmhosting.com/vbb/f200/how-fix-samsung-galaxy-s5-sm-g900f-dead-boot-1813266/
It seems to show that the S5 has a "alternative boot upon init fault" method similar to that that allows the galaxy s3 debrick to work (I have a guide I made with details) so would it be possible to somehow corrupt a very important part of the bootloader in an official update (would one or two bits still mess with the signature?), apply that, and have an insecure bootloader on a microsd card in the phone allowing it to boot into that, then use that with odin to flash an insecure bootloader to the s5 itself?
Now I have to ask an interesting question somewhere (since he: http://forum.xda-developers.com/verizon-galaxy-s5/help/g900v-hard-brick-t2914847 seems to have done it): "guys how do I brick my sm-g900v?"
They hijacked the boot init by basically using an alternate boot. It was essentially telling the phone to use a different boot method.
Check out koushs bootstrapper for the droid x and droid 2
Koush, birdman, and apex were the three that I remember the most from the beginning. When I remember who got root first, I'll post here. That or I'll try to get in touch with them.
tr4nqui1i7y said:
They hijacked the boot init by basically using an alternate boot. It was essentially telling the phone to use a different boot method.
Check out koushs bootstrapper for the droid x and droid 2
Koush, birdman, and apex were the three that I remember the most from the beginning. When I remember who got root first, I'll post here. That or I'll try to get in touch with them.
Click to expand...
Click to collapse
I think it might actually be easier
So long as a couple conditions are met for it:
1. The bootloader alone determines if an image is "signed" or not (like when flashed in odin)
2. The same UnBrick exploit from the S3 LTE variants works in some form (secondary storage, fault-triggered boot)
3. It is possible to get it to load a modified bootloader from that secondary boot (this is why number 1 is important)
4. KNOX is completely firmware based, and doesn't have any chip based verification
5. I or someone else actually knows how to modify the bootloader such that it will allow unsigned images (even if not removing it all together, then changing the key to one they publicize so people can sign their rom with it)
If all of these are met, then we might actually have free root! Basically all it would involve would be bricking the device badly enough it boots from secondary storage, have that secondary boot have a "back door" that allows a custom image to be flashed, that allows a bootloader image to be flashed that allows for a signed recovery (signed with that publicly available code) to be flashed without having to deal with safestrap or anything like that. Just full root like on any other phone. Anyone want to offer an opinion? Will this work? I would love to try this out, though I'm a bit unwilling to offer my s5 as a sacrifice just yet as I don't have a JTAG unit on site. I know the bounty is probs gone but I'm ok just getting my bootloader unlocked an' $#*+
The bootloader doesn't need to be bricked, it just needs to be bypassed. If we can find the magic words then we'll be golden.
I'm researching tonight. I'll try tests, hopefully tomorrow. Not sure when I'll be able to have the tone for sure.
An unlock isn't likely. A bypass should be possible though.
Bypassed in what way? I understand the thing with safestrap and such, but that doesn't allow custom kernels or anything, so just modified tw roms which is kinda limiting
tr4nqui1i7y said:
The bootloader doesn't need to be bricked, it just needs to be bypassed. If we can find the magic words then we'll be golden.
I'm researching tonight. I'll try tests, hopefully tomorrow. Not sure when I'll be able to have the tone for sure.
An unlock isn't likely. A bypass should be possible though.
Click to expand...
Click to collapse
Have you found anything yet?
dreamwave said:
Bypassed in what way? I understand the thing with safestrap and such, but that doesn't allow custom kernels or anything, so just modified tw roms which is kinda limiting
Click to expand...
Click to collapse
I need to look up this "safestrap" thing. It sounds like it might be the same thing. Also, by no means does any of this mean root access. If safestrap is what it sounds like, then the concept I was attempting might have already been done.
Safestrap appears to be the same concept, applied in a different way. I've got to do some catching up. I just got the s5, so I'm very late to the show. I'm wondering if anyone has looked into the similarities between the s5 variants.
tr4nqui1i7y said:
I need to look up this "safestrap" thing. It sounds like it might be the same thing. Also, by no means does any of this mean root access. If safestrap is what it sounds like, then the concept I was attempting might have already been done.
Safestrap appears to be the same concept, applied in a different way. I've got to do some catching up. I just got the s5, so I'm very late to the show. I'm wondering if anyone has looked into the similarities between the s5 variants.
Click to expand...
Click to collapse
safestrap uses root access in a stock rom to create a temporary recovery image that lasts for one boot, but it can be finicky and no way to boot into it if you can't access the rom
dreamwave said:
safestrap uses root access in a stock rom to create a temporary recovery image that lasts for one boot, but it can be finicky and no way to boot into it if you can't access the rom
Click to expand...
Click to collapse
The Droid X bootstrap was used with the same intent. It didn't allow custom kernels either. It didn't allow pure aosp ROMs because of that. It modified a boot file to boot to the custom ROM, rather than the actual ROM. It wasn't a recovery or anything like that. It was in app form and only needed to be applied manually the initial time. Unless you wanted to switch/update your custom ROM.
I'm wondering if safestrap, in conjunction with the oe1 rooted build, the oe1 tar, and the boot vulnerability could lead to a method that would allow a one time "downgrade".
Something along the lines of applying a pre-rooted tar, leaving the phone in a bricked state since the bootloader can't be downgraded, adb pushing safestrap files into place, thus modifying the bootloader to get passed the bricked state, allowing it to boot into the rooted tar that was applied or even booting into a ROM possibly.
^ Is all an uneducated guess. I haven't done enough research to know how viable of an option that would be.
tr4nqui1i7y said:
I need to look up this "safestrap" thing. It sounds like it might be the same thing. Also, by no means does any of this mean root access. If safestrap is what it sounds like, then the concept I was attempting might have already been done.
Safestrap appears to be the same concept, applied in a different way. I've got to do some catching up. I just got the s5, so I'm very late to the show. I'm wondering if anyone has looked into the similarities between the s5 variants.
Click to expand...
Click to collapse
that's why I'm hoping the debrick image method will work
tr4nqui1i7y said:
The Droid X bootstrap was used with the same intent. It didn't allow custom kernels either. It didn't allow pure aosp ROMs because of that. It modified a boot file to boot to the custom ROM, rather than the actual ROM. It wasn't a recovery or anything like that. It was in app form and only needed to be applied manually the initial time. Unless you wanted to switch/update your custom ROM.
I'm wondering if safestrap, in conjunction with the oe1 rooted build, the oe1 tar, and the boot vulnerability could lead to a method that would allow a one time "downgrade".
Something along the lines of applying a pre-rooted tar, leaving the phone in a bricked state since the bootloader can't be downgraded, adb pushing safestrap files into place, thus modifying the bootloader to get passed the bricked state, allowing it to boot into the rooted tar that was applied or even booting into a ROM possibly.
^ Is all an uneducated guess. I haven't done enough research to know how viable of an option that would be.
Click to expand...
Click to collapse
so far I've been able to downgrade just fine. Don't do anything with knox and it seems odin can flash back to the original Kitkat rom. Also, safestrap didn't do a thing with the bootloader, it was done during kernel init, right after firmware finishes. If a phone is hard bricked then adb won't work, and what I'm getting at is hard bricking it then using the debrick image thing
dreamwave said:
so far I've been able to downgrade just fine. Don't do anything with knox and it seems odin can flash back to the original Kitkat rom
Click to expand...
Click to collapse
Even after updating past OE1? I thought nobody has been able to downgrade after accepting anything past that update.
Hm, I'd be really interested in finding a way to get the downgrade to work properly for users that updated. Perhaps packaging the safestrap into a rooted tar. I'm not sure. There has got to be a possibility. We've got all the pieces, we just need to put them together.
When you say you want to hard brick then debrick... Are you thinking that the bootloader might be ignored when it is in a broken state, allowing an older image to be written?
tr4nqui1i7y said:
Even after updating past OE1? I thought nobody has been able to downgrade after accepting anything past that update.
Click to expand...
Click to collapse
I don't know, I got it to go back to when root was still possible to get via an app. I don't see why there's a need to downgrade the bootloader if the debrick image thing works
tr4nqui1i7y said:
Even after updating past OE1? I thought nobody has been able to downgrade after accepting anything past that update.
Hm, I'd be really interested in finding a way to get the downgrade to work properly for users that updated. Perhaps packaging the safestrap into a rooted tar. I'm not sure. There has got to be a possibility. We've got all the pieces, we just need to put them together.
When you say you want to hard brick then debrick... Are you thinking that the bootloader might be ignored when it is in a broken state, allowing an older image to be written?
Click to expand...
Click to collapse
Exactly. Safestrap is basically useless for flashing bootloader and stuff as it has no firmware involvement. If the bootloader is the part that determines whether or not it's being upgraded or downgraded then if this works it could be downgraded. If they have a hardware counter that determines it, then a modified new bootloader could be flashed probably but not a previous version.
dreamwave said:
Exactly. Safestrap is basically useless for flashing bootloader and stuff as it has no firmware involvement. If the bootloader is the part that determines whether or not it's being upgraded or downgraded then if this works it could be downgraded. If they have a hardware counter that determines it, then a modified new bootloader could be flashed probably but not a previous version.
Click to expand...
Click to collapse
I am not concerned with fllashing a bootloader. I am only trying to find a way to sneak the old exploit into the updated system via an old flaw.
Old System - Check
Root for old system - Check
init tweak - Check
New bootloader - Check
New system - Check
Rooted new system - Check
Old bootloader vulnerability - Check
New bootloader vuln - Missing
This means we either need to find a way to downgrade again, or find a root method for the new system.
What I am interested in is utilizing the init hack to spoof the old bootloader and allow for the new rooted system to boot for users who have taken updates past OE1.
tr4nqui1i7y said:
I am not concerned with fllashing a bootloader. I am only trying to find a way to sneak the old exploit into the updated system via an old flaw.
Old System - Check
Root for old system - Check
init tweak - Check
New bootloader - Check
New system - Check
Rooted new system - Check
Old bootloader vulnerability - Check
New bootloader vuln - Missing
This means we either need to find a way to downgrade again, or find a root method for the new system.
What I am interested in is utilizing the init hack to spoof the old bootloader and allow for the new rooted system to boot for users who have taken updates past OE1.
Click to expand...
Click to collapse
but that has already been done I think, root on a system with any bootloader so long as a root exploit exists for the OS
That's safestrap. It doesn't allow custom kernels or a full custom recovery though, that's why I'm trying to modify the bootloader
It has come to light that a new update has been released for the Prime version stock ROM. This update is called V6.6 (duh), and the update replaces the preloader. Some people have reported bootloops, one has gotten a brick, and I am all but certain that Amazon is trying to patch the preloader to remove any chance of rooting or converting to OEM ever again. It also replaces the boot image, which we believe is a way to re-lock the bootloader, or possibly even make fastboot ignore the unlocked status. This could also destroy your ability to root, run TWRP, or run any custom ROM ever again. If you are on the Prime stock ROM, DO NOT take the OTA to V6.6. It's really not worth it for the security patch. I also encourage all users of V6.1, V6.4, or V6.5 to go ahead and convert your phone to the non-Prime variant while you have the chance. Amazon is known for jamming updates down people's throats so I would not be surprised if they have a way of installing that update without your approval.
The conversion guide is here: http://forum.xda-developers.com/r1-hd/how-to/guide-convert-to-prime-rollback-ota-t3432499
There is some discussion about the OTA in the last few pages of the general discussion thread here: http://forum.xda-developers.com/r1-hd/how-to/blu-r1-hd-t3418354/post68565531#post68565531
We can use this thread to further dissect and discuss the update.
The boot img can lock the Bootloader.
Thanks for the warning. I would have taken it as I think V6.5 was a good update and improved performance (at the expense of battery life).
DarkBlood. said:
The boot img can lock the Bootloader.
Click to expand...
Click to collapse
No, but some kernel/ramdisk shenanigans could lock it at boot.
We've now confirmed that this update breaks SPFT. It is currently unknown if we will be able to recover from this, but I'm hoping we can.
http://forum.xda-developers.com/showpost.php?p=68578922&postcount=1319
It doesn't appear to relock the bootloader or break fastboot in any way, so if your bootloader is already unlocked you might be okay. I still highly recommend against it.
With the fire tablet they disabled the preloader and changed the pid
ColtonDRG said:
We've now confirmed that this update breaks SPFT. It is currently unknown if we will be able to recover from this, but I'm hoping we can.
http://forum.xda-developers.com/showpost.php?p=68578922&postcount=1319
It doesn't appear to relock the bootloader or break fastboot in any way, so if your bootloader is already unlocked you might be okay. I still highly recommend against it.
Click to expand...
Click to collapse
So, I wonder then, if we dont get a custom rom soon, can the security updates be pulled from the prime OTA and be incorporated into non Prime. I bet if 6.6 plugged SPFT and makes it near impossible for new users to switch to non prime or debloat, that will be the last OTA we see for awhile.
I installed V6.6 OTA update...not sure if I'll regret it. The amazon ads haven't bothered me because I always have notifications, and the ads are smaller than them...plus I was on a CHEAP phone ($10.00) from best buy via slickdeals ad about a year ago...so now I feel like I'm on a contender...it's all relative...Compared to http://www.lg.com/us/cell-phones/lg-LS620-realm I'm flying.
I am sticking to the prime version. I had disabled OTA. Bootloader unlocked. Hopefully someone can see if 6.6 has anything to offer.
DarkBlood. said:
With the fire tablet they disabled the preloader and changed the pid
Click to expand...
Click to collapse
You cannot simply "disable" the preloader. We discussed what exactly Amazon did with the Fire a little bit in the private hangout the other day. The bottom line is that we still don't know exactly what shenanigans Amazon is up to, or what tricks they have up their sleeve. Knowing Amazon, it can't be good for us.
jacewt said:
I am sticking to the prime version. I had disabled OTA. Bootloader unlocked. Hopefully someone can see if 6.6 has anything to offer.
Click to expand...
Click to collapse
It has the August security patch and some things that lock things down. Nothing else that I'm aware of.
bionictoothpick said:
I installed V6.6 OTA update...not sure if I'll regret it. The amazon ads haven't bothered me because I always have notifications, and the ads are smaller than them...plus I was on a CHEAP phone ($10.00) from best buy via slickdeals ad about a year ago...so now I feel like I'm on a contender...it's all relative...Compared to http://www.lg.com/us/cell-phones/lg-LS620-realm I'm flying.
Click to expand...
Click to collapse
If you unlocked your bootloader (fastboot style) via one of the methods before, you should still be able to gain root. If not, you are probably hosed, at least for now. Weather or not you will end up regretting that is up to you, but I certainly would.
kal250 said:
So, I wonder then, if we dont get a custom rom soon, can the security updates be pulled from the prime OTA and be incorporated into non Prime. I bet if 6.6 plugged SPFT and makes it near impossible for new users to switch to non prime or debloat, that will be the last OTA we see for awhile.
Click to expand...
Click to collapse
I agree. By the way, I will be releasing a TWRP version of the image for people who did manage to unlock their bootloader to use to convert after taking the update. I will also try to get a TWRP image of the old-school preloader image working once I've figured out if it's safe.
As for mixing the ROMs, I've considered doing it before. I worry about breaking some of the advantages of the OEM ROM. If this continues for too much longer, I'll consider it more seriously and start looking into it, but I think for now it remains a case of "there are more important things to do".
ColtonDRG said:
I agree. By the way, I will be releasing a TWRP version of the image for people who did manage to unlock their bootloader to use to convert after taking the update. I will also try to get a TWRP image of the old-school preloader image working once I've figured out if it's safe.
As for mixing the ROMs, I've considered doing it before. I worry about breaking some of the advantages of the OEM ROM. If this continues for too much longer, I'll consider it more seriously and start looking into it, but I think for now it remains a case of "there are more important things to do".
Click to expand...
Click to collapse
Fortunately, I had OTA blocked and as I said the other day when i get downtime(hopefully Sunday), I'm back to OEM, to hell with security patches!!
@ColtonDRG, @DarkBlood., @waingro808, @kal250, @ jacewt
Do we have the zip file for the OTA update yet ?
It's usually very trivial to repackage the update zip in order to make it update only /boot and /system, and nothing else (I've done this back with V6.5 since I wanted to keep the oldest bootloaders available). This way one gets all the updates, without any impact on the preloader, unlock status, etc.
This is kind of similar to how it's done for Fire 7 :
http://forum.xda-developers.com/amazon-fire/general/howto-install-fireos-5-1-1-root-gapps-t3265594
bibikalka said:
@ColtonDRG, @DarkBlood., @waingro808, @kal250, @ jacewt
Do we have the zip file for the OTA update yet ?
It's usually very trivial to repackage the update zip in order to make it update only /boot and /system, and nothing else (I've done this back with V6.5 since I wanted to keep the oldest bootloaders available). This way one gets all the updates, without any impact on the preloader, unlock status, etc.
This is kind of similar to how it's done for Fire 7 :
http://forum.xda-developers.com/amazon-fire/general/howto-install-fireos-5-1-1-root-gapps-t3265594
Click to expand...
Click to collapse
The zip is available in https://na.mirrors.coltondrg.com/coltondrg/r1hd/stockota/prime/
bibikalka said:
@ColtonDRG, @DarkBlood., @waingro808, @kal250, @ jacewt
Do we have the zip file for the OTA update yet ?
It's usually very trivial to repackage the update zip in order to make it update only /boot and /system, and nothing else (I've done this back with V6.5 since I wanted to keep the oldest bootloaders available). This way one gets all the updates, without any impact on the preloader, unlock status, etc.
This is kind of similar to how it's done for Fire 7 :
http://forum.xda-developers.com/amazon-fire/general/howto-install-fireos-5-1-1-root-gapps-t3265594
Click to expand...
Click to collapse
Go for it, but I'm not interested in taking any of Amazon's **** either way.
As @DarkBlood. said, the zip file is mirrored on https://na.mirrors.coltondrg.com/coltondrg/r1hd/stockota/prime/
I am curious, and we may already know, but did they fail to properly implement the version check in their OTA updater script? Just looking at the reviews on Amazon, it seems a few have suddenly been borked, and only able to boot to stock recovery since Sept 6th or so. I am curious as one of the recovery system check failure messages appears to be hanging up on the v6.1 files and refusing to boot saying they were modified. Was wondering if those are devices that updated from v6.1 straight to v6.6 whereas it seems Amazon/Blu should have ensured the updater abort if device was not v6.5. Thoughts? They may have created a real mess for themselves....
ariesgodofwar said:
I am curious, and we may already know, but did they fail to properly implement the version check in their OTA updater script? Just looking at the reviews on Amazon, it seems a few have suddenly been borked, and only able to boot to stock recovery since Sept 6th or so. I am curious as one of the recovery system check failure messages appears to be hanging up on the v6.1 files and refusing to boot saying they were modified. Was wondering if those are devices that updated from v6.1 straight to v6.6 whereas it seems Amazon/Blu should have ensured the updater abort if device was not v6.5. Thoughts? They may have created a real mess for themselves....
Click to expand...
Click to collapse
A handful of people around here actually got their phone bootlooped just after taking the upgrade straight from 6.5 to 6.6. At first I figured it was a fluke because their phones were altered, but at this point it's getting very suspicious (almost like it's a hit or miss thing for everyone, even those that haven't touched anything). I hope this doesn't damage the device's reputation too bad, and Amazon better get their **** together. Chopping off their nose in spite of their face. I guess I shouldn't be surprised at this point. This is Amazon we're talking about here.
bibikalka said:
@ColtonDRG, @DarkBlood., @waingro808, @kal250, @ jacewt
Do we have the zip file for the OTA update yet ?
It's usually very trivial to repackage the update zip in order to make it update only /boot and /system, and nothing else (I've done this back with V6.5 since I wanted to keep the oldest bootloaders available). This way one gets all the updates, without any impact on the preloader, unlock status, etc.
This is kind of similar to how it's done for Fire 7 :
http://forum.xda-developers.com/amazon-fire/general/howto-install-fireos-5-1-1-root-gapps-t3265594
Click to expand...
Click to collapse
If the zip can be modified, can we inject the 6.1 preloader and bootloader into the 6.6 OTA and modify it to run over current 6.6 installs allowing those who have been locked to at least unlock themselves?? I'm not savy enough to try....
I wish to root my phone(XT1686) but intend to keep the stock ROM(no bootloader unlock).
Is there any advantage in doing so? And will OTA updates be affected?
yourSAS said:
I wish to root my phone(XT1686) but intend to keep the stock ROM(no bootloader unlock).
Is there any advantage in doing so? And will OTA updates be affected?
Click to expand...
Click to collapse
It is not possible to root without unlocking the bootloader on this device...
If you don't have a specific reason to root, don't do it.
And once rooted, you cannot accept any OTA... most likely case if you do it will just fail, worst possible case it bricks (which can happen but is extremely rare).
To answer the question in your title, about the advantages of rooting...
Rooting gives you near full access to your device, and thus the ability to customize it beyond the options provided to you via the default interface. Also, some apps provide additional features on rooted phones. For example, some security programs recommend rooting your device so that it can more forcefully integrate itself with the device to protect against malware, hacking, etc. I tend to install a security package that works better on a rooted device, as well as make use of features that tend to only work on a rooted device, such as folder mounting from the internal SD card to the external one. Also, allows me to access system files that are unavailable otherwise, allowing me to customize certain sounds (or copy them at least).
If you decide you want to root your device, make sure you understand the steps to take BEFORE trying it. That means when you come across a guide on how to do it, make sure you get all the files that will be required and reading through the instructions step by step. If any of the steps sound like it will leave you lost on what to do, then DO NOT do any of it. Also, make sure you read the comments for the guide as well, looking for any mention of issues encountered and consider if you might encounter those issues as well. For example, if it causes issues for devices that use a particular carrier and you use that same carrier, you might want to leave well enough alone. Compare your phone version numbers with what others report having issues with (kernel, baseband, build, etc). Anything that someone has an issue with where their phone somehow matches up with yours in some way, take that as a sign to investigate deeper, so as to avoid having any issues yourself.
For the most part, unless you have a need or desire for a feature/function that requires rooting your device, don't mess with it. I'm not kidding, as one mistake can leave you without a working phone and without any options for returning/replacing it.
Thanks for the replies & warnings.
I'm not a noob so I know the risks of rooting. So maybe I should have rephrased it-
What are the advantages of rooting Moto G5 plus specifically?
Say like in terms of mods and other stuff? Also, is it possible to unroot once rooted- I mean to ask if it's possible to revert the state to factory mode with bootloader locked and stock ROM so that device will be eligible for OTA updates again?
yourSAS said:
Thanks for the replies & warnings.
I'm not a noob so I know the risks of rooting. So maybe I should have rephrased it-
What are the advantages of rooting Moto G5 plus specifically?
Say like in terms of mods and other stuff? Also, is it possible to unroot once rooted- I mean to ask if it's possible to revert the state to factory mode with bootloader locked and stock ROM so that device will be eligible for OTA updates again?
Click to expand...
Click to collapse
Bootloader lock is not relevant to OTA's. You might be able to relock, but the fact it was once unlocked cannot be hidden, it will always be very clear that it was unlocked.
Unrooting is easy, the issue arises undoing what you did with root, undoing them all depends what you changed.
I don't know of any reasons specific to this device to root.
acejavelin said:
Bootloader lock is not relevant to OTA's. You might be able to relock, but the fact it was once unlocked cannot be hidden, it will always be very clear that it was unlocked.
Click to expand...
Click to collapse
If the OEM knows I've unlocked bootloader, why will it push OTAs to my phone even though I've locked bootloader on my end? So isn't bootloader lock status relevant for OTA?
yourSAS said:
If the OEM knows I've unlocked bootloader, why will it push OTAs to my phone even though I've locked bootloader on my end? So isn't bootloader lock status relevant for OTA?
Click to expand...
Click to collapse
No, the status of your bootloader is not relevant... Moto will notify you of an available update and happily attempt to apply it regardless if your bootloader is locked or not.
What matters is if the boot or system partitions is changed, if there is ANY change to those, among other things like if the radio version or recovery versions don't match or the partition table is changed, the update will fail. If you flash any custom recovery it will fail as well.
On this subject I mention a slight con which is that some banking or financial apps might complain to you if they detect root. I have maybe 10 different bank and credit apps installed and all work flawlessly except 1. The Huntington Bank app wont allow me to use fingerprint login but otherwise the app is fully functional like mobile deposits. Just wanted to mention to be aware.
Because I never rooted my H918 and the replacement from T-Mobile insurance for bootloop issue came with H91810Q already installed, I have been looking for a way to possibly gain root access. Because an exploit will be needed for now, though there is some interesting looking work with modifying LG UP, I found this:
http://www.cvedetails.com/vulnerabi...r-2017/opec-1/Linux-Linux-Kernel-3.18.31.html
I'm not as familiar with coding or exploits as I would like to be, and not sure if I understand if this will give the necessary access but thought I would share for those that DO know and might point me in the right direction or explain if this would work or why it would not.
The exploit you are referring to is Blueborne. That doesn't help us. It is a bluetooth exploit that gains access to the phone. It allows the exploiter control over your phone, as in a thief who steals your phone now has control over it. That doesn't mean the thief could root it. Unless it's a dev on xda, but so far none have done it.
The dirty cow exploit no longer works after 10j firmware and since you can't roll back from 10q, no TWRP, no root.
As a US customer, I'm hesitant to unlock the bootloader and lose warranty after owning the phone for less than 48 hours. My last phone died due to a power button failure that happened a month after the warranty ran out. I'll probably eventually start flashing roms and all that fun, but for now I'm going to keep it boring and stock for at least a little bit.
I want to made a minor modification to the build.prop file, but I understand I need root access to save it again. Or, I can do it through TWRP's mount over USB, but that would also require the bootloader to be unlocked. I know in the past I've had phones that allowed temporary root with some sort of exploit or another, and would persist until reboot at least. Is there anything like that on the Moto G5+? Or am I stuck voiding my warranty for one measly line of text in a file?
Dishe said:
As a US customer, I'm hesitant to unlock the bootloader and lose warranty after owning the phone for less than 48 hours. My last phone died due to a power button failure that happened a month after the warranty ran out. I'll probably eventually start flashing roms and all that fun, but for now I'm going to keep it boring and stock for at least a little bit.
I want to made a minor modification to the build.prop file, but I understand I need root access to save it again. Or, I can do it through TWRP's mount over USB, but that would also require the bootloader to be unlocked. I know in the past I've had phones that allowed temporary root with some sort of exploit or another, and would persist until reboot at least. Is there anything like that on the Moto G5+? Or am I stuck voiding my warranty for one measly line of text in a file?
Click to expand...
Click to collapse
There is no known way to achieve root access without unlocking the bootloader, sorry.
Alright. Well, I guess I can always just unlock the bootloader to install TWRP, but don't bother rooting. I can mount and update the build.prop from the TWRP screen I believe.
I've heard that rooting causes some issues with OTA updates and passing safetynet. If I just unlock and replace the bootloader, will it effect those things as well? Or is that only for rooting?
Dishe said:
Alright. Well, I guess I can always just unlock the bootloader to install TWRP, but don't bother rooting. I can mount and update the build.prop from the TWRP screen I believe.
I've heard that rooting causes some issues with OTA updates and passing safetynet. If I just unlock and replace the bootloader, will it effect those things as well? Or is that only for rooting?
Click to expand...
Click to collapse
I don't think you understand, ANY change to the system, even just mounting /system read-write which TWRP would have to do to make changes, can cause any future OTA update to fail... Maybe... We don't what the OTA update script checks exactly as it isn't the same every time.
acejavelin said:
I don't think you understand, ANY change to the system, even just mounting /system read-write which TWRP would have to do to make changes, can cause any future OTA update to fail... Maybe... We don't what the OTA update script checks exactly as it isn't the same every time.
Click to expand...
Click to collapse
Shoot, that's messed up.
I already unlocked bootloader and booted in twrp (didn't flash into it though), but I'm stuck anyway where it keeps asking for a password I didn't set up in order to make changes to system. So you're saying once I get past that step, it might already break OTA??
Shoot.
Dishe said:
Shoot, that's messed up.
I already unlocked bootloader and booted in twrp (didn't flash into it though), but I'm stuck anyway where it keeps asking for a password I didn't set up in order to make changes to system. So you're saying once I get past that step, it might already break OTA??
Shoot.
Click to expand...
Click to collapse
Yes, that's exactly what I'm saying.
I can't remember on this device if the password is your PIN or you have to flash the dm-verity decrypt patch to get past that though.
Unlocking the Bootloader by itself won't effect OTA updates that we have seen, but we do know the script is capable of checking that... So, yeah.
acejavelin said:
Yes, that's exactly what I'm saying.
I can't remember on this device if the password is your PIN or you have to flash the dm-verity decrypt patch to get past that though.
Unlocking the Bootloader by itself won't effect OTA updates that we have seen, but we do know the script is capable of checking that... So, yeah.
Click to expand...
Click to collapse
So just swiping yes to modify system in TWRP does something that the OTA script detects? Even if I don't actually do any modifications?
I guess I don't really care that much as long as I'm still notified that there's an update and can do it manually. I'm just worried because I found a thread about the most recent update, and it seems folks who were rooted and/or otherwise had OTA fail had a hard time nailing down a reliable way to apply the update to their phones. Will this be a problem going forward?
Dishe said:
So just swiping yes to modify system in TWRP does something that the OTA script detects? Even if I don't actually do any modifications?
Click to expand...
Click to collapse
most times the script checks whether the md5 of the system partition has been changed
so as long as you dont modify anything on the system partition OTA should work fine
any small change to system partition will break future OTA
ckret said:
most times the script checks whether the md5 of the system partition has been changed
so as long as you dont modify anything on the system partition OTA should work fine
any small change to system partition will break future OTA
Click to expand...
Click to collapse
Aw man, so one build.prop line added will mess it up. Welp, guess I'm not going to get OTA either way now. I'll just reflash to stock if/when an update comes out, or flash the update directly if someone makes it available when it happens. Its worth it to bypass Moto's crummy camera processing.