I'm curious about how one would go about cracking a bootloader. Is it some complex algorithm that a super computer is required to solve?
If so, could someone write a PC program that uses parallel computation so that a bunch of people, say a thousand, running this program could solve the algorithim together? This approach is currently used by HIV researchers hoping to understand how proteins fold. I am curiuous if that strategy could be employed in our context.
Sent from my MB870 using XDA App
redwingfaninnc said:
I'm curious about how one would go about cracking a bootloader. Is it some complex algorithm that a super computer is required to solve?
If so, could someone write a PC program that uses parallel computation so that a bunch of people, say a thousand, running this program could solve the algorithim together? This approach is currently used by HIV researchers hoping to understand how proteins fold. I am curiuous if that strategy could be employed in our context.
Sent from my MB870 using XDA App
Click to expand...
Click to collapse
It sounds halfway reasonable, but I imagine if that's all it took to beat the encryption then I would be even more afraid of the Chinese government. (And ours...)
Sent from my DROID X2 using xda premium
I been wondering the same... I know this is going to sound retarded, but:
Is there a my problem that is used to determine the key? I ask this because couldn't we just find certain values to replace in the formula? I know I know, stupid question.
Tapin' the Talk on the xSquared
The way a bootloader's encryption works is the manufacturer will generate a random string of characters and use it to sign anything they wish to lock on the device. It may sound easy enough to simply pick apart one of the signed files and take a look at what the unlock code is, but the problem lies in that you can't see the key until you already have it, due to the way the phone is programmed to act. So, the idea is that they generate a a key to use and hope no one guesses it (or cracks it due to errors on their part, a dev leaking files, etc), as that key will unlock everything they want to hide.
Now, it's easy to say that we can just use a random number generator and brute force the bootloader after awhile, though how long "awhile" is is in itself the real value behind locking a bootloader in this way.
If I'm not mistaken, Motorola uses 256-bit encryption. That means that they used a form of encryption that allows the key to be one of 2^256 possibilities.
Now, let's assume that every person in the world, approx. 7 billion people (slightly less, but close enough), owns one computer. Let's also assume that each person has the ability and knowledge to brute force AES-256 encryption, and will do so on Motorola's Droid X2 bootloader.
If 7 billion computers are operating 100% of the time to try to figure out which of the 115,792,089,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000 possible combinations Motorola used to sign with, it will take those computers 103,227,037,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000 years to figure out the correct key.
Now keep in my I used my computer's processor (i7 3960x) clock and actions per second rate for determining the amount of time it would take. Using the specs of the average home computer, it could take up anywhere from 10 to 20 times longer (a retarded amount of time, considering how large the number already is). Also, the average brute force attempt will find the key in half the time it would have taken to find all of them (50%), and I applied this to the final time.
Don't ask why I know all this...
Hope I could help!
Excellent explanation. I know it's been stated in less detail, but you pretty much gave a great explanation that hopefully should make it completely clear why brute-force is NOT an option. Even if your numbers are off, it still makes clear that NO super computer could do it without giving YEARS, and I mean "years" in more than 10) to even have half-a-chance to crack the key.
No, the only way to unlock the bootloader is someone from Motorola leaks an unlocked bootloader or else, someone leaks the key. Both require someone from inside Motorola doing this and I don't see it happening.
theredvendetta said:
The way a bootloader's encryption works is the manufacturer will generate a random string of characters and use it to sign anything they wish to lock on the device. It may sound easy enough to simply pick apart one of the signed files and take a look at what the unlock code is, but the problem lies in that you can't see the key until you already have it, due to the way the phone is programmed to act. So, the idea is that they generate a a key to use and hope no one guesses it (or cracks it due to errors on their part, a dev leaking files, etc), as that key will unlock everything they want to hide.
Now, it's easy to say that we can just use a random number generator and brute force the bootloader after awhile, though how long "awhile" is is in itself the real value behind locking a bootloader in this way.
If I'm not mistaken, Motorola uses 256-bit encryption. That means that they used a form of encryption that allows the key to be one of 2^256 possibilities.
Now, let's assume that every person in the world, approx. 7 billion people (slightly less, but close enough), owns one computer. Let's also assume that each person has the ability and knowledge to brute force AES-256 encryption, and will do so on Motorola's Droid X2 bootloader.
If 7 billion computers are operating 100% of the time to try to figure out which of the 115,792,089,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000 possible combinations Motorola used to sign with, it will take those computers 103,227,037,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000 years to figure out the correct key.
Now keep in my I used my computer's processor (i7 3960x) clock and actions per second rate for determining the amount of time it would take. Using the specs of the average home computer, it could take up anywhere from 10 to 20 times longer (a retarded amount of time, considering how large the number already is). Also, the average brute force attempt will find the key in half the time it would have taken to find all of them (50%), and I applied this to the final time.
Don't ask why I know all this... I like balls
Hope I could help!
Click to expand...
Click to collapse
iBolski said:
Excellent explanation. I know it's been stated in less detail, but you pretty much gave a great explanation that hopefully should make it completely clear why brute-force is NOT an option. Even if your numbers are off, it still makes clear that NO super computer could do it without giving YEARS, and I mean "years" in more than 10) to even have half-a-chance to crack the key.
No, the only way to unlock the bootloader is someone from Motorola leaks an unlocked bootloader or else, someone leaks the key. Both require someone from inside Motorola doing this and I don't see it happening.
Click to expand...
Click to collapse
Thank you, I just thought it needed to be clarified why we couldn't brute force so easily, or at least within the time before the human race goes extinct. The numbers may be off by one or two zeros, but should be fairly accurate. You get the point though
Also, I think my friend edited my post and added "I like balls". That wasn't me, more of a fan PG lady parts personally
theredvendetta said:
Also, I think my friend edited my post and added "I like balls". That wasn't me, more of a fan PG lady parts personally
Click to expand...
Click to collapse
Was just about to ask about the balls.
Sent from my DROID X2 using xda premium
Jubomime said:
Was just about to ask about the balls.
Sent from my DROID X2 using xda premium
Click to expand...
Click to collapse
And just to clarify, I apparently can't type worth ****. I don't like "PG" lady parts, as that would make me either a pedophile or gay. Just thought I'd clear that up.
Inb4 I missed a typo in this post.
theredvendetta said:
And just to clarify, I apparently can't type worth ****. I don't like "PG" lady parts, as that would make me either a pedophile or gay. Just thought I'd clear that up.
Inb4 I missed a typo in this post.
Click to expand...
Click to collapse
Evidence is starting to pile up.
Sent from my DROID X2 using xda premium
Thanks for the explanation, I had a hint of most of that. What I was wondering:
Is there a FORMULA? (ie. 2x+6a-b=KEYFILE)
It was a stupid question, I'm just a sucker for these threads haha. Looking at the wiki now on AES.
Peperm1nt said:
Thanks for the explanation, I had a hint of most of that. What I was wondering:
Is there a FORMULA? (ie. 2x+6a-b=KEYFILE)
It was a stupid question, I'm just a sucker for these threads haha. Looking at the wiki now on AES.
Click to expand...
Click to collapse
Lol dude don't worry about it. So long as the question is relevant to the topic, I say there isn't such a thing as a stupid question. 'Sides, this isn't exactly common knowledge anyway.
There is a formula, yes, and I meant to say this earlier, though not in the conventional sense. AES divides inputted values into 4 bit groupings and generates a random outcome for each grouping. In the case of 256 bit AES, it will ultimately generate a random string with a length dependent on the original number of values the user has provided the encryption with.
Those values provided by the user will be the key, and the final outcome generated by the encrypter will be the "signature" in the bootloader. When attempting to verify bootloader access, if you don't input the character key string, AES will create a different outcome than the one assigned to the bootloader, and deny you access.
Because of how brilliant AES truly is, it is designed to encrypt and decrypt with the same key string, meaning we need either a sympathetic dev with credentials that aren't handed out lightly, or to find a flaw unnoticed by Motorola. Otherwise, we are stuck having to brute force, which is simply not going to happen.
I hope at least some of this made sense. I'm going by memory for a lot of this, you may get a better idea of it by doing some Googling.
Hope I could help!
---------- Post added at 04:28 PM ---------- Previous post was at 04:25 PM ----------
Jubomime said:
Evidence is starting to pile up.
Sent from my DROID X2 using xda premium
Click to expand...
Click to collapse
ಠ_ಠ damn it, you got me
I'm pretty good at math, and always found a way to work things out in my head by finding a way to make the operations simple. I know this isn't a simple process, but let me try to ask this to get a better understanding of how this works; btw thanks for all the information provided thus far.
Keep in mind this is going to be simple.
AES ENCRYPTION:
Motorola inputs A as the key for bootloader. The output is B.
B is what you will see if you were to look at the actual signature before decryption.
As we all know, there is no true random in computers, can't we just look at aes code and reverse the formula? We would need to know of a known value, but idk, it was just a thought. Also wpa is also aes encrypted, and I think I read somewhere of the aircrack-ng crew finding a way to go around the bruteforce of the keyfile.
Also,(this is a long shot)
If we know the exact length of the string, can't we just replace the hex with another key? And force the md5 sum to stay the same for security?
Tapin' the Talk on the xSquared
Peperm1nt said:
I'm pretty good at math, and always found a way to work things out in my head by finding a way to make the operations simple. I know this isn't a simple process, but let me try to ask this to get a better understanding of how this works; btw thanks for all the information provided thus far.
Keep in mind this is going to be simple.
AES ENCRYPTION:
Motorola inputs A as the key for bootloader. The output is B.
B is what you will see if you were to look at the actual signature before decryption.
As we all know, there is no true random in computers, can't we just look at aes code and reverse the formula? We would need to know of a known value, but idk, it was just a thought. Also wpa is also aes encrypted, and I think I read somewhere of the aircrack-ng crew finding a way to go around the bruteforce of the keyfile.
Also,(this is a long shot)
If we know the exact length of the string, can't we just replace the hex with another key? And force the md5 sum to stay the same for security?
Tapin' the Talk on the xSquared
Click to expand...
Click to collapse
that sounds feasible, but at the same time i suck at math, so id be no good at this...
couldnt we look in the chinese forums for this unlock? they seem to know what to do. or is it possible to change the atrix, photon, or xoom unlock to match ours since theyre phones are similar to ours?
Sent from my MB870 using Tapatalk
Peperm1nt said:
I'm pretty good at math, and always found a way to work things out in my head by finding a way to make the operations simple. I know this isn't a simple process, but let me try to ask this to get a better understanding of how this works; btw thanks for all the information provided thus far.
Keep in mind this is going to be simple.
AES ENCRYPTION:
Motorola inputs A as the key for bootloader. The output is B.
B is what you will see if you were to look at the actual signature before decryption.
As we all know, there is no true random in computers, can't we just look at aes code and reverse the formula? We would need to know of a known value, but idk, it was just a thought. Also wpa is also aes encrypted, and I think I read somewhere of the aircrack-ng crew finding a way to go around the bruteforce of the keyfile.
Also,(this is a long shot)
If we know the exact length of the string, can't we just replace the hex with another key? And force the md5 sum to stay the same for security?
Tapin' the Talk on the xSquared
Click to expand...
Click to collapse
Actually that is a fairly reasonable way of describing the process, I suppose I could've said that And no problem, I like being (at least somewhat) useful
For reversing the process in its entirety, we would need to know part of the key to solve for the whole thing. Think of it like this, where x is the first portion of the key, and y is the second:
If we know that x+y=10, we can't solve for the variables, even though we know the final outcome. It isn't until we are told that x=2 that we can figure out that y=8.
It seems like I'm reaching the extent of my knowledge on AES, because I'm not sure how successful your last point would be. It doesn't sound impossible per se, but it just sounds too easy
---------- Post added at 11:32 PM ---------- Previous post was at 11:27 PM ----------
ztotherad said:
that sounds feasible, but at the same time i suck at math, so id be no good at this...
couldnt we look in the chinese forums for this unlock? they seem to know what to do. or is it possible to change the atrix, photon, or xoom unlock to match ours since theyre phones are similar to ours?
Sent from my MB870 using Tapatalk
Click to expand...
Click to collapse
Unfortunately it isn't so simple. The Atrix was unlocked by a leaked bootloader, meaning we have no idea how to unlock it, as a lovely Moto dev did so for us. Not only that, but if it wasn't a flaw that the dev exploited, he probably used the correct key to unlock it, and I would each model is signed differently.
I have no idea about the photon or xoom to be honest lmao
theredvendetta said:
Actually that is a fairly reasonable way of describing the process, I suppose I could've said that And no problem, I like being (at least somewhat) useful
For reversing the process in its entirety, we would need to know part of the key to solve for the whole thing. Think of it like this, where x is the first portion of the key, and y is the second:
If we know that x+y=10, we can't solve for the variables, even though we know the final outcome. It isn't until we are told that x=2 that we can figure out that y=8.
It seems like I'm reaching the extent of my knowledge on AES, because I'm not sure how successful your last point would be. It doesn't sound impossible per se, but it just sounds too easy
---------- Post added at 11:32 PM ---------- Previous post was at 11:27 PM ----------
Unfortunately it isn't so simple. The Atrix was unlocked by a leaked bootloader, meaning we have no idea how to unlock it, as a lovely Moto dev did so for us. Not only that, but if it wasn't a flaw that the dev exploited, he probably used the correct key to unlock it, and I would each model is signed differently.
I have no idea about the photon or xoom to be honest lmao
Click to expand...
Click to collapse
side note: do you have a twitter or a gtalk account?
so we couldn't take the atrix sbf with the pudding and apply it to the x2 without ****ing up our phones hardcore? i wonder if we could take either the xoom or photon and do it then.. probably the xoom would be more successful since it's on verizon's network anyway.
ztotherad said:
side note: do you have a twitter or a gtalk account?
so we couldn't take the atrix sbf with the pudding and apply it to the x2 without ****ing up our phones hardcore? i wonder if we could take either the xoom or photon and do it then.. probably the xoom would be more successful since it's on verizon's network anyway.
Click to expand...
Click to collapse
I don't have a gtalk but I'm on Skype everyday. I find it much more convenient, plus all my friends from school use it. Seems like everyone on xda uses gtalk though lol. If you want my Skype let me know, n ill pm ya.
We wouldn't be able to sbf to an Atrix rom without a whole lot of optimization, including work on the bootloader. Our phones may have similar hardware to an Atrix, but each model is very different in the software department. We actually have an Atrix port, I believe.
ztotherad said:
side note: do you have a twitter or a gtalk account?
so we couldn't take the atrix sbf with the pudding and apply it to the x2 without ****ing up our phones hardcore? i wonder if we could take either the xoom or photon and do it then.. probably the xoom would be more successful since it's on verizon's network anyway.
Click to expand...
Click to collapse
If it "would" work, we would eventually need the kernel source for the x2 to fix our phone, which isn't released. And SBFing an x2 overlay would just lock it again(i think).
@theredvendetta
What I mean is this, we could hex edit where the actual keystring would be(0x***Keyfile**) to (0x***FakeKeyfile**). When we go to apply the unlock key we would already know what our encryption key would be to apply. In other words, "make" a new bootloader signature in which we would know the key, replace the existing master file in a Hex workshop, then apply the new key.
This is assuming there is a master file.
Peperm1nt said:
If it "would" work, we would eventually need the kernel source for the x2 to fix our phone, which isn't released. And SBFing an x2 overlay would just lock it again(i think).
@theredvendetta
What I mean is this, we could hex edit where the actual keystring would be(0x***Keyfile**) to (0x***FakeKeyfile**). When we go to apply the unlock key we would already know what our encryption key would be to apply. In other words, "make" a new bootloader signature in which we would know the key, replace the existing master file in a Hex workshop, then apply the new key.
This is assuming there is a master file.
Click to expand...
Click to collapse
so our kernel source hasn't been released? damn, i read in the atrix 2 forums that they're trying to bypass the bootloader and kernel. I'll provide a link after I post this then edit it.
I have a (possibly stupid) question.
In terminal emulator doesn't "dmesg" displays all the kernel info?,"dmesg -i kernel" can that be used to make up a kernel source?
Sent from my DROID X2 using Tapatalk
hggadm3 said:
I have a (possibly stupid) question.
In terminal emulator doesn't "dmesg" displays all the kernel info?,"dmesg -i kernel" can that be used to make up a kernel source?
Sent from my DROID X2 using Tapatalk
Click to expand...
Click to collapse
No. We have kernel source, but the amount of time required to get the signatures to get the kernel to work would take a very long time. Honestly not as long as previously posted (there is something called a "Birthday Attack" that can be used) but even if this was possible, the amount of time would still be completely unreasonable.
Related
Well I was just reading a thread about someone buying a Vibrant from someone who "found" it and this person was looking for a way to bypass WaveSecure.
We all know that with a little know how that it is possible with Recovery Mode.
The question I have is there a way to prevent even a Recovery Mode reflash? To absolutely stop someone from touching the ROM at all?
I know the Security Apps out right now can track you from GPS, wipe the phone remotely, etc... But can it stop someone from reflashing a ROM?
If there is a app out there like that please let me know, but if not, what would it take to create such a app.
What are YOUR thoughts??
What if this happens and then you brick for some reason need to reflash and it's locked. I would just bank on the fact that most people think that it's a "Droid" phone and don't know ****.
I was hoping for a question like that.
Either there is a security measure which at some point of using Recovery that it asks for a password or pin. Something that will allow you to access it securely and nobody else.
Yes, it is a droid, very true, but how many droids are out there now, are going to be out there, and with the new laws that allow you to unlock your device and pretty much do anything with it, more and more people are going to start playing around. Not only that, there is always somebody who knows someone, you know.
Personally myself, I would feel secure with having an implementation like this, everything else is pointless.
It's sort of like having a anti virus on your computer but not scanning for rootkits, only viruses.
The idea of that app sounds nice and all that but I seriously doubt that the average Android user would know about flashing ROMs and all that. But if it does get into the hands of somebody that does know how to do it then it can be a problem.
jzero88 said:
Yes, it is a droid, very true, but how many droids...
Click to expand...
Click to collapse
First of all these are android devices / android phones. I was mocking the people who call these phones "droid" phones.
Now on topic: All it takes to break this security is for one person to say, "I forgot my password on for the ==sUPERlOCKER== what do I do to get access?" Then all your worry is for nothing again.
What has been done can always be undone.
Sure, unlike me, I never forget my passwords. Especially for something this serious.
Second, of course something can be undo, but to what extent, after hearing your lack of concern makes me think you don't even have a lock on your phone
Again, would you rather have a password like "1234" that is easily guessed, or would you rather have something like "00LowJK54889$3%#". It's really a matter of personal security.
You sound like one of those people who would have Security Cameras, but never has the DVR on to record anything.
I'm saying your idea is bad. I have illustrated why. You have no counterpoint other than that I am 'relaxed' about my phone security.
How about this, keep your phone in your pocket or hand? 100% security.
This should be in general and not development
Sent from my Vibrant using xda app
This has been discussed a few times, you could compile your own recovery image and program in a password while at it, or you can accept that 90% of theives(or people who would find your phone) cannot get to recovery. If I found a phone then yeah I would go straight to recovery but I'm not your average user.
Sent from my T-Mobile myTouch 3G Slide using XDA App
I'm saying your idea is bad. I have illustrated why. You have no counterpoint other than that I am 'relaxed' about my phone security.
How about this, keep your phone in your pocket or hand? 100% security.
Click to expand...
Click to collapse
First, my idea is not bad, give it time, you will see.
Second, I do not have a counterpoint because my main point is stated in the first post. Read again.
Third, I don't care if you are relaxed about your security or not. This post obviously is not for you, another negative person who stunts development if they do not see a logical use for themselves.
I wish you the best and hope that you do not need to ever use such a tool or measure. Take it easy.
This has been discussed a few times, you could compile your own recovery image and program in a password while at it, or you can accept that 90% of theives(or people who would find your phone) cannot get to recovery. If I found a phone then yeah I would go straight to recovery but I'm not your average user.
Sent from my T-Mobile myTouch 3G Slide using XDA App
Click to expand...
Click to collapse
On the Vibrant forums? Haven't seen anything yet.
Also, I am not betting on a thief or someone who found the phone to be able to get to recovery, I'm worried about who these people might know. It's surprising to see how many people out here think that they are the only person in a 20 mile radius who knows how to do such mods... Maybe it's just the people I know but I know quite a few people who can easily google and find a way, easily.
I can bet that 90% of people here do not know anything except following directions, no pun intended to those who do. I definitely do not know half of what I should know, but again, is it really that hard?
Your own logic defeats what you are saying here. Don't you understand OP?
If there is a security measure, there will be a work around it? So why have more than ONE thing for the uneducated masses and stop there?
If the person who steals your phone knows someone who could get around WaveSecure, or any other security application. Then that same person can get around ANY AND ALL other types and forms of theft deterrent. If not, they will know someone, ask on forums, etc. UNTIL they gain access.
zaduma
Then why have any security on anything at all?
You my friend make no sense, good day!
jzero88 said:
Then why have any security on anything at all?
Click to expand...
Click to collapse
Ok, I will lay it out as simply as I can man. I do not want to argue, but you are missing why this is impossible to accomplish.
The existing security layers can be compromised by lets say... 10% of the population, seeing as most people who are thieves do not talk about it, most people dislike thieves.
So effectively 90% of people will be stopped dead in their tracks by having WaveSecure, etc.
The 10% who are not stopped however, can not be stopped by any means. None. They are the people who read these forums, have technical ability, etc.
Therefore having one layer of security means 90% of people are stopped from using your device. But it has ridiculously diminishing returns. With two layers, say stopping access to recovery, 10% are now stopped. Just boot into download mode and flash with odin. Stop download mode? First of all how? Second of all, there has to be a workaround for people who forget their passwords and stuff. And guess what, those 10% will know about that as well.
So please, address these issues and resolve them somehow, and your idea has merit. Without doing so you are wasting your time.
Also, much to your liking I will assume, I will no longer be posting in this thread due to your constant elevation of flaming.
Any security pro will tell you, if you have physical access to a computer, you can make it usable for you. The only real security you can hope for its to prevent access to your data by the thief. That's what full disk encryption and such is about. For our phones, we could achieve this much with a custom kernel perhaps, but how would you enter the password? No keyboard at that level.
The cellular providers can prevent the stolen phone from getting on their networks, and some do, but that's about as far as it goes.
Its like having a lock on your front door.. Its only going to keep out the honest people... Thats what they are made for, honest people, because dishonest people will just kick the door in.. And the good thieves can pick a dead bolt...
Sent from my SGH-T959 using XDA App
I'm starting to think this request/question is for the wrong crowd, truly it is...
If you build it they will hack it... Hands down... Look at the droid x, the unhackable phone, it took 5 weeks..
Sent from my SGH-T959 using XDA App
I agree, never did I not. This thread wasn't to debate whether a security measure could be hacked or not, the thread was created to see what we could do to implement such a measure.
I am totally aware of that. I know that if there is a will there is a way.
PERSONALLY, that is something I wouldn't mind having. Though some of you disagree and have a right to your own opinion, that is beyond the point. I am trying to see if a) is it possible. and b) what it would take to do so, and possibly c) if anyone was interested in trying or helping out.
So feel free to express your opinion. Mine is that you can never have enough protection cuz I would never bring a knife to a gun fight. But that's just me...
BTW, those who hacked the unhackable phone I would consider being part of the .01%.
jzero88 said:
I'm starting to think this request/question is for the wrong crowd, truly it is...
Click to expand...
Click to collapse
If you mean people that know how things work, I suppose. It's the same problem as drm. When you understand why that's not possible, you will understand this. Read up on jtag as well, you can't protect against that. 90% is about as good as it gets.
First off, I want to apologize if this information is either or both regurgitated and irrelevant.
I was looking for information on eMMC, and there really isn't much, and I found an old article that describes how data reliance works with eMMC. At least a cursory look.
One of the features of Reliance (and Reliance Nitro) file system is that it never overwrites live data. It will always use free space on disk or in case there is no space, it will give “disk full” error back to the application. Reliance also has a special transaction mode called “Application-controlled”. In this case, Reliance only conducts a transaction point when asked by the application.
Click to expand...
Click to collapse
Full article here. Information about integration with embedded linux, here.
What struck me was the "Application-controlled" part. It would explain the technology that is undoing changes to /system when the system kills the temp root. I wonder if its possible for temp root to trigger the "commit" function of reliance once some small changes have been made...
Hope this is of some use.
CyWhitfield said:
First off, I want to apologize if this information is either or both regurgitated and irrelevant.
I was looking for information on eMMC, and there really isn't much, and I found an old article that describes how data reliance works with eMMC. At least a cursory look.
Full article here. Information about integration with embedded linux, here.
What struck me was the "Application-controlled" part. It would explain the technology that is undoing changes to /system when the system kills the temp root. I wonder if its possible for temp root to trigger the "commit" function of reliance once some small changes have been made...
Hope this is of some use.
Click to expand...
Click to collapse
Just an FYI, system is an EXT4 FS. This would require not only a custom kernel, but a lot of one offs in the way it's dealing with data. From what I've seen, this isn't what they are using.
But that's a very good find, I am looking into some of the information. Never heard of this before.
Thanks for the info. I would love to find out more about how this memory technology works. More articles are welcome!
Isn't that basically just wear leveling?
Is your name Ben? Or are you perhaps searching on this because of a post that Ben made on HTC? His claim was that even with an unlocked bootloader, that the eMMC could still be locked and prevent us from getting root. This seems far fetched to me.
edufur said:
Is your name Ben? Or are you perhaps searching on this because of a post that Ben made on HTC? His claim was that even with an unlocked bootloader, that the eMMC could still be locked and prevent us from getting root. This seems far fetched to me.
Click to expand...
Click to collapse
In all reality, I'm thinking this is the eventuality. Sprint knows that with root access we can circumvent the WiFi tether that they want to charge you for. They would never be OK with that.
Sent from my PG86100 using Tapatalk
Just an FYI, system is an EXT4 FS. This would require not only a custom kernel, but a lot of one offs in the way it's dealing with data. From what I've seen, this isn't what they are using.
But that's a very good find, I am looking into some of the information. Never heard of this before.
Click to expand...
Click to collapse
Given that you have taken a much closer look at the inner workings than I have, I will defer to your observation with a caveat
According to wiki eMMC supports something called Reliable Write. This suggests that the reversion capability is a part of the eMMC standard. Reliance sounds more and more like a commercial implementation of this function decoupled from a specific media type. After looking it over again, nowhere in the article about Reliance is eMMC mentioned.
Isn't that basically just wear leveling?
Click to expand...
Click to collapse
Wear leveling is a byproduct of what reliable write is doing. The difference is the ability to defer commitment of file system changes, so that a failed system update wont brick the device.
I do not know if changes made to the device are immediate and revertable (i.e., if eMMC is not told to commit a write, the changes just "go away" when its remounted). Nor do I know if reversions can be made on the fly, as we are experiencing when temp root gets deactivation.
There really isn't much information out there about this that is easy to find.
Is your name Ben? Or are you perhaps searching on this because of a post that Ben made on HTC? His claim was that even with an unlocked bootloader, that the eMMC could still be locked and prevent us from getting root. This seems far fetched to me.
Click to expand...
Click to collapse
Neither. eMMC isn't "locked" per se. HTC is using some mechanism that will revert the contents of /system to a prior state when some unknown condition is met. I do not mean to suggest that this is being done through "reliable write" or "Reliance", since it has already been pointed out by someone much more knowledgable on the subject than I that a standard EXT4 file system is being used. I honestly have no idea. I found this information somewhat by accident, and thought that if it could prove useful I should share it here.
Something is dynamically protecting the contents of /system. Once the phone is rooted, I have no doubt that this "something" will be rendered quite impotent. If it were not possible to do so in the first place, OTAs wouldn't work
Sprint knows that with root access we can circumvent the WiFi tether that they want to charge you for. They would never be OK with that.
Click to expand...
Click to collapse
The first part of your statement is true, Sprint knows full well that we can circumvent their attempts to charge us for WiFi tethering with root access. They have known this for years. They also know that in reality there is no way they can completely prevent someone from tethering their phone in one way or another. Even without root access. Ref: PDANet.
In my opinion, this protection of the eMMC contents was designed to reduce support costs from failed OTA updates bricking phones, and perhaps as protection against malware that can attain root, not unlike what Temp Root does.
I am not as paranoid as some here and refuse to accept that this was done specifically to thwart efforts to root the phone. The vast (and i mean VAST) majority of people who buy this phone will never even consider rooting the devices. This same majority has a subset of people that are easily stupid enough to screw up an OTA update or download and install malware.
I will take it a step further and opine that the only reason HTC is unlocking the bootloader is because we are such a minority AND that by tinkering with an unlocked device, we are actually helping HTC improve their product. They would rather have a more appealing facebook page than worry about losing a minuscule fraction of wifi tethering income.m Moreover, take a good look at where Sprint stands in the market, and what they have done recently to improve their position. They are doing a lot of really cool things, and have taken impressive steps to improve customer service and corporate image. That they would allow this bashing of HTC to continue unabated over a handful of tethering dollars is unlikely.
I appreciate your canter, very informative. A thanks will come your way.
Sent from my PG86100 using Tapatalk
Does pdanet allow wireless tether? I didn't think it did.
Sent from my PG86100 using Tapatalk
Nutzy said:
Does pdanet allow wireless tether? I didn't think it did.
Sent from my PG86100 using Tapatalk
Click to expand...
Click to collapse
It doesn't act as a hotspot, no.
Sent from my PG86100 using XDA App
Nutzy said:
I appreciate your canter, very informative. A thanks will come your way.
Sent from my PG86100 using Tapatalk
Click to expand...
Click to collapse
Much appreciated!
Sent from my PG86100 using XDA App
So, I would be interested in hearing more thoughts on this. Is the eMMC independent of the OS? In other words, would a custom ROM have to obey and work with the eMMC? Or could a custom ROM be made to either disable the eMMC or make it do what we want?
edufur said:
So, I would be interested in hearing more thoughts on this. Is the eMMC independent of the OS? In other words, would a custom ROM have to obey and work with the eMMC? Or could a custom ROM be made to either disable the eMMC or make it do what we want?
Click to expand...
Click to collapse
I think you're misunderstanding this. The eMMC is the memory inside the device that everything is stored on. It replaced the old NAND chips in older devices.
The OS is stored & runs off of eMMC memory, it's not independent. If you were to 'turn off' the eMMC the device would do nothing. A lot of the security features available on the chip itself probably aren't in use. HTC has been using their own form of write protection since early last year, even on the NAND based Evo 4G. I'd stake a bet they're using the same system here, and we just need to find a way to flash the ENG bootloader like we did last year to get around it.
I agree with you. reliance is setup to ward against "unauthorized" changes to the /system partitions. i believe the developer community takes way too deep a look at each action made by a corporation (htc) and view them as "big brother", when infact most changes are actually approved, reviewed, and committed by someone in accounting with no technical skills whatsoever. these people are forced to look at the bigger scheme of things and make a decision about it (after working for sprint for almost 2 years now...i can tell you how many decisions are literally made by someone who has no idea what the heck he is making decisions on).
instead of looking at them "trying to stop the development community from unlocking wireless tether" look at them as a CEO (who most of the time has no technical knowledge) and a PR rep (who really only cares about how their company is viewed) and using this kind of encryption is only there to "safeguard" their devices against attacks.
one would think the secret to perm rooting the device is triggering the reliance write function so it commits the changes instead of reloading them. if /system doesnt get changed unless theres an OTA of some sorts....theres more than likely a hash table that reliance would check against to verify...so an OTA would need to write to that table first, then make the changes....
more than likely some other noob has already said something along those lines and been flamed for it as well...just throwing it out there....
newkidd said:
.........
one would think the secret to perm rooting the device is triggering the reliance write function so it commits the changes instead of reloading them. if /system doesnt get changed unless theres an OTA of some sorts....theres more than likely a hash table that reliance would check against to verify...so an OTA would need to write to that table first, then make the changes....
........
Click to expand...
Click to collapse
that stuck out in bold to me..... hmmmmmm
I probably was overlooking what eMMC was, however based on the links the user gave, I later learned a little more about its potential. It would appear that HTC is doing something along the lines of the operations expressed in the link. And if they are not fully replicating efforts, it would be a shame. I like the concept of wear leveling and efficient read/writes. It would be my hope that we could integrate all those functions within a custom rom.
I found a page on the Micron site on eMMC. In the tech notes section there are informational downloads for just one chip. Specifically, the Qualcomm QSC6695
You have to register to download them. A process I have already started. Their site claims it takes a half hour to register a new account.
Once I have the PDFs, I will attach them to the OP.
I don't know if this is the chip the evo 3d is using, but if it is these may prove beneficial to have.
EDIT: Nevermind. i'd have to sign an NDA first.
EDIT: Although, this looks interesting.
Geniusdog254 said:
A lot of the security features available on the chip itself probably aren't in use. HTC has been using their own form of write protection since early last year, even on the NAND based Evo 4G. I'd stake a bet they're using the same system here, and we just need to find a way to flash the ENG bootloader like we did last year to get around it.
Click to expand...
Click to collapse
Perhaps, but a hint at the design really tells me that it would only make sense to offload this protection to the eMMC. Posted a link just a minute ago with the eMMC "enablement" model in PDF form. Interesting read...
CyWhitfield said:
I found a page on the Micron site on eMMC. In the tech notes section there are informational downloads for just one chip. Specifically, the Qualcomm QSC6695
You have to register to download them. A process I have already started. Their site claims it takes a half hour to register a new account.
Once I have the PDFs, I will attach them to the OP.
I don't know if this is the chip the evo 3d is using, but if it is these may prove beneficial to have.
EDIT: Nevermind. i'd have to sign an NDA first.
EDIT: Although, this looks interesting.
Click to expand...
Click to collapse
VERY interesting link & read for sure
CyWhitfield said:
The first part of your statement is true, Sprint knows full well that we can circumvent their attempts to charge us for WiFi tethering with root access. They have known this for years. They also know that in reality there is no way they can completely prevent someone from tethering their phone in one way or another. Even without root access. Ref: PDANet.
In my opinion, this protection of the eMMC contents was designed to reduce support costs from failed OTA updates bricking phones, and perhaps as protection against malware that can attain root, not unlike what Temp Root does.
I am not as paranoid as some here and refuse to accept that this was done specifically to thwart efforts to root the phone. The vast (and i mean VAST) majority of people who buy this phone will never even consider rooting the devices. This same majority has a subset of people that are easily stupid enough to screw up an OTA update or download and install malware.
I will take it a step further and opine that the only reason HTC is unlocking the bootloader is because we are such a minority AND that by tinkering with an unlocked device, we are actually helping HTC improve their product. They would rather have a more appealing facebook page than worry about losing a minuscule fraction of wifi tethering income.m Moreover, take a good look at where Sprint stands in the market, and what they have done recently to improve their position. They are doing a lot of really cool things, and have taken impressive steps to improve customer service and corporate image. That they would allow this bashing of HTC to continue unabated over a handful of tethering dollars is unlikely.
Click to expand...
Click to collapse
I completely agree with all of that. Other carriers have taken many steps to try to prevent wireless tethering. They've asked google to filter certain apps from the market from their customers, they've sent out letters to their customers who they suspect of tethering, they've used ECM's to try to stop it.
But Sprint...they've been remarkably silent on that front. Hell they don't even seem to plan on putting any usage caps in place. In my opinion, I suspect that Sprint wants to be different from the other carriers. They can't outright allow tethering because people would go nuts with it and it would saturate their network. Instead they have this approach of telling you that you can't do it without paying extra, but they look the other way when you do.
I don't know if I fully agree on why HTC locks the phone so tight though. I mean they really went out of their way to make sure nobody touches it. There could have been far more simple countermeasures in place to prevent malware yet still be open to somebody who has physical access to the phone.
It can't be that Sprint insisted on it being that way, otherwise Sprint would have insisted that the Nexus S be fully locked, so I don't believe that this is a carrier issue at all, at least not as far as the Evo 3D is concerned.
One of my suspicions is that HTC may make a profit off of having certain apps installed, much in the way that PC OEM's get paid to preload different apps (e.g. norton.) It could be that they want to make sure that you can't remove them. However that profit they make off of these apps may be significantly offset by having a really negative facebook page, hence the decision to unlock.
Hard to say really.
BOOTLOADER CRACKED!
EDIT:After discussing it with Mills and Blagus, I will not be publicly sharing my knowledge on how to crack the boot loader. This is only temporary until we(all r800x owners) can get a more permanent solution.
maybe another week or so before anything is solid.
UPDATE:
there is no longer a free solution for unlocking the play.
please contact blagus or yifanlu to see if they have your meid on file.
and check out the current paid solution. :/
I have attached screenshots as proof of root
If you have already specified charset manually then why set --hex-charset again?
Sent from my R800i using XDA App
Isn't this attack better served by simply generating a full list of values using CUDA and then comparing them to the RCK_H CODE Key we have? Then once we figure out which one matches, we will know what 16 character code generated it. If we can find a few matches for a few devices then we will be able to probably figure out the algorithm.
Blagus said:
If you have already specified charset manually then why set --hex-charset again?
Sent from my R800i using XDA App
Click to expand...
Click to collapse
because when you specify hex charset it sends the information as the hex it represents rather than the string of characters. it does make a difference here.
ABCDEF1234567890 Hashed as HEX
Code:
eb5f4f42e353764daad987ef5b3a5df79339b021f08e90b1f00e1e7a79b15972
versus submitting it as text
ABCDEF1234567890 hashed as text
Code:
2b749913055289cb3a5c602a17196b5437dc59bba50e986ea449012a303f7201
its subtle, but its a big change in the hashing process.
if you hash the unlock code as text you get something completely different than if you were to submit it as the HEX it represents, which is what our RCK_H code is.
Mills00013 said:
Isn't this attack better served by simply generating a full list of values using CUDA and then comparing them to the RCK_H CODE Key we have? Then once we figure out which one matches, we will know what 16 character code generated it. If we can find a few matches for a few devices then we will be able to probably figure out the algorithm.
Click to expand...
Click to collapse
Yes, you could approach the problem with that school of thought, but the file size for that much information would be well over 100 terabytes if my math is close.
as far as the algorithm goes, based on an educated guess, I think it is a MYSQL323 hashing algorithm that inputs the IMEI as Hex to produce the unlock code.I dont see how this is beneficial to us at this point though, given that verizon doesnt use IMEI for their play. Maybe worth looking into for bootloaders that are locked but can get into fastboot and SE doesnt provide an unlock code, outside of verizon of course. The path we are taking now is capable of unlocking most plays.
Good progress gentlemen. Keep up the amazing work. This device has alot of potential.
Sent from my R800x using Tapatalk
So is the goal of using oclHashCat-Lite just to compare directly against the key and continue crunching until we get a match? Meaning it wont be exporting anything at all, it will just be a crank until it hits. So some phones might get really lucky and some might get really unlucky in regards to the time frame we are looking at.
Mills00013 said:
So is the goal of using oclHashCat-Lite just to compare directly against the key and continue crunching until we get a match? Meaning it wont be exporting anything at all, it will just be a crank until it hits. So some phones might get really lucky and some might get really unlucky in regards to the time frame we are looking at.
Click to expand...
Click to collapse
Yeah, in a sense that's the Idea. Statistically speaking, you will hit 50% mark every time. But, once we have one cracked I have an idea for us CDMA guys. I am waiting to hear back from Blagus on what he thinks.
the TA is digitally signed by SE, preventing us from tampering. but if we just overwrite with a TA we know the unlock for it should work, and hopefully without bricking it, since it is a Verizon TA being overwritten.
I know one guy tried this already but messed up since it was a GSM TA overwriting a CDMA one, different file sizes and everything.
so hopefully it will be much easier once we get one down.
ashergray said:
Yeah, in a sense that's the Idea. Statistically speaking, you will hit 50% mark every time. But, once we have one cracked I have an idea for us CDMA guys. I am waiting to hear back from Blagus on what he thinks.
the TA is digitally signed by SE, preventing us from tampering. but if we just overwrite with a TA we know the unlock for it should work, and hopefully without bricking it, since it is a Verizon TA being overwritten.
I know one guy tried this already but messed up since it was a GSM TA overwriting a CDMA one, different file sizes and everything.
so hopefully it will be much easier once we get one down.
Click to expand...
Click to collapse
No, because TA contains unique phone data, like IMEI/MEID, RCK_H, etc... you can't have two phones with same IMEI/MEID, right? Also, IMEI/MEID is also stored in OTP and EROM check the two on boot - if they don't match, no booting.
I see, didnt realize that it was tied together like that. Looks like that idea is nixed. Did a prelimanary run on my 3ghz dual core and 8800gt it said almost 70 days before it goes through the full list. Still doing some small scale runs and waiting on atom at hashcat for some help.
The guy who bricked his play was me... So i know all about how finicky that part of the phone can be. I would love to dedicate some cycles to cracking this thing. Realistically seventy days is not that bad. Certainly doesn't hurt to get the ball rolling and if we get a result before SE officially released the method, then we are ahead of the curve.
We could also do this as a team effort. Meaning if we took one person's key and everyone took a certain chunk and tried just those. If we had 7 people try it we would have a crack in ten days....
Also I'd love to give the same script a go if you got the command worked out already. I've got an 8 core i7 with a Quaddro FX800 card. This thing is more suited to crunch proteins in my lab but i think it could do well for it to take a few days and crack some code.
Sent from my R800x using XDA App
Mills00013 said:
The guy who bricked his play was me... So i know all about how finicky that part of the phone can be. I would love to dedicate some cycles to cracking this thing. Realistically seventy days is not that bad. Certainly doesn't hurt to get the ball rolling and if we get a result before SE officially released the method, then we are ahead of the curve.
We could also do this as a team effort. Meaning if we took one person's key and everyone took a certain chunk and tried just those. If we had 7 people try it we would have a crack in ten days....
Also I'd love to give the same script a go if you got the command worked out already. I've got an 8 core i7 with a Quaddro FX800 card. This thing is more suited to crunch proteins in my lab but i think it could do well for it to take a few days and crack some code.
Sent from my R800x using XDA App
Click to expand...
Click to collapse
ok download oclHashCat-lite if you havent already. v06 is what i am running on.
cmd line to the directory.
ok now for the ugly part
copy and paste this in
Code:
cudaHashcat-lite32.exe -m 1400 -d 1 --hex-charset -1 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f202122232425262728292a2b2c2d2e2f303132333435363738393a3b3c3d3e3f404142434445464748494a4b4c4d4e4f505152535455565758595a5b5c5d5e5f606162636465666768696a6b6c6d6e6f707172737475767778797a7b7c7d7e7f808182838485868788898a8b8c8d8e8f909192939495969798999a9b9c9d9e9fa0a1a2a3a4a5a6a7a8a9aaabacadaeafb0b1b2b3b4b5b6b7b8b9babbbcbdbebfc0c1c2c3c4c5c6c7c8c9cacbcccdcecfd0d1d2d3d4d5d6d7d8d9dadbdcdddedfe0e1e2e3e4e5e6e7e8e9eaebecedeeeff0f1f2f3f4f5f6f7f8f9fafbfcfdfeff d43e7744a1156d72fd434cb4a98ba1cb280028b507c315f708e7edefb8e421ac ?1?1?1?1?1?1?1?1 --outfile-format=1 --outfile=out.txt
just like I have it
let me know what you get
It is a bit messy, but because of certain limitations I had to create the massive 512 character set to get everything kosher.
it worked alright on smaller scale
It's by no means perfect, but it should do the trick.
btw make sure you have the latest cuda drivers installed.
Has anyone tried:
1. Backing up the TA
2. Editing the RCK_H code to a known code.
(For example: Edit to: eb5f4f42e353764daad987ef5b3a5df79339b021f08e90b1f00e1e7a79b15972
So your code will be: ABCDEF1234567890)
3. Restore the TA
4. Your TA will now be the exact same thing it was but with the new RCK_H code.
5. Use fastboot to unlock your bootloader with the code: ABCDEF1234567890
hatcyl said:
Has anyone tried:
1. Backing up the TA
2. Editing the RCK_H code to a known code.
(For example: Edit to: eb5f4f42e353764daad987ef5b3a5df79339b021f08e90b1f00e1e7a79b15972
So your code will be: ABCDEF1234567890)
3. Restore the TA
4. Your TA will now be the exact same thing it was but with the new RCK_H code.
5. Use fastboot to unlock your bootloader with the code: ABCDEF1234567890
Click to expand...
Click to collapse
It'll brick your radio. You can't modify it because it's hashed and checked at boot.
If it was so easy it would be already done.
If you need processing power, I could offer 16 cores with 12 gig of ram
Sent from my HTC Sensation Z710e using XDA App
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.
edit: another way to approach this would be to use the entire ASCII table instead of the charset I created above, and remove the --hex-charset flag, but you still have the same number of possible combos since ASCII directly relates to Hex from 0x00 to 0xFF. so the problem still remains.
we could create a table with all possible hex combos but that is 67108864 terabytes of storage which is pretty unfeasible at this point. so we will most likely have to stick with brute forcing it, or implementing a 2nd init.
edit2: possible work around found. Thanks to something Atom said I may have figured it out. someone created a distributed oclhashcat-lite gui that is capable of distributed cracking using software called drop box.
all we need are a lot of desktops running the same hash and all that gets changed is the 8th digit of the mask to 00 to ff
so its not perfect, and pretty unlikely that we will get it in the next few weeks at this rate.
Idea
okay so let's brain storm a bit
1.)on GSM plays the 14 digit IMEI is input on the SE website for unlock code
2.)unlock code is an unknown hash algorithm (possibly a mysql)
3.)which is then fed in as the hex it represents to unlock the bootloader by checking it with the RCK_H hash code
but what about CDMA which uses an MEID (ie. A1000XXXXXXXXX) how are the RCK_H codes generated if they don't have an IMEI.
so, perhaps another way of approaching this would be to figure out the hashing algorithm for the GSM plays and figure out a way to exploit it for our MEIDs.
anyone else see any benefit to doing it this way? it would be much quicker if we could understand the process it goes to from 14 digit meid to RCK_H.
if brute forcing it seems to be too much we may have to resort to reverse engineering the hashing algorithm.
That was essentially what I was proposing in the general thread. I think that method will be the most robust that will produce the best results. Its a daunting task, but not impossible, and definitely will be able to be accomplished in less than 82 thousand years of brute forcing.
ashergray said:
after speaking with Atom the developer of Hashcat I found out that it would take close to 82 thousand years to crack this.
Click to expand...
Click to collapse
That sucks! I'll probably have a new phone by then...
Thanks for all the work, keep it up!
crono141 said:
That was essentially what I was proposing in the general thread. I think that method will be the most robust that will produce the best results. Its a daunting task, but not impossible, and definitely will be able to be accomplished in less than 82 thousand years of brute forcing.
Click to expand...
Click to collapse
I thought a few people had mentioned it before.
But what I am worried about is if it isnt a standard 64bit hash algorithm and it is a larger truncated one.
I'm new to the forums, but I've been keeping an eye on the X2 bootloader issue for a while and haven't seen this suggestion come up yet, so I thought I'd give it a try. Is there a way we could use distributive processing to crack the bootloader? It would take years for a single computer to crack it, but if we got a few hundred or thousand people to download a program that worked at it, would it be possible to unlock it that way?
I'm not the best with this kind of stuff so I don't have a clue if this would actually work, but if it would, it might be a good way to solve our problems.
Does anyone know if this is possible? Has anyone attempted to write a program like this before?
wcsoccerboy828 said:
I'm new to the forums, but I've been keeping an eye on the X2 bootloader issue for a while and haven't seen this suggestion come up yet, so I thought I'd give it a try. Is there a way we could use distributive processing to crack the bootloader? It would take years for a single computer to crack it, but if we got a few hundred or thousand people to download a program that worked at it, would it be possible to unlock it that way?
I'm not the best with this kind of stuff so I don't have a clue if this would actually work, but if it would, it might be a good way to solve our problems.
Does anyone know if this is possible? Has anyone attempted to write a program like this before?
Click to expand...
Click to collapse
although it may be possible it would still take awhile to not only run the program but to also write the program. plus all of the computers would have to be linked somehow so that they worked on seperate parts/ not work on finished part. it can be a PLAUSIBLE idea though if moto is gunna be douches for a while to come -___-
I posted this same question not long ago in a similar this forum. Look for the one that says "bootloader question not an unlock."
Sent from my MB870 using XDA App
The only way this is going to have an ounce of a chance of happening is, we need to keep hounding both Motorola and Verizon.
Bombard their support with calls/emails, demanding to unlock the bootloader and release an ICS upgrade for the X2.
I've emailed Motorola support at least 20 times now, constantly explaining my position. The next step is to call them as well.
Please remember, BE CIVIL! Do not get belligerent, nasty and avoid cursing. Keep the email/call tactful because being immature about it won't help you. Explain your position and why you feel that what they are doing is not right and that as a consumer, you demand support for a phone that is not even a year old, but appears to have been all but abandoned by the company.
No developer is throwing us a bone. At least, I'm not holding out hope on that one.
Oh, and by "developer" I mean those at Motorola. The devs releasing ROMs are throwing us more than a bone and they are a godsend compared to what Motorola and Verizon are doing.
http://forum.xda-developers.com/showpost.php?p=22224030&postcount=4
Sadly it isn't so easy. Believe me, were it so easy, there would be a lot more unlocked bootloaders. Not a bad idea, but in practice, its just not practical.
---------- Post added at 07:17 AM ---------- Previous post was at 07:16 AM ----------
iBolski said:
The only way this is going to have an ounce of a chance of happening is, we need to keep hounding both Motorola and Verizon.
Bombard their support with calls/emails, demanding to unlock the bootloader and release and ICS upgrade for the X2.
I've emailed Motorola support at least 20 times now, constantly explaining my position. The next step is to call them as well.
Please remember, BE CIVIL! Do not get belligerent, nasty and avoid cursing. Keep the email/call tactful because being immature about it won't help you. Explain your position and why you feel that what they are doing is not right and that as a consumer, you demand support for a phone that is not even a year old, but appears to have been all but abandoned by the company.
No developer is throwing us a bone. At least, I'm not holding out hope on that one.
Click to expand...
Click to collapse
At this point, this may realistically be our only option. I'm game.
Hey all,
I've been a lurker for a while, been looking for a way to encourage the now Google-owned Motorola Mobility to unlock their bootloaders much like HTC has wisely done, but it's becoming more and more obvious to me that they don't care about the "minority" of us that actually feels as though we are entitled to full admin rights on our phones that we either paid a ton of cash for, or signed a lengthy contract to obtain. Verizon is the one blocking it? HTC found a way, and so can Motorola Mobility...that is cop-out.
My proposal is that there be an effort to unlocked the bootloader, I am not some expert programmer, and I am open to whatever will help the cause. I know there was a bounty on it, but to me this isn't about money, I'll donate time, money, information ripped from my phone if it, in some way, contributes to unlocked that bootloader. Even if you need my unused CPU cycles to calculate things, I don't care, just tell me what I can to do help, because I am sick of not being able to use my phone to it's fully potential.
Maybe I am being naive, but I believe if we all worked together we could accomplish this goal. If you agree, please, let's organize and figure this out!
-Joshua
I love optimism
I'm down with the movement...
This phone does have mad potential to be so limited compared to other phones.
I just can't believe that we are running an unofficial, incomplete version of CM7 and it runs smoother than stock Blur.
Is that telling you something about Motorola?
Do you guys think Google will make that decision for Motorola or will Moto stay the same?
Sent from my Android
Worth a try...
Re: Google changing Moto policy
I don't know so much about Google changing Motorola's stance on the locked bootloader, we've tried petitioning the company themselves, but have we tried petitioning Google? Or maybe it's too soon, maybe they are working on it right now? Hard to tell, and I don't want to put pressure on Google too soon especially if they are trying diligently right now to do the right thing.
But the above poster is right, cracking it ourselves is definitely worth a try. I have contacts (unfortunately know inside Motorola), I know people with lots of knowledge on encryption, I'll be honest one of my friends does have a knack for the impossible, but this would be too much for one lone person. I also have a few computers in the house, to donate computing power. None above 5 GB of RAM unfortunately, but my friend with all of that know-how does also have a synchronous 20/mbit up/down connection to the net, if that helps, and I have another friend that is the linux admin at a an unnamed private university in Durham that might could lend a hand in some way.
We have the resources, we just need to pool them.
Someone with the realistic technical know-how, just tell us where to begin, and the shortest path to getting to our goal and we'll do all we can to contribute!
Thanks for understanding and not just writing this off as a pipe-dream...because I know if we work together we can accomplish almost anything.
-Joshua
spyda256 said:
I don't know so much about Google changing Motorola's stance on the locked bootloader, we've tried petitioning the company themselves, but have we tried petitioning Google? Or maybe it's too soon, maybe they are working on it right now? Hard to tell, and I don't want to put pressure on Google too soon especially if they are trying diligently right now to do the right thing.
But the above poster is right, cracking it ourselves is definitely worth a try. I have contacts (unfortunately know inside Motorola), I know people with lots of knowledge on encryption, I'll be honest one of my friends does have a knack for the impossible, but this would be too much for one lone person. I also have a few computers in the house, to donate computing power. None above 5 GB of RAM unfortunately, but my friend with all of that know-how does also have a synchronous 20/mbit up/down connection to the net, if that helps, and I have another friend that is the linux admin at a an unnamed private university in Durham that might could lend a hand in some way.
We have the resources, we just need to pool them.
Someone with the realistic technical know-how, just tell us where to begin, and the shortest path to getting to our goal and we'll do all we can to contribute!
Thanks for understanding and not just writing this off as a pipe-dream...because I know if we work together we can accomplish almost anything.
-Joshua
Click to expand...
Click to collapse
i love your optimism i have some old pms that may help with the effort
SHA-1 brute force can be cracked for around $2 of Amazon cloud computing service.
http://www.geek.com/articles/news/r...for-2-10-with-amazons-cloud-service-20101122/
Isn't boot loader use SHA-1 encryption?
(of course, the key may be much longer, but it may not be impossible for cheap. I say try to pool together like $100 and try Amazon cloud computing a try?)
Re: Amazon
hpark21:
I like the way you're thinking, does anyone else think this might be a good call? I know there was a bounty of around ~$800 somewhere, so I doubt if all of us who rightfully were promised and unlocked bootloader wouldn't mind pooling a bit of money for the computing power, hell I myself would give $50 to the effort if we knew it was a viable solution.
Other thoughts?
Also, ztotherad, if you could send me those PMs maybe we can sift through those and see if there are some other avenues, nothing is off the table at this point.
thanks again for coming together on this, that is the true meaning of community.
spyda256 said:
hpark21:
I like the way you're thinking, does anyone else think this might be a good call? I know there was a bounty of around ~$800 somewhere, so I doubt if all of us who rightfully were promised and unlocked bootloader wouldn't mind pooling a bit of money for the computing power, hell I myself would give $50 to the effort if we knew it was a viable solution.
Other thoughts?
Also, ztotherad, if you could send me those PMs maybe we can sift through those and see if there are some other avenues, nothing is off the table at this point.
thanks again for coming together on this, that is the true meaning of community.
Click to expand...
Click to collapse
i can def send you them, idk how much help theyll be
Uh, I think it's already been established that brute forcing it is impossible.
Stuckinabox said:
Uh, I think it's already been established that brute forcing it is impossible.
Click to expand...
Click to collapse
In one of the many threads concerning bootloader unlocks, I believe the chances of us finding it were determined to be 1mill:1. It would take us over a decade to manually come up with the key. I don't want to kill confidence, but I'd like to keep things relatively rational.
Sent from my MB870 using xda premium
Stuckinabox said:
Uh, I think it's already been established that brute forcing it is impossible.
Click to expand...
Click to collapse
it's been established that brute forcing is nearly impossible, not completely impossible
it is something that would take an insane amount of resources to accomplish , and/or time ,
it would really come down to "how lucky are we?" really, as in::: how lucky are we that we stumble across or know a genius that can crack it, stumble across needed files, etc...
good luck to all who try, I wish I could do anything to get us there, but I don't know the first thing when it comes to this stuff, don't give up the dream!
Basically, what it comes down to is:
Find out what their hash key is. (encrypted password)
Then, try to go through all valid characters and see whether the input matches the output hash.
If one is lucky and they used short enough password, then it will be quick to find.
If unlucky and they used really long password, then the answer is that we won't be able to find it in REASONABLE time. (I would say 1-2 months to be reasonable - at $2/hr, it would cost $48/ day).
Only issue is when do we stop?
hpark21 said:
Basically, what it comes down to is:
Find out what their hash key is. (encrypted password)
Then, try to go through all valid characters and see whether the input matches the output hash.
If one is lucky and they used short enough password, then it will be quick to find.
If unlucky and they used really long password, then the answer is that we won't be able to find it in REASONABLE time. (I would say 1-2 months to be reasonable - at $2/hr, it would cost $48/ day).
Only issue is when do we stop?
Click to expand...
Click to collapse
There was some kind of crazy algorithm applied to each character to generate the correct item for each number of the key, correct? We would have to come up with that too?
Sent from my MB870 using xda premium
THANK YOU! Finally ... a revived movement. I pledged $100 on another thread and I'm good for putting it toward an unlocked bootloader again!
To learn from one of the most influential groups of our generation ... anonymous utilizes botnets to pool computing resources ... if we get a tool that could function similarly, could we not pool 1000s of computers together to crack it faster? It would make what is not feasible for a small set of computers to do... feasible. If all most users have to do is download a tool that gives us access to processing power and bandwidth ... users will download the hell out of it.
Count me in.
[ sent from _base2 ]
Hope
I understand doubters, and odds are likely against us, but that's ok, no one person can do it, and maybe not just one method, but somehow we WILL get to our goal. Whether Motorola capitulates or we find a method to crack it, we will not have this awesome hardware go to waste.
I am not generally a "black hat" kind of person, but in this case we are in the right so far as I am concerned (please don't quote DMCA BS to me, lol) because they made a promise to their customers, and it will be kept, whether they like it or not.
So, I am with the above poster that mention he didn't know quite where to start, or where we have already made progress, but if someone can help us out, explain the process, we figure out how to move forward. (Please forgive the run-on sentence).
I've minimal experience programming, only VB.net, C++, and a bit of Java from college, and I do tier 2 desktop support for a bank these days, but on my off time I'd love to spend it on something worthwhile, all of you deserve this, and we'll make it happen.
Maybe it's the troubleshooter in me that sees the problem and says "oh no, there's a way, we just need to find it". I have a colleague, the one I spoke of before, he has a knack for doing incredible things, so once we have a breakdown of what we need to do, perhaps he can be of help.
So my friends, where do we go from here?
spyda256 said:
I understand doubters, and odds are likely against us, but that's ok, no one person can do it, and maybe not just one method, but somehow we WILL get to our goal. Whether Motorola capitulates or we find a method to crack it, we will not have this awesome hardware go to waste.
I am not generally a "black hat" kind of person, but in this case we are in the right so far as I am concerned (please don't quote DMCA BS to me, lol) because they made a promise to their customers, and it will be kept, whether they like it or not.
So, I am with the above poster that mention he didn't know quite where to start, or where we have already made progress, but if someone can help us out, explain the process, we figure out how to move forward. (Please forgive the run-on sentence).
I've minimal experience programming, only VB.net, C++, and a bit of Java from college, and I do tier 2 desktop support for a bank these days, but on my off time I'd love to spend it on something worthwhile, all of you deserve this, and we'll make it happen.
Maybe it's the troubleshooter in me that sees the problem and says "oh no, there's a way, we just need to find it". I have a colleague, the one I spoke of before, he has a knack for doing incredible things, so once we have a breakdown of what we need to do, perhaps he can be of help.
So my friends, where do we go from here?
Click to expand...
Click to collapse
sir, did you get my pms?
Re: PMs
Nope, just saw them, thanks for that!