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.
Related
I'm just curious. I heard a lot of talk about cracking the bootloader or asking SE to open it. But if it is cracked or open, how much easier would it be to develop custom rom to it (not a dev), would we be seing 2.2 or even 2.3 quickly ported to our phone?
It would be mich easier to port coz we can make custom kernels now we need to build the os on se kernel and that is alot harder then make 2.3 on a 2.3 kernel insted of 2.3 on a 2.1.1 kernel
Sent from my U20i using XDA App
I see, thx.
What did SE says about open the bootloader?
And is it actually anybody as are working with cracking the bootloader to the mini/pro?
Sent from my U20i using Tapatalk
i post to their facebook group twice, not expecting a reply and yet they reply on the second post saying that he will forward this to the development team which I translate into I don't know what the hell is a bootloader and I'm just going to forward you to the development team email which the might read a year from now....
On other unrelated note, I don't see any attempt to break the mini or mini pro bootloader but I just came back from the big x 10 forum and see 2 attempt in breaking the bootloader
first traditional bootloader cracking but it's going slow, very slow
An attempt to bruteforce the 1024 bit RSA password by using the combined proccessor power of the community. Don't get your hope up though, it stll hasn't begin (many has volunteer their PCs) becase some of the exprienced people (science engineer) say that it is impossible right now as it will take millions of year to completely bruteforce it.
Divr said:
i post to their facebook group twice, not expecting a reply and yet they reply on the second post saying that he will forward this to the development team which I translate into I don't know what the hell is a bootloader and I'm just going to forward you to the development team email which the might read a year from now....
On other unrelated note, I don't see any attempt to break the mini or mini pro bootloader but I just came back from the big x 10 forum and see 2 attempt in breaking the bootloader
first traditional bootloader cracking but it's going slow, very slow
An attempt to bruteforce the 1024 bit RSA password by using the combined proccessor power of the community. Don't get your hope up though, it stll hasn't begin (many has volunteer their PCs) becase some of the exprienced people (science engineer) say that it is impossible right now as it will take millions of year to completely bruteforce it.
Click to expand...
Click to collapse
what?? let's use hacked ps3s!!! it will be easy as hell with their processing power!
Sent from my E10i using XDA App
ha no mate, its not that easy, brute forcing it the way they are trying is basically getting a program to guess a number that; along with a number of there choice, is put into an equation, gives them another number, this number is then put into another equation and should give back the original number of that they chose. If this didnt work then they go onto another number.
The maths says basically a computer has to check 2^1024 keys. Some people say that a £10 million machine it would take about 7 years to crack it
ha no mate, its not that easy, brute forcing it the way they are trying is basically getting a program to guess a number that; along with a number of there choice, is put into an equation, gives them another number, this number is then put into another equation and should give back the original number of that they chose. If this didnt work then they go onto another number.
The maths says basically a computer has to check 2^1024 keys. Some people say that a £10 million machine it would take about 7 years to crack it
Click to expand...
Click to collapse
uh. i understand now Oo.
Sent from my E10i using XDA App
Beside from what I gather from the post,the RSA code need to have a weakness for it to be succesfully bruteforce in reasonable time. It's the case with PS3 which the RSA code has a weakness and a developer took advantage of that.
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.
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.
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!
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.