Consolidated GApps Central

Following the retirement of Paranoid Android GApps Provider TKruzze and subsequent deletion of … more

Samsung Galaxy S4 I9505 Receives CyanogenMod 12.1

Released in 2013, the Samsung Galaxy S4 I9505 is the quad-core Snapdragon … more

Sunday Debate: Corporate Cyanogen Good for Android?

Join us in a fun Sunday Debate on Cyanogen Inc. Come with your opinions and feel … more

AOSP Lollipop 5.1.0 for LG Optimus 4X HD

One of the main rivals of the legendary Samsung Galaxy SIII, the LG Optimus 4X HD has received … more
Post Reply Subscribe to Thread Email Thread

Manually Rollback - Downloaded from their site.

22nd January 2015, 02:40 AM   |  #1  
OP Junior Member
Thanks Meter: 6
 
21 posts
Join Date:Joined: Jul 2014
Information already known. Deleted to keep people from trying.
Last edited by Eclipsys; 22nd January 2015 at 03:29 AM.
The Following User Says Thank You to Eclipsys For This Useful Post: [ View ]
22nd January 2015, 03:17 AM   |  #2  
EncryptedCurse's Avatar
Senior Member
Thanks Meter: 129
 
334 posts
Join Date:Joined: Jul 2014
More
These direct download links are definitely nothing new...
The problem is that the system has a "forward lock." One of the requirements that Amazon uses for verifying this file is that the firmware is a higher version than the current.
22nd January 2015, 03:23 AM   |  #3  
r3pwn's Avatar
Recognized Developer / Recognized Contributor
Flag Naples
Thanks Meter: 1,688
 
1,571 posts
Join Date:Joined: Jul 2012
Donate to Me
More
Quote:
Originally Posted by EncryptedCurse

These direct download links are definitely nothing new...
The problem is that the system has a "forward lock." One of the requirements that Amazon uses for verifying this file is that the firmware is a higher version than the current.

This is correct. Amazon uses an "anti-rollback protection" system to keep people from rolling back to previous firmware versions by blowing specific qfuses during the upgrade process. Downgrading will result in a permanent brick.
22nd January 2015, 03:28 AM   |  #4  
OP Junior Member
Thanks Meter: 6
 
21 posts
Join Date:Joined: Jul 2014
Quote:
Originally Posted by r3pwn

This is correct. Amazon uses an "anti-rollback protection" system to keep people from rolling back to previous firmware versions by blowing specific qfuses during the upgrade process. Downgrading will result in a permanent brick.

Aww, a definite disappointment. I'll update the first post to show this. I hadn't read this in any other posts, sorry for the false hope. Thanks for confirming this before I tried it.
22nd January 2015, 11:01 AM   |  #5  
Member
Thanks Meter: 76
 
68 posts
Join Date:Joined: Sep 2011
Quote:
Originally Posted by r3pwn

This is correct. Amazon uses an "anti-rollback protection" system to keep people from rolling back to previous firmware versions by blowing specific qfuses during the upgrade process. Downgrading will result in a permanent brick.

You can actually downgrade the device, but it will get bricked as anti-downgrading is also implemented on the bootloader level.
22nd January 2015, 11:47 AM   |  #6  
r3pwn's Avatar
Recognized Developer / Recognized Contributor
Flag Naples
Thanks Meter: 1,688
 
1,571 posts
Join Date:Joined: Jul 2012
Donate to Me
More
Quote:
Originally Posted by p1gl3t

You can actually downgrade the device, but it will get bricked as anti-downgrading is also implemented on the bootloader level.

Yes. I stated that. Did you read my post fully?
22nd January 2015, 06:24 PM   |  #7  
Member
Thanks Meter: 76
 
68 posts
Join Date:Joined: Sep 2011
Quote:
Originally Posted by r3pwn

Yes. I stated that. Did you read my post fully?

