Dear all,
this is my first post in this forum and I have done lots of reading concerning the chromecast hack and recoveries. I recently bought a device with Bootoader version 12940 which means it is not hackable. I also do not have the means to open the device and add wires to the UART. But when browsing through the different flashing/updating and recovery threads an idea came into my mind on how the bootloader security could be omitted:
I got the following facts (please correct if wrong):
- The Marvell ROM code verifies the bootloader binarys signature before executing it ( see http://blog.gtvhacker.com/2013/google-tv-or-how-i-learned-to-stop-worrying-and-exploit-secure-boot/ )
=> This means that the vulnerable original bootloader version 12840 must have a valid signature
This is my assumption:
- When the system is powered on and the NAND flash is kept in reset the SoC should try to boot from an alternate source (e.g. uart or usb).
=> This might be a way to boot the properly signed vulnerable older bootloader
There seems to be some mechanism to boot from USB if the system does not find any firmware image ( http://forum.xda-developers.com/showthread.php?t=2438715)
Idea:
=> Has already someone plugged the chromecast via USB to an PC and powered it on with the NAND disabled? It would be interesting if the device identifies itself on the USB bus (the recent Freescale and TI controllers I know do exactly this) and awaits a (most probably signed) firmware image (which we already should have with the old bootloader) or if someone found the datasheets of this SoC it might be possible to alter the bootstrap pins of the SoC to get it booting from another source
Edit: Typo
I am thinking that if there is a weakness to exploit as far as rooting, it might be found in one of the Developer enabled units faster than one of the consumer devices....
Perhaps not as the Dev Mode may only remove the Whitelist but it's worth a shot...
I have noticed that the ROM Updates seem to have slowed down a bit since Xmas...
I bet most folks would be happy enough if we just found some way of bypassing the Whitelist if we can't get full root.
probutus said:
Dear all,
this is my first post in this forum and I have done lots of reading concerning the chromecast hack and recoveries. I recently bought a device with Bootoader version 12940 which means it is not hackable. I also do not have the means to open the device and add wires to the UART. But when browsing through the different flashing/updating and recovery threads an idea came into my mind on how the bootloader security could be omitted:
I got the following facts (please correct if wrong):
- The Marvell ROM code verifies the bootloader binarys signature before executing it ( see http://blog.gtvhacker.com/2013/google-tv-or-how-i-learned-to-stop-worrying-and-exploit-secure-boot/ )
=> This means that the vulnerable original bootloader version 12840 must have a valid signature
This is my assumption:
- When the system is powered on and the NAND flash is kept in reset the SoC should try to boot from an alternate source (e.g. uart or usb).
=> This might be a way to boot the properly signed vulnerable older bootloader
There seems to be some mechanism to boot from USB if the system does not find any firmware image ( http://forum.xda-developers.com/showthread.php?t=2438715)
Idea:
=> Has already someone plugged the chromecast via USB to an PC and powered it on with the NAND disabled? It would be interesting if the device identifies itself on the USB bus (the recent Freescale and TI controllers I know do exactly this) and awaits a (most probably signed) firmware image (which we already should have with the old bootloader) or if someone found the datasheets of this SoC it might be possible to alter the bootstrap pins of the SoC to get it booting from another source
Click to expand...
Click to collapse
Good idea. I can chainload these bootloaders if I could get a dump of the vulnerable one.
There are two ways of disabling the NAND. One is to bridge a jumper (34 if memory serves me right) and the other is to just pull the disable pin high.
jchillerup said:
Good idea. I can chainload these bootloaders if I could get a dump of the vulnerable one.
There are two ways of disabling the NAND. One is to bridge a jumper (34 if memory serves me right) and the other is to just pull the disable pin high.
Click to expand...
Click to collapse
I have a partition dump of the exploitable bootloader if it helps. (which is just the bootloader written 8x times in a row, because google logic) Shoot me a PM if you need anything.
A raw dump would be best. I am considering searching for a vulnerable untouched CC and seeing what I can do with it with some hardware hackery. First things first is finding out is the nand is encrypted with a per device key, or is certain sections are encrypted, or if it isn't encrypted at all.
ddggttff3 said:
I have a partition dump of the exploitable bootloader if it helps. (which is just the bootloader written 8x times in a row, because google logic) Shoot me a PM if you need anything.
Click to expand...
Click to collapse
That would be really helpful! I'd appreciate that. I'm in #[email protected] like you, we can discuss further there.
ddggttff3 said:
I have a partition dump of the exploitable bootloader if it helps. (which is just the bootloader written 8x times in a row, because google logic) Shoot me a PM if you need anything.
Click to expand...
Click to collapse
I would be interested aswell:
probutus<at>yahoo.de Thanks!
By the way: Has anyone found a datasheet of the Armada 1500-mini CPU? Marvell seems to be rather restrictive...
It could help to find out about potential CPU bootmode options and alternatives
probutus said:
By the way: Has anyone found a datasheet of the Armada 1500-mini CPU? Marvell seems to be rather restrictive...
It could help to find out about potential CPU bootmode options and alternatives
Click to expand...
Click to collapse
I dug around a while back while looking for spec-ed operating temperature but I couldn't find anything substantial.
Seems like you have to register with Marvell or have an existing relationship to get that level of documentation.
do u think the noot version can be rooted ?
hello im wondering before buying this key if there will be probably a root ability in the near future ? or at least a way to use my own local vidéo with a non rooted one?
thanks by advance
yoann54 said:
hello im wondering before buying this key if there will be probably a root ability in the near future ?
Click to expand...
Click to collapse
Nobody knows the future.
yoann54 said:
or at least a way to use my own local vidéo with a non rooted one?
Click to expand...
Click to collapse
Avia, RealPlayer cloud and Plex. This is covered in the sticky FAQ.
Sent from a device with no keyboard. Please forgive typos, they may not be my own.
yoann54 said:
hello im wondering before buying this key if there will be probably a root ability in the near future ? or at least a way to use my own local vidéo with a non rooted one?
thanks by advance
Click to expand...
Click to collapse
The Idea is that if we can put the Marvell-CPU into usb or serial bootmode we could boot the vulnerable but properly signed original bootloader to just "recycle" the exploit. For this, I would need the cpu documentation. Till now, I didnt find anything usable
probutus said:
The Idea is that if we can put the Marvell-CPU into usb or serial bootmode we could boot the vulnerable but properly signed original bootloader to just "recycle" the exploit. For this, I would need the cpu documentation. Till now, I didnt find anything usable
Click to expand...
Click to collapse
Thanks for ur answers.....just a last question : this method here : http://gtvhacker.com/index.php/Google_Chromecast is it only for non updated chromecast devices ?
yoann54 said:
Thanks for ur answers.....just a last question : this method here : http://gtvhacker.com/index.php/Google_Chromecast is it only for non updated chromecast devices ?
Click to expand...
Click to collapse
Yes, that only works with the original (build 12072) vulnerable bootloader.
FlashCast uses the same vulnerability.
bhiga said:
Yes, that only works with the original (build 12072) vulnerable bootloader.
FlashCast uses the same vulnerability.
Click to expand...
Click to collapse
I'm starting to wonder if it isn't possible to trick the CCast by creating a fake Google services and tricking it into loading the original vulnerable version by telling it to load it as an OTA...
I suppose the biggest hurdle is finding a file of the vulnerable version that is OTA installable since the Original was never an OTAed version to begin with.
Asphyx said:
I'm starting to wonder if it isn't possible to trick the CCast by creating a fake Google services and tricking it into loading the original vulnerable version by telling it to load it as an OTA...
I suppose the biggest hurdle is finding a file of the vulnerable version that is OTA installable since the Original was never an OTAed version to begin with.
Click to expand...
Click to collapse
Google is one step ahead. Every OTA checks against the build.prop file build date (which is stored in the kernels initramfs) so you can't use old official OTA's to downgrade
ddggttff3 said:
Google is one step ahead. Every OTA checks against the build.prop file build date (which is stored in the kernels initramfs) so you can't use old official OTA's to downgrade
Click to expand...
Click to collapse
Yeah makes sense they would do some sort of version checking.
Related
I see it mentioned a few times but what on the phone prevents say 4.4.2 from being installed after the upgrade to 4.4.3?
Because the partion table and bootloader are different and can't be downgraded at all.
Or, you can downgrade... But brick your device after, even later.
Anyone who knows anything about the moto x will tell you just don't. ?
I find that odd. I wonder what the purpose is for doing that.
There is no way to just re-write those sections? Even on a Dev Edition?
knitler said:
I find that odd. I wonder what the purpose is for doing that.
There is no way to just re-write those sections? Even on a Dev Edition?
Click to expand...
Click to collapse
Security!
Look at the whole Windows/AntiVirus industry.
All because Microsoft wanted unsecure compatibility with the old OS.
Saving software dev time making things work.
knitler said:
I find that odd. I wonder what the purpose is for doing that.
There is no way to just re-write those sections? Even on a Dev Edition?
Click to expand...
Click to collapse
No, the Dev edition is no different. All the same "rules" apply.
The Dev edition is the same as any other.... It just keeps is warranty if you unlock it.
aviwdoowks said:
Security!
Look at the whole Windows/AntiVirus industry.
All because Microsoft wanted unsecure compatibility with the old OS.
Saving software dev time making things work.
Click to expand...
Click to collapse
I'm kind of not buying this for a second?
How about linux, which is often pointed to for its security... And you can upgrade, down grade, switch out every component for newer/older/different, switch kernels, upgrade kernels, downgrade kernels... hell change out kernels with out even rebooting.
Really not buying it has anything with security.
KJ said:
Or, you can downgrade... But brick your device after, even later.
Anyone who knows anything about the moto x will tell you just don't. ?
Click to expand...
Click to collapse
I think we understand that, I mean if the OP didn't he wouldn't have the question of "why not?". Its not I think it might be a good idea... We are just trying to understand the situation because it seems unique, and so we were hoping someone who knows a lot about
AGISCI said:
Because the partion table and bootloader are different and can't be downgraded at all.
Click to expand...
Click to collapse
This is the most I have heard so far, and I have heard it once or twice... But can't the recovery image include information on the partition table?
I realize the way it is, but was curious on some more technical information explaining it...
scryan said:
I'm kind of not buying this for a second?
How about linux, which is often pointed to for its security... And you can upgrade, down grade, switch out every component for newer/older/different, switch kernels, upgrade kernels, downgrade kernels... hell change out kernels with out even rebooting.
Really not buying it has anything with security.
I think we understand that, I mean if the OP didn't he wouldn't have the question of "why not?". Its not I think it might be a good idea... We are just trying to understand the situation because it seems unique, and so we were hoping someone who knows a lot about
This is the most I have heard so far, and I have heard it once or twice... But can't the recovery image include information on the partition table?
I realize the way it is, but was curious on some more technical information explaining it...
Click to expand...
Click to collapse
It is security. Specifically the SECURED BOOTLOADER. Don't confuse secured with locked. Yes, you can unlock your bootloader, but it is still secured.
Read up on "TrustZone" and see why it is important, and why the OEMs would not want you to be able to downgrade. You can "buy" or "not buy" whatever you want....
I really don't get the linux reference. We are talking about a bootloader, not linux in general. That's beyond the fact that any smart linux user would almost never have any reason at all to downgrade. Think about the heartbleed vuln that was discovered recently. Why on god's green earth would you want to downgrade openssl back to a version that is vulnerable??
The early (4.2.2 & 4.4) bootloader (motoboot.img) was vulnerable to an exploit that allowed us to disable write protection. The updated bootloader (4.4.2+) is patched. You *CAN NOT* downgrade back to the vulnerable version.
^Does that not have *everything* to do with security??
scryan said:
I'm kind of not buying this for a second?
How about linux, which is often pointed to for its security... And you can upgrade, down grade, switch out every component for newer/older/different, switch kernels, upgrade kernels, downgrade kernels... hell change out kernels with out even rebooting.
Really not buying it has anything with security.
I think we understand that, I mean if the OP didn't he wouldn't have the question of "why not?". Its not I think it might be a good idea... We are just trying to understand the situation because it seems unique, and so we were hoping someone who knows a lot about
This is the most I have heard so far, and I have heard it once or twice... But can't the recovery image include information on the partition table?
I realize the way it is, but was curious on some more technical information explaining it...
Click to expand...
Click to collapse
Because even though the patition file and bootloader are included in the archive, they fail to flash because they have a lower version than what is installed.
AGISCI said:
Because even though the patition file and bootloader are included in the archive, they fail to flash because they have a lower version than what is installed.
Click to expand...
Click to collapse
Can't just fake the version number?
No, it's not possible.
samwathegreat said:
I really don't get the linux reference. We are talking about a bootloader, not linux in general. That's beyond the fact that any smart linux user would almost never have any reason at all to downgrade. Think about the heartbleed vuln that was discovered recently. Why on god's green earth would you want to downgrade openssl back to a version that is vulnerable??
Click to expand...
Click to collapse
The linux reference was in direct reply to the quote above it that was making the argument that the PC anti-virus industry as well as the proliferation of malware and viruses is an example of the insecurity that is a result of a computers administrator having the technical ability to downgrade his OS software.
I mention linux because he was using PC OS's as an example, and Linux allows you not only to downgrade... but rewrite the bootloader. Or use a different bootloader. You bootloader can boot securely with UEFI, or you can just use BIOS. All this insecurity, but virtually no viruses, and very few security issues.
Why would you want to downgrade openssl? I wouldn't. I probably wouldn't flash back to an earlier version of android either... I keep my system pretty damn up to date. The point is more that his assertion that MS and Windows proves that being able to downgrade creates inherent security issues doesn't really hold up when you look at other systems that provide even more freedom.
samwathegreat said:
You can "buy" or "not buy" whatever you want....
Click to expand...
Click to collapse
I know, and that is why I want to understand what it is I would be buying.
AGISCI said:
Because even though the patition file and bootloader are included in the archive, they fail to flash because they have a lower version than what is installed.
Click to expand...
Click to collapse
I guess this is the part that we are not understanding. Perhaps because I don't understand enough and have not looked through decompressed recovery images enough... but basically the issue is that Motorola is bricking the device, rather then letting it be downgraded to an potentially insecure image. I am guessing then this is a soft brick?
Does recovery not have the ability to re-write the partition table though? Is there no partition table information in this recovery image? I get that the stock recovery would not allow it, but wouldn't a developer edition user be able to flash a custom recovery that wouldn't have issues flashing the partition table. Don't TWRP or CWM, ect do this?
I guess then that is where the trust zone comes in...
scryan said:
The linux reference was in direct reply to the quote above it that was making the argument that the PC anti-virus industry as well as the proliferation of malware and viruses is an example of the insecurity that is a result of a computers administrator having the technical ability to downgrade his OS software.
I mention linux because he was using PC OS's as an example, and Linux allows you not only to downgrade... but rewrite the bootloader. Or use a different bootloader. You bootloader can boot securely with UEFI, or you can just use BIOS. All this insecurity, but virtually no viruses, and very few security issues.
Why would you want to downgrade openssl? I wouldn't. I probably wouldn't flash back to an earlier version of android either... I keep my system pretty damn up to date. The point is more that his assertion that MS and Windows proves that being able to downgrade creates inherent security issues doesn't really hold up when you look at other systems that provide even more freedom.
I know, and that is why I want to understand what it is I would be buying.
I guess this is the part that we are not understanding. Perhaps because I don't understand enough and have not looked through decompressed recovery images enough... but basically the issue is that Motorola is bricking the device, rather then letting it be downgraded to an potentially insecure image. I am guessing then this is a soft brick?
Does recovery not have the ability to re-write the partition table though? Is there no partition table information in this recovery image? I get that the stock recovery would not allow it, but wouldn't a developer edition user be able to flash a custom recovery that wouldn't have issues flashing the partition table. Don't TWRP or CWM, ect do this?
I guess then that is where the trust zone comes in...
Click to expand...
Click to collapse
The custom recoveries don't flash gpt.bin nor motoboot.img so using a custom recovery it's impossible to correctly flash a Moto X. You MUST use stock recovery with a Moto X. The problem isn't that it causes a brick by flashing an old version. The problem is that a brick happens the next time you do an OTA update. When the OTA update occurs there is a mismatched partion table and bootloader, so it ends up causing a brick.
The developer edition and the standard moto x are 100% identical. They only difference is that you don't void the warranty when you unlock the bootloader on the dev edition, however with the non dev edition your warranty is voided. So the same problem with the partition table and the bootloader ALSO apply to the developer edition as well.
AGISCI said:
The custom recoveries don't flash gpt.bin nor motoboot.img so using a custom recovery it's impossible to correctly flash a Moto X. You MUST use stock recovery with a Moto X. The problem isn't that it causes a brick by flashing an old version. The problem is that a brick happens the next time you do an OTA update. When the OTA update occurs there is a mismatched partion table and bootloader, so it ends up causing a brick.
The developer edition and the standard moto x are 100% identical. They only difference is that you don't void the warranty when you unlock the bootloader on the dev edition, however with the non dev edition your warranty is voided. So the same problem with the partition table and the bootloader ALSO apply to the developer edition as well.
Click to expand...
Click to collapse
Well said :good:
Still the answer is security.
So upgrade as Moto intended & do not downgrade!
---------- Post added at 07:37 PM ---------- Previous post was at 07:30 PM ----------
scryan said:
Is there no partition table information in this recovery image? I get that the stock recovery would not allow it, but wouldn't a developer edition user be able to flash a custom recovery that wouldn't have issues flashing the partition table. Don't TWRP or CWM, ect do this?
Click to expand...
Click to collapse
Our recovery devs never restore such partitions or boot loader elements.
scryan said:
The linux reference was in direct reply to the quote above it that was making the argument that the PC anti-virus industry as well as the proliferation of malware and viruses is an example of the insecurity that is a result of a computers administrator having the technical ability to downgrade his OS software.
I mention linux because he was using PC OS's as an example, and Linux allows you not only to downgrade... but rewrite the bootloader. Or use a different bootloader. You bootloader can boot securely with UEFI, or you can just use BIOS. All this insecurity, but virtually no viruses, and very few security issues.
Why would you want to downgrade openssl? I wouldn't. I probably wouldn't flash back to an earlier version of android either... I keep my system pretty damn up to date. The point is more that his assertion that MS and Windows proves that being able to downgrade creates inherent security issues doesn't really hold up when you look at other systems that provide even more freedom.
I know, and that is why I want to understand what it is I would be buying.
I guess this is the part that we are not understanding. Perhaps because I don't understand enough and have not looked through decompressed recovery images enough... but basically the issue is that Motorola is bricking the device, rather then letting it be downgraded to an potentially insecure image. I am guessing then this is a soft brick?
Does recovery not have the ability to re-write the partition table though? Is there no partition table information in this recovery image? I get that the stock recovery would not allow it, but wouldn't a developer edition user be able to flash a custom recovery that wouldn't have issues flashing the partition table. Don't TWRP or CWM, ect do this?
I guess then that is where the trust zone comes in...
Click to expand...
Click to collapse
Smh I normally don't chime into these threads but I had to, you can't downgrade the bootloader because of security/compatibility plan and simple. It's the same concept as why you can't downgrade most PC's bios, if there is a flaw found in the system as a whole, then they don't want you to downgrade to that version. A lot of the times when people brick their device trying to downgrade is because it will flash, but because an efuse was blown when it was upgraded the downgraded version will not boot. Yes the recovery can technically rewrite those partitions but again because the efuse was blown it will not boot. Also yes being able to downgrade on any system Windows, Linux, Unix, IOS, Xbox, PS, etc are causes to security issues. If you can downgrade a system to a vulnerable version, it is then by definition less secure, no matter how you try to spin it. Take the futex vulnerability which affected most linux kernels from the past 5 years, so why would any desktop linux user ever want to downgrade to a vulnerable kernel? They wouldn't but if the end user isn't knowledgeable of the vulnerability they wouldn't know that downgrading makes them vulnerable. So since phones are used by so many people who are not knowledgeable of vulnerabilities, why would you want to give them the opportunity to downgrade themselves to a vulnerable OS?
Appreciate the info given... I don't want to downgrade, I am not trying to downgrade, I understand why its a bad idea, ect...
My view point was more questioning the insistence that it being technically possible to downgrade creates a security flaw on a machine that is kept up to date by a responsible individual. Unless we are trying to speak more abstractly about that fact that given someone the opportunity to make a mistake makes it more likely for one to occur, I don't think that security threat exists until you actually use that ability to downgrade to something with a flaw.
I guess then it comes down to personal viewpoint of do I want my phone to brick it self to protect me from myself and like sam said, you choose to go elsewhere... But then that is somewhat what I am trying to figure out. Even though its not something I would probably ever have to deal with, I don't like the idea... But "bricking" can be such a vague term with manufacturer specific recovery tools and "different levels of bricking".
Just trying to understand how what and when actually happens. I probably need to read some more of the recovery threads, and I have been looking through old threads here while considering VZ dev moto X and waiting for the x + 1 announcement, but I figured I would jump on the thread while it was here.
I understand keeping it simple because its generally a bad idea all around, and its just best not to confuse things... but its been hard to find deeper discussion or information then the general warnings. A bit of a better picture from this thread though.
aviwdoowks said:
Still the answer is security.
So upgrade as Moto intended & do not downgrade!
---------- Post added at 07:37 PM ---------- Previous post was at 07:30 PM ----------
Our recovery devs never restore such partitions or boot loader elements.
Click to expand...
Click to collapse
By "Our recovery devs" do you mean the ones doing the moto specific stuff? Do you know if this Is typical of the custom recoveries for other devices?
@scryan
I know far less then other posters, but yes android recoveries are all very similar in that regard.
scryan said:
Appreciate the info given... I don't want to downgrade, I am not trying to downgrade, I understand why its a bad idea, ect...
My view point was more questioning the insistence that it being technically possible to downgrade creates a security flaw on a machine that is kept up to date by a responsible individual. Unless we are trying to speak more abstractly about that fact that given someone the opportunity to make a mistake makes it more likely for one to occur, I don't think that security threat exists until you actually use that ability to downgrade to something with a flaw.
I guess then it comes down to personal viewpoint of do I want my phone to brick it self to protect me from myself and like sam said, you choose to go elsewhere... But then that is somewhat what I am trying to figure out. Even though its not something I would probably ever have to deal with, I don't like the idea... But "bricking" can be such a vague term with manufacturer specific recovery tools and "different levels of bricking".
Just trying to understand how what and when actually happens. I probably need to read some more of the recovery threads, and I have been looking through old threads here while considering VZ dev moto X and waiting for the x + 1 announcement, but I figured I would jump on the thread while it was here.
I understand keeping it simple because its generally a bad idea all around, and its just best not to confuse things... but its been hard to find deeper discussion or information then the general warnings. A bit of a better picture from this thread though.
Click to expand...
Click to collapse
The thing is you keep looking at it from a PC point of view, where you basically have full control over the software and hardware. Phones have much tighter restrictions on them from carriers, fcc, etc they're not personal computers. So the reason they make it where you can't downgrade the bootloader is because that's what controls the restriction on downgrading any other partition on the device.
So with the Moto X's 4.4.4 update they probably blew an efuse, so users with a locked device can't downgrade. This is done because with locked devices they can only flash signed kernels, so by blowing the efuse they can't downgrade to the vulnerable 4.4.2 and below kernel even though it is signed correctly. This is because lets say a malicious app was able to get on a device that had the ability to downgrade say back to 4.2.2. That app could flash the older vulnerable signed kernel to the recovery partition, to disable write protection gain more control over the phone etc, without the users knowledge. Now that is a stretch and probably will never happen but that doesn't mean the threat isn't there, and hackers are very creative at deploying malicious attacks. So by updating the bootloader and blowing an efuse the older vulnerable kernels can't be flashed. Now this is all negated if you're unlocked of course, but if you don't want to ever worry about this issue don't update your bootloader. This is not recommended but I've mentioned it several times on this forum I haven't updated my X's bootloader since I bought it, it's still running the factory 4.2.2 bootloader, running 4.4.4 with no problem.
The other thing you're missing is we're technically not supposed to have the ability to restore our phones, except for the developer edition of course. The fastboot restore files are leaked not released to the public, they are designed for use when phones are returned to be refurbished. So they don't want the phones that are being refurbished to be flashed back to an older version, they want it to be refurbished and the latest software version flashed to it.
iKrYpToNiTe said:
The other thing you're missing is we're technically not supposed to have the ability to restore our phones, except for the developer edition of course. The fastboot restore files are leaked not released to the public, they are designed for use when phones are returned to be refurbished. So they don't want the phones that are being refurbished to be flashed back to an older version, they want it to be refurbished and the latest software version flashed to it.
Click to expand...
Click to collapse
A bit selfish, and perhaps lazy of me but I am only really here talking about the developer version, I just haven't bothered to write the full "verizon developer edition " every time (most of this is research for next phone, which will be developer handset)... To me, obviously a locked phone is going to have weird restrictions and hacked together paths to getting things done, your not supposed to have admin rights...(yeah, maybe I do look at it too much as a computer. Mostly because I am annoyed the differences seem intentionally imposed). But when I pay outright for a device so that I can own it and have full administrative control... anyways, thats a different more philosophical discussion. The point is I have been talking about an unlocked device using third party software where possible.
Either way, appreciate the reply. I have a better understanding of the issue... Though coming from an S4 it still seems weird that MDK*/developer phones don't seem to have the same issues/warnings. It would seem however that the difference may be that MDK/dev owners only use kernels/roms prepared for their devices and do not update the bootloader. I suppose if more people in the Moto X community were worried about maintaining the ability to downgrade an unlocked device it would be technically possible to upgrade in a way that could be easily reversed, similar to the S4.
(*MDK was the first VZ S4 firmware, and the only one that has a released exploit to allow for a full custom recover. Later locked firmwares must rely on safestrap)
Hello XDA,
I just purchased a new Acer Iconia One 8 B1-850 and was wondering if I could root it.
I see many posts on B1-810 and similar, but nothing for the B1-850.
CoreyGamingTV said:
Hello XDA,
I just purchased a new Acer Iconia One 8 B1-850 and was wondering if I could root it.
I see many posts on B1-810 and similar, but nothing for the B1-850.
Click to expand...
Click to collapse
same here
i want to root to enable the multi user option by updating the build.prop file, i've been able to connect with ADB but the device isn't visible in windows or mac (tried both) when you reboot into boot loader, in fact it doesn't appear to boot into boot loader it just seems to power off (when using ADB reboot command or choosing boot loader from the recovery menu) so i wonder if its locked out somehow??
Need it too. Did anyone find a way to root B1-850?
Thanks!
dtalas said:
Need it too. Did anyone find a way to root B1-850?
Thanks!
Click to expand...
Click to collapse
I too just purchased a B1-850 tablet, but I've figured out how to root it. Really quite simple. Just use Kingroot:
1.) Navigate to https://kingroot.net/ from your tablet
2.) Download the APK for android
3.) Install said APK (this requires you to have allowed installation from unkown sources in the "Security" panel of the settings menu)
4.) Load up the app and follow its instructions
5.) Reboot and try it out
For good measure, I would also unlock the "Developer Options" panel and allow USB debugging (adb access) and such; I did this before proceeding. You'll have to search for instructions on that yourself, its well documented.
This all worked for me this morning! Really looking forward to unlocking the potential of this cheapy tablet.
Kingroot worked first try, just swap their super user program with supersu. I am having trouble installing the xposed framework though if anyone has any tips.
I was able to root, now I need to install a custom recovery. CWM says this model is not in the supported list. Has anyone been able to install a recovery? I need NANDROID backup functionality.
I made a thread walking you through how to do it on this tablet in the guides area but just use flash fire for recovery and xposed install
Did the B1-850 hardware updated in anyway? I was able to root it in June 2016, but after a screen repair and factory reset and fresh rom from acer, king root and all others can't work. I'm stuck without any root options. Any idea?
Same here
Dylfaus said:
Did the B1-850 hardware updated in anyway? I was able to root it in June 2016, but after a screen repair and factory reset and fresh rom from acer, king root and all others can't work. I'm stuck without any root options. Any idea?
Click to expand...
Click to collapse
There was recently new firmware released for this tablet (08/24/16, Build #: AV0L0.RV09RC04.WW.GEN1), and a handful of updates (08/25/16, 08/26/16) from Acer. I have this same tablet, and I'm unable to root after flashing to the firmware released on the 24th, and latest firmware (Build #: AV0L0.RV0BRC02.WW.GEN1) as well. Hopefully someone can find a fix, as the few different methods I've attempted simply will not work with the latest firmware from Acer.
On KingRoot Please click submit search if enough people do they will find a root until then just hold tight.
jared407 said:
On KingRoot Please click submit search if enough people do they will find a root until then just hold tight.
Click to expand...
Click to collapse
I have done this a bunch, sadly still no love. It's annoying me not being able to root a relatively cheaper tablet, as these tend to get rooted first since they get in more people's hands faster. Oh well, just have to have patience.
Thanks, I was having problems, two different rooters failed and I wondered if it was the recent software update! The image version on my B1-850 is the same as you have quoted! Please post if you find a solution, some apps that need deleting are annoying.
---------- Post added at 06:23 PM ---------- Previous post was at 06:13 PM ----------
random4t4x14 said:
There was recently new firmware released for this tablet (08/24/16, Build #: AV0L0.RV09RC04.WW.GEN1), and a handful of updates (08/25/16, 08/26/16) from Acer. I have this same tablet, and I'm unable to root after flashing to the firmware released on the 24th, and latest firmware (Build #: AV0L0.RV0BRC02.WW.GEN1) as well. Hopefully someone can find a fix, as the few different methods I've attempted simply will not work with the latest firmware from Acer.
Click to expand...
Click to collapse
I was having a problem rooting my device and wondered if it was the recent software update, and my image version is as you have quoted! I f you manage to root your device please post!
knockout350 said:
I made a thread walking you through how to do it on this tablet in the guides area but just use flash fire for recovery and xposed install
Click to expand...
Click to collapse
Which recovery do you install with flash fire; I don't see a link to it in your other thread?
Success!
The latest release of KingRoot is able to root the latest firmware for this tablet. I saw there was a new release of KingRoot back on the 23rd, and it's working as it should. I grabbed the working version here -> http://forum.xda-developers.com/devdb/project/dl/?id=21707
hi guys. any idea how to recover b1-850 from bootloop?
I no its a little late but i rooted mine with the kingoroot one click root apk. Ive installed xposed framework and customized like crazy everything from fonts to boot animation. Cant find a custom recovery tho.
I cannot root it with any of the tools I have tried (Kingo ROOT, KingRoot, etc). Anyone know any method that works?
Acer B1-850. Is this device even rootable?
This device has made an idiot of me. If I can be of any assistance finding a root exploit for this device let me know. I will gladly write a detailed procedure of the process. I made the mistake of assuming since it was an entry level, inexpensive device, the path to root would be simple. Three months later none of the common "one-click" programs has found an exploit. I have a copy of stock rom for recovery so testing is not a problem for me. It's a matter of pride at this point. So much so I found one on sale for $60 and bought it just for this purpose. I have followed every link I can find associated with this device to a dead end. Any help will be appreciated.
pdnorman said:
This device has made an idiot of me. If I can be of any assistance finding a root exploit for this device let me know. I will gladly write a detailed procedure of the process. I made the mistake of assuming since it was an entry level, inexpensive device, the path to root would be simple. Three months later none of the common "one-click" programs has found an exploit. I have a copy of stock rom for recovery so testing is not a problem for me. It's a matter of pride at this point. So much so I found one on sale for $60 and bought it just for this purpose. I have followed every link I can find associated with this device to a dead end. Any help will be appreciated.
Click to expand...
Click to collapse
Same here, still no root for me. Usually these cheapo tablets are not as locked down.
Still waiting!?
I have given up getting assistance from xda on this device. Its as political here as anywhere else. I don't drive a Samsung so nobody wants to help with root. I've heard every excuse from locked bootloader (unlockable in dev options) to what one dev actually told me,"There's little interest in spending energy on an inexpensive device." I understand, but why misrepresent the site by implying all android devices are treated the same? Hell on the Iconia One 8 thread, it says that the B1-850 does not have a MTK SoC, but instead has an Intel Atom chip. Then they send you to another thread where, of course, there is no B1-850 listed! That's because it uses a MTK8163 SoC. In both tablets.
As most of you know already from my other postings, I have a Verizon Xperia Z4V.
I have the dreaded bootloader unlock allowed = no at the moment (even though I have a Sony Dev. fastboot unlock code from their web tool)so am looking for a method to root the phone so I can extract the cdma radio and uhd screen drivers and use various other kernel sources to compile new ROM's
I have fastboot, and adb access.
So far, NOTHING has worked. Flashtool has come closest with the service menu exploit, however I cannot re-create what it did the first time.
The device is using 5.0.2 with kernel version : 3.10.49-perf-g301bca8-01952-g67d95bb / Platform : 64bits / Build number : 28.0.E.0.570
I know the device is NOT directly supported by any scripts, but it seems to me something should work from a similar device. After all, the only differences are the cdma radio and the screen resolution.
Any ideas?
Rick
BlackIce
https://www.xda-developers.com/root/
Choose your poison
That page is very useful. But as I mentioned the Z4V isn't listed at all.
Rick
BlackIce
Aha! Even though I am not abig fan of KingRoot, I managed to get version 5.3.0 to root the Z4V. Sort Of.
Sort Of? Well, I have Flashtool running on my PC and all drivers working. KingRoot runs and achieves root. Flashtool then recognizes root and pushes files and deactivates RIC. Then I get a crash or reboot on the phone, when it returns, root is gone.
Any ideas how to get it done?
RIck
BlackIce000
If i can get root for 15 seconds is there anyway i can flash a recovery or defeat RIC so I can keep it and begin to work on this phone??
Thanks,
Rick
blackice000 said:
If i can get root for 15 seconds is there anyway i can flash a recovery or defeat RIC so I can keep it and begin to work on this phone??
Thanks,
Rick
Click to expand...
Click to collapse
15 or 30 seconds is a bit short in time ...
Prophylaxis is key first (not breaking anything): create a backup of the kernel image/partition
https://android.stackexchange.com/q...img-and-recovery-img-from-sony-xperia-e4-dual (that example is with a MediaTek chipset so mostly different still a good starting point though)
you need to find out which partitions contain what data and create a dump / dd image as a backup of boot.img
https://github.com/lygstate/lygstat...10-Extract-boot.img-from-an-android-device.md
https://stackoverflow.com/questions/26967862/how-to-make-an-image-of-android-partition-to-your-pc
blackice000 said:
As most of you know already from my other postings, I have a Verizon Xperia Z4V.
I have the dreaded bootloader unlock allowed = no at the moment (even though I have a Sony Dev. fastboot unlock code from their web tool)so am looking for a method to root the phone so I can extract the cdma radio and uhd screen drivers and use various other kernel sources to compile new ROM's
I have fastboot, and adb access.
So far, NOTHING has worked. Flashtool has come closest with the service menu exploit, however I cannot re-create what it did the first time.
The device is using 5.0.2 with kernel version : 3.10.49-perf-g301bca8-01952-g67d95bb / Platform : 64bits / Build number : 28.0.E.0.570
I know the device is NOT directly supported by any scripts, but it seems to me something should work from a similar device. After all, the only differences are the cdma radio and the screen resolution.
Any ideas?
Rick
BlackIce
Click to expand...
Click to collapse
Just a small thing you may forgot, USB debugging mode to be on (for non carrier specific Z4) and you can use Flashtool for unlocking bootloader.
Before unlocking bootloader, take backup of DRM keys and important data.
New info. I can get root with Kingroot...I can manipulate using Flashtool. RIC is deactivated...after a short while phone reboots.
Any ideas?!! I'd really like to be able to use this phone.
Flashtool LOGFILE Attached
Rick
I'm about to get an XZ1 Compact and I'm interested in exploring its files. I understand Windows, but Android's terminology is new to me. I'm unsure whether I understand correctly how Android works. Is this right?:
(1) When turned on, a small OS (the "bootloader") powers on, and its objects call
(2) objects in the "recovery partition," which in turn
(3) call the files and objects in the main partition which power the actual Android OS.
To change files in the main partition ("flashing ROM") either the new files' API's must match those in the previous OS or else files in the recovery partition also need to change ("be customized"). Similarly, changing the recovery partition requires either the same API calls from the bootloader or else changing the bootloader ("unlocking" it).
Is all that right? Does this mean doing something like installing TWRP (from the command line on my desktop, where I already have Android Studio and the Android SDK tools) means I have to "unlock" the bootloader too? [Is there a suggested web site or reference, besides this forum, with good info to teach me what I need to know to understand bootloaders, recovery partitions, custom ROMs, etc.?}
Thanks!
Al C.
acolburn3 said:
Is all that right? Does this mean doing something like installing TWRP (from the command line on my desktop, where I already have Android Studio and the Android SDK tools) means I have to "unlock" the bootloader too? [Is there a suggested web site or reference, besides this forum, with good info to teach me what I need to know to understand bootloaders, recovery partitions, custom ROMs, etc.?}
Thanks!
Al C.
Click to expand...
Click to collapse
Hi AI C,
What you described is basically how it works, although the bootloader decides what partition to load the operating system from. The recovery is located in the recovery partition and the bootloader can start it up the same way as an operating system and it allows users control over certain aspects of the phone such as wiping partitions and modifying the currently installed Android.
Here is a site that describes some of the terms:
https://trendblog.net/guide-to-android-rooting-custom-roms-apps/
In order to modify your Android operating system and flash a custom ROM you need to unlock the bootloader as the locked bootloader will only boot your stock firmware (Android OS) that came with your phone.
---------- Post added at 05:28 PM ---------- Previous post was at 05:22 PM ----------
The XZ1 compact is not the easiest device to learn these things with as Sony has locked certain parts of the OS using DRM (digital rights management) which requires a couple extra steps when unlocking the bootloader. Without these DRM keys the camera does not work.
Additionally not all XZ1 compacts bootloader's can be unlocked.
Check this PDF for instructions to unlocking the bootloader and backing up DRM keys:
https://forum.xda-developers.com/xp...-exploits-temp-root-to-backup-t3795510/page39
If you have any specific questions I'm happy to help.
Your explanation makes perfect sense, and those look like really useful links. Thank you for taking the time to respond so thoughtfully. I'd read about the camera issues. Although some folks describe solutions (XperiFix?), I don't think I need Android 10 enough to want to risk flashing it yet. In the meantime, do installing a different recovery (TWRP?) or rooting the device require unlocking the bootloader, too?
p.s. If the answers to those questions are in the links you gave me, I'm perfectly OK being told "go read them!"
acolburn3 said:
Your explanation makes perfect sense, and those look like really useful links. Thank you for taking the time to respond so thoughtfully. I'd read about the camera issues. Although some folks describe solutions (XperiFix?), I don't think I need Android 10 enough to want to risk flashing it yet. In the meantime, do installing a different recovery (TWRP?) or rooting the device require unlocking the bootloader, too?
p.s. If the answers to those questions are in the links you gave me, I'm perfectly OK being told "go read them!"
Click to expand...
Click to collapse
The short answer is yes. You need to unlock the bootloader in order to root and install a custom recovery.
The long answer is that there is a workaround using the Temp-Root solution provided by J4nn: https://forum.xda-developers.com/xp...devonly-exploits-temp-root-to-backup-t3795510
that is used to root the phone temporarily so that the DRM keys can be backed up. When you use the magisk version version of the exploit that is linked in the first post you have root access until you reboot the phone.
If you want to get root back you need to connect it to your computer using ADB (android debugging bridge) and send the commands again. Additionally it only works with a few certain android oreo based stock firmwares.
So it is not exactly a workable solution.
I have not heard of XperiFix before. The thread I linked by J4nn and the previous PDF I mentioned is the way that I bootloader unlocked my device and made sure I still have a working camera, although other methods might exist.
I'm glad I could help.
Hey there,
So I need to know all the necessary steps to properly install Andronix and Termux (F-Droid) by unlocking the bootloader. Do you know where I can find all the information about that for Galaxy s10?
Depends on WHICH S10 you have. Snapdragon CPU versions cannot really be unlocked. Exynos can. This forum is full of threads on how to do the Exynos, of course... I have a Snapdragon so I haven't spent much time learning it...
Ok thanks I have a snapdragon also so I guess I will do something else
I hear you - I have Snapdragon too, so I gave up ROM and rooting on this phone. Honestly, I don't miss it. I used to ROM and root all my previous phones, but I don't see the need to do that anymore.
I want to ssh my network from my phone using a vpn to access my router so I can wake on lan my server
You should be able to do that without root from the phone - ssh doesn't require root to run, and it's just a secure terminal. You can get an app to do that (I see plenty on the play store). As for VPN, again, you don't need root on the phone to do that - I have used OVPN many times from my phone without issue (and without root).
schwinn8 said:
You should be able to do that without root from the phone - ssh doesn't require root to run, and it's just a secure terminal. You can get an app to do that (I see plenty on the play store). As for VPN, again, you don't need root on the phone to do that - I have used OVPN many times from my phone without issue (and without root).
Click to expand...
Click to collapse
Ok thanks
Why is everybody so convinced that rooting will only be possible with an unlocked bootloader? if there were to be a kernel exploit which would gain us access to the block devices i would say it's possible to downgrade the bootloader or anything which is accessible by block devices like the recovery partition. Am i missing something here?
DaanNL said:
Why is everybody so convinced that rooting will only be possible with an unlocked bootloader? if there were to be a kernel exploit which would gain us access to the block devices i would say it's possible to downgrade the bootloader or anything which is accessible by block devices like the recovery partition. Am i missing something here?
Click to expand...
Click to collapse
If you have a solution to root a galaxy s10 snapdragon cpu I will read your comments on it. But I think I believe that is because of the articles in the internet are only mentioning that I need to unlock the bootloader.
Indirectelex said:
If you have a solution to root a galaxy s10 snapdragon cpu I will read your comments on it. But I think I believe that is because of the articles in the internet are only mentioning that I need to unlock the bootloader.
Click to expand...
Click to collapse
Yes, everybody is so convinced that you need to unlock the bootloader and i wonder why.... we don't need odin to flash, afaik as we can find a kernel exploit which would gain us root access we could set properties to enable the oem unlock option.... making it available and usable could be a different case..... some requirements need to be met. If we could access block devices we should be able to install magisk and root the device.
Indirectelex said:
If you have a solution to root a galaxy s10 snapdragon cpu I will read your comments on it. But I think I believe that is because of the articles in the internet are only mentioning that I need to unlock the bootloader.
Click to expand...
Click to collapse
I think i'm getting somewhere, don't know for sure... at first i was only able to flash CSC and now i'm able to flash every slot.... do you have the same results in odin?
DaanNL said:
I think i'm getting somewhere, don't know for sure... at first i was only able to flash CSC and now i'm able to flash every slot.... do you have the same results in odin?
Click to expand...
Click to collapse
I cant do tests on my galaxy s10 but I will on a Moto z2
we are so ****ed with the cellphones
Yeah, I need one too! I got a Galaxy S10 Plus Snapdragon. It's it's been 2 years since I have it and I can't find nobody that can teach me how to root it!!!
Because it cannot be rooted. US carriers have made that happen, and the manufacturers have had to keep doing it.
Many have tried, and on older BLs it can be done, but once you update you are stuck on a newer BL and cannot downgrade. If you root with the older BL, you cannot upgrade the BL either, because that will relock it.
If someone comes up with a way to do it, I'm all ears, as are many others... but with higher level crypto being implemented for this protection (ie, you need to know the crypto key!), it likely won't happen.
I have an idea but i don't know if it's possible, i tried but it seems corepatch isn't working.
I see a lot of topics about what's needed to unlock the bootloader, but if i look in the source code what is required to unlock the bootloader there's a lot of ro. properties which we can't set because we are not root.
As LSPatch can now communicate with Shizuku and gain system level access we might be able to disable system app verification (platform certificate, by extending CorePatch or maybe someone can write a signature verification disabler for lsposed). Then create an app which doesn't check for all these properties and initiates an OEM unlock and install it as system user./