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.
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.
|Thread Tools||Search this Thread|