Related
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.
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)
I'm using Moto XT1060 and on 4.4.4. I want to flash custom ROM, is there any ways to do this? Because i saw that must be on 4.2.2 to use safestrap recovery, and downgrade would be brick ? So anyway for me to go on ?
Once you are on 4.4.4 downgrading will result in a brick! The bootloader can NOT be downgraded.
Travisdroidx2 said:
Once you are on 4.4.4 downgrading will result in a brick! The bootloader can NOT be downgraded.
Click to expand...
Click to collapse
Bad news !
Yup, anything after and including 4.4.2 will brick if downgraded. This even goes for my Dev edition
Have you looked into the China middleman? He seems to be becoming somewhat less reliable but you may be able to get an unlock code which would allow you to flash unlocked versions of ROMs rather than being limited to safestrap versions. Either that or wait to see if sunshine gets updated to work on 4.4.4.
To answer your question directly. Do NOT downgrade. While there is SOME conflicting info here, the overwhelming consensus is that downgrading will result in a brick either now or during a future upgrade.
cntryby429 said:
Have you looked into the China middleman? He seems to be becoming somewhat less reliable but you may be able to get an unlock code which would allow you to flash unlocked versions of ROMs rather than being limited to safestrap versions. Either that or wait to see if sunshine gets updated to work on 4.4.4.
To answer your question directly. Do NOT downgrade. While there is SOME conflicting info here, the overwhelming consensus is that downgrading will result in a brick either now or during a future upgrade.
Click to expand...
Click to collapse
Curious what the conflicting information is?
cntryby429 said:
To answer your question directly. Do NOT downgrade. While there is SOME conflicting info here, the overwhelming consensus is that downgrading will result in a brick either now or during a future upgrade.
Click to expand...
Click to collapse
Travisdroidx2 said:
Curious what the conflicting information is?
Click to expand...
Click to collapse
The conflicting information is due to a few things...
1. It usually revolve around not explaining that due to security and other issues, GPT.BIN and MOTOBOOT.IMG can't be downgraded properly. And this causes a wide variety of issues.
2. We've had some who downgrades, doesn't brick then declares it "SAFE" for all... without taking into consideration what happens when future OTA gets installed (which is brick).
3. We've seen some try to be "fancy" and use mfastboot to downgrade everything but GPT.BIN and MOTOBOOT.IMG, the phone reboots and may generally work, so its declared "safe"... but doesn't explain there have been issues (like when on 4.4.2 and flashing down to 4.4 this way, go to Settings -> Security kicks you out)... and also doesn't take into consideration what happens when parts of the phone are miss-matched when a future OTA is taken and gets installed (bricks or on occasion user gets lucky and it just fails to install instead)... and this also poses a challange returning to a 100% consistent state.
4. We've seen those who don't explain that trying to downgrade with RSDLite will likely fail or will immediately brick your phone (which has happened). Or at least convey some kind of warning.
and more..
In most/all of these cases, the person who "tested it" and says "Its safe" fails to explain the risks and fails to state there are MANY threads and Posts of users who HAVE BRICKED while trying to downgrading, or at some point after downgrading, etc.
So, rather than seeing a ton of caveats, conditions, etc you'll just see most of give the "DO NOT DOWNGRADE!!" warnings.
I have read all of those "safe" way to downgrade that eventually leads to a brick. That is why I tell people do not downgrade even though I know it is the gpt.bin and bootloader security that can not be downgraded. I was just curious if that was the conflicting information or if it was me telling him that you will brick if downgrading was the conflicting information.
Travisdroidx2 said:
I have read all of those "safe" way to downgrade that eventually leads to a brick. That is why I tell people do not downgrade even though I know it is the gpt.bin and bootloader security that can not be downgraded. I was just curious if that was the conflicting information or if it was me telling him that you will brick if downgrading was the conflicting information.
Click to expand...
Click to collapse
Sorry if that wasn't clear. By "here" I meant that conflicting info can be found here in the Moto X xda forum, not in your post. Now that these people have recklessly posted stuff trying to say that you can downgrade, I think it's worth acknowledging that the misinformation exists rather than just saying "you can't, period." That way the casual reader doesn't see one of those posts and think he's about to get away with something that other (read, capable & most knowledgeable) folks have said "just can't be done." That's all. No confrontation intended unless you count those yahoos trying to say it's safe.
cntryby429 said:
Sorry if that wasn't clear. By "here" I meant that conflicting info can be found here in the Moto X xda forum, not in your post. Now that these people have recklessly posted stuff trying to say that you can downgrade, I think it's worth acknowledging that the misinformation exists rather than just saying "you can't, period." That way the casual reader doesn't see one of those posts and think he's about to get away with something that other (read, capable & most knowledgeable) folks have said "just can't be done." Today's all. No confrontation intended unless you count those yahoos trying to say it's safe.
Click to expand...
Click to collapse
Thanks for the response! I see your point. It is a good one to point out because we still see people ending up with a brick because they followed what someone told them was safe. Or they just don't read the warnings first.
I'll try to sum this up...
No, you can't downgrade. Unless you have money sitting in your pocket for a new device... Which more times than not is what you'll need to do.
2 new downgrade brick threads today.
Still wanna try? ?
Hi,
I am absolutely new to this, please redirect me or correct me where i am wrong.
I need to recover deleted photos and videos from the interal memory, I have installed "DiskDigger" to perform that task however my device is not "rooted".
I am anxious not to permenantly removed the data that i could possibly recover. (if at all possible)
I have seen a couple of threads on how to flash the phones, but nothing corresponding to my exact config. (Kitkat 4.4.4 build 14.4.A.0.157)
Could somebody indicate the process i should follow?
thanks
cabrolse said:
Hi,
I am absolutely new to this, please redirect me or correct me where i am wrong.
I need to recover deleted photos and videos from the interal memory, I have installed "DiskDigger" to perform that task however my device is not "rooted".
I am anxious not to permenantly removed the data that i could possibly recover. (if at all possible)
I have seen a couple of threads on how to flash the phones, but nothing corresponding to my exact config. (Kitkat 4.4.4 build 14.4.A.0.157)
Could somebody indicate the process i should follow?
thanks
Click to expand...
Click to collapse
Check this post for info on rooting your phone.
http://forum.xda-developers.com/xperia-z1/help/guide-downgrade-root-dualrecovery-c6916-t3062919
Use this site to get your specific firmware instead of Z1s c6916
http://storagecow.eu/index.php?dir=Xda%2FSony%2FXperia+Z1%2FC6903%2F
cabrolse said:
Hi,
I am absolutely new to this, please redirect me or correct me where i am wrong.
I need to recover deleted photos and videos from the interal memory, I have installed "DiskDigger" to perform that task however my device is not "rooted".
I am anxious not to permenantly removed the data that i could possibly recover. (if at all possible)
I have seen a couple of threads on how to flash the phones, but nothing corresponding to my exact config. (Kitkat 4.4.4 build 14.4.A.0.157)
Could somebody indicate the process i should follow?
thanks
Click to expand...
Click to collapse
I know this isn't exactly answering your question, but mine was on the same build and I searched high and low. The only methods I found for kitkat weren't working, but I believe they were for 4.4.2, not 4.4.4.
I ended up downgrading to Jellybean and rooting it that way. Sticking with Jellybean too, kitkat can kiss my rear, lol
SonyXperiaz1s said:
I know this isn't exactly answering your question, but mine was on the same build and I searched high and low. The only methods I found for kitkat weren't working, but I believe they were for 4.4.2, not 4.4.4.
I ended up downgrading to Jellybean and rooting it that way. Sticking with Jellybean too, kitkat can kiss my rear, lol
Click to expand...
Click to collapse
Thank you for the feedback.
Can you or somebody else confirm if by downgrading and rooted , will i still be able to recover deleted files within the DCIM folder ?
cabrolse said:
Thank you for the feedback.
Can you or somebody else confirm if by downgrading and rooted , will i still be able to recover deleted files within the DCIM folder ?
Click to expand...
Click to collapse
that depends completely on the folders location and software used to recover them. if on your external then should be good. if on internal then might get writen over during flashing process. remember that the information is not deleted...just marked with a deleted flag...meaning that the OS thinks its empty space and can use that space to write new information. it would be all luck sorry to say.
cabrolse said:
Hi,
I am absolutely new to this, please redirect me or correct me where i am wrong.
I need to recover deleted photos and videos from the interal memory, I have installed "DiskDigger" to perform that task however my device is not "rooted".
I am anxious not to permenantly removed the data that i could possibly recover. (if at all possible)
I have seen a couple of threads on how to flash the phones, but nothing corresponding to my exact config. (Kitkat 4.4.4 build 14.4.A.0.157)
Could somebody indicate the process i should follow?
thanks
Click to expand...
Click to collapse
Hi Bro,
Try this method which i used myself. this does not required any downgrade or re-flash or data loss. You just need .157 running already with your device.
I upgraded from 5.1.1 to 6.0 by flashing the factory image without flashing userdata. Everything worked perfectly, but, as many people have noted, I get a "Your device is corrupt" message briefly on startup, before having the opportunity to enter my encryption code. Again, the phone functions just fine despite this.
I'm wondering what it is about my phone that causes this message to display. My bootloader is unlocked, though I don't think this alone should be a problem. I am completely stock, unrooted (though I was rooted on previous versions). As such, I don't think it can be a problem with the system or boot partitions, since, again, I have flashed and re-flashed these directly from the factory image. I don't see how it can be problem with userdata, since this isn't even decrypted when I get the "corrupt" message (i.e., I haven't entered the encryption code yet). Perhaps it's some problem with how userdata is encrypted?
Any logs that might give insight into where the fault is occurring?
Verity is the cause. That post should answer your question.
cupfulloflol said:
Verity is the cause. That post should answer your question.
Click to expand...
Click to collapse
Thanks for the link. I'm still not sure this explains my situation. I get a red "corrupt" warning telling me my device is actually corrupt, which should mean that system files have been modified. However, my system is unmodified; I know this because I have flashed it directly (multiple times).
Although it is extremely unlikely and might be a unique situation, Verity might have actually worked for what it was designed for, for once, and your system might actually be corrupted by either persistent malware or bad memory.
I would warranty return the phone, if possible.
Sent from my VS985 4G using Tapatalk
Wipe data factory reset from stock recovery.
trent999 said:
Although it is extremely unlikely and might be a unique situation, Verity might have actually worked for what it was designed for, for once, and your system might actually be corrupted by either persistent malware or bad memory.
I would warranty return the phone, if possible.
Sent from my VS985 4G using Tapatalk
Click to expand...
Click to collapse
droidstyle said:
Wipe data factory reset from stock recovery.
Click to expand...
Click to collapse
Thanks. I'm not looking really looking for a radical solution (wiping phone, returning it); I'm looking for an explanation (which might guide me to a less radical solution). Again, I wonder whether Verity makes a log somewhere. As I mentioned, my phone is working perfectly.
Hard to imagine it's persistent malware, since I've flashed every partition other than userdata (which is still encrypted when I get the "corrupt" message). Moreover, I'm by no means the first person to report this behavior.
NYZack said:
Thanks. I'm not looking really looking for a radical solution (wiping phone, returning it); I'm looking for an explanation (which might guide me to a less radical solution). Again, I wonder whether Verity makes a log somewhere. As I mentioned, my phone is working perfectly.
Hard to imagine it's persistent malware, since I've flashed every partition other than userdata (which is still encrypted when I get the "corrupt" message). Moreover, I'm by no means the first person to report this behavior.
Click to expand...
Click to collapse
it will appear when you boot up on marshmallow, when you have an unlocked bootloader.
simms22 said:
it will appear when you boot up on marshmallow, when you have an unlocked bootloader.
Click to expand...
Click to collapse
I didn't notice mine until I installed a custom recovery. Hrm..maybe I just didn't pay attention lol
Tower1972 said:
I didn't notice mine until I installed a custom recovery. Hrm..maybe I just didn't pay attention lol
Click to expand...
Click to collapse
i didnt get it either. but i flashed a custom kernel as well, which gets rid of that message.
simms22 said:
it will appear when you boot up on marshmallow, when you have an unlocked bootloader.
Click to expand...
Click to collapse
I'm unlocked, stock and get no such message(s). Expecting it when I install a recovery though
Larzzzz82 said:
I'm unlocked, stock and get no such message(s). Expecting it when I install a recovery though
Click to expand...
Click to collapse
So I can't figure out what the true story is. Some people say that it happens to everybody with an unlocked bootloader, but, according to what you say, this isn't the case. I am stock in every way - recovery, bootloader, boot image, system image - and yet I get this warning. It's not a big deal, but it eats at me and makes me wonder whether there really is something corrupt about some aspect of my system.
NYZack said:
So I can't figure out what the true story is. Some people say that it happens to everybody with an unlocked bootloader, but, according to what you say, this isn't the case. I am stock in every way - recovery, bootloader, boot image, system image - and yet I get this warning. It's not a big deal, but it eats at me and makes me wonder whether there really is something corrupt about some aspect of my system.
Click to expand...
Click to collapse
It has to be changes to recovery. I'm running stock 6.0 with an unlocked bootloader and root and I have no such message on startup. Rooted and unlocked through Wugfresh NexusTool and temporary modified recovery option (non-persistent).
dasDestruktion said:
It has to be changes to recovery. I'm running stock 6.0 with an unlocked bootloader and root and I have no such message on startup. Rooted and unlocked through Wugfresh NexusTool and temporary modified recovery option (non-persistent).
Click to expand...
Click to collapse
No, if you're rooted, it's a different story. The modified boot image installed when you root disables verity checking.
I got the message after rooting my phone with CFRoot. Have done that before, always worked. But now the phone stops working after that boot message, I have reinstalled the stock image.
simms22 said:
it will appear when you boot up on marshmallow, when you have an unlocked bootloader.
Click to expand...
Click to collapse
I can confirm that this is not true. I ultimately factory-reset my phone from Recovery (it was acting strangely in other ways - Contacts crashing, for instance). My bootloader remains unlocked, but I no longer get the "Corrupt" message on startup.
I'm unlocked on marshmallow also and have never had that message
Take a look at here, it was my experience and solution.
https://productforums.google.com/forum/m/#!topic/nexus/sTu8Bdc1GLA;context-place=topicsearchin/nexus/category$3Adevice-security
Sent from my Nexus 6 using XDA Free mobile app
Semseddin said:
Take a look at here, it was my experience and solution.
https://productforums.google.com/forum/m/#!topic/nexus/sTu8Bdc1GLA;context-place=topicsearchin/nexus/category$3Adevice-security
Sent from my Nexus 6 using XDA Free mobile app
Click to expand...
Click to collapse
A simple factory reset in Recovery was all I needed. But I was hoping for a solution that didn't involve wiping my phone, ... and some insight into why so many of us are getting this message with stock systems.
NYZack said:
A simple factory reset in Recovery was all I needed. But I was hoping for a solution that didn't involve wiping my phone, ... and some insight into why so many of us are getting this message with stock systems.
Click to expand...
Click to collapse
Glad you could fix yours with a simple factory reset. Mine was in a much worse situation where i immediately got the corrupted message once i entered gmail account into phone. Google reps couldnt find the answer to the issue but advised me to downgrade to previous os and take OTA to marshmallow, that definitly fixed the issue for me.
Sent from my Nexus 6 using XDA Free mobile app
Device verification on Android and Nexus can be a bit of an interesting subject.
In theory, dm-verity on a Nexus will ONLY validate the system image, and nothing else.
This is the key description that Google made regarding verified boot;
http://source.android.com/devices/tech/security/verifiedboot/verified-boot.html
The key takeaways from that are;
1) an enforcing secure boot chain will involve validating each of the bootloader/boot partitions from the previous level, up to and including the boot.img.
2) The boot image contains the linux kernel and the verity_key file.
3) The verity_key file is the public key used to validate the contents of the metadata partition, which stores the hash tree for the system partition and is used to validate the contents of the system partition *on the fly*.
4) When dm-verity detects a change, it causes an I/O error.
5) On Nexus devices, the validation of the boot partition can be disabled.
The part that is interesting, is figure 2.
The part where it verifies metadata signature files --> no, causes it to reboot in logging mode and gives you the big ugly warning page.
Note that an unlocked Nexus 6 does NOT implement the yellow or orange warning states in its default configuration - see the description of "Class A". I'm not entirely sure if they can be enabled or not, but I've heard chatter of something to the effect of fastboot oem verify, which might enable validation of the boot partition.
So what happens during a dm-verity?
Well, when init tries to mount the system partition using dm-verity, it fails signature check. When it fails signature check, it sets a boot flag that it failed signature check, and *reboots*. The bootloader picks up this boot flag, and loads the error. If dm-verity PASSES signature check, it just continued boot as normal -- no rebooting.
So the approach for getting rid of that error message is actually this; if you tell init not to apply dm-verity, then the signature check is never even applied, so it continues boot as normal.
What isn't clear, is how it could be even remotely possible for a corrupt boot or cache partition to trigger a bootloader error. The only thing I can imagine, is maybe there is some additional check that isn't documented, or a bug in the bootloader that gets triggered when some boot flag is set wrong.