Related
Does having my bootloader unlocked affect getting updates? I have no interest in installing custom roms(for now), and mainly just want root to block ads, install seeder to fix this damn lag, and possibly connect a ps3 controller to play games. Figured I'd just unlock and root. I didn't plan on installing cwm so I could still get updates straight from google. I know an update would just overwrite root, but not sure if the bootloader would affect it. My galaxy nexus I always installed custom roms so I don't know how the bootloader affected OTA's. thanks guys.
In principle it should not affect updates.
Have a look at a prior OTA update's installer script
./META-INF/com/Google/android/updater-script
The OTAs perform binary patching on individual files, one by one. (That is why OTAs can be so small.) Before they perform the patching, a checksum is performed on every file on the tab/phone targeted for patching. If even one of those checksums fail, the entire install is aborted.
In addition the version of the recovery is sometimes checked, too - so merely having a custom recovery can trip up an OTA if that type of assert() check is performed.
To put that in general terms, you could say that an OTA update will almost always succeed if you merely add things to a ROM and leave the stock recovery in place.
If you want to flash stuff without altering the stock recovery just use a soft boot of a custom recovery, e.g. "fastboot boot custom-recovery-image-file.img"
If an OTA fails, don't get scared - you can simply unpack it, modify the updater-script file to remove the failing assert(), re-zip it and flash it. This would need to be done with a custom recovery, though as the modified OTA would no longer be correctly signed.
HTH
Yes but don't remove any of the Google apps that come preinstalled, don't edit the build prop, and that might be it.
Sent from my Nexus 7 using Tapatalk 2
BrianDigital said:
Yes but don't remove any of the Google apps that come preinstalled, don't edit the build prop, and that might be it.
Click to expand...
Click to collapse
yep.
The most recent OTA had the boot image file as one of its patching targets, so it was also subject to checksum verification during the initial assert() sequence of "updater-script".
I guess that means that if you hook anything into the boot sequence that needs to be in the ramdisk, that will trip up the OTA, as it is pretty typical for OTA updates to diddle the kernel or ramdisk. I guess that if you want to stay on a near-factory base distro including new ota updates, that puts the onus on you to either
(a) check the installers of the stuff you flash to make sure the boot image is not being re-packed -or-
(b) maintain a chain of pure stock backup sequences: then you can then restore them, run the OTA patch kit on them, make a new nandroid backup, and re-run your custom flashes. Probably use TiB to restore your apps on top of that, too. Almost like an OS re-install sequence, frankly.
cheers
thanks guys! Does an update from google relock the bootloader? I'm guessing not since its a nexus and they're okay with us unlocking it but just wondering. Just trying to decide if its worth it. I feel myself using my nexus 7 less cause of the latest update. It's smooth once its running but turning the screen on after its been sitting, it take some time to get together.
tu3218 said:
thanks guys! Does an update from google relock the bootloader? I'm guessing not since its a nexus and they're okay with us unlocking it but just wondering. Just trying to decide if its worth it. I feel myself using my nexus 7 less cause of the latest update. It's smooth once its running but turning the screen on after its been sitting, it take some time to get together.
Click to expand...
Click to collapse
Whoops (old timers disease) I said "bootloader" in that post above where I should have said "boot partition" or "boot image". (Now corrected.)
Updates typically don't touch the bootloaders. Interesting question though - if you replace a bootloader via fastboot, does it change the lock status? To that Q I don't know the answer from direct experience.
Maybe I'll give it a try. Ugh that's gonna be a lot of backup/restore ops.
In the meantime, have you seen a page with links to (older) *full* ROM install bundles that Google no longer has on their site? I only got a N7 in early Jan '13, so I don't have any of those older full-ROM+bootloader fastboot-based install bundles.
bftb0 said:
Whoops (old timers disease) I said "bootloader" in that post above where I should have said "boot partition" or "boot image". (Now corrected.)
Updates typically don't touch the bootloaders. Interesting question though - if you replace a bootloader via fastboot, does it change the lock status? To that Q I don't know the answer from direct experience.
Maybe I'll give it a try. Ugh that's gonna be a lot of backup/restore ops.
In the meantime, have you seen a page with links to (older) *full* ROM install bundles that Google no longer has on their site? I only got a N7 in early Jan '13, so I don't have any of those older full-ROM+bootloader fastboot-based install bundles.
Click to expand...
Click to collapse
Nah I haven't seen that. To be honest I've been so busy with flashing roms on my sgs3. I finally have settled down on a rom for my phone so I figured I'd give my nexus 7 a go. But I'd rather not be performing the whole backing up/flashing/modding on both. Its so much lol Plus my tablet I need to be dependable when I need it. That's why I hadn't planned on running roms, just basic root for blocking ads, etc. Before the last update this thing was so fast and enjoyable to use. It still is but its not to where it use to be. I was going to go back but I don't like knowing I'm not on the latest.
and mainly just want root to block ads, install seeder to fix this damn lag, and possibly connect a ps3 controller to play games.
Click to expand...
Click to collapse
Seeder doesn't fix lag. Doesn't work. If your n7 is lagging then there is another cause.
Sent from my Nexus 7 using Tapatalk HD
I admit it, I'm confused by the various different rooting threads at this point.
Which root method is the right one for the Sprint model?
Sent from my SPH-L720 using Tapatalk 2
I used this & it worked for me. Easy & quick: http://forum.xda-developers.com/showthread.php?t=2219803
I used the method mentioned above. Seemed to work perfectly. Very easy too.
Sent from my SPH-L720 using Tapatalk 2
Is the bootloader locked or unlocked on the Sprint version ?
Doesn't it have to be unlocked since they are reporting success rooting it?
mysongranhills said:
Doesn't it have to be unlocked since they are reporting success rooting it?
Click to expand...
Click to collapse
These threads are a bit confusing and i want to make sure before i decide to get one
No one really knows if the bootloader is locked or not. Some are able to obtain root, but when flashing certain things, bricked their s4. One dude tried flashing stock and bricked. So I wouldn't get too crazy yet until a dev or someone who knows what they're doing figures out exactly what's going on.
Wow thats crazy flashing something to your phone that isn't made for it.
opz187 said:
No one really knows if the bootloader is locked or not. Some are able to obtain root, but when flashing certain things, bricked their s4. One dude tried flashing stock and bricked. So I wouldn't get too crazy yet until a dev or someone who knows what they're doing figures out exactly what's going on.
Click to expand...
Click to collapse
We have a Stock (dump) build, which will be made available later today that flashes just fine.
If you're following the Engadget bootloader thread, i posted this earlier today..
http://forum.xda-developers.com/showpost.php?p=40844084&postcount=141
This method worked and was painless.
http://forum.xda-developers.com/showthread.php?t=2252248
With regards to the boot methods - we have found something interesting.
@crawrj Had used the Moto root method and couldn't use Solid Explorer properly (i.e. couldn't open init.rc to view, copy system files, etc)
He then used the CF autoroot method and functionality came back.
While not specific enough to point at anything (we don't have logs to look at) I would advise you to check your apps that need root to make sure they function properly.
Just FYI.
I used the AT&T root method and worked fine for me only took 20 seconds.
http://forum.xda-developers.com/showthread.php?t=2252248
Just follow the steps and you will be rooted.
Sent from my SPH-L720 using xda premium
---------- Post added at 09:43 AM ---------- Previous post was at 09:42 AM ----------
Pheonix28 said:
This method worked and was painless.
http://forum.xda-developers.com/showthread.php?t=2252248
Click to expand...
Click to collapse
Sorry didn't see this post.
Sent from my SPH-L720 using xda premium
benny3 said:
Is the bootloader locked or unlocked on the Sprint version ?
Click to expand...
Click to collapse
The write protection is enabled in odin mode....don't know what that means as I haven't dived in yet :thumbup:
Sent from my SPH-L720 using Tapatalk 2
Shadow_God said:
The write protection is enabled in odin mode....don't know what that means as I haven't dived in yet :thumbup:
Sent from my SPH-L720 using Tapatalk 2
Click to expand...
Click to collapse
I have the HTC ONE and it has the Write Protection enabled also. We have a work around that can be flash through recovery, Not sure how you would implement it with Odin but here is the Link, Maybe you can look at it and may help
http://forum.xda-developers.com/showthread.php?t=2236849
JasonJoel said:
I admit it, I'm confused by the various different rooting threads at this point.
Which root method is the right one for the Sprint model?
Sent from my SPH-L720 using Tapatalk 2
Click to expand...
Click to collapse
Motochopper, featured in you tube (http://www.youtube.com/watch?v=6fi1tYaoP0U) or (http://www.youtube.com/watch?v=GrvrXXFb2Uo) and be sure to Download the Drivers from the samsung website. For some reason, the drivers within XDA didn't work for me. Once I D/Ld the one specifically for Sprint, motochopper was able to communicate w/my s4 and rooted it:good:
I've not tried the motochopper stuff so I can't speak for that.
I can confirm that I had success the first time with no driver download needed when I used the CF auto-root method. I simply plugged the phone in, let Win7 download the drivers. I then put it in recovery mode (vol down, home and power button, release power button) and once win7 downloaded those (MHT etc) drivers I loaded the file through pda in odin and it went right through with no problems whatsoever.
The CF auto-root thread is here:
http://forum.xda-developers.com/showthread.php?p=39901375
I would suggest waiting until we figure out just what WRITE PROECTION: ENABLED means on the download screen.
Keep in mind that obtaining Root and bootloader lock status are two completely separate things. Typically, the bootloader being locked doesn't affect the ability to OBTAIN Root. But it will block certain partitions of the device being flashed, if it's indeed locked. And it can also affect the root from being permanent or not. (sticking after a reboot)
Root is an android system thing. An operating system thing. Bootloader is a low level boot thing, before android itself is even initialized. Think of it like the BIOS on a PC, it's the screen you see before you get to windows or linux or whatever operating system you're running.
It's sounding like they are having success with writing to many of the partitions that are ordinarily blocked by a locked bootloader. So it's sounding like the WRITE PROTECTION: ENABLED doesn't actually indicate whether or not the bootloader is locked. But we don't know that for sure yet. It's too early to tell.
Unknownforce said:
I would suggest waiting until we figure out just what WRITE PROECTION: ENABLED means on the download screen.
Keep in mind that obtaining Root and bootloader lock status are two completely separate things. Typically, the bootloader being locked doesn't affect the ability to OBTAIN Root. But it will block certain partitions of the device being flashed, if it's indeed locked. And it can also affect the root from being permanent or not. (sticking after a reboot)
Root is an android system thing. An operating system thing. Bootloader is a low level boot thing, before android itself is even initialized. Think of it like the BIOS on a PC, it's the screen you see before you get to windows or linux or whatever operating system you're running.
It's sounding like they are having success with writing to many of the partitions that are ordinarily blocked by a locked bootloader. So it's sounding like the WRITE PROTECTION: ENABLED doesn't actually indicate whether or not the bootloader is locked. But we don't know that for sure yet. It's too early to tell.
Click to expand...
Click to collapse
Our phone is not locked, at least not in the way we know it. We have flashed kernels, recovery and the system partition from Odin. CF Auto root is the best method of Root IMO. Although both rooting options install and stick. But as MoHoGalore stated I had trouble with an app that required root access using the Moto method. I switched to the CF method and everything was working perfectly. We have no idea what the Write Protection means yet but so far it has not inhibited us in any way.
If unknownforce tells me to wait, I wait. I trust his advice quite a bit, after seeing what he is capable of in the evo3d section.
Sent from my SPH-L900 using Tapatalk 2
k2buckley said:
If unknownforce tells me to wait, I wait. I trust his advice quite a bit, after seeing what he is capable of in the evo3d section.
Sent from my SPH-L900 using Tapatalk 2
Click to expand...
Click to collapse
There is nothing wrong with staying with what you know.
Once we get a complete package, which may not be too far in the near future, we'll know more.
---------- Post added at 06:26 PM ---------- Previous post was at 06:23 PM ----------
crawrj said:
Our phone is not locked, at least not in the way we know it. We have flashed kernels, recovery and the system partition from Odin. CF Auto root is the best method of Root IMO. Although both rooting options install and stick. But as MoHoGalore stated I had trouble with an app that required root access using the Moto method. I switched to the CF method and everything was working perfectly. We have no idea what the Write Protection means yet but so far it has not inhibited us in any way.
Click to expand...
Click to collapse
I can attest to this and I'm still functional.
But, for the masses, there are a few of us willing to try if you want to wait.
Here's hoping we know more very soon. :beer:
Are the root methods too complicated/risky for you? This is a simple solution.
Start with: original droid maxx software (12.7.7 i believe) on Verizon
1. Install motoroot 1.0 (JCase's first root method from original development section), run it, and click root (that's click #1). Make sure everything's working, reboot a few times, use rootchecker to make sure you've got root. (note you won't have write protection off and there'll be a 10-15 sec delay after booting up before you have root). But hey, it's 1 click.
2. Take 1st Verizon OTA to the 4.2.2 with camera update (12.15.15 i believe). Root should survive. Check that it did with root checker.
3. Install the write protection no more from the moto x original development section on your computer. download android-sdk and make sure adb is working, make sure fastboot is working. connect your phone to your computer and run the "write protectoin no more" app on your computer (that's click #2).
That's it. Now I have write protection permanently off, and I have root. I didn't have to use cydia impactor and mess with a tricky update to 4.4 which if it doesn't work I couldn't go back to a rooted phone. I never had to fxz anything or restore anything to stock, or lose any of my data. I didn't have to pay a dime or give someone on ebay all my phone info.
Sure I'd like to have 4.4, but pretty happy with where I am and how easily I got here. And I've read a lot of people say "the root methods are too complicated" --- well this is pretty easy cause you're just using 2 packaged apps.
I've gotten a lot from this forum, and just thought I'd share. Please don't flame. I feel like this is the best compromise of features:effort for me.
It was really easy to put an unlock code into adb.
Sent from my XT1080 using Tapatalk
Piaband said:
It was really easy to put an unlock code into adb.
Sent from my XT1080 using Tapatalk
Click to expand...
Click to collapse
if i could unlock it when i had gotten it in august, sure. but it's too much effort to start over at this point. i have everything set up perfectly. never had to start over. also didn't want to pay for it and send my info to some stranger on the internet. anyway, moot point. good for you, but that option's not available for most people.
So does this work when your already updated to 4.4?
Sent from my XT1080 using XDA Premium 4 mobile app
No nothing roots 4.4 at this point.
vegasdgk said:
So does this work when your already updated to 4.4?
Sent from my XT1080 using XDA Premium 4 mobile app
Click to expand...
Click to collapse
No he basically just rewrote the instructions of how to root the original firmware.
akellar said:
No he basically just rewrote the instructions of how to root the original firmware.
Click to expand...
Click to collapse
I didn't rewrite it. No where are there instructions for getting root AND write protection off on the 4.2.2 camera update without 1 using command line commands AND 2 that network based program (called Cydia compactor I think). There's none of those complications here. Most people don't even realize 1 click root survives the camera update.
But you are right as to kit kat. I thought my title was clear that this is for jellybean though.
mistermojorizin said:
Are the root methods too complicated/risky for you? This is a simple solution.
Start with: original droid maxx software (12.7.7 i believe) on Verizon
1. Install motoroot 1.0 (JCase's first root method from original development section), run it, and click root (that's click #1). Make sure everything's working, reboot a few times, use rootchecker to make sure you've got root. (note you won't have write protection off and there'll be a 10-15 sec delay after booting up before you have root). But hey, it's 1 click.
2. Take 1st Verizon OTA to the 4.2.2 with camera update (12.15.15 i believe). Root should survive. Check that it did with root checker.
3. Install the write protection no more from the moto x original development section on your computer. download android-sdk and make sure adb is working, make sure fastboot is working. connect your phone to your computer and run the "write protectoin no more" app on your computer (that's click #2).
That's it. Now I have write protection permanently off, and I have root. I didn't have to use cydia impactor and mess with a tricky update to 4.4 which if it doesn't work I couldn't go back to a rooted phone. I never had to fxz anything or restore anything to stock, or lose any of my data. I didn't have to pay a dime or give someone on ebay all my phone info.
Sure I'd like to have 4.4, but pretty happy with where I am and how easily I got here. And I've read a lot of people say "the root methods are too complicated" --- well this is pretty easy cause you're just using 2 packaged apps.
I've gotten a lot from this forum, and just thought I'd share. Please don't flame. I feel like this is the best compromise of features:effort for me.
Click to expand...
Click to collapse
Hello,
I have rooted my phone when i am in 12.7.7, then i took the OTA update 12.15.15, now my device is in a boot loop, it boots normally and after a few seconds it will reboot and it goes over and over again.
any thoughts on this and should I use RSDLite to flash it to either 12.7.7 / 12.15.15???
-Zeta- said:
Hello,
I have rooted my phone when i am in 12.7.7, then i took the OTA update 12.15.15, now my device is in a boot loop, it boots normally and after a few seconds it will reboot and it goes over and over again.
any thoughts on this and should I use RSDLite to flash it to either 12.7.7 / 12.15.15???
Click to expand...
Click to collapse
which method did you use to root it? what system stuff did you change after rooting it?
a lot of people had bootloops after taking an OTA because they did the root method that had replaced their stock recovery with a write protect off mode. so in effect, they were having bootloops because they didn't have the recovery, not because they had root. it their case, there was an easy solution of just flashing a recovery. unfortunately i don't know the details of how to do that off the top of my head.'
in any case, rsd'ing to either of those software versions will likely fix all problems.
i rooted as i described with motoroot 1.0, which didn't affect my recovery and was easy to OTA without problems.
good luck
mistermojorizin said:
which method did you use to root it? what system stuff did you change after rooting it?
a lot of people had bootloops after taking an OTA because they did the root method that had replaced their stock recovery with a write protect off mode. so in effect, they were having bootloops because they didn't have the recovery, not because they had root. it their case, there was an easy solution of just flashing a recovery. unfortunately i don't know the details of how to do that off the top of my head.'
in any case, rsd'ing to either of those software versions will likely fix all problems.
i rooted as i described with motoroot 1.0, which didn't affect my recovery and was easy to OTA without problems.
good luck
Click to expand...
Click to collapse
Thanks for the quick reply,
I used the PwnMyMoto here to root, i forgot that this method will replace / remove the stock recovery.
With a minute of panic and some google search, I'd managed to use RSD lite to flash the 12.15.15 FXZ and now my phone is back in business but kinda lost root.
Right now I am looking into the RockMyMoto method here and see if it can help me to gain root.
-Zeta- said:
Thanks for the quick reply,
I used the PwnMyMoto here to root, i forgot that this method will replace / remove the stock recovery.
With a minute of panic and some google search, I'd managed to use RSD lite to flash the 12.15.15 FXZ and now my phone is back in business but kinda lost root.
Right now I am looking into the RockMyMoto method here and see if it can help me to gain root.
Click to expand...
Click to collapse
glad you got your phone back in order, might want to check out slapmymoto (which is the path to rooted kit kat and involves running rockmymoto on the way) while you're at it
mistermojorizin said:
glad you got your phone back in order, might want to check out slapmymoto (which is the path to rooted kit kat and involves running rockmymoto on the way) while you're at it
Click to expand...
Click to collapse
Not sure about the battery life on kitkat of the MAXX right now, so i will stick with 4.2.2 first and do a little research.
Anyway, thanks for the reply and I've gained root on 4.2.2 (12.15.15) using RockMyMoto:laugh:
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
As title said, what features im going to lose besides the OTA and knox?
Sent from my SM-G950F using Tapatalk
iiD4x said:
As title said, what features im going to lose besides the OTA and knox?
Sent from my SM-G950F using Tapatalk
Click to expand...
Click to collapse
Caution: This phone has dm-verity enabled. This means that if you root your phone, it will no longer boot as it can't pass the "Integrity check". I lost a bunch of stuff when I rooted, because I didn't knew that. Recovering it after with something like TWRP is not possible, because the data partition is encrypted.
Backup everything before!!!
gunner007dc said:
Samsung Pay if you use it (any Knox dependant apps), Android Pay can work with Magisk but it's a cat-mouse game of passing SafetyNet. Some financial apps will refuse to work on rooted phones (some can be avoided with Magisk Hide) but if they mean anything to you it's best to check the apps to see if anyone reports problems with a rooted device. I know Netflix and other content providers sometimes block rooted phones.
Click to expand...
Click to collapse
:good: Thanks.
Fusseldieb said:
Caution: This phone has dm-verity enabled. This means that if you root your phone, it will no longer boot as it can't pass the "Integrity check". I lost a bunch of stuff when I rooted, because I didn't knew that. Recovering it after with something like TWRP is not possible, because the data partition is encrypted.
Backup everything before!!!
Click to expand...
Click to collapse
Yeah, i did backup before rooting, Thanks.
Warrenty
Pokemon go
Warranty (tripping knox), Android & Samsung Pay and over-the-air updates.
Generally you have to unroot for the OTA updates to work, but sometimes that is not enough, you have to factory restore the device as well. There is the app "FlashFire" which help you keep root as you upgrade OTA, but I find this won't work on all phones.
These three reasons are why I simply do not root anymore. Now if you have a Google Pixel or OnePlus, they generally don't take away your warranty even if you unlock bootloader or root. Some manufacturer like HTC and Moto, generally you have to request a bootloader unlocking code in order to install custom recovery to root, and in requesting the unlock code you forfeit your warranty.
Is there a way to patch s Health to get it working?
Fusseldieb said:
Caution: This phone has dm-verityenabled. This means that if you root your phone, it will no longer boot as it can't pass the "Integrity check". I lost a bunch of stuff when I rooted, because I didn't knew that. Recovering it after with something like TWRP is not possible, because the data partition is encrypted.
Backup everything before!!!
Click to expand...
Click to collapse
The only thing you said that is correct is that the phones have dm-verity. But given that is implemented by the boot. Img, you can either remove it with 1, an engineering boot, because you can disable dm verity with selinux in permissive. 2, flash a rom that doesn't contain the dmverity flag, seeing as the boot only checks dm verity against the partitions that contain the flag(which isn't many. And is none on a full custom rom) or 3, pull apart the boot image and remove the dmverity file.
And general root has no bearing on dmverity anyways unless an app attempts to obtain root during boot up.
But anyways. It really depends on the root method as to what you lose. If we can achieve root with a locked bootloader, you will still be able to use Samsung pay and other Knox apps with standard root hider
Hi all is there a saver root yet every one I see there was problems
cheers