Related
Update
Since this thread seems to have become quite popular, I thought I'd update it to give people all the newest information in one place.
Since I've made this post, there has been another OTA (build 12940) that improves bootloader security even further and prevents some potential root methods which were being developed for 12840. As of now, neither build 12840, build 12940, nor build 13300 has a published root method. New units have the patched bootloader preloaded from the factory and are not rootable. If you buy a unit at this point, there is a good chance that you will get one that is patched. (EDIT 2013-10-22: People are reporting that units they have purchased from Best Buy and Amazon are still running the vulnerable build. It is unclear if this is simply old stock or if there are still vulnerable units being produced.)
As for the methods described below, they cannot be performed through a shell (i.e. telnet) since the root filesystem is formatted as squashfs, which is read-only. Instead, the root images must be manually repacked for each OTA and flashed using a USB drive with an image such as FlashCast. @ddggttff3 maintains a FlashCast mod to update Chromecasts to the latest firmware without losing root, which can be found here.
For those of you who have managed to keep your vulnerable bootloaders, keep your eyes out. There should be some very cool releases in the near future.
Original post
As can be seen in this commit to Google's Chromecast source mirror, firmware version 1.1 adds a check for the result of image verification on line 755. This check will cause GTVHacker's USB image to fail to boot, and you will not be able to obtain root. Even if another root exploit is found, it seems very unlikely that it will be as clean or simple as the one which exists now, which simply uses version 0.7's unlocked bootloader to flash a new system image.
Unfortunately, I don't have a Chromecast to test on, so I cannot recommend a method of disabling OTAs. However, from looking at the system image, there are a few possibilities I see. THE FOLLOWING METHODS ARE UNTESTED AND ARE NOT GUARANTEED TO WORK OR LEAVE YOUR CHROMECAST IN A WORKING STATE. PERFORM THEM AT YOUR OWN RISK.
After telnetting into your rooted Chromecast or otherwise obtaining a root shell, you can try these two possible methods
Rename otacerts.zip to otacerts.zip.bak in /system/etc/security/. This may remove the OTA signing keys and cause the Chromecast to reject any OTAs. However, I do not know whether this file is actually used or whether is simply a remnant from Chromecast's Android base.
Replace /chrome/update_engine with an empty, executable, shell script (make sure to make a backup copy first). I am very unsure of this method, since it is simply going off the name of the update_engine binary. If update_engine happens to perform some task core to the system, doing this will leave your device in an unusable state. If this happens, simply re-rooting using GTVHacker's USB image should restore your system to how it was.
Again, I am not responsible for any bricked Chromecasts which may result from attempting this. If you do try either method, please report whether or not it appeared to work or have any ill effects.
Any idea when they'll push the update?
xuser said:
Any idea when they'll push the update?
Click to expand...
Click to collapse
According to Google, it's rolling out now.
Thanks for this, just checked my unit, which is still on the old version. Am waiting for my cable to get here so I can root it, so glad I caught it before it updated!
Looks like the update will be automatic and my Chromecast is plugged up at home (connected to wifi). Hope it doesn't get pushed today. My powered USB OTG cable hasn't arrived yet so I can't even root it ATM.
Sent from my GT-N5110 using Xparent Green Tapatalk 2
joshw0000 said:
Looks like the update will be automatic and my Chromecast is plugged up at home (connected to wifi). Hope it doesn't get pushed today. My powered USB OTG cable hasn't arrived yet so I can't even root it ATM.
Sent from my GT-N5110 using Xparent Green Tapatalk 2
Click to expand...
Click to collapse
find out the server name/ip for the OTA update, block it on your router
paperWastage said:
find out the server name/ip for the OTA update, block it on your router
Click to expand...
Click to collapse
Here are the URLs:
Stable channel updates http://goo.gl/3yy01K
Beta channel updates http://goo.gl/53l5sA
Dev channel updates http://goo.gl/JVkHhl
Weird...when I just loaded those, the stable channel has the highest build number. Stable is at 12840 (which is the update that is rolling out now), Beta is at 12726, Dev is at 12819
paperWastage said:
find out the server name/ip for the OTA update, block it on your router
Click to expand...
Click to collapse
I wont be home until later tonight.
Sent from my GT-N5110 using Xparent Green Tapatalk 2
also, i'd assume replacing /boot/recovery.img with a custom recovery or just removing it would also prevent updates. not sure though, I also don't have a chromecast.
also, if you are feeling adventurous, try this: http://db.tt/Ja1XBNgH. if it works, you'll have the latest software, root, and no updated bootloader. if it doesn't work, you might be able to recover by using gtvhacker's image. no promises though, since I don't own a chromecast, I cant test it. Don't blame me if your chromecast quits working, explodes, kills your puppy, or hands north korea some working nukes.
@xuser your signature made me think there was an actual bug on my screen. I tried to kill it, but it ignored my attempts and kept crawling around under the glass
[removed]
Wouldn't it be possible to flash build 12072 back onto the device (since it is signed by Google), and then root it using that build? That is a fairly common practice for many devices that have exploits in early releases. Is there a copy of the image for build 12072 floating around yet?
It's possible. But it seems like more and more manufacturers are preventing downgrading. Who actually manufacturers this thing?
Sent from my SCH-I545 using Xparent Green Tapatalk 2
the chromecast seems to have a recovery mode (like android) that flashes update zips (like android). so if we found a google signed update for the original firmware that includes flashing the insecure bootloader, then downgrades are possible. but the update zips posted above include a build date check,which means you have to either modify your build.prop (requires root, which is what we are trying to accomplish) or modify the update zip (which will make it no longer google signed and valid, so it would need a custom recovery. which requires root). so, unless google lets us, downgrading is not possible.
I'm still hoping that google built in a dev-mode, like their chrome os devices.
Hmm I wonder if I were to order one now would it come with the old software or the new update?
I'm guessing that it would still be on the old build (assuming you get it shipped soon, or pick it up at Best Buy). My Chromecast sticks still haven't updated to the latest build.
joshw0000 said:
Who actually manufacturers this thing?
Sent from my SCH-I545 using Xparent Green Tapatalk 2
Click to expand...
Click to collapse
Good question.
mine updated itself today and lost root
no one tried my image yet?
I'm curious if you had your Chromecast powered off during the day today. And if so, did you see it update when you turned it on?
I have been using my Chromecast to stream music all day, and so far it hasn't updated to the latest build. I would assume as long as the Chromecast is off or in use casting then the update will not be performed.
Louer Adun said:
I'm curious if you had your Chromecast powered off during the day today. And if so, did you see it update when you turned it on?
I have been using my Chromecast to stream music all day, and so far it hasn't updated to the latest build. I would assume as long as the Chromecast is off or in use casting then the update will not be performed.
Click to expand...
Click to collapse
I've turned it off a few times but it finally updated ~30 min ago.
Watch out if you are planning to root! Currently we do not know if this prevents new root!
New firmware 19084 was released yesterday. It predictably does not mention anything about fixing new root exploit, but anybody who would like to attempt root in future should prevent his Chromecast from updating.
https://productforums.google.com/forum/#!topic/chromecast/FOIWpJydK9Y
Thanks for the update! From google source site, it looks like they have yet to patch the new exploit, but until I have a copy in-house to test with, I can not confirm this.
They might purposefully neglect to mention any patch of the exploit in hopes of catching people by surprise....
Munch better safe than sorry for those who are still waiting for a teensy to root
HEADS UP: Seems that google HAS PATCHED the HubCap exploit, but did not post the source for it (to keep us guessing?). Please avoid this OTA if you want root!
How can we see which firmware is currently installed on the chromecast? I connected it back to my tv with router off so it can't update, but I see no info concerning firmware.
TRoN_1 said:
How can we see which firmware is currently installed on the chromecast? I connected it back to my tv with router off so it can't update, but I see no info concerning firmware.
Click to expand...
Click to collapse
Use the CCast setup app....
But I suggest you disconnect the Internet from the router before you check...
Asphyx said:
Use the CCast setup app....
But I suggest you disconnect the Internet from the router before you check...
Click to expand...
Click to collapse
I more than suggest. I don't know when it started, but the current Chromecast app will try to force an update before it completes setup.
I still have version 17977
I am not rooted I am hopping this new update allows native screen mirroring.
shamelin73 said:
I still have version 17977
I am not rooted I am hopping this new update allows native screen mirroring.
Click to expand...
Click to collapse
Screen mirroring is already available...A new update isn't going to change anything about that if you can't mirror already the issue is your phone or tablet not the CCast.
SO if you want to root I suggest not taking the Update until you do, You are not going to gain anything just lose the ability to root.
Asphyx said:
Screen mirroring is already available...A new update isn't going to change anything about that if you can't mirror already the issue is your phone or tablet not the CCast.
SO if you want to root I suggest not taking the Update until you do, You are not going to gain anything just lose the ability to root.
Click to expand...
Click to collapse
I am guessing I don't know how to get it to work then. I thought the Moto X was not supported yet till the update but I am guessing it is an update to the phone that I need.
Sent from my XT1053 using Tapatalk
shamelin73 said:
I am guessing I don't know how to get it to work then. I thought the Moto X was not supported yet till the update but I am guessing it is an update to the phone that I need.
Sent from my XT1053 using Tapatalk
Click to expand...
Click to collapse
Yes it is most likely the phone side that is the issue...
The Mirroring works for the devices that support mirroring and it is unlikely to change much in an update.
All the CCast does is receive a stream....the Phone/Tab does the majority of the work by creating the stream and not all units have the ability to do that yet.
Besides...Even if you root the CCast it won't take long for Team Eureka to update the rom to get any goodness the newest update has in it....
So even after you root if there DOES happen to be something that allows your phone to mirror you will get it in Team Eureka Rom soon enough.
If you have a Chromecast "tucked away" waiting to be rooted you might want to turn off WiFi and factory reset it so it has no ability to update when you power it up for rooting later.
Anyone know when the update mentioned in the io will be pushed?
Deeco7 said:
Anyone know when the update mentioned in the io will be pushed?
Click to expand...
Click to collapse
Been pushed already! SO if you haven't rooted yet and your unit has gotten the update your SOL...
It should also be noted, that once you get this update, a factory reset COULD essentially brick the device, or at least give you problems.
Sources:
https://plus.google.com/110558071969009568835/posts/QUjWK6fkHNR
...and
https://plus.google.com/110558071969009568835/posts/cEhdykfYstF
mdamaged said:
It should also be noted, that once you get this update, a factory reset COULD essentially brick the device, or at least give you problems.
Sources:
https://plus.google.com/110558071969009568835/posts/QUjWK6fkHNR
...and
https://plus.google.com/110558071969009568835/posts/cEhdykfYstF
Click to expand...
Click to collapse
Looks like they tried to push out an update to fix the new root exploit too quickly.
where is my backdrop? ;_;
What works with the nexus 6? Any links or videos that you guys know of that work on mac? Device is on my company line and already got notified that i need it to be stock.
thanks in advance, guys.
huxington said:
What works with the nexus 6? Any links or videos that you guys know of that work on mac? Device is on my company line and already got notified that i need it to be stock.
thanks in advance, guys.
Click to expand...
Click to collapse
Do you have any company apps installed?
---
You could try the full unroot option in SuperSU, or go through the process of flashing the factory images available here: https://developers.google.com/android/nexus/images
Note: Flashing factory images will wipe the device
zylstrajs said:
Do you have any company apps installed?
---
You could try the full unroot option in SuperSU, or go through the process of flashing the factory images available here:
Note: Flashing factory images will wipe the device
Click to expand...
Click to collapse
I have exchange set up, and the first notifications were geared towards that. Third notification was "rooted device on network".
huxington said:
I have exchange set up, and the first notifications were geared towards that. Third notification was "rooted device on network".
Click to expand...
Click to collapse
I'm not aware of any root cloak apps currently compatible with lollipop, I'd follow company policy until one is released.
zylstrajs said:
I'm not aware of any root cloak apps currently compatible with lollipop, I'd follow company policy until one is released.
Click to expand...
Click to collapse
well, supersu worked, and root checker backed that up.
That should be enough for the company. Right?
huxington said:
well, supersu worked, and root checker backed that up.
That should be enough for the company. Right?
Click to expand...
Click to collapse
Can't really say. You'd have to check internally to follow up.
If you are going to stay unrooted, might as well flash factory images. That way, you can get OTA without any issues of restoring stock images first
There are a couple toolkits that make it effortless.
http://forum.xda-developers.com/nexus-6/development/toolkit-wugs-nexus-root-toolkit-v1-9-8-t2947452
Also very easy to flash it yourself as others have said, I have oem unlocked, locked rooted unrooted by flashing about 6 or 7 times now. Have also used wugs toolkit above, and works really well, just a little slower than manual.
This is the place to discuss anything and everything related to SuperSU and SafetyNet / Android Pay.
To clarify, I am not currently actively doing any development on having SuperSU pass SafetyNet detection, or having Android Pay work; the same way I put no effort into beating other root detection methods such as various enterprise security tools.
In case any SuperSU-rooted device passes SafetyNet, that is a bug in SafetyNet, not a feature of SuperSU.
While I may not agree with Google's stance, I'm not about to go messing with payment systems. Is it possible though? Probably yes.
This thread has been created because you guys simply cannot stop talking about this, so these posts can now go here, where I don't ever have to see them.
Will v2.50 cause Android Pay not to work in 6.0? If so, I am guessing there is no way around it?
0.0 said:
Will v2.50 cause Android Pay not to work in 6.0? If so, I am guessing there is no way around it?
Click to expand...
Click to collapse
Root is a no no with android pay and I think custom ROMs are also out at the moment
Sent from my A0001 using Tapatalk
Pure Drive GT said:
Hey, thanks for your continued support for root on Android, was just wondering, is google making it harder to achieve decent root privileges, as in they don't want rooted devices or are they just unrelatedly changing up things which forces you guys to adapt?
On another note, is there any progress on root without the modded boot? This is by no means an ETA, just wanted to know if you think it's possible or the situation looks rather dire.
Thanks again for your many efforts!
Click to expand...
Click to collapse
Well, just look at Android Pay, it will not allow one to add a credit card if it detects the device is rooted. So yeah, Google definitely wants to stop root, or at least make sure there is a strong dissuasion towards same. It's not a bad thing persae, as Google is just making the devices more secure for the masses. We 'power users' are lucky to have those such as Chainfire working so hard to get us what they can.
mdamaged said:
Well, just look at Android Pay, it will not allow one to add a credit card if it detects the device is rooted. So yeah, Google definitely wants to stop root, or at least make sure there is a strong dissuasion towards same. It's not a bad thing persae, as Google is just making the devices more secure for the masses. We 'power users' are lucky to have those such as Chainfire working so hard to get us what they can.
Click to expand...
Click to collapse
Many banking and financial apps restrict access on rooted devices; it's not just Google.
It makes sense in some ways: root access allows running things in the background to either circumvent, monitor, or interrupt program transactions. They're being paranoid, and I don't blame them.
I don't like the Google Pay concept (or Apple's either); like every other encryption or security system, it's destined to eventually be hacked.
mdamaged said:
Well, just look at Android Pay, it will not allow one to add a credit card if it detects the device is rooted. So yeah, Google definitely wants to stop root, or at least make sure there is a strong dissuasion towards same. It's not a bad thing persae, as Google is just making the devices more secure for the masses. We 'power users' are lucky to have those such as Chainfire working so hard to get us what they can.
Click to expand...
Click to collapse
Yep, I was able to add my debit card but not credit.
VZW LG G4
mdamaged said:
Well, just look at Android Pay, it will not allow one to add a credit card if it detects the device is rooted. So yeah, Google definitely wants to stop root, or at least make sure there is a strong dissuasion towards same. It's not a bad thing persae, as Google is just making the devices more secure for the masses. We 'power users' are lucky to have those such as Chainfire working so hard to get us what they can.
Click to expand...
Click to collapse
http://www.androidpolice.com/2015/0...hy-android-pay-doesnt-support-rooted-devices/
shaggyskunk said:
Yet the Note 5 has been rooted for at least a couple of weeks
Click to expand...
Click to collapse
On Lollipop... And you also have to unlock your bootloader to do that, right? If yes, then you will trip the KNOX, and that mean you will loose some of your device functionality (Samsung Pay for example), without option to take it back. On the Nexus on the other hand, when you want to use Android Pay on Nexus, you can restore your phone to completely stock condition, without any trace of previously used root.
Also, all of this is completely irrelevant to carried device users, since they have a locked bootloaders.
Srandista said:
On Lollipop... And you also have to unlock your bootloader to do that, right? If yes, then you will trip the KNOX, and that mean you will loose some of your device functionality (Samsung Pay for example), without option to take it back. On the Nexus on the other hand, when you want to use Android Pay on Nexus, you can restore your phone to completely stock condition, without any trace of previously used root.
Also, all of this is completely irrelevant to carried device users, since they have a locked bootloaders.
Click to expand...
Click to collapse
I believe that it's only at&t and Verizon that locks the bootloader - And none in Canada and many other Countries.
Sent From my SM-N910W8 Running SlimRemix V5.1
Had an interesting event, on 2.52.
I unchecked "Enable Superuser" in Settings, to attempt to use Android Pay (Android Pay still wouldn't work). Then, when I rechecked "Enable Superuser", the re-installation of the binary failed, and I was prompted to reboot to try again. However, then I got a boot loop (never even got the opportunity to enter my encryption code). The only way I was able to boot was to re-flash the modified boot.img and re-install SuperSU from the zip (no idea whether both steps were necessary).
I have a Marshmallow Nexus 6, encrypted. For what it's worth, I was previously rooted on 5.1.1, and, after updating to 6.0 and until I re-rooted, I always got a "Your device is corrupt" message on startup, despite being all stock.
NYZack said:
Had an interesting event, on 2.52.
I unchecked "Enable Superuser" in Settings, to attempt to use Android Pay (Android Pay still wouldn't work). Then, when I rechecked "Enable Superuser", the re-installation of the binary failed, and I was prompted to reboot to try again. However, then I got a boot loop (never even got the opportunity to enter my encryption code). The only way I was able to boot was to re-flash the modified boot.img and re-install SuperSU from the zip (no idea whether both steps were necessary).
I have a Marshmallow Nexus 6, encrypted. For what it's worth, I was previously rooted on 5.1.1, and, after updating to 6.0 and until I re-rooted, I always got a "Your device is corrupt" message on startup, despite being all stock.
Click to expand...
Click to collapse
Root doesn't have to be enabled for pay to fail. Any time the system partition is modified pay will not work. There was an xda news article on it. A quick Google search involving Android pay and root should find it.
Lrs121 said:
Root doesn't have to be enabled for pay to fail. Any time the system partition is modified pay will not work. There was an xda news article on it. A quick Google search involving Android pay and root should find it.
Click to expand...
Click to collapse
I also found that having an unlocked bootloader will stop Pay working. When MM released I decided to go fully back to stock but kept the bootloader unlocked so I could flash MM. Pay still failed, so I've given up and gone rooted again.
Sent from my Nexus 6 using Tapatalk
Ch3vr0n said:
@Chainfire if you actually are able to pull off fully working stable root WITHOUT modifying the /system does that mean you MIGHT have opened the door into having root AND still being able to get OTA's?
Click to expand...
Click to collapse
osm0sis said:
Yup, all you'd need to do is reflash stock kernel to pass the boot partition EMMC check, or, we could automate restoring the previous stock kernel, flashing the OTA and then injecting the new stock kernel with root after flashing (à la AnyKernel2 or MultiROM). So many exciting possibilities there where custom recoveries are concerned.
Click to expand...
Click to collapse
Chainfire said:
Honestly it's not so different from using FlashFire to flash re-flash system, then OTA, then re-root. But it is easier, yes.
Click to expand...
Click to collapse
This is indeed exciting. However, I noticed that @Chainfire posted this downside on Google+ :
Andrew Morykin 12:24
This should retain Android Pay, right?
Click to expand...
Click to collapse
Chainfire 12:58
+Andrew Morykin if it does, then it's by accident and not by design, and Android Pay will be updated to block it.
Click to expand...
Click to collapse
https://plus.google.com/+Chainfire/posts/aJbqUZ8PEP4
also, I was confused by this:
Chainfire said:
- I have not tested with encrypted devices
Click to expand...
Click to collapse
http://forum.xda-developers.com/showpost.php?p=63197935
Aren't
Nexus 6P / angler
angler-mdb08k-boot-systemless.zip
Click to expand...
Click to collapse
and
Nexus 5X / bullhead
bullhead-mdb08i-boot-systemless.zip
Click to expand...
Click to collapse
encrypted out of the box?
dabotsonline said:
This is indeed exciting. However, I noticed that @Chainfire posted this downside on Google+ :
Click to expand...
Click to collapse
How is that a downside?
It's exactly the same with every other form of root you will ever see. They don't want to support Android Pay (and some other stuff) on rooted devices. If we find a root that allows it, they will update their system to detect and block it. That cat and mouse game will not end as long as Google doesn't want Android Pay on rooted devices.
Maybe someone will make apps/modules that help circumvent this, but it certainly will not be me.
also, I was confused by this:
Aren't
Nexus 6P / angler
and
Nexus 5X / bullhead
encrypted out of the box?
Click to expand...
Click to collapse
Still can't test what I don't have.
russlowe73 said:
Factory images
Click to expand...
Click to collapse
So basically I have to go back to 100% stock using ADB, and then flash the new SuperSU stuff with any custom ROM? If so, what are the benefits of this other than getting Android Pay while rooted?
I'm not sure if anyone has specifically mentioned this, but Android Pay still works with this form of root on the Nexus 6!!
efrant said:
Starting with Android 5.0, OTA updates are now block-based rather than file-based, so any modification to the system partition will cause the OTA to fail, even mounting the system partition as r/w.
Click to expand...
Click to collapse
Just to add to this, it's a whole-partition /system patch OTA if the device launched with Lollipop or later, anything that launched with KitKat is still receiving the old file-based patch OTAs. Modifying Settings.apk would likely trip either method for a lot of OTAs though, since it's a pretty central component.
galaxyuserx said:
I use Galaxy s6 G9200 HK with Kernel compiled by me, but i have problem with root 5.1.1 and i think in future too 6.0
These root method is integrated in kernel source or i can integrate with those "boot.img systemless" my selfcompiled kernel?(repack boot.img with kernel compiled by me)
Is possible to work this new root method to android 5.1.1?
I have problem with gain root when i use kernel compiled by me ( STOCK kernel have too this problem BOOTLOOPs and FREEZEs on boot system) and i don't know how slove it :/
I found on chineese forums root integrated in boot.img it working good and isn't comunicat "KERNEL is not SEandroid enforced" but when i try integrate my kernel with this boot.img error with boot system :/
Click to expand...
Click to collapse
Yup, it's all ramdisk changes so should be workable on any version of Android. Chainfire left instructions outlining the ramdisk changes in the WIP thread if you want to give it a try.
phishfi said:
I'm not sure if anyone has specifically mentioned this, but Android Pay still works with this form of on the Nexus 6!!
Click to expand...
Click to collapse
Yup, seems to be the case with most banking and root-detecting apps... for now.
Can someone with the non-system SU use this app: https://play.google.com/store/apps/details?id=com.cigital.safetynetplayground and post the results?
This app is supposed to do the SafetyNet checks cleanly, the same way Android Pay does them.
Would be interesting to see if it succeeds on devices with this new supersu version.
secguy said:
Can someone with the non-system SU use this app: https://play.google.com/store/apps/details?id=com.cigital.safetynetplayground and post the results?
This app is supposed to do the SafetyNet checks cleanly, the same way Android Pay does them.
Would be interesting to see if it succeeds on devices with this new supersu version.
Click to expand...
Click to collapse
Just ran it and it passed.
Went ahead and installed su on a stock nexus 5, so far working well, android pay does not work but that was me being stupid and changing the host file and dpi before setting it up
I do notice a little input lag after this, not enough to even make me consider removing root, but it is noticeable, anybody else with this?
I have Fire 7 5th Gen that is rooted using SuperTool on FireOS 5.1.1. I disabled auto system updates. For some reason, Ads do not appear anymore. I tried rebooting and shutting down, but none of that helped. I have ADB setup and all, not sure what to do next.
Thanks in advance
seskanda said:
I have Fire 7 5th Gen that is rooted using SuperTool on FireOS 5.1.1. I disabled auto system updates. For some reason, Ads do not appear anymore. I tried rebooting and shutting down, but none of that helped. I have ADB setup and all, not sure what to do next.
Thanks in advance
Click to expand...
Click to collapse
Likely related to killing OTA updates. Reinstall FireOS 5.1.1 if you really want those ads.
Make double sure that it's the fireOS version that's at 5.1.1, not the generic Android one. They are easily confused, and may result in bricks. If in doubt, check the bootloader timestamp (inside the partition) - should be 20150923-180133 for your OS.
If you need to reinstall/re-root, precautions are in place. You decide whether getting ads is wirth risking root at all.
Davey126 said:
Likely related to killing OTA updates. Reinstall FireOS 5.1.1 if you really want those ads.
Click to expand...
Click to collapse
I see, but we also have an old Fire HD 7 2nd gen that is rooted and still shows ads. How can it have ads but this newer one does not? If I re-install FireOS 5.1.1, will it turn off OTA updates and/or remove root?
Where can I find the right version of FireOS 5.1.1? I do not want to lose root just for some ads.
seskanda said:
I see, but we also have an old Fire HD 7 2nd gen that is rooted and still shows ads. How can it have ads but this newer one does not? If I re-install FireOS 5.1.1, will it turn off OTA updates and/or remove root?
Where can I find the right version of FireOS 5.1.1? I do not want to lose root just for some ads.
Click to expand...
Click to collapse
The SuperTool disables a bunch of different stuff depending on FireOS build; the local ad server likely got caught up in that.
Reloading FireOS will remove root and enable OTA updates. With WiFi enabled the device would immediately be exposed to an wanted update to FireOS 5.6 which can not be rooted. You also need to be confident of the current FireOS version to avoid bricking the device; see previous post by @steve8x8.
In your shoes I'd leave things as-is. But if you really need to see those ads past FireOS builds can be found here.
Davey126 said:
The SuperTool disables a bunch of different stuff depending on FireOS build; the local ad server likely got caught up in that.
Reloading FireOS will remove root and enable OTA updates. With WiFi enabled the device would immediately be exposed to an wanted update to FireOS 5.6 which can not be rooted. You also need to be confident of the current FireOS version to avoid bricking the device; see previous post by @steve8x8.
In your shoes I'd leave things as-is. But if you really need to see those ads past FireOS builds can be found here.
Click to expand...
Click to collapse
I recall choosing the options to root and disable OTA updates, and that's all. I did not pick the one to turn off lock screen ads.
So if I root and then disable OTA updates, the ads will stop completely? What does OTA updates do with lock screen ads? If that is the case, there is really no need for me to re-install FireOS at this point. I think the FireOS builds from the link you gave are fine to use.
I do not see the benefit of ads if it breaks root or keeps OTA updates on.
seskanda said:
I recall choosing the options to root and disable OTA updates, and that's all. I did not pick the one to turn off lock screen ads.
So if I root and then disable OTA updates, the ads will stop completely? What does OTA updates do with lock screen ads? If that is the case, there is really no need for me to re-install FireOS at this point. I think the FireOS builds from the link you gave are fine to use.
I do not see the benefit of ads if it breaks root or keeps OTA updates on.
Click to expand...
Click to collapse
Never saw the benefit of ads. If you are happy with the status quo there is no need to take any action. Should you decide to reload FireOS:
- be 100% sure you have the correct build; using the 'wrong' version can have unfavorable outcomes
- you'll need to reroot and assume the risk of taking an unwanted OTA update during that process
- the SuperTool throws a lot of switches; some may do more than advertised, especially on older FireOS builds
- in most cases disabling OTA updates via the SuperTool does not block ads
- you'll need to take manual actions to block OTA updates and/or lock screen ads if you want more precise control
As the old saying goes "if it ain't broke don't fix it".
Davey126 said:
Never saw the benefit of ads. If you are happy with the status quo there is no need to take any action. Should you decide to reload FireOS:
- be 100% sure you have the correct build; using the 'wrong' version can have unfavorable outcomes
- you'll need to reroot and assume the risk of taking an unwanted OTA update during that process
- the SuperTool throws a lot of switches; some may do more than advertised, especially on older FireOS builds
- in most cases disabling OTA updates via the SuperTool does not block ads
- you'll need to take manual actions to block OTA updates and/or lock screen ads if you want more precise control
As the old saying goes "if it ain't broke don't fix it".
Click to expand...
Click to collapse
Actually the ads do suck overall I agree with you, just want to know why or how to fix it, that's all.
If I use the FireOS 5.1.1 in the link provided will that be the correct build for me?
If I disconnect WiFi, will that guarantee not being force-fed an OTA update?
Which version of SuperTool is the best or most stable one? Or that does not mess up lock screen ads when disabling OTA updates?
Do you know in which case will disabling OTA updates break lock screen ads?
What do you mean by this? Let's say I did disable lock screen ads via SuperTool by accident, is any way to undo that by chance?
seskanda said:
Actually the ads do suck overall I agree with you, just want to know why or how to fix it, that's all.
If I use the FireOS 5.1.1 in the link provided will that be the correct build for me?
If I disconnect WiFi, will that guarantee not being force-fed an OTA update?
Which version of SuperTool is the best or most stable one? Or that does not mess up lock screen ads when disabling OTA updates?
Do you know in which case will disabling OTA updates break lock screen ads?
What do you mean by this? Let's say I did disable lock screen ads via SuperTool by accident, is any way to undo that by chance?
Click to expand...
Click to collapse
Lots of questions that would take much back-and-forth to definitively answer. Many would love to be in your shoes. You have a rooted, working system with no ads or notable deficits. Enjoy your device.
Davey126 said:
Lots of questions that would take much back-and-forth to definitively answer. Many would love to be in your shoes. You have a rooted, working system with no ads or notable deficits. Enjoy your device.
Click to expand...
Click to collapse
Appreciate if you could answer the first question and any question about SuperTool. Or else, if someone can chime in that'd be fine also.
seskanda said:
Appreciate if you could answer the first question and any question about SuperTool.
Click to expand...
Click to collapse
You need to verify with 100% certainty which version of FireOS your device is currently running. Many confuse Android 5.1.1, which is the base for all FireOS v5 builds with a specific FireOS version number. The latter is all that matters and should be shown under Settings->System Updates (details).
Davey126 said:
You need to verify with 100% certainty which version of FireOS your device is currently running. Many confuse Android 5.1.1, which is the base for all FireOS v5 builds with a specific FireOS version number. The latter is all that matters and should be shown under Settings->System Updates (details).
Click to expand...
Click to collapse
I see, according to Settings-->System Updates it is FireOS 5.1.1. Does that mean the one linked here is the correct build for me?
seskanda said:
I see, according to Settings-->System Updates it is FireOS 5.1.1. Does that mean the one linked here is the correct build for me?
Click to expand...
Click to collapse
Correct. You are fortunate to be on what may view to be a 'preferred' build of FireOS. IMO the chance of taking an spontaneous OTA to an unrootable build outweighs whatever benefits might be realized given your device appears to be performing as expected sans lock screen ads. As an alternative you could simply perform a factory reset. However, the risks of an unwanted OTA sneaking in remains until the device is rerooted and updates blocked. Good luck with whatever course of action you choose.
Davey126 said:
Correct. You are fortunate to be on what may view to be a 'preferred' build of FireOS. IMO the chance of taking an spontaneous OTA to an unrootable build outweighs whatever benefits might be realized given your device appears to be performing as expected sans lock screen ads. As an alternative you could simply perform a factory reset. However, the risks of an unwanted OTA sneaking in remains until the device is rerooted and updates blocked. Good luck with whatever course of action you choose.
Click to expand...
Click to collapse
Yes, I was lucky that I rooted it quickly and disabled OTA updates at the same time. The Wifi was disconnected when I did both of that. I'm thinking If I do something similar it should end up as is now. With WiFi not connected, there is zero chance of OTA update, right? Will factory reset keep root? If not, then I might as well re-install the firmware for FireOS 5.1.1.
seskanda said:
With WiFi not connected, there is zero chance of OTA update, right? Will factory reset keep root?
Click to expand...
Click to collapse
- OTA updates are delivered via WiFi which typically must be enabled to root
- Root may or may not survive a factory reset
Davey126 said:
- OTA updates are delivered via WiFi which typically must be enabled to root
- Root may or may not survive a factory reset
Click to expand...
Click to collapse
It's been awhile since I rooted this, but do not recall needing WiFi to root, why would that be required?
Well, then I should definitely try a factory reset first before re-loading the firmware.
seskanda said:
It's been awhile since I rooted this, but do not recall needing WiFi to root, why would that be required?
Well, then I should definitely try a factory reset first before re-loading the firmware.
Click to expand...
Click to collapse
Unless using the desktop (tethered) varient KingRoot receives/retrieves 'instructions' from the cloud.
Davey126 said:
Unless using the desktop (tethered) varient KingRoot receives/retrieves 'instructions' from the cloud.
Click to expand...
Click to collapse
I use SuperTool, which is desktop (tethered) so do not internet to root. Do you know if SuperTool retains root after a factory reset?
Davey126 said:
Unless using the desktop (tethered) varient KingRoot receives/retrieves 'instructions' from the cloud.
Click to expand...
Click to collapse
I use SuperTool, which is desktop (tethered) so do not need internet to root. Do you know if SuperTool retains root after a factory reset?
seskanda said:
I use SuperTool, which is desktop (tethered) so do not need internet to root. Do you know if SuperTool retains root after a factory reset?
Click to expand...
Click to collapse
Last I knew the version of KingRoot included with the SuperTool is the standalone build which DOES need internet access. As for your second question the SuperTool has nothing to do with retaining root following a factory reset.