I must admit to not having read the last sentence. I'm sorry.
I wanted to stress out that you can actually start a downgrade even from 4.5.x. We could exploit this if there isn't any signature verification on the ota archive after the device reboots into recovery.
Do you have any idea who should I ask for a recovery bin dump? Or maybe someone already knows if the signature check is only done in android, before rebooting.
22nd January 2015, 06:28 PM   |  #8  
r3pwn's Avatar
Recognized Developer / Recognized Contributor
Flag Naples
Thanks Meter: 1,688
 
1,571 posts
Join Date:Joined: Jul 2012
Donate to Me
More
Quote:
Originally Posted by p1gl3t

I must admit to not having read the last sentence. I'm sorry.
I wanted to stress out that you can actually start a downgrade even from 4.5.x. We could exploit this if there isn't any signature verification on the ota archive after the device reboots into recovery.
Do you have any idea who should I ask for a recovery bin dump? Or maybe someone already knows if the signature check is only done in android, before rebooting.

It's okay. I know a downgrade from 4.5.X is possible, but people would then need to intercept the traffic by sniffing for a link through logcat. Only then, they could mass-distribute the rollback file from Amazon and hope that the bootloader exploit has not been fixed.
The Following User Says Thank You to r3pwn For This Useful Post: [ View ]
22nd January 2015, 08:11 PM   |  #9  
Member
Thanks Meter: 76
 
68 posts
Join Date:Joined: Sep 2011
Quote:
Originally Posted by r3pwn

It's okay. I know a downgrade from 4.5.X is possible, but people would then need to intercept the traffic by sniffing for a link through logcat. Only then, they could mass-distribute the rollback file from Amazon and hope that the bootloader exploit has not been fixed.

I don't think logcat would provide any usable info. I have suggested multiple times and even provided a pretty complete guide for sniffing the actual http traffic.
But I wasn't speaking of the downgrade that amazon provides. I was referring to a experiment that I did to bypass the version check that is enforced at the Android (before rebooting). I managed to flash a 3.2.6 image, but I got a brick as the sbl1 from 3.2.6 has a lower version number. I can bet that the 3.2.7 ota that Amazon provides for downgrade actually has both the build number and the sbl version number higher than the public 4.2.x.

If the recovery doesn't check the signature of the OTA we could do the following:
- provide a bogus image with a higher build number so that it passes the version check
- swap the checker binary from the ota with one that swaps the ota with a valid (signed one) so that it will pass the signature check
- while the android framework is verifying the valid ota swap it again by adb with a crafted ota that has the latest bootloader and kernel so that it can boot
- after the signature check passes the device would reboot and start flashing the crafted ota

If someone would provide a dump of the recovery partition we could disassemble it and see if it does any crypto signature verification.
22nd January 2015, 11:51 PM   |  #10  
r3pwn's Avatar
Recognized Developer / Recognized Contributor
Flag Naples
Thanks Meter: 1,688
 
1,571 posts
Join Date:Joined: Jul 2012
Donate to Me
More
Quote:
Originally Posted by p1gl3t

I don't think logcat would provide any usable info. I have suggested multiple times and even provided a pretty complete guide for sniffing the actual http traffic.
But I wasn't speaking of the downgrade that amazon provides. I was referring to a experiment that I did to bypass the version check that is enforced at the Android (before rebooting). I managed to flash a 3.2.6 image, but I got a brick as the sbl1 from 3.2.6 has a lower version number. I can bet that the 3.2.7 ota that Amazon provides for downgrade actually has both the build number and the sbl version number higher than the public 4.2.x.

If the recovery doesn't check the signature of the OTA we could do the following:
- provide a bogus image with a higher build number so that it passes the version check
- swap the checker binary from the ota with one that swaps the ota with a valid (signed one) so that it will pass the signature check
- while the android framework is verifying the valid ota swap it again by adb with a crafted ota that has the latest bootloader and kernel so that it can boot
- after the signature check passes the device would reboot and start flashing the crafted ota

If someone would provide a dump of the recovery partition we could disassemble it and see if it does any crypto signature verification.

It doesn't do any verification of any sort AFAIK. The only verification is done in recovery mode, and that is done before any binaries of any sort get executed. Also, using the newer bootloader on an older boot image would result in a bootloop, plus you wouldn't be able to install twrp.

Post Reply Subscribe to Thread
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes