WARNING
The topics discussed below are THEORETICAL only, and don't imply real world feasibility.
WARNING
That being said, let me test my understanding of how the system works:
The Droid 2 has a 'locked bootloader'. This means that the kernel has an RSA signed hash. THEORETICALLY, one could break the RSA key into its two component primes to determine the private key and enable anyone to sign a kernel correctly, thereby allowing custom kernels on the device.
If this is the case, where does the eFuse technology come into play? Is it merely a means of hard wiring the correct hash into the phone?
Also, assuming the above is correct, where can one find the public key used in the RSA key pair for the Droid 2? Thank you for your time.
I actually thought of this a couple months ago, but never got around to asking, I'd like to know also.
Can anyone confirm at least the first part of my understanding? Is there a common encryption key across all devices of the same make, or does that change within models? For example, If you knew the encryption key for a single Droid 2, does that mean you know the encryption key for every Droid 2?
Again, thanks for your time.
noctolater said:
Can anyone confirm at least the first part of my understanding? Is there a common encryption key across all devices of the same make, or does that change within models? For example, If you knew the encryption key for a single Droid 2, does that mean you know the encryption key for every Droid 2?
Again, thanks for your time.
Click to expand...
Click to collapse
Think about it. If it were really that simple, don't you think the Devs would have unlocked it by now?
DeBaKai said:
Think about it. If it were really that simple, don't you think the Devs would have unlocked it by now?
Click to expand...
Click to collapse
Even using the General Number Field Sieve, which is the best known large integer factorization method currently available, it took a group of researchers 2 years to crack a 768-bit key in 2009 (look up RSA numbers). Every bit you add doubles the difficulty of the problem, meaning a 1024-bit key would be 10^77 times harder to crack. By their estimations, it will be feasible in roughly ten years time.
So no, I don't think the Devs would have unlocked it by now. And this is why this is a THEORETICAL discussion, instead of a practical one. I understand that what I am talking about is probably not possible at this time, I just want to make sure I fully understand how the manufacturers are locking down the phones. Thanks for you time.
I understand what you are saying (and for the record, your reasoning is accurate) but even theoretically it is pretty improbable (almost impossible without aid from Moto).
You could have just as easily done some research to find your answer. Although interesting, this topic is somewhat redundant.
DeBaKai said:
I understand what you are saying (and for the record, your reasoning is accurate) but even theoretically it is pretty improbable (almost impossible without aid from Moto).
You could have just as easily done some research to find your answer. Although interesting, this topic is somewhat redundant.
Click to expand...
Click to collapse
I did do research, about a weeks worth of Google searches, before I posted this. I couldn't really find any concise locations of information, so my knowledge is piecemeal at best. I just want to test my understanding of the concepts, even though it serves no practical purpose.
That being said, if you have any links to concise descriptions, I would be more than happy to see them
Fair enough. Although I think it may take a while before you get your answer.
Unfortunately, my knowledge in this particular subject is limited. I'm not going to be of any real help. Good luck with this, though.
Related
With the IT press getting hold of information regarding the Droid X (Slashdot story here) I thought I'd start a thread regarding this significant find.
As of posting, this is not confirmed. There's no credible source for this information yet, just a community hacker like most of us. If anyone finds better sourced information, post it here.
Mods: Might want to sticky this one
From the /. article:
"If the eFuse failes to verify this information then the eFuse receives a command to "blow the fuse" or "trip the fuse". This results in the booting process becoming corrupted and resulting in a permanent bricking of the Phone. This FailSafe is activated anytime the bootloader is tampered with or any of the above three parts of the phone has been tampered with."
EDIT: I understand there have been threads about this already, but they've moved down the rankings. Lots of people will be looking for information on this topic, and there doesn't seem to be any. A single thread for discussion and information posting seemed appropriate.
Go to boygeniusreport.com, scroll down and find "Reality Check: Modding the DROID X may not lead to a bricked phone."
eFuses have been in phones with TI's OMAP processors for a while now, but they have not been used to brick phones because of custom modifications to the phone. The phone still has an encrypted bootloader which will be hard to crack like just like the Milestone's but it doesnt necessarily mean that the eFuse will trip if the bootloader messed with.
Again, this is still an educated speculation and cant be confirmed until someone goes around and finds a way to unlock the bootloader and flashes a custom ROM on it (hopefully successfully )
i applaude companies that try to beef up security for their own sake. It's sort of like with the PSP, old Xbox, and Wii. They are just trying to protect their own business
We just need to worry about root for now...
Sent from my DROIDX using XDA App
The possibility of eFuse bricking your phone: officially debunked.
http://www.engadget.com/2010/07/16/motorola-responds-to-droid-x-bootloader-controversy-says-efuse/
storino03 said:
i applaude companies that try to beef up security for their own sake. It's sort of like with the PSP, old Xbox, and Wii. They are just trying to protect their own business
Click to expand...
Click to collapse
Gay
Sent from my Samsung Galaxy S using the XDA App.
So after many conversations with Blagus on this and a lot of research and trial and error I managed to find some software capable of 16 digit password hash cracking.
I would have posted in DEV but I don't have my 10 posts yet.
oclHashCat-lite is capable of 15 to 55 digit SHA-256 hash cracking.
you need either a CUDA (Nvidia) enabled graphics card or an OpenCL (ATI) enabled card to run the program.
So I believe we have the software we need now. All we need is to figure out whether the hash is Salted/unsalted and what type of hash it is.
I am guessing that it is SHA-256 from what Blagus mentioned, but we could be wrong.
If you are unfamiliar with which hash I am referring to it follows after something like this.
Code:
RCK_H=
On a side note if you have not already unlocked your Play and can get that information (RCK_H) and get an unlock code from SE, we might be able to figure out what hash type and salt it is.
ashergray said:
So after many conversations with Blagus on this and a lot of research and trial and error I managed to find some software capable of 16 digit password hash cracking.
I would have posted in DEV but I don't have my 10 posts yet.
oclHashCat-lite is capable of 15 to 55 digit SHA-256 hash cracking.
you need either a CUDA (Nvidia) enabled graphics card or an OpenCL (ATI) enabled card to run the program.
So I believe we have the software we need now. All we need is to figure out whether the hash is Salted/unsalted and what type of hash it is.
I am guessing that it is SHA-256 from what Blagus mentioned, but we could be wrong.
If you are unfamiliar with which hash I am referring to it follows after something like this.
Code:
RCK_H=
On a side note if you have not already unlocked your Play and can get that information (RCK_H) and get an unlock code from SE, we might be able to figure out what hash type and salt it is.
Click to expand...
Click to collapse
Agreed... However, to really check to see if it is a particular method, we need to see what people feed the systems (their ESN/PhoneID/etc) and then the code they get back from SE that they then feed to the fastboot bootloader unlocker. Hopefully being able to find what they do with the code when they apply it would also be handy...
So seed and code, plus method, and then we could brute to find out the salt. Then once we have salt and method, we can attempt to use it against other systems to see if we can figure out the method...
We, the R800i crowd, have to type the first fourteen digits of our IMEI number if we want to get an unlock code.
I think most of us are aware of that process by now I think what ryucoon wanted to do was figure out how the create the unlock code from the 14 digit imei.
What I was wanting to do was figure out whether the rkc_h code was the unlock code hashed with a common algorithm. Ie. SHA256 or similar.
Perhaps you r800i guys could do some comparisons with your se unlock codes and rck hash.
Wish I knew what you guys talking about here I have a desktop with [email protected] and SLI-GTX580 , I been reading the R800X root thread for the last few months waiting for something good to happen but sadly nothing yet
1st post
If you download the omnius software and backup your ta, within that file blagus and I think that's where the unlock code is processed and stored.
I back up my TA and is a bunch of numbers and letters I don't have any idea what is that lol
It is the RCK_H hash.
also switch over to my progress thread for updates.
R800X Bootloader Unlock Progress Thread
I can't post on the developers area don't have enough posts
well atleast follow if you cant post. and Post here, or PM me and I will answer any questions I can.
To everyone willing to offer processing power:
Please do, however, after speaking with Atom the developer of Hashcat I found out that it would take close to 82 thousand years to crack this.
here is the math
256 different 2-character combinations
00 to FF, this is how it is they are input when you use the --hex-charset flag.
we have 8, 2-character spaces with 256 possible combos per space
so the math is
256^8=18446744073709551616 possible unlock combos.
roughly 40 million combos per sec
so about 224640000000000 combos per year
possible unlock combos
___________________ = 82116.916282538958404558404558405 years
combos per year
anyone still wanna give it a go?
I will keep racking my brain for what to do next.
Click to expand...
Click to collapse
Since I don't have the requisite 10 posts for over there yet, I need to post this here to get this out.
As was mentioned before, the R800i guys use the first 14 digits of their IMEI to generate the unlock code, which if I understand correctly, should then be hashed by the phone and compared to the RCK_H value. Do you think it is likely that SE uses a different hashing algorithm for the CDMA phones? I wouldn't think so, they just don't use the IMEI as the input.
So I propose we figure out the hashing algorithm using R800i IMEI #s, SE's corresponding unlock code, and the TA RCK_H values. Technically, we should only need 3 sets of values (3 equations, 3 unknowns). Once we've determined the hashing algorithm, we can take the RCK_H values from our individual TA, and calculate the unlock code from there.
You know, in theory, at least. 82 thousand years of brute force attacking is a bit too long, so we need to try and approach this a bit more analytically. I'm a complete noob when it comes to security, hashing, and cracking; but it seems to me that at least in theory the above method should produce results.
Feel free to shoot it full of holes though. The more I learn about this stuff, the better help I can become in the future.
crono141 said:
Since I don't have the requisite 10 posts for over there yet, I need to post this here to get this out.
As was mentioned before, the R800i guys use the first 14 digits of their IMEI to generate the unlock code, which if I understand correctly, should then be hashed by the phone and compared to the RCK_H value. Do you think it is likely that SE uses a different hashing algorithm for the CDMA phones? I wouldn't think so, they just don't use the IMEI as the input.
So I propose we figure out the hashing algorithm using R800i IMEI #s, SE's corresponding unlock code, and the TA RCK_H values. Technically, we should only need 3 sets of values (3 equations, 3 unknowns). Once we've determined the hashing algorithm, we can take the RCK_H values from our individual TA, and calculate the unlock code from there.
You know, in theory, at least. 82 thousand years of brute force attacking is a bit too long, so we need to try and approach this a bit more analytically. I'm a complete noob when it comes to security, hashing, and cracking; but it seems to me that at least in theory the above method should produce results.
Feel free to shoot it full of holes though. The more I learn about this stuff, the better help I can become in the future.
Click to expand...
Click to collapse
So I propose we figure out the hashing algorithm using R800i IMEI
Click to expand...
Click to collapse
That's harder then you'd imagine. In fact, that's one of the fundamental problems of computer science. P?=NP. Basically, you have the output, but need to find the input is a very hard problem. Let's say you have 10. Did you plug in 5*2? 5+5? 2*3+1? Same thing here, finding the algorithm using traditional methods will take forever.
Now, non-traditional methods. I'm not advocating anything illegal, but if someone can somehow get access to the source code at sony's unlock bootloader website... Another possibility is that there is no algorithm and everything is stored in a table (IMEI -> Serial Number -> Lookup table -> Key). I can say they're not using any common hashing algo for the unlock key. In fact, there isn't many 64-bit hashes to choose from.
I understand it isn't a simple process, but it isn't quite as bad as you say. We have the input (SE unlock code) and the output (RCK_H value). In your example, we have 10, the output. But we also have the input: 5. So we know the algorithm is input*2=output. We can confirm this if we have a different set of values: say an input of 6 and an output of 12. That's why I propose getting multiple values.
And obviously, a leak from SE would make this VERY easy. But given sony's recent troubles with security, I don't think getting the leak will be easy at all.
If only we had Anon. But keep up the good work everyone!
I don't think Anon will start another #OpSony just for us poor verizon users.
Thanks Developers for the great job
Thanks to ashergray and other developers involved on jailbreaking the R800X yesterday I got my unlocking code from ashergray and today I am rooted i get rid of all the bloatware and my phone is running faster than usual
I can't be happier hope we see more support now that the verizon" Xperia play is free
Hey,
I don't understand what's the difference between those terms. Is an appcontainer just a instantiated chamber? Or are these actually two terms for the same thing?
Any help is very much appreciated!
FabFaeb
UPDATE:
My current understanding is, that the AppContainers in which the apps are executed are located inside of the LPC (Least Privilege Chamber), that is again separated from the Trusted Computing Base (TCB). What feels strange for me, is that the two terms are basically nowhere mentioned together...
Nobody..? :-\
.. okay so for anybody who might have the same question, here's what I think now:
AppContainer is essentially the same as Chambers in WP. Container is just a new term for the "old" thing. Unfortunately I couldn't finy any reliable information, but after looking into this for a while, that's the only thing that seems to make sense.
I'm new to the community. I've spent countless hours reverse engineering assembly and tinkering with hardware on past smart devices (game consoles as well) and most times there were more paths to exploits through software alone. Sometimes exploits were found in the hardware. Sometimes directly interfacing with hardware (jumping connections to cause a short, putting the device in a recovery mode), even replacing EEPROM chips in some cases to gain kernel/firmware write access.
Has anyone explored hardware exploits?
Interesting question. I remember on one of my HTC devices (Rezound I think) the root method was to short two of the connectors under the back cover using a specific timing.
To my knowledge of browsing these forums, I have not seen anyone mention anything about this type of approach.
ssb13 said:
Interesting question. I remember on one of my HTC devices (Rezound I think) the root method was to short two of the connectors under the back cover using a specific timing.
To my knowledge of browsing these forums, I have not seen anyone mention anything about this type of approach.
Click to expand...
Click to collapse
You are right on the Rezound. I had one and it was a very nerve racking experience to short 2 pins, timed, to get s-off.
mefloump said:
You are right on the Rezound. I had one and it was a very nerve racking experience to short 2 pins, timed, to get s-off.
Click to expand...
Click to collapse
I think it took me a few tries, at least. But worth it!
If I recall correctly, the VZW Note 2 was unlocked through the UART "port" by Adam Outler.
I don't know if this area has been completely explored, but I can't imagine anyone is actively working on it.
So what realistically are the time frames on getting a new root and BL unlock for the snapdragon chipsets?
I ask since now the leak that happened means keys and other information are public.
Here's the thing about real security that has been properly implemented: a source leak doesn't compromise the security of the system. Thus, there is no realistic time frame, because there is no guarantee that a source leak will even result in a bootloader unlock method. A source leak will give insight into how the system works, and it might even expose a vulnerability, but even if revealed, it doesn't mean it will translate into a practical bootloader unlock method.
Imagine for example this purely hypothetical speculation: the persistent state of the OEM unlock bit, in the steady partition or wherever it is stored, is not encrypted or protected by a secure hash. While such a hypothetical vulnerability represents an attack vector, it would likely still be problematic to activate, possibly even requiring direct physical access to the device's eMMC IC.
I've seen said leak. If you're hoping for such access, I'd recommend disabling updates for a while. As far as phones are concerned, the leak goes deep. We're talking certs, signing apps, source code, even qualcomm source.
I dont imagine it will be long.
FesterCluck said:
I've seen said leak. If you're hoping for such access, I'd recommend disabling updates for a while. As far as phones are concerned, the leak goes deep. We're talking certs, signing apps, source code, even qualcomm source.
Click to expand...
Click to collapse
There is a lot there for sure. That said, the Snapdragon (cinammon) bootloader trees seem a lot lighter than the Exynos (strawberry) bootloader trees.
On the Exynos side, "SATURN/bootloader/lib/sbl_security/ddi.c implements get_oem_unlock_val() which is called in a variety of places. I'm still trying to understand the relationship between the two instances of the OEM Unlock flag, that is FROM_RPMB vs. FROM_PERSISTENT. In the case of the latter, this seems to simply be stored in the clear as the last byte in the PERSISTENT partition, where 0 means locked, and 1 means unlocked. As such, it can probably be readily written via JTAG or directly to the eMMC in a matter analogous to how the PERSISTENT partition is deleted to clear FRP state in many YouTube videos, though admittedly these both require special tools and invasive physical access.
I assume there exists at least conceptually similar implementation on the Snapdragon side, but so far I have not found it.
@Badger50 if there is a better place for this development-oriented discussion please advise or move the thread as (a) there does not seem to be a lot of development-oriented discussion in this forum and (b) it is likely not very specific to S20 devices--it is likely to apply to many recent Samsung models.
sjevtic said:
@Badger50 if there is a better place for this development-oriented discussion please advise or move the thread as (a) there does not seem to be a lot of development-oriented discussion in this forum and (b) it is likely not very specific to S20 devices--it is likely to apply to many recent Samsung models.
Click to expand...
Click to collapse
I'll move it to the "Guides and News" section since that would be the more appropriate section. Thanks for the shout out.
I'd be happy to donate to make progress. Just bought a new S20 and of course it has v2 BL. So lmk if there is anything needed.