-
After 15+ years, we've made a big change: Android Forums is now Early Bird Club. Learn more here.
Root Bootloader cracked **Update - This was a fake **
- Thread starter yawdapaah
- Start date
-
- Tags
- motorola droid x
- Status
yawdapaah
Android Expert
@Aggie: I know right. Out of nowhere. I wonder why he called out TBH. 
@Irmac: From what I understand, you can sign your own sbf and flash it on the DX.
Edit:
which should mean that the Blurless GB build can be signed and flashed onto regular DXs. I went into RSDlite but I don't see any related options.
@Irmac: From what I understand, you can sign your own sbf and flash it on the DX.
Edit:
which should mean that the Blurless GB build can be signed and flashed onto regular DXs. I went into RSDlite but I don't see any related options.
ericsch333
Well-Known Member
On twitter p3droid and nenolod have posted the private key for the droid x they say soon will have custom kernels and CM7...
althepal1984
Member
This just made my day... and I got half off of my dinner so I thought that was as good as it gets... this would be fantabulousa
ericsch333
Well-Known Member
With the private key . Iv , you can sign a replacement recovery and pack it in an sbf @nenolod from twitter.
Well they have the keys to something but I don't see anything about them saying its the keys to the efuse. hmm after reading a few more tweets it looks/sounds like they have cracked motomobiles custom encryption and found the keys
nenolod William Pitcock
props to @motomobile for cooking their own modified elgamal signature scheme and doing a bad job at it. no props to TBH.
1 hour ago
nenolod William Pitcock
frequently asked question: what are these keys for? answer: signing SBF update files for rsdlite.
nenolod William Pitcock
continuing... SBF files can be used to load a new recovery on the phone. or to flash entirely different software (e.g. non-android)
1 hour ago http://twitter.com/#http://twitter.com/#http://twitter.com/#http://twitter.com/#
Sounds good!
http://twitter.com/#http://twitter.com/#http://twitter.com/#http://twitter.com/#
nenolod William Pitcock
props to @motomobile for cooking their own modified elgamal signature scheme and doing a bad job at it. no props to TBH.
1 hour ago
nenolod William Pitcock
frequently asked question: what are these keys for? answer: signing SBF update files for rsdlite.
nenolod William Pitcock
continuing... SBF files can be used to load a new recovery on the phone. or to flash entirely different software (e.g. non-android)
1 hour ago http://twitter.com/#http://twitter.com/#http://twitter.com/#http://twitter.com/#
Sounds good!
http://twitter.com/#http://twitter.com/#http://twitter.com/#http://twitter.com/#
Wow...saw this thread got created first...I see some thread-merging about to happen, but its all good since its all good news, lol!
So, you think the ex-Droid X users that moved to the Fascinate will come back now? 
Pretty cool if this pans-out...
So, you think the ex-Droid X users that moved to the Fascinate will come back now?
Pretty cool if this pans-out...
C0n57an71n3
Android Enthusiast
So, rather than cracking the bootloader they found a way to repackage SBF files to flash entire things, i.e. kernel, boot, etc?
That sounds pretty smart.
That sounds pretty smart.
Sholes signing key leak explained
Sholes signing key leak explained
The Motorola(r) sholes platform uses a trusted bootloader environment. Signatures are stored as part of the CDT stored on the NAND flash. mbmloader verifies the signature on mbm before passing control. mbm verifies all other signatures before allowing the device to boot.
There is a vulnerability in the way that Motorola generated the signatures on the sections stored in the CDT. This vulnerability is very simple. Like on the PlayStation 3, Motorola forgot to add a random value to the signature in order to mask the private key. This allowed the private key and initialization vector to be cracked.
The keys can be cracked using Mathematica. Read up on how the Elgamal signature scheme works.
Ok, what does this mean?
Please refer to the following table:
Boot chain component Status OMAP secure bootrom secure Secure keystore replaceable mbmloader secure, but irrelevant, replaceable but unnecessary mbm secure, but irrelevant, replaceable but unnecessary recovery replaceable (providing new keys is recommended) system replaceable (providing new keys is recommended) bootimage replaceable (providing new keys is recommended) I do not plan on doing any more work on this. But all information has been handed over to people who are working on this. Follow the FreeMyMoto people for their progress.
Advisory history
LOL I love the last line....typical Motorola lol
Sholes signing key leak explained
The Motorola(r) sholes platform uses a trusted bootloader environment. Signatures are stored as part of the CDT stored on the NAND flash. mbmloader verifies the signature on mbm before passing control. mbm verifies all other signatures before allowing the device to boot.
There is a vulnerability in the way that Motorola generated the signatures on the sections stored in the CDT. This vulnerability is very simple. Like on the PlayStation 3, Motorola forgot to add a random value to the signature in order to mask the private key. This allowed the private key and initialization vector to be cracked.
The keys can be cracked using Mathematica. Read up on how the Elgamal signature scheme works.
Ok, what does this mean?
Please refer to the following table:
Boot chain component Status OMAP secure bootrom secure Secure keystore replaceable mbmloader secure, but irrelevant, replaceable but unnecessary mbm secure, but irrelevant, replaceable but unnecessary recovery replaceable (providing new keys is recommended) system replaceable (providing new keys is recommended) bootimage replaceable (providing new keys is recommended) I do not plan on doing any more work on this. But all information has been handed over to people who are working on this. Follow the FreeMyMoto people for their progress.
Advisory history
- December 20th, 2010 — Motorola notified of keystore vulnerability. No response received from Motorola.
- February 20th, 2011 — Motorola notified again of keystore vulnerability. No response received from Motorola.
- February 27th, 2011 — Motorola notified that keystore vulnerability will be disclosed to public on March 20th. No response received from Motorola.
- March 20th, 2011 — Keystore signature generation vulnerability publically disclosed including private key leak. Response received from Motorola legal.
LOL I love the last line....typical Motorola lol
http://nenolod.net/~nenolod/sholes-k...explained.html
Sholes signing key leak explained
The Motorola(r) sholes platform uses a trusted bootloader environment. Signatures are stored as part of the CDT stored on the NAND flash. mbmloader verifies the signature on mbm before passing control. mbm verifies all other signatures before allowing the device to boot.
There is a vulnerability in the way that Motorola generated the signatures on the sections stored in the CDT. This vulnerability is very simple. Like on the PlayStation 3, Motorola forgot to add a random value to the signature in order to mask the private key. This allowed the private key and initialization vector to be cracked.
The keys can be cracked using Mathematica. Read up on how the Elgamal signature scheme works.
Ok, what does this mean?
Please refer to the following table:
Boot chain component Status
OMAP secure bootrom secure
Secure keystore replaceable
mbmloader secure, but irrelevant, replaceable but unnecessary
mbm secure, but irrelevant, replaceable but unnecessary
recovery replaceable (providing new keys is recommended)
system replaceable (providing new keys is recommended)
bootimage replaceable (providing new keys is recommended)
I do not plan on doing any more work on this. But all information has been handed over to people who are working on this. Follow the FreeMyMoto people for their progress.
Advisory history
* December 20th, 2010
Sholes signing key leak explained
The Motorola(r) sholes platform uses a trusted bootloader environment. Signatures are stored as part of the CDT stored on the NAND flash. mbmloader verifies the signature on mbm before passing control. mbm verifies all other signatures before allowing the device to boot.
There is a vulnerability in the way that Motorola generated the signatures on the sections stored in the CDT. This vulnerability is very simple. Like on the PlayStation 3, Motorola forgot to add a random value to the signature in order to mask the private key. This allowed the private key and initialization vector to be cracked.
The keys can be cracked using Mathematica. Read up on how the Elgamal signature scheme works.
Ok, what does this mean?
Please refer to the following table:
Boot chain component Status
OMAP secure bootrom secure
Secure keystore replaceable
mbmloader secure, but irrelevant, replaceable but unnecessary
mbm secure, but irrelevant, replaceable but unnecessary
recovery replaceable (providing new keys is recommended)
system replaceable (providing new keys is recommended)
bootimage replaceable (providing new keys is recommended)
I do not plan on doing any more work on this. But all information has been handed over to people who are working on this. Follow the FreeMyMoto people for their progress.
Advisory history
* December 20th, 2010
ericsch333
Well-Known Member
Www.nenolod.net/"~nenolod/sholes-key leak-explained.html
Sholes signing key leak explained
The Motorola(r) sholes platform uses a trusted bootloader environment. Signatures are stored as part of the CDT stored on the NAND flash. mbmloader verifies the signature on mbm before passing control. mbm verifies all other signatures before allowing the device to boot.
There is a vulnerability in the way that Motorola generated the signatures on the sections stored in the CDT. This vulnerability is very simple. Like on the PlayStation 3, Motorola forgot to add a random value to the signature in order to mask the private key. This allowed the private key and initialization vector to be cracked.
The keys can be cracked using Mathematica. Read up on how the Elgamal signature scheme works.
Ok, what does this mean?
Please refer to the following table:
Boot chain component Status OMAP secure bootrom secure Secure keystore replaceable mbmloader secure, but irrelevant, replaceable but unnecessary mbm secure, but irrelevant, replaceable but unnecessary recovery replaceable (providing new keys is recommended) system replaceable (providing new keys is recommended) bootimage replaceable (providing new keys is recommended) I do not plan on doing any more work on this. But all information has been handed over to people who are working on this. Follow the FreeMyMoto people for their progress.
Advisory history
- December 20th, 2010
dmiller2007
Android Expert
Quick question, I know this is still very early, but is this probably going to be like flashing an sbf to change roms, or will it be an sbf that enables custom roms? thoughts?
C0n57an71n3
Android Enthusiast
If I had to guess, it would be flashing an SBF to change ROMs. They will probably be packaged as .zips though, like the 3.4.2 leak and the maderstcok.
Sounds like you use RSlite to flash ROMS. My take is that by using this method you bypass the bootloader key check ???
dmiller2007
Android Expert
hm. Maybe. its honestly still over my head. I'm good at getting a grasp on this stuff but I can see I'm still a couple of "dumb it down" versions away. But good thing I finally decided to build myself a pc instead of using my dx for all my computing needs lol
D
Deleted User
Guest
This is going to allow a custom recovery to be flashed through RSDlite.
After that, it'll just be like any other unlocked phone.
After that, it'll just be like any other unlocked phone.
D
Deleted User
Guest
BTW, you don't bypass the key check... The private key was cracked and leaked. This means you can use the private key to sign the file, making it totally legit as far as the phone is concern.
After you do this, you pack an SBF file to replace the keys in the keystore, and then the keys that the phone verifies against are not Motorola's keys - they are whatever you put there. Prevents Motorola from pushing a system update to overwrite it (i.e. Motorola no longer has access to your bootloader), and prevents malicious applications from being able to write to the bootloader.
Thus, you get the security of the locked bootloader (i.e. no malicious app can write to it), but we can still have a custom recovery.
After you do this, you pack an SBF file to replace the keys in the keystore, and then the keys that the phone verifies against are not Motorola's keys - they are whatever you put there. Prevents Motorola from pushing a system update to overwrite it (i.e. Motorola no longer has access to your bootloader), and prevents malicious applications from being able to write to the bootloader.
Thus, you get the security of the locked bootloader (i.e. no malicious app can write to it), but we can still have a custom recovery.
dmiller2007
Android Expert
So its an sbf that allows custom roms? Awesome...
- Status