WHy does downgrading not work?

Search This thread
D

Darth

Guest
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)
You need to realize though... As far as the Moto X goes, they made it no different what so ever than any other unlockable moto X. The only benefit it has over the other devices that can be unlocked, is you keep your warranty. But all the same restrictions apply.

I agree, doesn't make the name Developer Edition seem to mean much.

The X is by far no Nexus.... Or even as friendly to flash with than a lot of other devices. But it is what it is. And I expect future Motorola devices will be no different.

Not a typical XDA members dream device, that's for sure.
 

scryan

Senior Member
Oct 19, 2013
780
687
You need to realize though... As far as the Moto X goes, they made it no different what so ever than any other unlockable moto X. The only benefit it has over the other devices that can be unlocked, is you keep your warranty. But all the same restrictions apply.

I agree, doesn't make the name Developer Edition seem to mean much.

The X is by far no Nexus.... Or even as friendly to flash with than a lot of other devices. But it is what it is. And I expect future Motorola devices will be no different.

Not a typical XDA members dream device, that's for sure.

The VZ S4 Dev edition was a normal S4 with an unlocked BL(which I can't even find for sale new anymore?), didn't even get updates and if you used a regular OTA it would lock the phone irreversibly... So Moto X dev seems ahead in those reguards :D

Nexus I think would be a no brainer, but with all my complaints I haven't been able to find a carrier that can take me away from Verizon and they won't let me have one.
 
D

Darth

Guest
The VZ S4 Dev edition was a normal S4 with an unlocked BL(which I can't even find for sale new anymore?), didn't even get updates and if you used a regular OTA it would lock the phone irreversibly... So Moto X dev seems ahead in those reguards :D

Nexus I think would be a no brainer, but with all my complaints I haven't been able to find a carrier that can take me away from Verizon and they won't let me have one.
Yeah, Verizon doesn't like nexus or development in general it seems.

I'm not knocking the X though... It's just not a tinkerers ideal device. Little development support, no downgrading... Etc.

It's a great device anyway, even unrooted. But without all the moto features... Not a lot of interest in aosp /cm roms. Stock based roms or just gravity box are nice though.
 
Last edited:

iKrYpToNiTe

Senior Member
Sep 16, 2012
364
680
Sanford, NC
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)


Have you actually read the previous posts that other members have posted? The developer edition or in full as you say the "verizon developer edition" has the exact same software on it as a retail Verizon XT1060 that can be bought in the store has on them. There is no difference what so ever, all the extra money people spend on the dev edition is literally to put their phone's serial/imei number on the whitelist of Moto's bootloader unlock code generator! Every single Moto X is unlockable, but Moto has all of the retail Verizon and AT&T models on a blacklist, so that their website will not generate the bootloader unlock code for them. I have a retail Verizon XT1060, but thanks to the china middle man my X is now unlocked. So my previous post still stands, when they release software their main target group is locked users not unlocked users unfortunately.

Since you are looking at it from a computer point of view, then let me explain it this way. A computers bios is similar to a bootloader on a phone in a sense, and for the most part bios's are released only by the manufacturer and normally can't be downgraded once upgraded. So yes I understand your point that paying for a dev edition should give you full administrative rights but unfortunately it's a phone not a PC.

The OP asked why can't they downgrade, that normally means they're talking about a locked device. Now if the OP is unlocked then I don't see the point of this thread, because they can downgrade everything except the bootloader just fine. Once the bootloader is unlocked they can flash any kernel, baseband, or ROM they want they just can't downgrade the bootloader which doesn't matter when you're unlocked anyway. As sam posted in post #8 it's the secured bootloader don't confuse secure with locked or unlocked. If you want a more technical explanation of why you can't downgrade. Look up efuses and the part they play in bootloaders, cpus, xbox 360s, etc when it comes to downgrading. Also look over this pdf http://theroot.ninja/PAE.pdf it goes over android security and the boot sequence of most Android devices.
 
  • Like
Reactions: samwathegreat

scryan

Senior Member
Oct 19, 2013
780
687
Have you actually read the previous posts that other members have posted?

YUP.
The OP asked why can't they downgrade, that normally means they're talking about a locked device.
Wait... Did YOU actually read the previous posts that other members posted? Because the OP ACTUALLY asked:
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?
And TWO POSTS LATER EXPLICITLY ASKED
Even on a Dev Edition?
Nothing about boot loaders even. Simply about installing 4.4.2 after upgrading to 4.4.3, EVEN ON A DEV EDITION?
He also has the signature:
T-Mobile
7 2013 - moto x Developer Edition
Previous: HTC One X+, Nexus 4, LG G2, Nexus 7 2012, Nexus 5

The OP never even asked about bootloaders, just "installing 4.4.2" and it takes three pages of me pulling teeth for one of you to finally say :
Now if the OP is unlocked then I don't see the point of this thread, because they can downgrade everything except the bootloader just fine. Once the bootloader is unlocked they can flash any kernel, baseband, or ROM they want they just can't downgrade the bootloader which doesn't matter when you're unlocked anyway.
Sorry me or the OP are not as smart as you. I'll leave now.
 

KidJoe

Inactive Recognized Contributor
Aug 23, 2008
3,211
1,561
Thorndale/Romansville, PA
PMJI,

Many who have never had Moto android phones in the past often confuse "unlocking the boot loader" with the "ability to do anything I want to the phone."

On HTC android phones when you obtain S-OFF while unlocking the boot loader you can in fact downgrade. You can flash all parts. But that is due to S-OFF, or turning security checks off, not unlocking the boot loader.

mDK on the S4 was mentioned. There a vulnerability was exploited (Loki I think) to allow you to reach a unlocked boot loader state. What other features did that exploit allow? Maybe it gave an s-off type state? I do know that once your phone was upgraded past MDK, you couldn't downgrade to use the exploit.

Point is, on the Moto X, developer edition, or other unlocked boot loader variant, the security features on the phone (which stay in place even when unlocking the boot loader) prevent downgrading GPT.BIN and MOTOBOOT.IMG when they change. ( except for the rare case of 4.4 to 4.2.2 w/camera update, for whatever reason, downgrading wasn't an issue)

We have seen soft bricks and/or features not work, when using mfastboot to downgrade only parts (skipping gpt.bin and MOTOBOOT.img), and we've seen many bricks when trying to upgrade via OTA when there are mismatched versions on a phone (gpt from one rom, with system.img of another, etc).

We've seen issues upgrading when using a full SBF/FXZ if mismatched versions are on the phone.... I.e. The need to use mfastboot to flash gpt and MOTOBOOT, reboot to bootloader followed by immediately flashing the entire rom, starting with gpt and MOTOBOOT .

The security checks on all variants of the Moto X get in the way and cause issues.
 
  • Like
Reactions: scryan

AGISCI

Senior Member
Apr 21, 2013
1,257
616
Concepción
www.cromer.cl
PMJI,

Many who have never had Moto android phones in the past often confuse "unlocking the boot loader" with the "ability to do anything I want to the phone."

On HTC android phones when you obtain S-OFF while unlocking the boot loader you can in fact downgrade. You can flash all parts. But that is due to S-OFF, or turning security checks off, not unlocking the boot loader.

mDK on the S4 was mentioned. There a vulnerability was exploited (Loki I think) to allow you to reach a unlocked boot loader state. What other features did that exploit allow? Maybe it gave an s-off type state? I do know that once your phone was upgraded past MDK, you couldn't downgrade to use the exploit.

Point is, on the Moto X, developer edition, or other unlocked boot loader variant, the security features on the phone (which stay in place even when unlocking the boot loader) prevent downgrading GPT.BIN and MOTOBOOT.IMG when they change. ( except for the rare case of 4.4 to 4.2.2 w/camera update, for whatever reason, downgrading wasn't an issue)

We have seen soft bricks and/or features not work, when using mfastboot to downgrade only parts (skipping gpt.bin and MOTOBOOT.img), and we've seen many bricks when trying to upgrade via OTA when there are mismatched versions on a phone (gpt from one rom, with system.img of another, etc).

We've seen issues upgrading when using a full SBF/FXZ if mismatched versions are on the phone.... I.e. The need to use mfastboot to flash gpt and MOTOBOOT, reboot to bootloader followed by immediately flashing the entire rom, starting with gpt and MOTOBOOT .

The security checks on all variants of the Moto X get in the way and cause issues.
The reason that the pre cam to pre cam did not fail was because the partition table and bootloader did not change between the two versions so, there was no problems. However they did change post cam.

Sent from my XT1058 using Tapatalk
 

KidJoe

Inactive Recognized Contributor
Aug 23, 2008
3,211
1,561
Thorndale/Romansville, PA
The reason that the pre cam to pre cam did not fail was because the partition table and bootloader did not change between the two versions so, there was no problems. However they did change post cam.

Sent from my XT1058 using Tapatalk
Thanks, I understand that, but other contents in motoboot.img did change... so I didn't want to get into specifics.
 

Top Liked Posts

  • There are no posts matching your filters.
  • 3
    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...

    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.
    3
    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...

    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?
    1
    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?
    1
    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...
    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.
    1
    @scryan

    I know far less then other posters, but yes android recoveries are all very similar in that regard.