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 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.
OK, so I've had Android since the G1, then the Vibrant and now the SGS2 so I'm familiar with flashing and rooting and all that good stuff but some of the basics elude me...
I'm not a coder, programmer or modder in any way, shape or form. Nor do I claim to be.
Here's my question. Google writes the source code for the Android OS, then releases it to manufacturers to add their bloat/spin (TouchWiz, Sense, etc). If the underlying code is the same, why is it not easier to take the original source code and flash it on any phone?
I'll use Windows as an example here:
If I buy a PC with Windows Home Premium on it from HP, I'll get all of the extra bloat that HP puts on the machine to "enhance" my experience. However, if I decide to, I can format (or flash) my PC and install a "clean" version of Windows (direct from Microsoft) on it direct from CD or DVD. Doesn't matter if I format and install on an HP, Dell, Gateway, Acer, etc. because the source code is same. Aside from a couple of driver issues, on first boot, everything works.
Why is it not the same for Android on the phones? Is getting the code for the drivers what holds us back?
The other bonus is that even if something goes wrong, since I essentially rooted my PC (I removed what was originally installed on the PC and put the original source code on it) I can still send it in to get repaired to HP or Gateway or Dell. I can't do that with a phone. If I root my phone, my warranty is void. Even if the hardware is defective.
Windows has a "minimum hardware requirements" that a PC must meet in order to run Windows.
Why would Google not have a similar requirement? "A phone must have these specs to run Android."
I understand that Sense, TouchWiz, etc will add bloat to the interface but (and maybe I'm naive here) it shouldn't be that hard to get back to the source code on the phones, should it?
Help me. I don't understand. Again, I'm not a coder, programmer or modder in any way, shape or form. I root my phone(s) and try to get as close to the original source code as I can but I rely on smarter people to get me there. Granted I could buy a Nexus device and not have to worry about it. However, that just goes to further emphasis my question; Google pushes original source code out to the Galaxy Nexus, Nexus One, Nexus S. So why is it not easier to get that same source code on other phones?
Thanks in advance...
-Steve
The reason you void your warranty with rooting is simply because that's what you agree to when you purchase it. Just something that carriers/manufacturers have gone with and we as consumers haven't fought it. Realistically it might be something that could be addressed in court or through the FCC. If you buy a car and modify it, if something fails unless the dealership can prove that your modification caused the failure they still have to cover the repair under warranty. That said, for now the majority accept it and the majority still do not root and such so it's accepted. Perhaps as more people become aware of what can be done with their phones, especially if companies start using apps like Tasker to increase efficiency of their corporate devices, there's the possibility that this will change.
Buying an Android device, the warranty covers the system installation. Buying a PC, it does not.
The reason you void your warranty with rooting is simply because that's what you agree to when you purchase it. Just something that carriers/manufacturers have gone with and we as consumers haven't fought it. Realistically it might be something that could be addressed in court or through the FCC. If you buy a car and modify it, if something fails unless the dealership can prove that your modification caused the failure they still have to cover the repair under warranty. That said, for now the majority accept it and the majority still do not root and such so it's accepted. Perhaps as more people become aware of what can be done with their phones, especially if companies start using apps like Tasker to increase efficiency of their corporate devices, there's the possibility that this will change.
kuisma said:
Buying an Android device, the warranty covers the system installation. Buying a PC, it does not.
Click to expand...
Click to collapse
I appreciate the feedback and I get the analogies, however, my original question remains unanswered:
Why is it so difficult to get the original source code onto any android device? Is it drivers? Manufacturer incompatibility?
I'd be interested to learn the process (just a general overview and hopefully in English) it takes to port the original source code onto multiple devices.
Thanks again...
-Steve
brisseau said:
Why is it so difficult to get the original source code onto any android device? Is it drivers? Manufacturer incompatibility?
Click to expand...
Click to collapse
Hardware manufacturers develops specific hardware suitable for their devices, requiring special drivers and/or kernel modifications.
The radio code is not a part of the Android OS, and only the Radio Interface Layer (RIL) must conform to the Android API specs.
Hardware manufacturers are free to vary installation parameters such as what disk types to use (mmc, mtd), sizing of partitions to best utilise the available space, etc.
I have a Moto E (1st gen) lying around. It's not on any network. It used to be on a carrier (forgot name) that got acquired by Tracfone. I use it only on wifi. Use google voice to use it as a home phone and an app called Automateit to do a lot of useful things. So, the phone is still useful. Very good battery capacity (still goes strong for 2-3 days on a single charge).
It has a stock 4.4.4 android, which is incompatible with most new apps. Looking to install Lineage 15.1 or newer, but I got stuck while trying to unlock the bootloader, as this is an ineligible phone for bootloader unlocking. I spend few hours trying to read up on any hacks that someone might have figured out to unlock the bootloader. Most answers that I saw was that this cannot be done.
It is a shame to throw away any resource that still holds value. We, as a society, have a tendency to keep on accruing newer things, while we are fully capable to extending the useful lives of existing things. I know that I can probably buy a newer phone. On principle, I want to see if I can upgrade the os on this phone and keep using it. For that, I need to unlock the bootloader first.
Has anyone figured out how to jailbreak the bootloader on XT830c yet? If so, can you point me to the post (which I might have missed)?
I am willing to spend some free time on this if I can get some guidance from the experts. I have teeny bit understanding of assembly language and I learn fast. I might know some machine learning too. I am thinking, if I can get as many examples of the oem_unlock_data (the long 5 line output from fastboot) and the unique codes that Motorola sends to eligible phones to unlock the bootloader, I can try to reverse engineer the encryption key to generate the unique code for even ineligible phones, making it work for all Motorola phones.
If I have a large enough sample, maybe a machine learning algorithm can be useful too. Since bootloader encryption is a tough topic, not many people might have ventured in to this. It is definitely gibberish to most people. Therefore, it is safe to assume that Motorola has let their guard down and might have used the same encryption key on (atleast) most of the older phones.
For this reverse engineering to work, I need a large number of samples. I need,
1) the 5-line oem_unlock_ data from fastboot.
2) the unique code send out from Motorola bootloader website after entering the long string in.
Appreciate all the help from the xda community.... share the knowledge and empower the common man...
greenlantern2014 said:
I have a Moto E (1st gen) lying around. It's not on any network. It used to be on a carrier (forgot name) that got acquired by Tracfone. I use it only on wifi. Use google voice to use it as a home phone and an app called Automateit to do a lot of useful things. So, the phone is still useful. Very good battery capacity (still goes strong for 2-3 days on a single charge).
It has a stock 4.4.4 android, which is incompatible with most new apps. Looking to install Lineage 15.1 or newer, but I got stuck while trying to unlock the bootloader, as this is an ineligible phone for bootloader unlocking. I spend few hours trying to read up on any hacks that someone might have figured out to unlock the bootloader. Most answers that I saw was that this cannot be done.
It is a shame to throw away any resource that still holds value. We, as a society, have a tendency to keep on accruing newer things, while we are fully capable to extending the useful lives of existing things. I know that I can probably buy a newer phone. On principle, I want to see if I can upgrade the os on this phone and keep using it. For that, I need to unlock the bootloader first.
Has anyone figured out how to jailbreak the bootloader on XT830c yet? If so, can you point me to the post (which I might have missed)?
I am willing to spend some free time on this if I can get some guidance from the experts. I have teeny bit understanding of assembly language and I learn fast. I might know some machine learning too. I am thinking, if I can get as many examples of the oem_unlock_data (the long 5 line output from fastboot) and the unique codes that Motorola sends to eligible phones to unlock the bootloader, I can try to reverse engineer the encryption key to generate the unique code for even ineligible phones, making it work for all Motorola phones.
If I have a large enough sample, maybe a machine learning algorithm can be useful too. Since bootloader encryption is a tough topic, not many people might have ventured in to this. It is definitely gibberish to most people. Therefore, it is safe to assume that Motorola has let their guard down and might have used the same encryption key on (atleast) most of the older phones.
For this reverse engineering to work, I need a large number of samples. I need,
1) the 5-line oem_unlock_ data from fastboot.
2) the unique code send out from Motorola bootloader website after entering the long string in.
Appreciate all the help from the xda community.... share the knowledge and empower the common man...
Click to expand...
Click to collapse
I know I have the 5-line oem data and the unique code from 2 Moto E XT1021, but I must find them first (they're somewhere in my backup hard disk) but since this is an older phone I doubt you will get too much help. At least I've been trying to contact any XT1021 user (to try to recover this phone since is bricked) for almost 2 years without any luck, no one in this forum seems to be using the Moto E 1st gen anymore. Your only hope is people with the Moto e XT1022 (which had more users due to its market target), but viewing the lack of activity in this forum I can tell you it will be very hard to get help, which its a shame, because if somehow you manage to reverse engenieer the bootloader ecryption key it will be very usefull for other Motorola devices that cannot be unlocked throught the Moto website.
@nickleby, thank you for your offer to help. I should have been clearer in the op that even data from other similar models will be useful too. While doing my research on this, I didn't see many XT830C users. But there were many users of XT1021. If I can get a large sample of data from as many of XT1021 users, that will suffice too.
greenlantern2014 said:
@nickleby, thank you for your offer to help. I should have been clearer in the op that even data from other similar models will be useful too. While doing my research on this, I didn't see many XT830C users. But there were many users of XT1021. If I can get a large sample of data from as many of XT1021 users, that will suffice too.
Click to expand...
Click to collapse
You'll only get those code lines from XT10xx users, I don't think any XT830C is elegible for unlocking the bootloader at the Motorola website. I'll send you my codes by pm.
nickleby said:
You'll only get those code lines from XT10xx users, I don't think any XT830C is elegible for unlocking the bootloader at the Motorola website. I'll send you my codes by pm.
Click to expand...
Click to collapse
Can u tell me how to network unlock the Motorola xt830c? Please
Hello,
I don't know if you have seen this link: https://forum.xda-developers.com/showthread.php?t=2755857
I hope it help you
LS
1) phoneSN: IMEI with last 5 pairs of digits swapped so IMEI of 123456789123456 converts to 1A23457698214365 (see fastbootConvert)
2) (not used by verifyPhone POST) ASCIIZ serial# and model
3) phoneHash
4) phonePUID (also from 'fastboot getvar uid' command)
phoneSN 64 bits
phoneHash 160 bits
phonePUID 40 bits
Total 264 bits
ABCDEFGHIJKLMNOPQRSTUVWXYZ234567 5 bits * 20 chars = 100 bits unlock code
1A23457698214365
5441383930304242443700585431303332000000 TA8900BBD7[0]XT1032
140A858731D55F3B5DF78F0F6BB9EAE32A2B8945
3D372B020F0000000000000000000000
-> W4ZUEO2TZALOGJJWPRMO
3A45890085904167
54413838333041324D5A00585431303332000000 TA8830A2MZ[0]XT1032
5D0E47A39BBB9DA7B9632E8C19BD2873B018B7BA
C2FDC7010F0000000000000000000000
-> KAYG2LJBKENAFTW2VTJE
3A55000805631104
54413931393030364F4A00585431303334000000 TA919006OJ[0]XT1034
FF1E8DC44A01DC00C5CA53DB553418873A750D1C
5FABFE010F0000000000000000000000
-> BEXHELCKBBJZKZ5GYUWE
3A55000495481029
5441393333303054504C00585431303333000000 TA93300TPL[0]XT1033
68A78DB5876D57028D521650859379865F072507
AD2E37020F0000000000000000000000
-> MRA23VVVTUQSVHUWQ6BC
3A95030785674464
5441393239305249594D00585431303332000000 TA9290RIYM[0]XT1032
3B36049E202479A93483375131B58A8051435A35
6ACCA0030F0000000000000000000000
-> O4HIGKGEIDJNOYLCGCMF
3A45210407360617
5A59323233434338394D004D6F746F2047200000 ZY223CC89M[0]Moto G [0]
9FE785BCB7BB69DF44FD4B308E4F2B5680100755
E07A1301000000000000000000000000
-> 6MSWCW52YHNYJG2JFOBJ
9900054679155800
54413039383030384C4100585431353236000000 TA098008LA[0]XT1526
1C199BFBEE304D78A540F1ECA9FC127F622BCA12
313A2A04000000000000000000000000
-> BKFQFGNWFDGG3KJRWEMI
3A95130205739271
5A58314236323339535800585431303235000000 ZX1B6239SX[0]XT1025
E6E955680B50A5BBFD48CE5FBC163852F4B3B01A
EF75DF03120000000000000000000000
-> QI3AEKXAEPB3JDNNCEVN
3A55000705233318
5441383830303038485300585431303334000000 TA880008HS[0]XT1034
BE53E38F5A7950E3443C815717626E293C782CA7
A8CC19020F0000000000000000000000
-> EKQDM2GUDTDB4YKKAWPR
9900050917037800#
5441393931323037435800585431303933000000# TA991207CX[0]XT1093
B2665F8E98B351F7B72BCEAB5D38817B8165F0E1#
021A66120B0000000000000000000000
-> HKLORD7BGTQL7HYHZSJN
9900054648011700#
5441303938304E57585300585431353236000000# TA0980NWXS[0]XT1526
047D707D8F8024C179D1CDFD1DE0793FD5BC4633#
9AB1F909000000000000000000000000
-> 6KULMXGH3UCAI3Q4NPF4
Where is verification routine in phone? Aboot?
code has SSL X5099 certs SHA1, SHA256 routines,
public, private RSA keys?
certBuffer in certificate.c
All I was looking for is what file on the phone contains ALL the contacts information, ie name and 10 digit phone #.
I downloaded the Trac_CDMA_XT830C_4.4.4_KXC21....file, Then I looked for a .DAT file that was readable or that indicated phone numbers.
I didn't find any.
Will I have to create an xls file and copy all my contacts, one at a time to that file?
I'm planning on getting a new phone that may be a locked Android using AT&T service.
When my XT830C phone is transferred, does the contact info/file get transferred as well?
Thank you for your help.